A friend of mine, let’s call him Oli, doesn’t work in tech. He is a very capable computer user and what people now call a “citizen developer,” but he is not a software engineer.
He has been circling the same product idea for years and discussed it with me back in the day. A few days ago, he told me it was live. Properly live. He had described what he wanted to ChatGPT Codex (new tab), kept working with it until he got what he wanted, and ended up with a real product. Sign-ups, user accounts and customer details stored in a database. He was delighted, and he had every right to be.
While he was telling me about it, the engineer in me was already making a list of awkward questions. Where exactly does the customer data live? Who can access it? Is there anything stronger than a password between the Internet and everyone’s records? What authentication system is it using? Did the agent build that authentication itself? What is being logged? What happens when something goes wrong?
I have known Oli for years and I know he cannot answer most of these questions. Truthfully, I didn’t want to ask them either. Partly because I didn’t want to embarrass him, and partly because I didn’t want to sound like, “you thought you didn’t need engineers anymore, but here I am telling you that you do.” So I wrote this article instead. Hopefully he isn’t reading it.
This is the strange place we have reached. Someone with no software-engineering background can now build something useful that stores other people’s data. That is genuinely impressive. Put the same application inside a regulated company, though, and the questions start immediately.
The term was meant as a joke
Oli vibe coded and, funnily enough, he knew the term and used it himself.
Vibe coding started as a joke, or at least as a deliberately unserious description of a new way of building software. On February 2, 2025, Andrej Karpathy described it (new tab) as fully giving in to the vibes, forgetting that the code exists, accepting changes without looking at the diffs and feeding errors back to the AI until they disappear. He was also quite clear about where he was using it: throwaway weekend projects.
The Internet did what the Internet does with a good phrase, and the name became a sensation. Within months, the term covered everything from someone building an experiment on a Saturday afternoon to production applications with real customers and real money involved. “We vibe code” slowly began to sound like a development methodology.
I can understand why the phrase survived. It describes something genuinely new. Someone like Oli can now build useful software alone, and I don’t want to dismiss how significant that is. A few years ago he would have needed to learn programming, find a developer or give up on the idea. Now he can try it himself.
Karpathy himself didn’t stay with the term. In a retrospective in February 2026 (new tab), a year after coining it, he described professional work with coding agents as happening with much more oversight and scrutiny. His preferred term became agentic engineering. Agentic because you are increasingly orchestrating agents rather than typing every line of code yourself, and engineering because there is depth to the skill and you can get better at it.
That description makes much more sense to me, although I would stretch the engineering part beyond the skill of the individual using the agent. The practices and processes around the agent matter just as much. One person can practice agentic engineering, but in a company it quickly becomes a team discipline.
The goal is to claim the leverage from the use of agents but without any compromise on the quality of the software.
Yet much of the industry kept the old term. I have even seen people trying to add rules, controls and engineering practices to vibe coding, effectively trying to regulate a word that was coined to describe working without those things.
The nth feature is when the trouble starts
The first version is where coding agents look magical. You describe something, the agent writes a surprising amount of code and suddenly there is an application on the screen. Add another feature and it appears. Then another one. The interesting part is what happens later.
I have to admit, with the context memory of today’s coding agents and the tooling around them, I think an acceptable level of engineering is within reach of almost anyone prepared to put some effort into understanding it. Concepts such as shifting left, TDD, separation of concerns and automated testing aren’t particularly difficult to understand. You don’t need to become an expert in all of them before building anything, but knowing that these practices exist already changes the way you instruct an agent.
I learned this myself. About a year ago I was tinkering with agentic coding tools such as Lovable (new tab) and Cursor (new tab), and eventually landed on Augment Code (new tab) because, at the time, its large context memory appealed to me.
I wanted something slightly more realistic than a Mickey Mouse project, so I picked a units-conversion application. I deliberately tried to vibe code it. I put my engineering background to one side as much as I could and concentrated on writing decent specifications. Thinking about it now, even writing decent specifications probably benefited from having an engineering background, but that is another subject. I assumed there would be instructions somewhere behind the scenes telling the coding agent to follow sensible software-engineering practices.
There weren’t.
The first few features went very well. Then, as the application grew, every additional feature became a little harder. Changes began affecting things that had previously worked. Fixing one problem would occasionally create another. Anyone who has maintained a badly structured application will recognize the pattern.
What I eventually realized was that I had never actually told the system what engineering meant for this project. I was assuming it would somehow infer all the best practices and do that by default, but it didn’t.
For Oli, learning some of those practices is a personal choice, and at the moment he probably doesn’t even know that choice exists. Engineers working within a regulated environment cannot vibe code, especially when it comes to handling personal information or sensitive data. That doesn’t mean they cannot use agents to write code. They absolutely can, but it should be done in a structured, audited and secure way, read: agentic engineering.
Code is no longer the expensive part
For most of my career, code has been the expensive item. I have spent a fair amount of time in rooms where teams debated estimation methods. Story points, T-shirt sizes, planning poker and what have you. We protected sprint capacity, moved features between releases and queued work for months because turning requirements into working software took time.
A lot of the Agile machinery we have been using since the late 2000s was built around that reality. Then coding agents arrived and made the construction part dramatically cheaper, very quickly. I don’t think our delivery processes have caught up yet.
An agent can produce a working implementation of a reasonably well-described feature in minutes. That doesn’t make software free because somebody still has to decide precisely what should be built, whether the generated implementation is correct, whether it is secure, whether it breaks anything else and whether it should be allowed into production.
The expensive part has moved elsewhere. Writing a good specification is expensive. Reviewing what came back is expensive. Testing it properly is expensive. Security is expensive. Making sure somebody can explain six months later why a particular decision was made is expensive.
There is an irony here because most of these practices are not new at all. We have been talking about specifications, automated testing, code review, observability, security and traceability for years. What changed is the ratio. When producing another thousand lines of code was expensive, some engineering disciplines could become checkpoints around construction. When an agent can produce those thousand lines while you make a cup of coffee, the checking and governing mechanisms have to operate at roughly the same pace.
Otherwise we end up optimizing the delivery process around a bottleneck that has already moved.
Governance is where vibe coding runs out of road
Agents have also moved pressure onto code review. Lee Boonstra, an engineer in Google Cloud’s Office of the CTO (new tab), described this happening inside her own team. Agent-generated commits were arriving faster than the traditional review process could comfortably absorb, and reviewers started approving changes reflexively through fatigue. Her conclusion was straightforward: “Guardrails aren’t optional.”
That problem is going to become familiar. If an agent can generate code much faster than a human can review it, then simply keeping the old pull-request process and increasing the volume isn’t going to work forever. Review itself needs engineering, and this is where governance comes in. Governance sounds like a grand word until you write down the questions.
What is your code-review process, and is it actually followed? Who has access to source control? What privileges do they have? Where is the specification that this implementation was built against? Who reviewed the security implications? Who approved the release? Who owns the application when it reaches production? What evidence is left behind if an auditor asks how a particular change happened? Have you segregated dev and prod?
A regulator, an auditor, a security review or a serious production incident will eventually ask some version of these questions.
A vibe-coded application gives you surprisingly little to point at. There may be no specification beyond a conversation with an agent, no reliable record of what was checked, no defined review process and nobody whose name sits clearly against the decision to release it. Oli doesn’t have an auditor. Most of the companies I work with do.
Closing remarks
I still cringe a little when I hear professionals describing production development as vibe coding. If somebody tells me they vibe coded a tool over the weekend, fine. I know exactly what they mean and I have done the same thing myself. It is fun, extraordinarily productive and probably one of the best ways of experimenting with what these agents can do.
Using the same term for professional software stretches the joke beyond usefulness. Agentic engineering needs a set of practices that fit the speed at which agents now work. Some of those practices will be familiar: TDD, peer review, CI/CD, observability, good architecture and shifting security left. Others will have to change because reviewing ten agent-generated changes a day is a different problem from reviewing one human-written change.
Security deserves its own discussion and I have barely touched it here. Governance deserves the same attention. The important thing for me is that these practices are part of agentic engineering itself. They cannot be something we bolt on afterward once the agent has finished generating the application.
Coding agents can now produce an astonishing amount of software. A company still has to know what it built, why it built it, who checked it and who owns it when something goes wrong.