Vibe coding works. I built a photo collage tool that way myself. Vibe engineering goes a step further: the agent writes and the engineer steers. But I think even that won't be enough.
Vibe coding works. For collages.
I admit it, I tried vibe coding and it worked :-D I needed a simple tool for photo collages. I described what I wanted, the agent wrote it, a few times I said "move this" and "make this bigger" and it was done. I never really looked at the code.
And you know what? That's completely fine. A tool for me, nothing in production, no sensitive data. If it breaks, I'll write a new one.
The problem starts when you try the same approach on a production system. There it's no longer about whether the collage renders. It's about customer data, security, operations. And "it works, so I'll leave it" isn't enough there.
Vibe engineering is the right direction
Vibe engineering does it better. The agent writes the code, the engineer steers, verifies and sets the rules. The agent gets context, boundaries and tools. The result goes through tests, CI and review.
I described what this setup looks like for us in the article Everyone has better models. Why do some teams fly while others don't?.
But even that is, in my opinion, just an intermediate step.
Code as the new assembler
When did you last read the assembler your compiler spat out? Exactly.
I think AI-generated code will end up the same way. Fewer and fewer people will read it line by line. There won't be time for it and, more importantly, it won't make sense. The value moves elsewhere. To checking intent, behavior and results.
Sure, the comparison is not perfect. A compiler is deterministic, an LLM isn't. Same prompt twice, two different results. But that's exactly why tests, CI and verifying the result will matter even more than today. If I no longer read the code, I have to be able to verify it does what it should.
Ticket closed, product not delivered
If the agent can write the code, what's left for the engineer? Everything else, I think.
Understanding the problem. Knowing who the user is and what they really need. Deciding what to do and what not to do. Deploying. Measuring whether it helped. And then taking care of it in production.
Product engineering instead of "I closed the ticket". Nobody cares about a closed ticket. They care whether the product works.
What I won't hand to an agent without understanding it
Then there are things that stay with the human. Not because the agent can't write them. It can. But without understanding them, I can't tell whether it wrote them well.
- Encryption.
- Authentication and authorization.
- Databases and data consistency.
- Performance.
- Security.
- Operations.
A real example? Token refresh. The agent wrote code that looked completely fine and the tests passed. But I found flaws in it. A short-lived token could create a long-lived one, which completely bypassed the intent that access should expire after some time. And elsewhere a token allowed reading data longer than intended.
No test failed. No error message. The code did exactly what was written in it, just not what we wanted. If you don't understand how tokens and authorization work, a bug like this will get past you even in review.
What makes a good engineer today
A good engineer in the age of agents:
- gives the agent context and boundaries,
- verifies the result with tests and CI, not by gut feeling,
- knows where to trust AI and where not to.
The last one is the hardest. And the only way to learn it is to really understand the things underneath.
So what now
- Deliver the product, not just tasks. From the problem all the way to production.
- Invest in the hard fundamentals. Security, data, distributed systems. The agent can't judge this for you.
- Build a setup where the agent works safely. Rules, tests, CI, review.
Code is becoming assembler. The engineer is becoming a product architect. Whoever stays at just writing code will be the first one the agent catches up with.
