AI, Code, and the Emergence of the Product Creator

Over the past four months, I’ve been running a fairly intense experiment.

Using AI tools as a code generator like Claude Code and Codex, I’ve generated around ~195,000 lines of code, with a total code turnover closer to 220,000 lines once refactoring is included. This was a UI application, in a programming language and technology stack I have no prior experience with, and where I had no prior familiarity or experience with developing a browser-based application at scale - at best I am a “bedroom coder” skill level.

My goal was simple, I wanted to create a viable, working application where I wrote ZERO lines of code myself, just piloting the AI systems. I was not trying to test my coding skills, my primary aim was to evaluate the usefulness of using AI tools for developing software at my company.

I was conscious that the scope of developing a front-end app using React was quite narrow, so actually I ran four independent projects at the same time, different tech stacks with different levels of personal expertise I could apply:

  • A browser-based front-end application built with React and Vite (basically no prior knowledge or experience here) - 190k lines of new code
  • A Windows/x64 screen capture, recording, and graphics annotation tool written in C++/20, using Win32/DirectX APIs - 27k lines of C++ code
  • Embedded STM32 IoT system, very low-level bare-metal, DMA, communications, MP3 decoding, polyphonic sound generation, multi-tasking, WiFi, Thread/Zigbee, as well as Serial, RS485 and USB comms, user interface, TFT display, keypad, haptic feedback, audio subsystem, various environmental sensors etc - essentially a fairly complex HMI/IoT device, about 12k lines of code
  • A distributed Cloudflare-based file sharing and interactive sharing application using Durable Objects, D1, WebSockets, and event-driven patterns - about 11k lines of code
  • And various works on a large, well established, mature production C++ codebase that has evolved over some 20 years. ~1000 lines of code, but the work was more about understanding and working with the existing code than writing new code.

The outcome on all fronts has been far better than I expected to be honest. In several cases, the quality of the result—both structurally and functionally—has exceeded what I’ve previously seen produced by entire dedicated teams.

AI Code Quality

The experience has clarified something more important than just enhanced productivity for me though, it has changed how I think about what a “developer” actually is in an era where AI is a dominant and transformative technology.

Coding without ownership of outcome is no longer a career

There’s a dramatic shift underway in the software development industry that I am sure many people feel, but there is a lot of denial too. Much is written about how badly AI writes code, and that’s mostly right, but that is a “Piloting” issue and not an AI issue as far as I can see, and so coding with AI tools is a galactic-scale shift and the disruption to the status quo is massive:

The ability to write code because you have experience with a language or can troubleshoot a defect - those skills have all but lost their value, 3 years ago, those skills alone would get you a job - not any more!

That doesn’t mean that software development is dead, but it does mean that if all you do is code, that’s no longer enough to be valuable.

AI systems:

  • know the syntax of virtually every mainstream language
  • understand frameworks, APIs, and patterns across ecosystems
  • can produce working implementations on demand

If you define a developer as “someone who knows JavaScript” or “someone who can write React components,” then AI has effectively commoditised that layer completely.

And the industry is already reacting:

  • layoffs disproportionately affecting junior developers
  • reduced hiring at the entry level
  • increasing expectations that developers deliver more than just code

At the same time:

  • investment in AI tooling is accelerating
  • organisations are looking for leverage, not headcount

This doesn’t feel temporary. It feels structural to me.

AI doesn’t remove the work — it changes it

If I simply ask AI to “build things,” it will and it will often work first time…

But it will also:

  • duplicate logic a lot
  • drift in structure
  • ignore existing abstractions
  • optimise for local success, not system integrity
  • and unless you are very controlling, it will not retain long-term memory about the things it has already built, the decisions it has already made, or the overall architecture of the system.

Left unchecked, it produces something functional—but, at scale, fragile.

Three concrete examples stand out.

In the React application, we defined a colour and styling system early on — design tokens, consistent palettes, spacing conventions. AI ignored it constantly, defaulting to inline styles and arbitrary values. It took continuous regrounding, over and over, until there was a large enough body of work that the patterns became dominant and AI finally started following them by default.

In the same application, as the scale and complexity of data being rendered grew, AI consistently failed to handle memory and resource management properly — virtual scrolling, React rendering cycles, and component lifecycles were all areas where it would produce solutions that worked in isolation but fell apart under real load. Getting that right required persistent steering and a refusal to accept “it works” as good enough.

What made it harder was that I couldn’t articulate the problems in React’s own terms — I didn’t know how React should handle it. But I could observe that something was wrong. So I directed AI to build specific debugging views into the UI — render cycle counters, memory monitors, component lifecycle observers — which gave me enough insight to create more points of observation, until I fully understood what was happening internally even without knowing the code itself.

That process — observe, instrument, understand, direct — is exactly the kind of work a Product Creator does. You don’t need to know the syntax. You need to know something isn’t right, and be relentless about finding out why.

A third example: component design. AI was inconsistent about when and why to create a new component, often producing one-off implementations instead of reusable building blocks. The fix was establishing explicit rules — when a component should be created, what must accompany it (a playground/showcase entry, documentation, and test cases), and how it should relate to existing components. Without those rules, AI would happily create fifty slightly different button variants. With them, it became disciplined. But it would never have imposed that discipline on itself.

These aren’t edge cases. They’re the norm. AI will always take the path of least resistance unless you actively prevent it.

To get good results, I’ve had to stay firmly in control of:

  • architecture
  • system boundaries
  • code organisation
  • reuse
  • continuous refactoring

A large portion of my time hasn’t been spent writing code at all. It’s been spent:

  • steering
  • correcting
  • consolidating
  • simplifying

AI will not do this unless you explicitly make it. That responsibility doesn’t go away. It intensifies, and if you are bad at that, it’s really likely to show up much more.

The real leverage: collapsing idea → product

Where AI becomes genuinely transformative is not in writing code—it’s in collapsing the distance between:

“I have an idea” → “I have a working system”

I’ve built systems in domains where I had little or no prior experience:

  • React front ends
  • DirectX-based Windows tools
  • embedded systems with complex maths and hardware features
  • Cloudflare-native distributed systems

Not by becoming an expert in each of these—but by being able to direct their implementation.

I have been fortunate enough over the years to work with great developers and teams, and for some areas like front end development I have been more on the side of product owner than coder. So the pattern goes something like:

  • I have an idea or requirement
  • I write it (the requirements) down
  • I share/explain it to a developer and/or team
  • They schedule the work and implement it

Now we are in the dev/test/review cycle, and iterate our way to an outcome. This disconnect between requirements and implementation is a fundamental part of how software development has worked for decades, but it’s also a source of friction, miscommunication, and delay. The fidelity of the requirement often degrades as it moves through this process, and the feedback loop is slow. Its easy for individual developers to take iteration direction as a personal criticism, I would often hear thinks like “that was not made clear” or “I didn’t understand the requirement” and it can be hard to maintain a shared vision of the product as it evolves, because the product owner owns the outcome, the developer owns the implementation, and the two are not always in sync.

In steps AI, and suddenly the pattern looks more like this:

  • I have an idea or requirement
  • I explain it to AI in a dialect I have already established with the body of work thats already present, and make AI explain back to me to confirm we have a common understanding, create detailed documentation at that point.
  • I tell AI to build what we have documented
  • I enter the dev/test/review/iterate implementation with AI, my concern stays focused 100% on the value outcome, AI focuses on the mechanics of the implementation.

Something that can take weeks in a traditional development process at a similar scale I can achieve now in just a few hours. Here is what I get (and don’t get) from that process:

  • I get exactly what was in my head without having to train others to visualize the same thing I am seeing.
  • I can change the thing as much as I want, without the concerns around the sensibilities of other people in the same creation loop
  • I am not having to negotiate a committee of competing ideas and approaches to solve the same problems in different ways. That’s not to say diverse perspectives don’t have value — they do — but the human cost of managing experienced people with strong opinions, egos, and competing visions is enormous, and with AI, that friction simply doesn’t exist.
  • I am capable of creating the outcome myself, unhindered and unobstructed.

Even if you consider all of that work is just “prototype level quality” that’s such a huge step forward in terms of speed and leverage that it cannot be described as anything other than transformative.

That’s the shift, and it’s very real, and it’s here now.

From Developer to Product Creator

What I’ve found myself doing doesn’t feel like traditional development anymore, not at all in fact.

It sits somewhere between:

  • Product owner
  • Architect
  • Engineer

But it isn’t quite any of those roles individually.

It’s more integrated.

If I had to name it, I think I want to call it:

Product Creator

A Product Creator:

  • collates requirements, innovates the product features that meet the requirements, and owns the ideas
  • defines functional behaviour/UX
  • shapes technical architecture
  • directs (but does not do the) implementation
  • validates the outcome

and the primary execution layer is AI driven code generation and tooling.

This is not theoretical, I have done it for real, and I know many companies are doing this already too.

One capable individual, with AI piloting chops, AI tools, a well-structured codebase/body of work creates the dialect and one person can now deliver what previously required multiple disciplines and teams.

Why this works (and when it doesn’t)

This approach only works under certain conditions.

1. The codebase must be AI-friendly

AI performs best when:

  • structure is clear
  • responsibilities are well defined
  • concepts are consistently implemented

If your system is chaotic, AI will amplify that chaos.

2. Documentation becomes a force multiplier

One of the most useful patterns has been:

  • describing concepts clearly
  • letting AI map those concepts to code
  • generating and maintaining documentation alongside the system

This creates a feedback loop:

  • better documentation → better AI output → better structure

3. You must stay in control

If you:

  • accept everything AI produces
  • stop questioning decisions
  • allow structure to drift

You will lose control of the system surprisingly quickly.

AI is not self-correcting in this regard.

The hidden risk: false productivity

There is a subtle trap.

Because things move quickly, it’s easy to feel productive.

But without discipline, you can:

  • accumulate technical debt rapidly
  • lose conceptual integrity
  • build systems that are harder to evolve over time

Speed without control is not progress, it’s a plane crash in the making.

The scaling problem (and how to avoid it)

Left unchecked (or in a poorly designed, complex codebase), I observed:

  • increasing time to implement small changes
  • growing inconsistency
  • duplication
  • structural drift

The fix is not complicated, but it requires very deliberate piloting:

  • enforce reuse
  • refactor aggressively
  • maintain clear boundaries
  • think at the system level

In other words: behave like an architect, with good engineering discipline.

What this means going forward

If this direction holds—and I believe it will—the implications are significant.

For individuals

The question is no longer:

“Can you write code?”

It becomes:

“Can you create a coherent, valuable product using code as a medium? Can you be responsible for customer outcomes?”

That’s a much higher bar, something that developers will often shy away from.

For teams

We may start to see:

  • smaller teams
  • more end-to-end ownership
  • individuals responsible for complete products or product slices

Not everywhere — but increasingly for sure where speed and leverage with change matter.

For the industry

Coding is not disappearing. But coding alone is no longer enough.

The value is shifting upward:

  • towards systems thinking
  • towards product awareness
  • towards decision-making
  • towards ownership of outcomes

Final thought

After four months of working this way across multiple domains, my conclusion is simple:

AI hasn’t replaced engineering.

But it has raised the bar.

It rewards:

  • clarity
  • structure
  • discipline

And it exposes:

  • technical ability (technical design or architecture direction)
  • vagueness
  • inconsistency
  • lack of ownership

If there’s one takeaway I’d state, it’s this:

AI doesn’t automatically make you a better developer - it will amplify the developer you already are.

I believe that the developers who survive the AI revolution and thrive won’t be coders any more. They’ll be something else entirely.

Product Creators.

Four months ago, I set out to test whether AI could build software. What I discovered is that it already can — the bottleneck was never the code. It was always the thinking.

Loading comments…