Even When AI Writes the Code, Software Still Needs Revision

We are living in the age of vibe coding.

Describe an idea and code appears. Paste an error log and the tool starts tracing the cause. Ask about an unfamiliar framework and it gives you a working example. Boilerplate that used to take half a day can appear in minutes. Bugs that once felt lonely can now be investigated through a conversation. Coding has absolutely become easier.

But “coding is easier” and “building a usable application is easier” are not the same sentence.

It is much faster to create a first screen that runs. It is still hard to make that screen meet user data, respect permissions, survive failures, read configuration in production, expose useful logs and metrics, and help an operator understand what happened when something breaks.

AI writes code quickly. Software, however, is not finished by code alone.

Illustration of scattered draft pieces passing through review marks and becoming organized software blocks — A fast AI-generated draft still needs review and revision before it becomes usable software.

Good Results Still Come from Understanding

Anthropic’s June 2026 report, Agentic coding and persistent returns to expertise, makes this point in an interesting way. The report analyzed roughly 400,000 Claude Code sessions between October 2025 and April 2026.

The central finding is straightforward: even with an AI coding tool, people with stronger domain understanding achieved better outcomes. The difference between novice and intermediate users was large, while the difference between intermediate and expert users was more modest.

One caveat matters: this was not a long-running study of production quality after deployment. The analysis inferred success from signals observable inside sessions, such as passing tests, commits or pull requests, and user confirmation. So the useful reading is not “intermediate users always build better products.” It is that domain understanding makes AI coding tools more effective.

This should not be read as “novices should not use AI.” If anything, the opposite is true. AI is a powerful accelerator for beginners too. But better outcomes still require the ability to judge questions like these:

Does this code solve the actual problem?
What requirement is missing?
What happens when this fails?
Do the tests cover meaningful paths?
Can this structure keep changing as the code grows?
Do configuration, logs, permissions, and data connect naturally in production?

This is not the intuition of a mythical architect. It is closer to the eye of an intermediate practitioner: someone who has seen the problem space, can notice gaps in the first result, and can distinguish “it runs” from “it is usable.”

The First Result Is a Draft, Not the Final Version

The output from an AI coding tool can be impressive. There is a UI, an API, and sometimes even tests. That creates a tempting misunderstanding.

It runs
  -> it is almost done

More often, the state is this:

It runs
  -> we now have a draft we can review

Having a draft is a huge step forward. We spend less time staring at a blank file. But a draft is still material to revise.

Imagine building an internal operations screen for searching customers and changing their status. AI can quickly generate a search form, a table, a detail screen, an update API, and a few basic tests. With demo data, the result may run smoothly and look convincing.

Then the real application starts asking harder questions. Which roles can see which customer fields? How should deleted or merged customers appear? Will pagination and indexes hold up with hundreds of thousands of rows? Are duplicate submissions blocked? Can personally identifiable information leak into logs? Is every status change auditable? What does the UI show when an API is slow or fails?

Those are not decorative details added at the end. They are part of what makes the result usable software.

Software drafts often leave gaps like these:

The happy path exists, but failure paths are thin.
Demo data works, but real data shapes are not fully represented.
Types compile, but domain rules are missing.
Tests exist, but important failure conditions are not checked.
The user experience looks plausible, but becomes awkward when repeated every day.
It works locally, but deployment, configuration, and observability are incomplete.

These gaps do not appear only because AI is imperfect. People create the same gaps when they code by hand. The difference is speed. AI creates the draft faster, which means we get the chance to revise faster too.

Good vibe coding is therefore not “letting the feeling drive everything.” It is closer to creating a fast draft and revising it with precision.

What the Intermediate Eye Sees

People who get good results are not merely writing longer prompts. They are looking at the result and asking better follow-up questions.

What input will break this?
Where will this become annoying if a user repeats it every day?
Which code path slows down first when the data grows by 10x?
Which API becomes risky when permissions change?
Will operators have the logs they need during an incident?
Which part of this code will fight the next feature?

These questions are not flashy. They are where application quality improves.

AI can suggest answers. It can add tests, refactor code, improve documentation, and compare alternatives. But deciding what to ask next, what result to accept, and how much revision is enough remains human work.

The required skill is not the ability to implement everything manually. It is closer to:

turning requirements into sharper constraints
reading the intent of generated code
spotting mismatches between domain rules and implementation
choosing the paths worth testing
separating what must be fixed now from what can be handled later

With that level of understanding, AI tools become much more powerful. They do not replace judgment; they stretch it across faster experiments and faster revisions.

Software Has Revision Too

William Zinsser’s On Writing Well is one of the English-language books that treats writing as craft rather than inspiration. Its lasting lesson is that clear writing comes from removing clutter, choosing precise words, and revising until the sentence says only what it needs to say.

Software is similar.

The first code is a draft of thought. Tests are a way of reading that draft aloud. Refactoring removes unnecessary phrasing. User feedback shows where the reader stops. Incidents and operational logs reveal context that never appears while the work stays on a desk.

The fact that good software rarely appears in one pass is not discouraging. It is the opposite. Software can get better because it can be changed.

AI coding tools make that process faster. They create drafts quickly, help expand tests, compare alternatives, and make tedious edits less painful. But speed does not mean we can skip revision.

In fact, the faster the output arrives, the more important revision becomes. More code appears in less time. Plausible results appear earlier. Plausibility is not a substitute for review.

Completion Is Not a Single State

Software is not especially comfortable with the word “finished.”

After the first release, users use features in unexpected ways. Data becomes larger than expected. Security requirements change. Dependencies move. Operating environments evolve. Incidents happen through combinations nobody wrote down. A structure that was good yesterday may become a little stiff for tomorrow’s change.

Software development is therefore less like a task with an endpoint and more like a process of continuing completion.

That changes how we should use AI coding tools.

Ask AI for the final version

is less useful than:

create a draft with AI
set human standards
revise through tests and feedback
reshape it into something better

In practice, a healthier loop looks like this:

create a fast draft
  -> apply domain constraints
  -> add failure paths and tests
  -> revise again from real usage and operating signals

Vibe coding has made software development lighter. That lightness is good. More people can try their ideas, experiment faster, and begin implementations that once felt too large to attempt alone.

Maybe a large share of writing code is no longer a human-only role. But software development still needs human judgment. Deciding what to build, understanding why it should be built that way, checking whether the result solves the real problem, and continuing to revise what is missing remain human work.

But good software still does not appear in one pass. Even when AI writes the code, software still needs revision.

And perhaps the best developers ahead will not be the people who type the most code, but the people who revise it best.

References

Anthropic, Agentic coding and persistent returns to expertise, June 16, 2026