Three ways to work with AI-generated code — and why your mix matters
Most teams default to one approach when working with AI-generated code and never question it. Some accept everything without review. Others refuse to trust anything the AI produces. Both extremes miss the point.
There are three legitimate ways to work with AI code — and experienced developers blend them deliberately. The question isn't which approach is correct. The question is whether you've made a conscious choice about your mix.
Where the term started
Andrej Karpathy, former Director of AI at Tesla and OpenAI researcher, introduced the term "vibe coding" in February 2025:
"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. I 'Accept All' always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension. Sometimes the LLMs can't fix a bug so I just work around it or ask for random changes until it goes away. It's not too bad for throwaway weekend projects."
The key phrase: "throwaway weekend projects." Karpathy was describing one valid mode of working — not a methodology for everything. The problem isn't vibe coding itself. The problem is teams applying one approach to every situation without thinking about it.
Three legitimate approaches
Every team that works seriously with AI-generated code ends up somewhere on a spectrum. In our workshops, we see three distinct approaches — all valid, each with its own place:
| Approach | When it fits | Typical proportion | Key characteristic |
|---|---|---|---|
| Vibe coding | Simple, low-risk tasks; experienced developers who know the domain | 10-20% | Speed over review — you trust your ability to catch problems later |
| Structured balance | Daily production work; the bulk of real development | 50-70% | Reasonable planning upfront, systematic review of output |
| Hardcore planning | Complex systems, high-stakes changes, unfamiliar territory | 20-30% | Full documentation and specification before any code is generated |
The proportions aren't rules — they're patterns we observe in teams that work effectively. Some weeks are 40% vibe coding because you're prototyping. Some weeks are 80% hardcore planning because you're rebuilding authentication. The point is that you choose deliberately.
Ni kommer hitta er egen mix.
The real shift: from builder to validator
The deeper change isn't about which approach you pick. It's about what AI does to how you think.
The promise everyone sells is "think less, do more." That's not what happens. What actually happens is that you stop writing and start defining. You stop implementing and start validating. You stop building details and start reviewing systems.
None of those things are easier. They're harder. But they're harder in a different way — and that shift is invisible until you actually do it.
A senior developer at a client tested AI-assisted development for three days. Same output as manual coding. Same functionality, same quality, roughly the same time. He wasn't faster. He wasn't slower.
But he said one thing that stuck: "I had to think in a completely different way."
The builder mentality is sequential — you take one step at a time and each step gives you clear feedback. The validator mentality requires holding the entire system in your head simultaneously. You need to understand not just what the code does but what it SHOULD do, and then compare the two.
That's why experience matters more with AI, not less. The person who has built systems for twenty years has an advantage that can't be skipped.
"Om du inte tänker hårdare validerar du inte. Om du inte validerar vibe-codar du."
Conscious friction — the control point IS the work
There's a temptation to automate every step. Auto-commits. Auto-generated changelogs. Agents that push code without human review. It looks efficient. It's not.
An auto-generated changelog looks professional. It has the right format, the right structure. It's also meaningless — a summary of something nobody reviewed. The moment you automate the documentation of what you did is the moment you stop understanding what you did.
Every commit is a promise: I have read this. I understand this. I stand behind this. Remove that moment and you remove the promise.
"Jag vägrar auto-commits... Det ÄR friktion. Och friktionen är medveten."
"Automation tar bort steg. Medveten friktion gör att varje steg räknas."
This isn't inefficiency. Conscious friction is slower per step — but every step holds. And the sum of steps that hold is faster than the sum of steps that need to be redone.
No auto-commits. No auto-changelogs. No agents pushing unreviewed code. The control point isn't an obstacle on the way to delivery. The control point is the work.
Experience as the multiplier
AI is a catalyst. A catalyst accelerates a reaction — it doesn't create it. If there's nothing to react with, nothing happens, regardless of how effective the catalyst is.
A person with decades of experience building systems, delivering to clients, living with the consequences of being wrong — AI makes that person extraordinarily productive. They know what the right answer looks like. They know what looks good but is wrong. They can review, challenge, and steer.
A person without that foundation gets output — lots of output — but has no way to know if it's good or bad. And that's worse than having nothing at all, because you believe you have something.
"Du äger varje rad output. Och du kan inte äga det du inte förstår."
The three preconditions for working at scale with AI:
Knowledge. Years of building systems, delivering to clients, living with consequences. This is the foundation AI amplifies. Without it, there's nothing to scale.
Chain. Voice to text, text to structure, structure to action. Preparation before the meeting, transcript after, project tracking, daily overview. Not one tool — a chain where each step builds on the previous one.
Accountability. Every line of output passes through you before it leaves the system. This is non-negotiable. More volume without control isn't delivery — it's production of problems.
"AI föreslår. Jag bestämmer. Jag pushar. Ordningen är oförhandlingsbar."
When each approach breaks down
Every approach has failure modes. Knowing them is how you choose deliberately.
| Vibe coding | Structured balance | Hardcore planning | |
|---|---|---|---|
| Works when | Simple tasks, known domains, experienced developers, throwaway prototypes | Daily production work, familiar tech stacks, reasonable complexity | Complex systems, unfamiliar territory, high-stakes changes, regulatory requirements |
| Breaks when | Applied to production systems without review; used by developers who can't validate the output | Requirements are genuinely unknown and need exploration; or when rigidity prevents iteration | Speed matters more than perfection; scope is small; over-documentation becomes busywork |
| Risk | Security vulnerabilities, technical debt, code nobody understands | False sense of control if reviews become rubber stamps | Paralysis by analysis; documentation that's outdated before code is written |
| Experience required | High — you need to catch problems intuitively | Medium — systematic process compensates for gaps | Variable — the documentation itself builds shared understanding |
Security and compliance
Regardless of which approach you use, some things are non-negotiable. AI can generate vulnerabilities that aren't obvious during development. Systems handling personal data, payments, or regulatory compliance cannot rely on casual acceptance patterns.
GDPR, PCI-DSS, and other compliance requirements demand that someone understands and validates every component. That's true whether you're vibe coding a prototype or executing a hardcore planning process. The question is always: can someone explain what this system does and why?
The stilts metaphor
Working with AI is like learning to walk on stilts. Initially uncomfortable. Unfamiliar. You wobble. It doesn't feel like progress — it feels like regression.
But once you find your balance, you see things you couldn't see before. You reach things you couldn't reach. Not because the stilts do the work for you — but because they extend what you're already capable of.
Each person finds their own balance. Some lean forward, some lean back. Support each other when someone wobbles. That's what a team does.
This is capability building, not a magic shortcut. The stilts don't walk for you. But if you have the foundation — the knowledge, the chain, the accountability — they change what's possible.
Varje person hittar sin egen balans.
Originally published August 2025. Revised February 2026 to reflect 18 months of production experience and an evolved understanding of the spectrum of approaches.