Reading time: 8 minutes

A strange thing happened this week while building software with AI: AI was helping me generate more code than I could comfortably read.

AI Lets One Person Generate More Code Than One Person Can Comfortably Read

Throughout my career, I’ve understood every line of code I’ve written. Of course, over time, you forget, but you do remember the essence.

With AI, that’s all changed.

I realised that I was generating more code than I could comfortably read in the old way.

This was unsettling at first, and to some extent it still is.

Do I try to read all the code, or trust the code blindly? I’m gravitating to somewhere in between.

A quick scan.

Perhaps a small hope.

Then move on — trusting that testing will discover any flaws.

I need to focus more on the creative process rather than the creation process.

I’ve started using an AI “code review” memory. I apply it to all the code to ensure it meets the architectural and design standards. I find it almost impossible any other way.

I find this mimics the traditional large development process, where many developers code different parts of the app. There was never any expectation that one programmer understood all the code. Perhaps this was an unrealistic expectation I had at the start of my AI journey.

For most of my career, the rhythm of programming looked like this:

1. Think about the design
2. Write the code
3. Read the code carefully
4. Refactor it
5. Repeat

The reading step was essential.

You understood every line because you wrote every line.

That model is now changing.

The New Reality of AI-Assisted Development

When working with AI, the loop becomes something different:

1. Design the architecture
2. Ask the AI to generate code for a component
3. Review the structure and intent
4. Adjust the design
5. Generate the next piece

The key difference is subtle but profound.

You are no longer reviewing every line.

You are reviewing the architecture and the contracts.

AI does the coding. You don’t.

For simple scripts, you can still read and understand everything.

But if you’re building a real system, the volume grows quickly.

Suddenly you have thousands of lines of code appearing faster than you could ever write them.

Panic sets in.

I’m experiencing this pressure now.

The amount of code being generated is overwhelming. How can I realistically review it all?

After much anguish, I eventually realized this is no different to traditional large projects.

The only difference now is I’m a sole developer building complex software with the help of AI. I now work with an infinite team of AI programmers – actually one, it just feels like many.

I now have:

• One programming style.
• Consistency.
• Tighter coding.
• A much faster development cadence.

This allows me to meet my software goals considerably faster.

But is AI development making me more exhausted due to the pace of development?

This Is How Large Systems Have Always Been Built

Thinking about it, this is how large development projects work. It is not possible for a single developer to understand every line of code.

Rather, they strive to understand the architecture, the overall design, the interfaces, the contracts between components, as best as they possibly can.

Different developers, or even different teams, write different pieces of code.

Essentially, this is the role of AI today.

AI handles the majority of the actual coding. At least that’s what I’m finding in the project I’m currently building.

My role is now to guide AI to build my vision and validate what’s being created.

I no longer need to worry about the nuts-and-bolts of coding.

Instead I can focus on the direction, the objectives, and ensuring what’s being built meets the requirements.

Sound familiar?

No difference to how projects have been traditionally run.

No longer am I only a typist of code, I’m now functioning more as a system architect and reviewer.

The New Skill: Architectural Reading

No longer do I need to perform the laborious task of reading and understanding every line of code.

The new skill set is reading the structure.

I now focus on questions like:

• Does the component obey the architecture? Is the component doing what it should, and nothing else? There should be no leakage of responsibilities.
• Are guardrails in place? Does the code check for reasonable limits, enforce necessary validations, and follow safe coding principles?
• Are the failure modes safe? Does the code handle failures in a predictable way, avoiding cascading failures?
• Are the contracts correct? Do the components behave as expected? Are the inputs and outputs clearly defined?
• Does it meet the design philosophy and goals? Is the solution simple, consistent, and does it meet the objectives of the app?

I’ve actually spent considerable time thinking about both the guardrails and failure modes in the app I am building.

Now I can focus on the intent of the system, not just the syntax.

The Strange Feeling of Scale

At first this felt strange. It felt uncomfortable.

I’m now generating far more code than I can possibly review. I no longer have the bandwidth to deal with the scale of what’s being created.

Initially I panicked.

What do I do?

Slow down the development process by trying to deeply read all the code.

Or scan the code at a higher level to ensure it meets the intent.

Or accept that AI has increased the amount of software a single person can produce.

It doesn’t help me type faster.

It allows me to operate at a higher level of abstraction, spending less time writing code and more time thinking about the app itself.

The Real Limiting Factor

Coding is no longer the bottleneck.

The bottleneck becomes:

• Architecture. What components exist. What they’re meant to do. How they interact.
• Judgement. Should this feature exist? When should it exist? What is the benefit? Is it useful? Does anyone want it? Is the feature safe in production?
• Taste. Is this simple and easy to use? Does the naming make sense? Is the design consistent? Is there too much configuration, too little configuration?
• Design discipline. Ensuring the architecture is followed. Ensuring patterns and rules are obeyed. My experience has shown that AI can sometimes introduce complexity or duplication without you realizing it.
• Avoiding the perfection loop. Finish something. Publish something. I still struggle with this. AI has, on many occasions, prompted me to move forward instead of endlessly refining.

AI can generate the code.

You decide what should be built, how it should work, and when it should exist.

Only you decide what should exist in the system at all.

The Trap of Perfect Code

AI can write code so perfectly that it can become difficult to understand.

The years have taught me one thing. Simple code beats clever code every time.

I’ve spent countless hours fixing production issues under time pressures where fancy code hindered the process. I’m guilty of doing this myself earlier in my career.

I’m finding AI often writes complex code. While it works, and is impressive, I’m regularly asking for a human-understandable version.

This raises an interesting question.

If AI writes all my code, and I don’t get the chance to read it, who fixes the production problems at 3am in the morning? AI, the developer, or a combination of both. My experience so far suggests a combination of both.

I’ve found AI to run me around in circles at times, especially when fixing bugs.

“This code will fix it”.

No it didn’t.

“Try this”.

Still no good.

Sound familiar?

Eventually I had to resort to the old fashioned manual debugging process. When I pointed out the problem AI finally managed to fix it.

AI will improve. But for now, I feel a hybrid AI-human development process seems to work best.

Is this actually any different to what exists today? Not really.

New Risks

Working this way introduces some potential risks:

• When AI refactors code, how can I know whether it is making only the intended change, or altering other parts of the code? My experience suggests that other code sometimes gets changed.
• How can I ensure AI isn’t introducing insecure or even malicious code? Is this a real concern, or simply paranoia?
• The more comfortable I become with AI-generated code, the less inclined I am to read it. I’m still unsure whether this is a good thing.
• I find AI often produces complex code. There needs to be a balance between AI-written code and simplicity.

A Thought for the Future

Are we entering a period where:

• One person can build systems that previously required teams. I’m trying that myself now.
• Architecture and creativity become the primary skills.
• Reading and understanding code line-by-line becomes less important than understanding systems.

While AI probably won’t replace programmers entirely, it may turn programmers into architects, or allow architects to replace programmers.

It is an exciting future with infinite possibilities.

Earlier posts in this series

If you haven’t read the first article in this series:

→ I Hate AI Written Posts

Last edited: