Agentic engineering vs vibe coding, where is the line?

Vibe coding can produce a convincing demo before lunch. Agentic engineering can produce a change that your team is willing to own at 2 a.m. The visible action may look identical: a person describes an outcome, an agent edits a repository, tests run, and a pull request appears. The difference sits in everything around that action, especially who defines the constraints, who examines the evidence, and who accepts the consequences.

I have watched teams confuse speed at the keyboard with speed through production. The first feels dramatic because code appears in seconds. The second is quieter. It includes finding the right problem, protecting data, checking architecture, proving behavior, releasing safely, and learning from failures. Agents can shorten much of that path, but only when the team gives them a disciplined operating system. Without one, the agent simply creates uncertainty faster.

This distinction is not a debate about whether prompting counts as engineering. Prompting is a small part of both modes. The useful question is whether the team can explain why a change is correct, reproduce how it was made, limit what the agent may touch, and recover when the result is wrong. If those answers live only in one person's chat history, the team is still improvising.

The line is ownership, not prompt style

Agentic engineering begins when humans retain ownership of the system while delegating bounded work to an agent. Vibe coding begins when the generated result itself becomes the source of confidence. One mode says, the agent produced code that looks right; the other says, our acceptance checks, review, and release controls show that this change meets a defined contract.

That line has consequences. A beautiful prompt does not turn improvisation into engineering. Neither does an expensive model, a long context window, or a setup with multiple agents. If nobody defined the invariant that must survive the change, the agent has no reliable way to protect it. If nobody can trace a database migration back to an approved requirement, the team has surrendered design responsibility while pretending it only delegated typing.

The field often blurs autonomy with authority. Autonomy describes how many steps an agent can take without interruption. Authority describes which resources and decisions it can control. A team can allow high autonomy inside very narrow authority: the agent may edit one service, run local tests, and open a draft pull request, but it cannot read production secrets, alter billing, merge code, or deploy. Mixing up those concepts leads teams to grant broad credentials merely because they want fewer confirmation clicks.

Ownership also means a named person accepts the change. That person does not need to inspect every generated token. They do need to understand the intended behavior, the risk boundary, the proof presented by the agent, and the rollback route. When a reviewer cannot explain those four things, approval is ceremony rather than control.

Vibe coding belongs inside a sandbox

Vibe coding is useful when the cost of being wrong is deliberately small. I use it for disposable prototypes, interface sketches, data exploration with synthetic inputs, and disposable scripts whose output a human checks before using. It is a fast way to discover what a requirement should have been. Treating it as forbidden would throw away one of the best learning loops these models offer.

The boundary is not whether code reaches production. A tiny internal utility can expose customer data or delete files, while a production copy change may carry little operational risk. Look at blast radius, reversibility, data sensitivity, and the ability to verify the result. If a mistake can charge a customer, corrupt shared state, disclose a secret, or silently shape a business decision, improvisation has outlived its safe zone.

A prototype should also wear an expiration label. Teams get hurt when a Friday experiment becomes Monday infrastructure because it already seems to work. Put the assumption, owner, permitted data, and disposal date in the repository. If the prototype graduates, rewrite its acceptance criteria and pass it through the same controls as any other maintained component. Generated code does not carry technical debt differently; it merely lets you incur it at a pace that hides the total.

There is another awkward case: a founder who can evaluate the product behavior but cannot evaluate the implementation. Vibe coding may still be rational for testing demand, provided the prototype uses fake data, constrained accounts, spending limits, and a hosting boundary that can be discarded. It is not rational to infer security or maintainability from a working screen. Before real customers depend on it, an engineer must establish the architecture, threat assumptions, tests, observability, and recovery plan.

An executable contract gives the agent a job

A coding agent needs a testable change contract, not a motivational paragraph. The contract states the outcome, the files or components in scope, the behavior that must remain unchanged, the checks that prove completion, and the conditions that require a human decision. This turns an unbounded conversation into a unit of engineering work.

I prefer a small task file committed beside the work. It can be generated from an issue, but the repository copy matters because the request, implementation, and review evidence then share a history. A minimal version looks like this:

task: reject expired password-reset tokens
owner: payments-platform
scope:
  allow:
    - services/auth/reset/**
    - tests/auth/reset/**
  deny:
    - db/migrations/**
    - infra/**
invariants:
  - valid unused tokens keep their current response shape
  - logs never contain token values
acceptance:
  - unit test covers expired, used, malformed, and valid tokens
  - integration suite auth-reset passes
  - changed lines receive human review
escalate_when:
  - schema change appears necessary
  - public API response would change

The file prevents three common failures. Scope rules stop opportunistic cleanup from inflating a small fix. Invariants tell the agent what not to break, which ordinary issue descriptions often omit. Escalation conditions stop the model from quietly making a product or architecture decision when its planned route becomes inconvenient.

The contract must describe behavior, not dictate every edit. Specifying every implementation detail reduces the agent to autocomplete and preserves the human's untested assumptions. Giving too few details leaves the model to invent policy. The useful middle is observable: define inputs, outputs, forbidden effects, compatibility requirements, and proof. Let the agent propose the code path, then make it justify departures from local patterns.

An agent should return a completion record tied to the contract. Require a list of changed files, acceptance checks with their actual exit status, unresolved assumptions, and any work it skipped. A statement such as all tests pass is weak evidence. A command and result such as make test-auth-reset, exit 0, 48 passed lets a reviewer reproduce the claim and notice when the agent ran a narrow suite instead of the required one.

Bound permissions before increasing autonomy

An agent should receive the least authority needed for the current task, with credentials and network access separated by purpose. Teams often reverse this order. They first give the agent a developer's full environment, then add approval prompts after a frightening command appears. By then, the model may already have read secrets into context or modified state that a prompt cannot restore.

Start with an isolated workspace, a clean branch, and synthetic or masked data. Mount source directories intentionally. Keep deployment credentials, production databases, customer support systems, and billing APIs outside the default environment. If a task genuinely needs one of them, create a short lived credential with a narrow role and record why it was issued. Convenience is a poor reason to hand a probabilistic worker a permanent token.

Command controls need semantics, not a blacklist of scary strings. Blocking rm does not stop a database client from dropping a table, a build script from publishing a package, or an HTTP request from changing remote state. Classify tools by effect: read local state, write local state, access a network, change shared state, or release an artifact. Then set a policy for each class.

A practical default allows the agent to read the repository, edit its branch, and run deterministic local checks. It asks before downloading dependencies or contacting an external service. It cannot merge, publish, deploy, change access controls, or use production credentials. Human approval should bind to the exact proposed action, including target and parameters. An approval for run migration is vague; an approval for a reviewed migration checksum against a named staging database has a usable boundary.

Do not mistake an approval dialog for supervision. If reviewers approve repetitive commands without reading them, the dialog trains reflexes rather than judgment. Remove low risk interruptions through policy and reserve explicit approval for actions with meaningful consequences. The fewer approvals you request, the more attention each one receives.

Review the evidence and the behavior

Agent generated code needs review aimed at behavioral risk, not a contest to spot odd syntax. Models are good at producing locally plausible code, so polishing each line can distract a reviewer from a missing authorization check, a changed retry policy, or an incorrect assumption about transaction boundaries. Begin with the contract and test evidence, then inspect the code paths capable of violating the invariants.

Ask the agent to annotate its own change before a human opens the diff. It should explain the chosen approach, identify the highest risk edit, name alternatives it rejected, and map each acceptance criterion to a test. This explanation is not proof, but it helps the reviewer find hidden assumptions. If the prose claims a test covers idempotency and the test only repeats a pure function, the mismatch is immediately useful.

Generated tests require the same suspicion as generated implementation. An agent can make a green suite by asserting its own wrong behavior, mocking away the failing boundary, or replacing a strong assertion with a snapshot that nobody reads. Review at least one failure case manually. Mutate or remove the production condition and confirm that the new test fails for the expected reason. A test that never catches the defect it names is decoration.

Keep mechanical checks automatic: formatting, type checks, dependency policy, secret scanning, static analysis, and focused test suites should run without a reviewer asking. Human attention belongs on business rules, security boundaries, failure modes, operability, and consistency with the architecture. This division matters because an agent can respond to deterministic failures cheaply, while a human should resolve ambiguity.

The author of the task contract should not always be the only reviewer. For high impact changes, separate requirement approval from implementation approval. The first person confirms that the requested behavior is correct; the second confirms that the implementation and evidence support it. Small teams can combine roles when risk is low, but they should make that choice explicitly instead of letting one person approve their own assumptions through an agent.

A fast agent can hide a slow failure

A typical failure starts with an apparently modest request: add retries to outbound webhook delivery. The agent finds the HTTP client, wraps failed calls in exponential retry logic, writes tests around status codes, and reports success. The diff is clean. The focused suite passes. The pull request reaches production within an hour.

The original issue never stated whether delivery is idempotent. Some recipients process the request but time out before replying. The new code retries those requests, and recipients perform the action twice. The agent did exactly what the task asked, while the team failed to define the business invariant that one event must not create duplicate effects. Faster implementation shortened the time available for someone to notice the missing question.

The damage expands because the agent copied the service's existing log pattern and included the response body for failed attempts. One recipient returns personal data in an error response. Now retry debugging stores data that the original path never retained. Nothing in the unit tests fails because the tests examine timing and status codes, not log content or downstream effects.

A disciplined contract changes the route before code appears. It states that each event has a stable delivery identifier, receivers may process a request before a timeout, logs must exclude bodies, retry counts need an upper bound, and operators need a way to stop a failing destination. The agent may then propose an idempotency header, bounded backoff, structured redaction, and a dead letter state. A human still decides whether the receiver contract can support those choices.

This failure is easy to recognize because teams made it before agents existed. Agents change its frequency and speed. They can repeat a missing assumption across many services before the first incident reveals it. The corrective action is not a cleverer prompt. It is a work system that forces invariants and failure effects into the task before implementation begins.

Use a five-level maturity ladder

A team should earn broader agent autonomy by demonstrating control at the current level. Buying a better model does not move the team up this ladder. Reliable contracts, bounded authority, reproducible evidence, and measured outcomes do.

1. Level one, private exploration. Individuals use agents for explanation, disposable code, and local edits. They do not expose secrets or merge generated work without ordinary review. The goal is basic fluency: asking for plans, checking assumptions, and recognizing confident errors.
2. Level two, assisted implementation. Agents work on normal backlog items inside a developer session. The human selects files, runs checks, and owns the pull request. The team adds repository instructions and records which checks a change must pass. Success means generated work follows the same review path as handwritten work.
3. Level three, bounded task execution. An agent receives a committed change contract, edits an isolated branch, runs approved tools, and opens a draft pull request with evidence. Policies restrict paths, credentials, network use, and state changes. Humans still approve design exceptions and every merge.
4. Level four, coordinated delivery. Multiple agents can split planning, implementation, testing, and review across well defined interfaces. The pipeline records artifacts and prevents one agent from approving its own output. Teams permit low risk changes to advance automatically through staging when contract checks pass, while release authority remains policy controlled.
5. Level five, managed autonomy. Agents handle selected classes of work from intake through monitored release. The team has proven rollback, ownership, auditability, cost controls, and incident response for those classes. Humans govern goals, architecture, exceptions, and production risk; they do not supervise every command.

Promotion should happen per work class, not for the company as a whole. A team may operate at level four for dependency updates, level three for internal services, and level one for payment logic. This is healthy. Risk differs by domain, and a single maturity badge encourages unsafe generalization.

Demotion must be normal too. If escaped defects rise, evidence becomes unreliable, or reviewers cannot explain changes, reduce autonomy for that work class until controls recover. A maturity model that only moves upward is a sales funnel. An engineering ladder needs a safe way down.

Measure completed outcomes, not generated code

Agent adoption is working when the team delivers verified customer outcomes with less elapsed time, rework, and operating cost. Lines of code, prompts sent, agent sessions, and pull requests created measure activity. They are easy to inflate and often move in the wrong direction when an agent learns to solve a problem with less code.

Measure the path from an approved task to verified production behavior. Track elapsed cycle time, time waiting for human decisions, review effort, failed checks before merge, escaped defects, rollback frequency, and work reopened after release. Add agent cost and the engineering time spent preparing context or correcting output. Compare similar work classes over several deliveries rather than announcing success after one unusually easy feature.

A simple calculation exposes fake savings. Suppose an agent reduces implementation from eight hours to two, but task preparation adds one hour, review grows from one hour to three, and one in four changes requires four hours of rework. The expected effort becomes seven hours: two for implementation, one for preparation, three for review, and one averaged across rework. That is an improvement, but it is not the fourfold gain suggested by implementation time alone.

Quality needs leading indicators as well as incidents. Check whether required tests were actually run, whether contract exceptions increased, whether reviewers override agent recommendations, and whether rollback procedures still work. These signals reveal control decay before a customer finds it. Do not create a composite score that hides the cause. Keep the measures separate enough that the team knows what to fix.

Cost comparisons must include the system around the model. Count model usage, orchestration, additional CI load, sandbox infrastructure, observability, and the people who maintain instructions and evaluation sets. Then compare that total with capacity released or time shortened. Headcount reduction may be an outcome in some businesses, but using it as the first target encourages teams to remove the reviewers and operators that make autonomy safe.

Team roles change before headcount does

Agents shift engineering work toward specification, judgment, and system design before they justify changing team size. A developer who once spent most of a day implementing a contained change may spend an hour defining it, an hour reviewing evidence, and the remaining time handling harder boundaries across services. The work has not vanished. Its center has moved.

Product managers need to express acceptance conditions and exclusions with more precision. Senior engineers need to turn architectural knowledge into repository rules, executable checks, and clear escalation paths. Security and operations staff need to define reusable policies instead of reviewing every task manually. Engineering managers need to control work in progress because cheap code generation can flood a review queue faster than humans can evaluate it.

Junior engineers still belong in this system. Removing their implementation work entirely also removes the practice through which they learn debugging, tradeoffs, and operational consequences. Give them bounded tasks, require them to predict the agent's approach, and have them verify a failure case. They should learn to challenge output, not become prompt couriers who cannot repair the code when the model stalls.

Repository context deserves deliberate maintenance. Agents read whatever is easiest to retrieve, not whatever an experienced engineer would recall at the right moment. Put stable facts such as service boundaries, supported runtime versions, test commands, naming rules, and forbidden dependencies in versioned repository instructions. Keep decisions for a specific task in the change contract. This distinction prevents a temporary exception from becoming a permanent rule and stops global instructions from growing into an unreadable manual.

Do not dump every design document into context. Stale and conflicting material can make an agent less reliable while increasing usage cost. Curate a compact path from the task to the relevant architecture record, interface definition, and local examples. Test those instructions with representative tasks whenever a service changes. Context is part of the engineering system, so it needs an owner, review history, and removal of obsolete rules.

Tool choice comes after operating design. Evaluate whether a coding agent can respect repository instructions, expose tool calls, operate in isolation, return structured evidence, and fit your identity and audit controls. Model quality matters, but a small difference in benchmark performance rarely compensates for weak permission boundaries or an opaque action history. Run the same representative tasks through candidates and score the resulting change, evidence, review burden, and cost.

Teams should resist creating an agent specialist who becomes the only person able to operate the system. A small enablement group can build policies and templates, but product teams must own their contracts and results. Otherwise the organization replaces one queue for developers with a queue for agent operators.

Promotion gates keep autonomy honest

Every increase in autonomy should pass a recorded promotion gate for a specific class of work. The gate is evidence that the team can control the current mode, not a forecast that a new tool will behave. I use five questions before widening an agent's scope:

• Can the team state the invariant and acceptance checks before execution?
• Can it restrict files, tools, credentials, networks, and release actions by policy?
• Can another engineer reproduce the agent's evidence from the repository and logs?
• Can the owner stop, roll back, and diagnose a bad change within the required time?
• Have several comparable changes reduced total effort without increasing escaped defects?

A no does not ban the agent. It identifies the control that needs work. Keep the agent at its current level, repair that control, and run another representative task. This approach prevents a successful documentation edit from becoming the justification for autonomous schema migrations.

The first adoption move should be a narrow work class with frequent examples, deterministic checks, and cheap rollback. Dependency updates, test additions, and small internal refactors often fit, provided the repository already has reliable tests. Pick actual backlog work rather than a staged demo. A demo teaches the agent your happiest path; routine work exposes the context gaps that will govern real throughput.

At oleg.is, the Team & AI Audit examines those gaps across work flow, roles, tooling, and cost before a company commits to a larger transformation. The useful deliverable is not a count of places where AI might fit. It is a defensible map of which work can move up the ladder now, which controls are missing, and where autonomy would cost more than it saves.

Do not aim for an autonomous engineering department. Aim for a department that can grant autonomy deliberately, observe what happens, and withdraw it without drama. When the contract, permissions, evidence, owner, and recovery path are all visible, the agent is doing engineering work inside a system. When one of them disappears, the team has crossed back into vibe coding, however polished the interface looks.