Revisit

About a year ago, I wrote a piece arguing that code-first development, supercharged by AI inside the IDE, was on track to overtake low-code for any serious software project. If you want the original context, you can read it here.

A lot has changed since then.

We've moved well beyond autocomplete-on-steroids into the era of full coding agents — tools like Codex, Claude Code, and GitHub Copilot's agentic workflows. These tools can now navigate a codebase, scaffold features, run tests, fix issues, and return with something surprisingly complete without needing constant supervision.

That shift felt significant enough that I wanted to revisit the original argument. Not to declare winners or losers, but to reflect on what the last year of actually using these tools has changed in the way I think about software development.

What Coding Agents Actually Changed

The jump from "AI helps write code" to "AI executes work" is bigger than it first appears.

A year ago, you were still driving most of the process yourself. The AI was useful, but it largely operated as an assistant sitting beside you. With coding agents, the interaction changes completely. You describe an outcome, provide enough context, and the agent disappears for twenty minutes before returning with a pull request, test coverage, and implementation notes.

What surprised me most is how much this compresses delivery timelines.

The bottleneck in software development was never typing speed. It was always time, context switching, and cognitive load. You could design a strong architecture, but if every feature still took weeks of implementation effort, the appeal of low-code platforms or off-the-shelf solutions remained understandable.

Agents dramatically reduce that friction.

Work that I would previously estimate as a one or two week sprint can now realistically be finished in an afternoon. Not perfectly finished, but often close enough that the remaining work becomes refinement rather than construction.

That changes the economics of building software quite a bit.

The Part I Underestimated

Reading back over my original post, I realised I framed the discussion too much as code-first versus low-code.

After another year of working with these systems, I think that framing misses the bigger point.

Coding agents are amplifiers.

They amplify clarity, structure, and systems thinking. Unfortunately, they also amplify confusion, weak design decisions, and vague requirements. You can absolutely produce poor architecture faster than ever before — and with far more confidence than you should probably have.

That was the piece I did not fully appreciate 1.5 years ago when I wrote the article.

I focused heavily on what the tools were capable of doing. In practice, the more important question turned out to be: what human skills do these tools reward?

Why Computational Thinking Matters More, Not Less

There's a common assumption that better AI lowers the engineering bar.

On the surface, it makes sense. If the agent can remember syntax, generate boilerplate, and wire together APIs, surely the need for deep engineering discipline starts fading away.

But, I've seen the opposite happen.

The value of computational thinking has increased significantly. The ability to break problems into clean abstractions, model systems properly, and reason about trade-offs matters more now than it did before.

Once you delegate implementation to an agent, a few new problems appear very quickly:

• The review paradox
  Agents rarely produce code that is obviously broken. Instead, they generate code that looks correct, compiles successfully, passes most tests, and still contains subtle architectural flaws or incorrect assumptions. If you do not already have a strong instinct for what "good" looks like, those problems are easy to miss and compile into a big disaster.

• The complacency trap
  Agents are extremely obedient. If you suggest a poor design decision, they usually will not challenge it. They will confidently implement the flawed approach at remarkable speed. In many ways, the human still needs to provide the architectural judgement and restraint.

• The context gap
  Vague prompts produce shallow software. Asking an agent to "build a dashboard" generates something generic. Giving it detailed constraints, state management expectations, edge case handling, and interaction patterns produces something substantially better. The difference is rarely the model itself. It's the quality of the thinking behind the prompt.

I do think the skill floor has dropped. You can build functional prototypes today without mastering every framework or memorising APIs.

But the ceiling for building good systems has arguably moved even higher.

Where I Was Wrong

Looking back, there are a few areas where my original thesis was clearly overconfident.

1. Low-code evolved faster than I expected

Platforms like Retool and Power Platform did not stand still while code-first tooling improved.

They integrated AI capabilities aggressively and became much more capable. For internal tooling and enterprise workflows especially, the "describe what you want and generate the interface" model is genuinely effective.

Low-code still has a very strong place in certain environments especially for quick exloration.

2. "Dark code" became a real problem

One thing I barely touched on in the original post was maintenance debt.

Agents can generate hundreds of lines of code in seconds, but somebody still needs to understand, review, and maintain that code later. Increasingly, teams are merging large volumes of AI-generated code that no individual developer fully understands end-to-end.

The speed of generation has outpaced the speed of comprehension.

That creates a kind of hidden operational debt. When something fails six months later at 2:00 AM, somebody still has to untangle the logic and work out what the agent was actually trying to do.

3. Agent lock-in is becoming its own ecosystem problem

Technically, code remains portable.

But the workflows surrounding that code often are not.

Prompt structures, memory files, context conventions, and agent-specific behaviours start becoming part of the development process itself. Moving between ecosystems is possible, but not always frictionless.

It is not the same kind of lock-in as a proprietary enterprise platform, though it does introduce a softer dependency layer that I think people are still underestimating.

Final thought

The biggest thing I've changed my mind on is this:

The future probably is not about code-first versus low-code. It's about how much systems thinking remains attached to the work.

Tools that keep you closer to the underlying architecture tend to strengthen your ability to reason about systems. Tools that abstract too much away can feel incredibly productive in the short term, but they also risk weakening the exact thinking skills that make coding agents powerful in the first place.

The people I've seen getting the most value from coding agents are usually the ones who could have built the system themselves manually — just more slowly. The agent does not replace the thinking. It extends the reach of the thinking. And that distinction feels far more important to me now than it did more than a years ago.