The point of the investigation is not to end up investigating yourself.
It is very easy to make fun of vibe coding right now. AI writes bad code, AI does not understand architecture, AI creates technical debt, and AI can build a beautiful demo that collapses the first time it touches a real product. Fair. That happens.
But there is a small problem with this story: we have seen it before. Before Claude Code, Cursor, Copilot, Codex, and all the other AI coding assistants, were we living in a monastery of clean architecture? Every spec was polished? Every hotfix went through an architectural review?
We were already writing ad hoc code. We were already shipping hacks because “the release was burning.” We were already capable of accumulating a month of technical debt in a week and then explaining it with a very adult face.
We had a whole genre for this: explaining a stupid mistake with a serious face until it sounded like an architectural event. Not “I accidentally wrote https instead of http,” but “the problem space required a transitional integration pattern.”
And then came the usual routing of responsibility: the spec was vague, the deadline moved, the business changed its mind, product was still figuring things out, and of course we would do a proper refactor later.
So when I hear that vibe coding creates bad code, my first question is: compared to what? Compared to ideal engineering from textbooks — yes, it looks dangerous. Compared to ordinary product development reality in many codebases? Vibe coding does not look like a new disease. It looks like the same disease on fast-forward.
AI did not invent bad engineering. It made bad engineering faster, cheaper, and much harder to ignore.
Terminal noir: the most suspicious line in the blame output still says “author: you”.
Developer excuses are deprecated since v5.6
Fake release notes: developer excuses deprecated since v5.6.0.
The funny part is not that AI is innocent. It is not. AI can generate nonsense with the confidence of an industrial machine. The funny part is that most of these sins were well-known long before the model showed up.
When a human wrote a hack, the hack had a biography. It had context. It had a deadline. It had a tragic backstory. When a model writes the same hack, we immediately call it slop and act as if responsibility evaporated.
You can even build a small phrasebook:
| Developer says | What it actually means | When AI did it |
|---|---|---|
| “This is a temporary solution” | A terrible hack I wrote | AI slop |
| “This is a terrible hack” | A terrible hack someone else wrote | Finally, proof that AI is dangerous |
| “We unblocked the release” | We pushed a workaround because everything was on fire | AI blindly coded a pile of hacks |
| “We iterated quickly” | The architecture changed mid-flight and not everywhere | AI does not understand architecture |
| “This is a pragmatic compromise” | Technical debt, but right now it is convenient not to think about it | AI creates technical debt |
| “There are a few complications” | My code is buggy | AI failed on edge cases |
| “The code is a bit muddy” | Someone else’s code has no comments | AI generates unreadable code |
| “The code speaks for itself” | My code has no comments | AI does not document decisions |
| “We will need to rework this later” | It works, but I do not fully understand how | AI wrote unmaintainable code |
| “That is how it evolved historically” | Nobody knows why this works anymore | AI breaks legacy context |
| “That is out of scope” | I do not like this feature | AI does not understand product intent |
| “We need to clarify the requirements” | The current spec can produce almost anything | AI did not do what I meant |
| “We need an architectural refactor” | The project already has four ways to do the same thing | AI added the fifth |
| “Production will tell us” | There are no tests, but we really need to ship | AI cannot be trusted without tests |
| “We did not have time” | We consciously chose speed over quality | AI lowers engineering quality |
| “We will pay down the debt later” | Never | AI creates uncontrolled technical debt |
| “Let’s check git blame” | Let’s find out who did this and hope it was not me | AI slop has no owner |
| “Git blame will not help here” | It probably will, but I already know the answer | The model ruined everything by itself |
| “There is historical context here” | git blame shows my name | AI does not understand legacy |
| “It was a temporary solution” | git blame shows it has been living here since 2021 | AI creates unmaintainable code |
That is the uncomfortable part. At least in the old world, we had git blame. You could inspect the “temporary” hack from three years ago, quietly see your own name, take a deep breath, and close the tab. Ritual complete.
With AI, the story becomes more convenient. Nobody is responsible. The tool did it. Except git blame should still point to a human being: the person who wrote a vague task, accepted the diff, skipped review, or merged on a Friday because “it looked fine in the demo.”
“It did not do what I meant”
One of the most common complaints about AI coding is: “It did not do what I meant.” Right. And humans always did exactly what you meant?
A developer does not read minds either. A developer builds what they understood from the ticket, the old code, the deadline, the Slack thread, the strangely named method called processNewDataV2Final, and the three contradictory comments in the PR.
With AI, many people simply removed that step. They write “refactor this,” “fix the bug,” “add payments,” “improve the architecture,” or “make it production-ready,” and then they expect the model to reconstruct product intent from vibes alone.
But “improve the architecture” is not a task. It is an incantation. Improve it for what: speed of development, security, testability, minimal diff, backward compatibility, migration safety, alignment with existing patterns? That is the actual task. Without it, you are not delegating engineering — you are delegating guessing.
If we point vaguely into the fog, we should not be shocked when AI confidently builds a microservice there.
A person points into the fog; an AI agent is already building a microservice architecture inside it.
AI does not read minds. And honestly, that is a useful slap in the face for the whole industry: apparently, describing the task still matters.
AI does not break the process. It puts the process into turbo mode
AI tools do not enter a sterile laboratory. They enter a real codebase. And many real codebases are already having a wonderful little festival: tests exist, but mostly as decoration; CI is green because it checks the easy paths; three patterns compete for the same job; module boundaries are polite fiction.
Then we launch an AI agent into this environment and everyone is surprised: “It created chaos.” No. It found chaos and started following its rules. If the project already has three ways to do the same thing, the model will add a fourth. If boundaries are fuzzy, it will cross them. If requirements are muddy, it will generate muddy code at impressive speed.
The model is not your engineering culture. It is a mirror with a GPU attached.
A GPU-powered mirror: the reflection is not a robot, but a tired developer with legacy context.
AI does not break the process. It puts the existing process into turbo mode. In a mature system, that accelerates useful work. In a broken system, it accelerates the brokenness. A well-run team with clear contracts, tests that mean something, and an explicit runtime layer for tools gets leverage. A team that already ships on hope gets hope, faster.
Good vibe coding looks suspiciously boring
Bad vibe coding looks magical: “I wrote two lines and AI built the feature.” Good vibe coding looks much more boring: “Here is the context. Here is what we are changing. Here is what we are not touching. Here are the critical scenarios. Here are the files you must not touch. Here are the project patterns. Here are the tests that must pass.”
Boring? Yes. It works.
The model can write code, but a human must check the meaning. The model can suggest an abstraction, but a human must decide whether the system actually needs it. The model can generate tests, but a human must verify they test behavior — not the illusion of behavior.
AI is not a magical architect. Steve Jobs once called the computer a bicycle for the mind; in that metaphor, AI is an electric scooter for the mind. Faster, no pedaling required, helmet optional, very capable of arriving at the pole sooner.
Notice the important part: it is still for the mind. Your mind. Yes, AI sometimes delivers confident nonsense with the facial expression of a senior staff principal distinguished engineer — but so do you, occasionally. Give a vague task, get a fast vague answer. Give a good frame, get acceleration.
AI as an electric scooter for the mind: faster, useful, and very capable of hitting the pole faster.
Code is getting cheaper. Clarity is getting more expensive.
This is probably the real shift. AI made code cheap: not good, not safe, not maintainable — just cheap to produce. You can now generate a thousand lines of almost correct code very quickly. And that “almost” is the dangerous part.
There is a useful way to think about programming: it is less like typing text and more like watchmaking. What matters is not the number of parts; what matters is how precisely those parts mesh. One gear slightly off and the whole mechanism lies.
AI code behaves like that. One inaccurate assumption in the requirements, one unnecessary abstraction layer, one misunderstood edge case, one test that verifies the illusion of behavior instead of behavior — and the system looks fine until production teaches it otherwise. That is the same failure mode production ML teams know well: not always wrong, but wrong with variance.
That is why the problem is not just that AI sometimes makes mistakes. The problem is the variance of those mistakes. If precision varies too much, fast generation stops being acceleration and starts being roulette. Applied AI is not a web service — and neither is AI-assisted coding. The hard part moved upstream.
Development did not become simple. Complexity moved. Before, writing code was expensive; now, clear thinking is expensive. Clear requirements, clear boundaries, clear risk, clear review — that is the new bottleneck. The teams that treat RAG and retrieval as “just plumbing” discover the same thing: the expensive part was never the typing.
So the story is not “AI writes bad code.” Yes, it does. But so did we. The difference is that bad code can now appear faster, cheaper, and with a much more convenient suspect.
You can complain about slop, agents, vibe coding, and how “engineering used to be more serious.” But are you really going to uninstall Cursor, Claude Code, Copilot, Codex, and go back to autocomplete and stubborn pride?
We will complain. We will reject bad diffs. We will say, “the model produced another architectural crime scene.” And five minutes later, we will ask it to explain legacy code, find duplicates, draft a migration plan, or write the test we have been avoiding for six months.
Meme insert: “Then maybe don’t talk about it, sir.”
Frequently asked questions
What is “git blame codex” about? It is an opinion piece on AI-assisted coding arguing that most complaints about AI slop describe sins engineering already committed — AI just made them faster, cheaper, and harder to hide behind git blame.
Does AI coding create more technical debt than humans? Not necessarily more — but faster. The same vague specs, missing tests, and architectural drift that produced human-written debt now scale with agent speed.
Who is responsible when AI writes bad code? Still the human who accepted the diff. Git blame does not point at the model — it points at whoever merged the change, wrote the prompt, or skipped review.
Why do people say AI “did not do what I meant”? Because the task was underspecified — same failure mode as handing a vague ticket to a human. Clear boundaries, files, and acceptance criteria matter more with agents than without them.
What does good vibe coding look like? Boring on purpose: explicit context, scoped changes, off-limits files, critical scenarios, project patterns, and tests that verify behavior — not illusion.
Is AI an electric scooter for the mind? That is the article’s metaphor: faster than a bicycle, still requires a rider, still capable of hitting the pole harder. AI accelerates whatever process already exists.
Should teams stop using AI coding assistants? The piece argues you probably will not — and should not pretend the scooter does not exist. The real question is who holds the handlebar.
Related reading
- Vibecoding Is the New PHP — same movie, different cast
- Multi-Agent Systems Architecture — what happens when agents enter real codebases
- Model Context Protocol as a Runtime Layer — tooling boundaries for LLM agents
- Why Machine Learning Models Fail in Production — when “almost right” is the dangerous part
- Applied AI Is Not a Web Service — complexity moved upstream
- RAG Architectures in Production — retrieval is not magic glue
- AI Development services