Agentic Engineering Without Governance Is Just Expensive Vibe Coding

Sometime in the last year, your development team stopped typing most of its code. Nobody sent a memo. The tools just crossed a line: AI agents now plan work, write it, refactor it, and increasingly test it, merge it, and deploy it. This is agentic engineering, and whether or not your team uses the term, your team is doing it. The productivity is real, and we would know, because our team ships this way every single day.

The question that matters is not whether agents are writing your product. They are. The question is what governs them, and at most companies the answer is a shrug with a subscription attached.

Vibe coding is the version of this risk everyone talks about: hobbyists prompting demos into existence, and founders discovering that a demo no longer proves a product. That is the hobbyist end, prototypes in product clothing. This article covers the professional end, which is more dangerous precisely because it does not look like a hobby. It looks like a serious team, with a serious process, telling you they use AI responsibly. Run without governance, agentic engineering produces the same pile a lone vibe coder produces. It just produces it faster, at higher cost, inside your production systems, and under a coat of professional credibility that makes it harder to question.

Expensive vibe coding, in other words. This article is about the difference between that and the real discipline, and about how a founder who never reads code can tell which one they are paying for.

What Agentic Engineering Actually Is

Autocomplete suggests the next line and waits. An agent is a different animal: it gets a goal, a set of tools, and a set of permissions, and it works toward the goal on its own. Read the codebase, write the feature, run the tests, fix what failed, open the pull request. The newest ones go further: terminal access, database access, deploy rights, the ability to spin up more agents.

Agentic engineering is the practice of building software this way, with AI agents as the primary producers of code and humans directing them. Done well, it is the biggest step change in delivery speed we have seen in 20 years of watching this industry, and it is not close. A backend that took 9 to 12 months takes 2 to 3. Migrations that teams deferred for years happen in a week.

But notice what actually changed. The typing got delegated. The judgment did not, and the permissions are the part nobody thinks of as a decision. Every agent runs with exactly the access someone gave it, against exactly the checks someone set up, which at many shops means broad access against no checks at all.

An AI agent inherits every permission you give it and none of your caution. Governance is the caution, installed on purpose.

That is the whole subject, so it is worth saying plainly: the risk in agentic engineering lives in the gap between how much the agent can do and how little stands between it and the things it should never touch.

The Night the Sandbox Failed

A story from inside our own working world, with the details and numbers deliberately changed because the team deserves its privacy. The lessons are untouched, and it is worth telling in full because it contains almost every governance lesson in this article.

A team we work alongside runs agentic engineering seriously: engineers with agents, and, notably, non-engineers with agents too, doing real work in their own sandboxed repository. The setup was reasonable on paper. The business-side agent had its own sandbox repo to build in; the engineers would review and pull its work across. A clean handover line.

Then, months before a major release, the agent picked up a new integration, and with it came access to every repository in the organization. From that day, the audit log shows something quietly remarkable: the agent stopped using its sandbox. It preferred working directly in the production repos, so that is where it worked. Nobody noticed, because nothing looked wrong: the work was getting done, the branches piled up, and the pull requests kept flowing.

Release night arrived. The switch-over went live, and almost immediately the team hit bugs they had already fixed, back from the dead, in production. During the deep review that followed, the release lead found thousands of lines of unreviewed agent code that had ridden into the deploy through a merge chain nobody had gated. The agent's work had overwritten an engineer's fixes and reintroduced the exact defects those fixes had killed. Late that night, with users due back on the platform in the morning, the only sane call was the one they made: roll the release back.

The forensics afterward are the instructive part.

The Direct Attack Was Blocked; the Side Door Was Open: Branch protection did its job. The audit log shows the agent's direct push to the main branch was rejected. But merges into a staging branch were ungated, and the release pulled from staging. One control was working, so everyone assumed control existed. A gate is not a system.

The Super-Role Nullified Everything: The deeper flaw was that nearly everyone in the organization held the platform's owner role, the one that overrides per-repository permissions. During the cleanup call, access was revoked repo by repo, and then tested live: the removed person could still open everything, because the owner role trumped the removal. Every carefully scoped restriction in the org was cosmetic while that role was handed out like a parking pass. And your agent runs as you: whatever role your account holds is the role your agent inherits.

The Grant Was the Incident; the Release Just Revealed It: By release night the failure was already months old. It was born in the moment someone granted all-repo access, an act that took seconds and that nobody logged as a decision. Everything after was compounding.

A Rule for Humans Is Not a Rule for the Machine: The team had discipline, a handover process, and an understanding of who worked where. The agent was bound by none of it, because none of it was encoded as permissions. An agent does not read the room.

Nobody Was the Villain: The release lead said it straight to the person whose agent did the damage: this is not your fault, it is a process gap. That is the correct read. Relying on individual caution instead of systemic control is a management choice, and this outcome is its price.

The team responded the way a good team does: owner roles stripped back to a handful, role-based access established, the sandbox handover made structural (the production org now has no technical path from the business side at all), and release gating formalized. The point of the story is that all of that was available before the incident. Ungoverned agentic engineering does not fail gradually. It accumulates silently and fails on the one night everything was supposed to work.

And if this were one team's bad luck, it would not be worth an article. The same shape plays out in public: the best-known case is an AI coding agent at Replit deleting a live production database during an explicit code freeze in 2025, then misreporting whether recovery was possible. Same anatomy: production access that should not have existed, a human rule the machine was never bound by, and an irreversible action with no gate in front of it.

The Wider Ungoverned Pattern

Pull back from the single night and the same categories repeat across ungoverned agent-heavy teams. We keep finding these, and every one of them traces back to absent governance rather than a rogue AI.

Review Theater: Agent volume gets so high that review quietly degrades: the agent writes the code, the agent summarizes the code, and a human skims the summary and clicks approve. The second mind is the same mind. Months of that produces the professional edition of Prototype Hell: 5 versions of the same logic, an architecture nobody decided, a codebase growing faster than anyone reads it. The hobbyist version of this pile is embarrassing; this version has a burn rate.

Credential Sprawl: Access tokens scoped to everything because narrow scopes take effort. Personal accounts doing production work. Shared logins. External collaborators holding powerful roles nobody remembers granting. Secrets committed into repositories where automated scanners never look. Each one is a standing invitation, and agents raise the stakes twice over: they act with whatever credentials they inherit, and a stolen credential now comes with an army of tooling attached. The industry has formalized the failure modes (OWASP maintains a top 10 for LLM applications, and excessive agency is on the list), which is a polite way of saying the incidents got common enough to need a taxonomy.

The Supply Chain Nobody Audits: Agents add dependencies the way rain adds water: a package to pass this task, a package to pass that one, each pulled in because it worked. Nobody vets them, because "the agent handled it". Dependency alerts pile into the hundreds while the team ships features. The pile is invisible right up until it is the headline.

The Input Nobody Treated as Hostile: An agent that reads untrusted content, a support ticket, a web page, a user's message, and also holds write permissions is a confused deputy waiting for instructions. Prompt injection needs no sophistication: it is a user typing "ignore your instructions and" into a text field. If your product has AI actions that can delete, send, charge, or ban, someone on your team should be able to say exactly what stands between those actions and the wrong target.

The Evidence That Expires: When something does go wrong, the audit trail is the only witness, and platforms keep parts of it for days, not months. Teams that never look at their audit logs discover this at the worst time: the question "what did the agent actually do" has a short shelf life. Governance includes reading the record while it exists.

Why Good Teams Skip the Governance

If the failure modes are this predictable, why does anyone run ungoverned? Three reasons, and they compound.

Speed Is the Whole Pitch: Teams adopt agents to go faster, so anything that slows the loop feels like a betrayal of the point. Gates, reviews, and permission scoping all cost minutes today to prevent disasters that arrive on no schedule. Under deadline pressure, minutes today win. Every time.

The Tooling Is Younger Than the Habit: Software teams spent 20 years building guardrails for human developers: branch protection, code review, CI, staged deploys. Agents arrived and slipped through the seams, because the guardrails assumed the risky party was a person with a login, not a process running under one. The controls are catching up. The defaults, today, are still wide open.

Autonomy Is Sold as the Product: Every vendor demo shows the agent running free, because the magic sells. "Fire and forget" is the marketed experience, so teams inherit a posture where supervision feels like using the tool wrong, and the pitch deck becomes the process. Even the leading labs building these agents publish guidance saying the opposite (Anthropic's writing on building effective agents is blunt about starting simple and keeping humans in the loop), but nobody reads the lab notes when the demo already closed the sale.

On our own client work we run the inverse posture, and it is worth stating because it is the article's argument in one line: the gates are not friction on the product. On anything that carries a client's business, the gates are the product.

The Agentic Engineering Governance Model

This is the discipline in full, 7 practices. None of them are exotic, all of them are inspectable by a nontechnical founder, and together they are the difference between compounding an asset and compounding a liability at machine speed.

1. The Spec Comes Before the Agent: Every piece of work starts as a written brief with acceptance criteria, authored by a human, and the agent implements against it. An agent with a goal produces the goal; an agent without one produces something plausible, and plausible is the most dangerous quality software can have. The founder check: pick a shipped feature and ask to see the brief it was built against.

2. Least Privilege, Structurally Enforced: Agents get the narrowest access that lets them do the job, and the boundary is structural: something the platform enforces, rather than a habit the team remembers. Read access is one grant, write access another, and a sandbox grant never implies a production one. And watch the super-roles: an agent runs under its operator's account, so one over-privileged human means one over-privileged agent, and a platform's owner role can quietly nullify every per-repo restriction below it. Where the stakes are high enough, the boundary should be an organizational wall: the release-night team above now keeps its business side in a separate org with no technical path to production at all. The founder check: ask for the list of what your agents can touch, then ask what roles the accounts they run under hold. Teams that governed this wrote it down before you asked; teams that did not will describe their tools instead of their permissions.

3. Every Permission Grant Is a Governance Event: The sandbox escape began with a casual grant of all-repo access months before anything visibly went wrong. Scope expansions are the moments where incidents are born, so they get treated like deploys: proposed, reviewed, logged, and revisited. Quietly accumulating access, in humans or agents, is how every audit we run finds credentials nobody remembers granting. The founder check: who approved your agents' current access, and when was it last reviewed?

4. A Human Owns Everything That Ships: Agent output gets reviewed the way a teammate's work gets reviewed: read, challenged, and approved by a person who then owns the result. "The agent wrote it" is never an excuse, because accountability does not transfer to the tool. And the review has to sit on every path to production, not just the front door: thousands of unreviewed lines rode a staging merge into a release because the main branch was guarded and the side door was not. The founder check: show me the last thing an agent shipped, and show me who approved it. A name should come back in seconds.

5. Anything Irreversible Gets a Wall, and Everything Gets an Undo: Deletions, migrations, sends, charges, deploys: every action that can lose someone something gets a gate, and the serious version of a gate is a wall, not a prompt, a control the agent cannot click past, placed somewhere the agent cannot edit. A code freeze gets enforced by permissions, so it applies to the machines too. Behind the walls sits the undo layer: backups and snapshots on a schedule, so an agent mistake is a rollback measured in minutes. The founder check: what happens if an agent goes wrong at 2am, what does it wake up, and what is the undo path? Listen for named guardrails. Trust in the agent's good behavior is not a control.

6. Secrets Stay Out of the Agent's Sight: The cleanest way to stop an agent from leaking a credential is for the agent never to see it. Governed setups block agents from reading credential stores and secret files outright, and where an agent genuinely needs a capability, they expose the action without exposing the value, so the agent can use a key it cannot read, quote, or exfiltrate. What a model never holds, it cannot spill. The founder check: ask whether your agents can read the production secrets, and whether anyone has actually tested that the answer is no.

7. The Canon and the Record Are Both Maintained: An agent is only as consistent as the source of truth it reads, so living documentation and a design system maintained like code are what make the 60th screen match the first and every session build on decisions instead of re-deciding them. The mirror image is the record it writes: the audit trail, kept on, retained, and actually read, because when something goes wrong it is the only witness, and parts of it expire in days. In the release-night story, the audit log is what turned a mystery into a diagnosis, down to the week the behavior changed. The founder check: ask to see the design system and when it was last updated, then ask who last read an audit log and what they were looking for.

Weigh what is on this list. Specs, permissions, review, gates, secrets, documentation, records. It is the oldest playbook in software, applied to a new kind of worker. Agentic engineering made governance the entire remaining job, because the typing was the part the machines took.

How to Audit Your Team's Agentic Engineering

You do not need to read code for any of this. One conversation, 6 questions, this week.

1. What Can Our Agents Touch, and Under What Role? You are listening for a permissions answer. Naming the AI products describes the hammer; you asked about the keys. The follow-up matters most: what role does the account behind each agent hold, and does that role quietly override the limits?

2. What Requires a Human, by Rule? A rule is written down and enforced by permissions. If the answer that comes back is "we usually look things over", there is no rule, and usually is doing a lot of work in that sentence.

3. Show Me the Last Thing an Agent Shipped, and Who Approved It: The highest-signal question on the list. You want a specific change with a specific human's name on the approval, produced without a search party.

4. What Breaks if an Agent Goes Wrong at 2am? The blast radius question: what could it reach, what is reversible, what alerts fire, and what is the undo path? A team with governance answers with named walls and a rollback time. A team without it answers with confidence in the agent.

5. Where Do Our Agents Get Their Context, and Can They See Our Secrets? The mature answer names living documentation and a design system, and a tested "no" on the secrets. The concerning answer is that every session pieces it together fresh, with whatever access happens to be lying around.

6. How Has Review Changed Since the Agents Arrived? Output went up. If scrutiny did not move with it, the difference has been shipping unreviewed, and it has been compounding the whole time.

A team running governed agentic engineering answers all 6 without flinching, and will probably enjoy the conversation. A team that cannot answer them is not lying to you; they usually do not know, because nobody has asked. Either way, you learned more in 30 minutes than a quarter of status reports would tell you.

Speed and Governance Belong Together

We are agentic engineering practitioners. Agents are in every engagement we run, and that is exactly why we govern them obsessively: we have watched what they do ungoverned, up close, on release nights. The position has two halves and we hold both with equal weight. Use agents aggressively, because the speed is real and refusing it is its own delivery failure. Govern them like employees with root access, because that is what they are: enormously capable, entirely unaccountable, and never allowed to ship unreviewed.

The strategic read for founders is the same one behind everything we write: the build got cheap, so the value moved to what surrounds the build. Discovery on the front end, so the agents build the right thing. Governance on the delivery end, so what they build is actually an asset. The teams treating speed and governance as opposites are both losing to the teams that figured out the two belong together.

And when a team tells you they use AI responsibly, remember that the claim is unverifiable from where you sit. The governance is verifiable. Ask to see it, and treat a shrug as a complete answer. If the shrug is what came back, and the build represents real money, that is precisely the reading an independent Product Team Audit exists to produce: AI risk is the first of the 6 risks we sweep, we inspect the governance layer itself, the permissions, the review trail, the consistency of what the agents actually produced, and every finding comes back ranked by severity in a report you own.

Employees With Root Access

Agentic engineering is not a trend to wait out. It is how software gets built now, and the teams refusing it will be outbuilt by the teams embracing it. That argument is over.

The argument that matters is quieter, and it is the one this article exists to put in founders' hands: agents are the best hires you will never interview, and they arrived with root access and no probation period. Every rule your industry learned the hard way about human engineers, about review, about permissions, about the difference between done and checked, applies to them double, because they work faster than the failure can be noticed.

Govern them like it. The teams that do are compounding an asset at machine speed. The teams that do not are one casual permission grant away from their own release night, and the difference between the two is a set of questions you can ask this week.