Can AI Produce Authentic Python, Django and React.js Code?
The Original Question Still Stands
Can AI produce authentic code? I asked that question when I’d been using Claude Code for a month. I’m asking it again after twelve months, 26 years of web development behind me, and over 2,700 commits in the repository. I now run three revenue streams from a terminal — client services, ecommerce properties, and a domain portfolio — all on infrastructure I built with Claude Code, which started by nearly burning my codebase to the ground.
The answer is still yes. But the real answer is more interesting than that.
The code isn’t authentic because the model is clever. It’s authentic because the infrastructure behind it has been corrected, tested, and refined across twelve months of daily use.When I first wrote this piece, I talked about “vibe coding” and a three-document system I’d invented to keep the model on track. That system worked. It was also scaffolding — the temporary structure you build so the real building can take shape. Here’s what the building looks like.
What I Got Right the First Time
The core insight hasn’t changed: the real skill isn’t coding. It’s communication.
I wrote that when I had four weeks of evidence. Twelve months have only made it more true. The model builds exactly what you tell it to build, not what you think you told it to build. That gap between intention and instruction is where every AI project goes wrong. I wrote about this early on in when the algorithm comes for your business — that AI doesn’t replace expertise, it amplifies it. That’s held up.
What changed is my understanding of what “communication” actually means in this context.
June 2025: I was writing three planning documents before each coding session — planning.md, task.md, and roadmap.md. Manual, per-project, started from scratch every time. It worked, and it taught me the discipline of writing clear instructions.
March 2026: Those three documents evolved into an operating system. The business rules, the voice, the principles, the client context, and the operational state — all of it loads automatically when I start a session. The model doesn’t need a planning document because it already knows the plan. It’s been corrected thousands of times, and every correction compounds into something the next session inherits.
The difference isn’t sophistication. It’s accumulation. Twelve months of showing up and doing the work left residue that became the foundation.
What Changed Everything
The original article described a workflow where I’d upload documents to ChatGPT or Claude and hope the model remembered them by message fifty. I had a rule: start a fresh conversation for every new feature, because after fifty messages the model starts contradicting itself.
That was the best I could do at the time. It was also a sign that the real problem wasn’t the model’s memory — it was the absence of infrastructure.
I now work in Claude Code, which reads my entire codebase, understands how files connect, and makes changes across the whole project simultaneously. When I change a Django API endpoint, it updates the frontend calls that depend on it. When I add a new client to the database, it knows the folder structure, the templates, and the conventions without being told.
But the tool isn’t the breakthrough. The breakthrough is what I built around it.
Here’s what that looks like in practice. I open a terminal. I type one word — “initialise” — and the system loads my business context, my client state, my operational priorities, and my voice rules. It knows what I’m working on, who I’m working for, and how I write. Not because someone programmed it to know. Because I’ve been correcting it every day for a year, and those corrections travel forward through the codebase.
The three-document system was me manually doing what the infrastructure now handles automatically. The lesson wasn’t “write better documents.” The lesson was: build the soil, and the seed takes care of itself.
The Stack I Actually Use
There’s something the title doesn’t quite cover. When I first wrote this article, I was experimenting with React frontends. I’ve since moved to Astro — a framework that generates static HTML, loads faster, costs less to host, and suits the kind of sites I build for small businesses and my own ecommerce properties.
The Python and Django are real. My entire backend — client management, SEO audits, financial tracking, supplier integrations, and pipeline automation — runs on Django. I write Python every day. The model writes Python every day. And after twelve months, I can tell you: the code works, it’s maintainable, and I built it for a fraction of what a development team would quote.
If you’re building with React, the principles here still apply. Context, communication, and infrastructure matter more than the framework. The framework is the least interesting part of the equation.
The Real Question, Twelve Months Later
The original piece asked: can AI produce authentic code? I now think that was too small a question. A better one: can you build authentic infrastructure around an AI, so that the code it produces is informed by your actual business?
Because the code that comes from a well-situated system doesn’t look like “AI-generated code.” It looks like code written by someone who understands the business — because the system has been taught to understand it.I’ve deployed Django applications that process SEO audits across dozens of client sites. I’ve built a pipeline that takes a prospect from discovery to proposal to payment without leaving the terminal. I’ve created keyword tracking systems that show me where every client’s rankings sit and why they moved. My git history is a searchable forensic record of every decision I’ve made in the past year — and when a client’s rankings shift, I can trace the exact change that caused it.
None of this happened because the model is brilliant. It happened because I showed up every day, corrected the drift, and let the infrastructure compound.
What This Means for Your Business
Small business owners: You can build custom tools without hiring a development team. But the real investment isn’t the subscription. It’s the discipline of communicating clearly and building context over time. The model doesn’t know your business — you have to teach it. That teaching compounds. The first month is painful, and the sixth month is when the velocity arrives.
Ecommerce businesses: Custom inventory systems, automated supplier integrations, and personalised product management are within reach for hundreds of pounds instead of tens of thousands. I built six ecommerce properties and manage thousands of products from a single codebase. Start with strategy before code.
Service businesses: Client portals, booking systems, and project management tools can be built and deployed in days. I know this because I built mine. The key is starting with something small enough to finish, then letting it grow. Start with what your business actually needs before building the thing that sounds impressive.
The Cost Nobody Mentions
The original article said I spent 30% of my time on “prompt engineering.” I’d retire that phrase entirely. Prompt engineering implies crafting clever inputs to compensate for a thin environment. It’s a workaround, not a practice.
What I actually do is maintain infrastructure. I update the documentation. I encode corrections when the model drifts. I review what’s working and what’s gone stale. That’s closer to 20% of my time now, and it drops every month as the system tightens. The corrections I made in January catch errors automatically in March. The compound effect is real.
The subscription costs less than the tools it replaced. I cancelled SEMrush, reduced my hosting bills, and eliminated the WordPress maintenance overhead that used to eat entire afternoons. The Python and Django infrastructure I built with Claude Code runs on a basic deployment and an API key. The total spend on AI in twelve months came in under a thousand pounds — less than a single month of the old tooling.
Getting Started Without the Expensive Mistakes
I’d change some of the advice I gave six months ago. Here’s what I’d tell someone starting today:
Don’t start with code. Start with context. Write down how your business actually works — not aspirationally, but accurately. The rules, the constraints, the vocabulary, and the things that matter. That document is worth more than any coding tutorial, because it gives the model something real to work from.
Use one tool properly. I use Claude Code. It reads the entire codebase, understands the connections between files, and maintains the architecture across changes. Pick one tool and go deep rather than switching between three.
Expect the first month to be slow. I rebuilt features multiple times. I lost work when conversations ran too long. I had to learn where the model is strong and where it drifts. That learning period is unavoidable — and it’s also the period where you’re building the context that makes month six feel like a completely different experience.
Think in systems, not features. A login form is a feature. A client management system that tracks communications, flags overdue work, and generates reports — that’s a system. AI is better at building systems than isolated features, because systems reward the kind of accumulated context that compounds over sessions.
The Bottom Line
Can AI produce authentic code? Here’s what I know after twelve months of building production systems with Claude Code.
The code is authentic when the infrastructure behind it is authentic. A model that’s been corrected for a year, situated in a specific business context, and given a searchable history of every decision — that model produces code that solves your actual problems, not generic problems from its training data.
What used to require a team of developers over twelve weeks now happens in a focused session. Not because AI replaced the expertise. Because the infrastructure amplified it.I wrote the first version of this piece when I had four weeks of evidence and a system I was proud of. That system was the beginning. The operating system I work with now — the documentation, the correction loops, the compounding context, and the voice that writes like me because I’ve spent a year teaching it — that’s what daily practice produces.
The answer was never about the model. It was always about what you build around it.
Ready to Explore What’s Possible?
I’m helping small businesses build the kind of infrastructure that would have cost tens of thousands to develop traditionally — and I’m doing it at a pace that still surprises me after twelve months. If you’re curious about what’s possible for your specific situation, I’d genuinely like to have that conversation.
Drop me an email at tony.cooper@webuildstores.co.uk
Tony Cooper
Founder
Put My Crackerjack Digital Marketing Skills To Work On Your Next Website Design Project!
Get Started