Coding is solved? Software is not. - Arcplane journal

toggle theme Boris Cherny, the creator of Claude Code, said in a recent talk:

…at this point, it’s safe to say that coding is largely solved - at least for the kind of programming that I do.

He described a workflow where Claude Code writes 100% of the code and Claude reviews every pull request, while humans still act as checkpoints for safety and quality.

The line works because AI coding tools can feel both magical and disappointing. A change that used to take an afternoon can arrive as a credible first draft in minutes, and then the team may still spend hours, sometimes days, deciding whether it was the right change to make.

If implementation is becoming abundant, why does building software still take so much time and effort?

Coding is not the whole job

“Coding is solved” is a provocative statement. It is also an incomplete one.

Models still hallucinate, and generated changes still need review. But the statement points at something real: for many software teams, writing code has stopped being the slowest part of building software.

And yet, software development does not feel solved.

Because coding does not equal software development.

Coding turns instructions into implementation. It remains important, and it is imperfect. But software development is larger than that: it turns ambiguous intent into a reliable system.

No matter what process a team follows, someone has to understand the problem before code exists. The team has to narrow the scope until “done” means something concrete.

After code exists, someone has to prove that the change belongs in the system, ship it safely, and keep owning the consequences.

This is where the promise frays. Implementation gets dramatically faster; the rest of software development does not disappear.

Software development reduces entropy

Not in the physics sense. But as a metaphor, it feels right.

A new feature often starts as a messy request: “Can we add team invitations?” At that point, there may not be an implementation to compare. The team is still figuring out which product behavior the request implies.

Product thinking reduces the mess first. Maybe “team invitations” means a simple email invite into an existing organization. Maybe role assignment can wait. A vague request becomes a narrower bet.

Design gives that bet a shape. The team decides who can send an invite, what an existing user sees, and what happens when an invite expires. Now there is proposed behavior, not just a product wish.

Implementation turns the behavior into a real change. Code gives the idea weight, but it also gives the team something new to distrust. The next question is no longer “can we build this?” It is “did we build the right thing, in the right way?”

Review and deployment close the loop. The change has to survive contact with the rest of the product and with real users.

At each step, software development narrows a messy space of possibilities until there is a change the team can verify. In that loose sense, software development is entropy reduction: turning confusion into a verified change.

The diagram below shows the clean version of that journey: intent becoming a shipped change the team can stand behind.

But fast coding can add entropy too

At first, it feels like AI agents can own implementation. In more ambitious versions of the story, they may eventually own the whole loop. But in practice, we often find that agents are “too smart” for their own good.

The failure mode is subtle. A generated test suite can be large and still mostly confirm the implementation the agent already chose. A review thread can grow longer because the agent nitpicks around the core issue. A plan can sound thoughtful while leaving the actual product tradeoff undecided.

This is one form of “AI slop”: output that looks complete, but does not actually reduce the mess.

After introducing AI agents, entropy can decrease in one part of the process and increase in another. The implementation arrives faster, but the team may spend more time reconstructing the agent’s intent and deciding how much of the evidence to trust.

The team produces code faster, but it does not necessarily trust the result sooner.

The missing piece: a new workflow

Once agents enter day-to-day work, the magic wears off a little. They start to feel more like capable junior teammates. The work starts to look more like mentoring:

You give them enough context to begin, then keep checking whether the work is heading toward the thing you meant.

In our team, the transition happened gradually.

At first, agents were personal assistants. They helped inside the developer’s existing loop, while the rest of the development process stayed mostly the same.

Then developers started delegating larger parts of implementation. Instead of writing most of the code by hand, they became editors of an agent’s proposed change.

That worked surprisingly well. It also made the surrounding...