“Building the app was easy compared to wiring Vercel, auth, payments, DNS, secrets, and production settings.”
That is Andrej Karpathy at Sequoia Ascent, describing what it actually took to ship a small app called MenuGen. The person who gave the industry vibe coding has now named its professional successor: agentic engineering. Vibe coding raises the floor, so anyone can make software. Agentic engineering raises the ceiling, and it is a discipline: coordinating fallible agents without giving up correctness, security, taste or maintainability.
The naming is overdue and the definition is right. But read that first sentence again. The model wrote the app. A very good engineer then spent his time on plumbing.
The discipline is real, and it is being described as a personal skill
The practices are converging fast, and they are sound. Write the spec before you prompt. Review the agent’s diff with the rigour you would give a colleague’s pull request. Treat tests as the harness the agent iterates inside, not as a chore afterwards. Isolate worktrees, manage permissions, inspect what came back. Addy Osmani puts the split plainly: “AI does the implementation, human owns the architecture, quality, and correctness.”
Karpathy is blunter about where the responsibility sits. You are not allowed to introduce vulnerabilities because of vibe coding. You are still responsible for your software, just as before.
Every one of those is a description of what a good engineer does. Which is why the same discourse keeps landing on the same uncomfortable observation: this disproportionately benefits senior people. If the discipline lives in an individual’s judgement, then the quality of your software is a function of who happened to be at the keyboard.
That is a fine answer for a founder shipping a side project. It is not an answer for an organisation.
A quality bar that only exists in someone’s head is not a quality bar
Enterprises have spent thirty years learning this lesson in other forms. Standards that live in senior heads do not survive growth, turnover or a hiring push. They get written down, then the wiki goes stale, then someone runs a training day, then the standard quietly becomes whatever the last contractor did.
Agentic engineering makes this sharper, not softer, because the volume went up. When one Builder can open five parallel worktrees, a “productionise this for me” request to IT starts to feel like an organisational DDoS attack. The bar has to be structural: present in the loop, runnable, and the same for everyone, including the person who joined on Monday.
The good news is that this is a tractable problem. Everything a prototype gets to skip can be packaged: enterprise auth patterns, code quality conventions, service contracts, domain-driven structure, infrastructure-as-code driven workflows, differentiation between dev and prod deployment environments. Packaged that way, the practice is not advice. It is something the agent runs.
The other half of the ceiling is environmental
Now go back to MenuGen. Karpathy’s bottleneck was not the model’s capability and it was not his own discipline. It was that Vercel, auth, payments, DNS and secrets are not things an agent can reach. He says as much himself: what he wants is agent-native infrastructure, where you say “build MenuGen” and the deployment simply happens.
Hold that list next to the list an enterprise Builder faces. Identity and IAM. Secret management. Data isolation. Private registries. Infrastructure as code. CI/CD. Vulnerability scanning. An actual deploy target with an actual boundary around it. It is the same list, one order of magnitude harder, and with a compliance team attached.
Here is the trap. The obvious response to “the agent cannot reach production” is to give the agent more access, and that is exactly the wrong move in a governed organisation. The right move is the opposite: build the environment so the governed path is the reachable one. The agent should not need permission it shouldn’t have, because the safe route is already the route in front of it.
That is a change to the environment, not to the prompt.
A facade is cheap, and it feels like progress
The most useful idea in Karpathy’s talk is his account of why coding improved so fast in the first place. Traditional software automates what you can specify. LLMs automate what you can verify. Coding and maths raced ahead because they are resettable, repeatable and measurable, while other domains stayed jagged.
The Facade is about what happens when you keep the appearance and skip the verifying. Ajey Gore’s image is a film set: a storefront that is perfect from the camera’s angle, with dirt and plywood braces behind it. “A facade is built to match whatever you point at it: the demo, the coverage number, the velocity chart, the Monday dashboard.” It is Feynman’s cargo cult with better tooling. The towers get built, the headphones get worn, and no planes come, because the towers never caused the planes.
Which is the honest description of vibe coding at production scale, and it is worth being blunt about it. Without an environment and guardrails that are capable of contradicting you, this is not fast software engineering. It is cosplay: producing the appearance of software without the quality, maintainability and craft. The agent is ambivalent about which of the two it has been pointed at. “Point it at a real engineering foundation and it compounds; point it at a facade and you get a bigger facade, faster.”
Enabling this is not one job
So what does enabling agentic engineering actually look like? There is no single answer, and software engineering splits in three is a good account of why. The one engineering function is breaking into tiers that no longer do the same work, and each tier comes at this from a different starting position.
Tier one is the technology companies. Software is the product, platform engineering is a standing function, and they will go on building their own substrate because owning it is part of the advantage. For the thing they sell, this is solved.
For everything else in the same building, it is not. That platform is built for the product and staffed to the product, and the internal work queues behind it. Finance needs a reporting workflow. Operations needs an internal tool. Go-to-market has a data problem nobody owns. All of them are on the same engineering backlog, underneath the roadmap, and good luck. It is the best platform engineering in the world, pointed somewhere else.
Tier two is the large enterprise: banks, insurers, retailers, telcos, where software is critical but is not the product. There is platform capability, but it is stretched, and it is losing ground to a governance surface that grows faster than headcount. What that tier reaches for is specific. Platforms with “sane defaults and built-in guardrails”, designed on the principle of guardrails over gates. And “fractional senior expertise” rather than standing teams of specialists, with consulting shifting away from selling hours towards selling judgement.
Tier three is newer. Custom software has just become affordable for mid-market and smaller businesses, and a market is forming to serve them: small shops and independent Builders, the piece’s software plumbers, who win on understanding the customer’s problem rather than on engineering headcount. Here there is no platform capability at all and there never will be. A three-person agency now ships what used to need a department, and carries the same obligations to a client’s data that a bank carries to its own.
Those are three different problems. Tier one solved the build problem and turned it into a queueing one: the rails exist, most of the company just cannot get on them. Tier two has a governance problem: the guardrails have to hold up to somebody’s audit. Tier three has a capacity problem: the guardrails have to exist at all, because nobody is coming to build them.
What does not change is the ingredients. The same three keep turning up, in very different proportions, which is what makes this a product question rather than a bespoke one:
- A place where the guardrails are real. Not a policy document, a perimeter. Identity, data boundaries, secrets and deployment enforced by the environment rather than by everyone remembering. The bank needs that to satisfy its own controls. The small shop needs it because a client’s obligations do not scale down just because their supplier is small.
- Defaults that are actually the default. The golden path has to be the path of least resistance, or Builders route around it. And it has to be maintained centrally, so best practice arrives as something an agent executes instead of something each Builder is expected to have read. This is the difference between a client portal that is production software and one that is Gore’s facade with a login screen on it.
- Expertise you can reach on the day you need it. Judgement is the scarce input and it is unevenly distributed. The enterprise cannot put a senior specialist on every team. The small shop does not have one to put anywhere. In both cases the answer is the same: make one reachable in an afternoon rather than in a hiring round.
This is the job Alis Build does, and it is deliberately all three. It stands up a production-grade foundation in your own Google Cloud, with Git, CI/CD, artifact management, infrastructure as code and governed model access already wired together. It carries the practice as skills your AI harness runs natively, published by your own team, by trusted vendors and by the community, so the safe path is also the fast one. And when a skill is not enough, a Build Specialist is bookable by the hour for the database work, the complex agent build or the codebase takeover, which is fractional senior expertise with the procurement cycle removed.
The bank and the four-person partner want very different things from that, and both get them off the same rails. Production discipline should not be a function of how many engineers you can afford to employ.
Karpathy’s sharpest line is about people, not tooling: you can outsource your thinking, but you cannot outsource your understanding. That is true, and it is worth defending. It is also worth noticing that understanding is not the only thing you need. A discipline needs somewhere to be practised, and most organisations are currently asking their Builders to practise agentic engineering in a place that was never built for agents, against standards nobody maintains, with nobody to call when it gets hard.
Give them the place, the path and the people to call. Then the bar is something you can actually hold them to.