From vibe coding to agentic engineering: how AI-assisted development grew up in 2026

01What vibe coding was, and why it worked

In early 2025, Andrej Karpathy gave a name to a practice that had already spread through engineering teams: vibe coding. The idea, as he sketched it in a short note, was to describe a problem in plain language, let a model generate the code, and accept the changes largely as delivered - focusing on the feel of the result rather than reading every line. The term stuck because it named something real.

It worked for a reason that is worth remembering honestly. A large share of routine software work is boilerplate, glue, and scaffolding that an experienced developer could verify at a glance. For that class of task, trusting the model and skimming the diff was faster than typing, and the error rate was tolerable. Prototypes, one-off scripts, and greenfield demos were the sweet spot.

What vibe coding never promised was a way to maintain what it produced. Code that nobody read carefully accumulates quiet assumptions, and a prototype that ships becomes someone's production problem. The practice scaled until it met long-lived systems, and then it stopped scaling.

02Karpathy’s framing: from improvisation to engineering

The conversation embedded above, recorded with Stephanie Zhan at Sequoia, is useful framing evidence for how the profession's own description of itself moved. Karpathy's position, as we read it, is not that vibe coding was a mistake but that it was a stage: a necessary period in which developers learned what models could do by surrendering control, followed by a period of taking that control back in a more disciplined form.

The vocabulary he uses for the destination is agentic engineering: work in which the model, or a harness around it, plans a change, edits multiple files, runs the tests, reads the failures, and iterates - with the human directing and reviewing rather than typing. The shift is from prompting as a one-shot improvisation to delegating a bounded task with verifiable acceptance criteria.

This is original N43 analysis, not a transcript summary: what matters for the argument here is the structure of the move. Improvisation treats the model as a slot machine that occasionally pays out working software; engineering treats it as a junior collaborator that must show its work. The second posture is the one that survives contact with production.

03What agentic engineering actually means

In practice, agentic engineering means the unit of delegation grows. Instead of asking for a function, you ask for a change: fix this bug, add this endpoint, migrate this call site - and the agent decomposes the request, edits the relevant files, executes the build and test suite, and reports back with evidence. The loop of plan, act, observe, and revise runs without a human in every iteration.

Two properties make this qualitatively different from autocomplete or a chat window. First, the agent has persistent context across steps: it knows what it just changed and why. Second, it has feedback: failing tests, type errors, and linters act as an automatic reviewer that cannot be charmed. That feedback loop is what turns generation into engineering.

The discipline that makes it work is specification. Teams that succeed with agents invest in the acceptance criteria: small, well-scoped tasks; a test suite the agent must satisfy; and guardrails on what it may touch. Teams that skip that scaffolding rediscover vibe coding with more compute attached.

04What still requires human engineers

The unambiguous remainder is judgment about what to build. Agents can implement a requirement, but deciding whether the requirement is right, whether the architecture should bend to accommodate it, and whether a shortcut will be regretted in eighteen months remains human work. Strategy is not yet delegable.

Review is the second durable obligation, and it changes shape rather than disappearing. When an agent produces a correct-looking diff at machine speed, the reviewer's job shifts from catching syntax errors to interrogating design: is this the right boundary, the right data model, the right failure mode? Reading code critically becomes more valuable than writing it fluently.

Accountability is the third. An agent cannot be on call, cannot sign off on a change to a regulated system, and cannot take responsibility for an incident. Someone must own every merge, and the job title attached to that ownership is still engineer. The 2026 version of the role carries more supervisory weight and less typing than its 2023 predecessor.

05How the tooling changed in 2026

The IDE absorbed the agent. Editors now ship with multi-file editing, terminal access, and the ability to run tests and read the output as part of a single delegated task, which turns the traditional editor into a cockpit for supervision. The modalities that used to live in separate chat windows and terminal panes merged into one interface.

Around the IDE grew the harness layer: orchestration tools that run agents against a repository, check their work, and retry with the failure attached. Open-source harnesses and hosted equivalents both matured, and the practical difference between them is mostly where the secrets live. A second crop of tools treats agents as CI residents - scheduled workers that triage flaky tests, upgrade dependencies, and open pull requests overnight.

CI itself became agent-facing infrastructure. Pipelines now emit machine-readable results not just for humans but for the tools that will act on them, and repository policies grew agent-specific permissions: what an automated author may touch, which checks it must pass, and whether a human must approve the merge. The build system learned to expect non-human colleagues.

06What it means for teams and hiring

Team topology is the first visible change. The ratio of reviewing to writing shifts, and senior engineers spend more of the week as editors and spec-writers than as authors. Some teams split the role explicitly - a small group that frames tasks and holds the bar, and agents that produce candidate implementations at volume - and the bottleneck quietly moves from implementation to verification.

Hiring criteria are following. Interview loops that measured leetcode-style typing speed carry less signal about the job as it now exists; evaluating a candidate's ability to scope a task for delegation, to review a large generated diff critically, and to debug a system whose code they did not write maps more directly onto daily work. Expectations are higher, not lower: the junior tasks that used to train people are increasingly done by machines, so entry paths must teach judgment earlier.

The optimistic reading is a flattening of grunt work; the pessimistic one is a widening gap between engineers who can direct agents and those who cannot. Both are true simultaneously, which is the usual shape of a real transition. DORA-style research on software delivery performance has consistently found that capability, not tooling alone, predicts outcomes - and this cycle is unlikely to be the exception.

07Limits and open questions

The honest limits first: agents are still unreliable on long-horizon work, on unfamiliar legacy systems, and on tasks whose requirements are ambiguous. Tests can be gamed by an agent that learns the suite's blind spots, and generated code reviewed at speed can carry generated vulnerabilities. Every claim of a fully autonomous engineering process should be read with those failure modes in mind.

The measurement problem is real. The chart above is illustrative precisely because good public data on agentic cycle-time improvements does not yet exist; reported numbers come from vendors with an interest and teams without controls. Until independent, methodologically clean studies accumulate, treat all productivity figures in this space as approximate reported values.

The open questions worth tracking: whether review capacity becomes the new constraint on team throughput; how security review adapts to machine-authored code at volume; and whether the entry-level pipeline into the profession survives the disappearance of entry-level work. What is no longer an open question is the direction - the improvisational phase is over, and what replaced it is a supervisory discipline that looks, increasingly, like engineering always claimed to be.