Vibe Coders Learned This. Vibe Authors Have Not.

Vibe coding produced a finding this year that should worry every writer using AI.

Less experienced engineers get less benefit from AI coding tools than experienced ones. They also spend more on tokens doing it. The tool that was supposed to level the field widened it.

The reason is simple once you see it. AI writes code quickly. Deciding whether that code is any good is a separate skill, and the model cannot supply it. So the engineer who knows what good looks like gets faster. The one who does not gets more code, more quickly, in a shape nobody understands.

Writing is running the same experiment right now. With one difference that makes it worse.

The two crafts are closer than they look

I write books and I build software. The editing process maps onto the development cycle almost stage for stage.

A structural edit is architecture. What is this thing, what are its parts, does the shape hold weight. Get it wrong and everything built on top has to come down.

A line edit is refactoring. Nothing is broken. The chapter works. You are changing how it reads, how it moves, whether a person wants to keep going. It is the pass that separates functional from good, in both fields, and it is the one most often skipped in both.

A copy edit is linting. Rules, consistency, style enforcement. Largely mechanical, painful when neglected.

A proofread is the final build check on the artifact you actually ship. Not on the source. On the thing the reader receives.

Even the sequencing error is identical. Copy editing a chapter you are about to cut is the same mistake as optimising a function you are about to delete. Both feel productive. Neither is.

The difference that matters

Code has a compiler. It has tests, a pipeline, a staging environment, and eventually a production incident with your name on it. When a junior engineer accepts bad AI output, the system catches it. Not always, not immediately, but there is a mechanism that says no.

Prose has none of that. A weak chapter compiles perfectly. A flattened voice passes every check. There is no build that fails, no test that goes red, no alert at three in the morning.

So the writer using AI without craft does not get caught. They get a manuscript that reads acceptably, and they find out eighteen months later, in the form of readers who do not finish it and reviews that say the book was fine.

That is the worst outcome available. Bad work gets fixed. Forgettable work does not, because nobody can tell you what to fix.

Engineering has a name for this. Technical debt. Code that runs, that nobody understands, that costs more every quarter you leave it. Half of all code is now machine written, and 55% of engineering leaders say codebase comprehension is their biggest concern. They are describing a book nobody can edit because nobody knows why it is shaped the way it is.

Where I draw the line

I use AI for formatting, https://aksharakit.com/. I build AI systems for a living, so I am not going to pretend otherwise.

I will not use it to write the story. I will not use it to make structural changes to a first draft.

Both refusals are about the same thing. A model can tell me the pacing sags in the middle. It cannot know what I was trying to do, because I have not finished working that out myself yet. The first draft is where the book decides what it is. Handing that over does not save time. It produces a book that is about nothing in particular, competently.

The engineering parallel is exact. AI is good at implementing a specification. It is bad at deciding what the specification should be. Architecture stays with the person who has to live with the consequences.

After that, the ground changes. Once the structure is settled and the intent is mine, the downstream passes are work I can delegate with review, the way I would delegate a refactor to someone competent and then read the diff.

The word doing the work in that sentence is review.

You have to be the test suite

That is the practical takeaway, and it applies in both fields.

If you are writing with AI, you are the compiler. Nothing else is going to catch a bad suggestion. Which means you need to be able to do three things.

• Recognise a structural problem when you see one, and know it is structural rather than a sentence problem
• Tell a line edit from a copy edit, because a model will happily do one when you needed the other
• Say why a sentence is wrong, not only that it feels wrong

If you cannot do those, you are not editing. You are accepting. In engineering that is called merging without review, and we know exactly how that ends.

None of this is an argument against the tools. I use them every day. It is an argument that they multiply what you already have, which is very good news if you have spent years learning the craft, and much worse news than advertised if you were hoping to skip that part.

The tools got faster. The apprenticeship did not get shorter. It just stopped being obvious that you skipped it.