Agentic Engineering: Karpathy's AI-First Development

Why This Matters

"Vibe coding" made AI-assisted development feel accessible: describe the app, accept a patch, run it, and keep steering until the result feels right. That style is useful for prototypes. It is not enough for professional software work where a patch can break billing, leak data, weaken authorization, or quietly delete a migration.

Agentic engineering is the harder version of the same shift. The agent can still plan, edit, run commands, and iterate. The difference is that the engineering system around the agent decides what counts as acceptable work. Plans become reviewable artifacts. Tool access is scoped. Tests and static checks become gates rather than suggestions. Logs become evidence instead of chat history. Human review moves from "watch every keystroke" to "approve the right boundary with enough context."

This guide uses Andrej Karpathy's 2025 framing of software's move toward natural-language-programmed systems as the starting point, then connects it to current coding-agent platforms from OpenAI, GitHub, and Anthropic. Effloow Lab also ran a small local sandbox PoC for this article. The PoC simulated a bad agent patch, blocked it with a deterministic unit-test gate, and saved a trace artifact. The evidence note is at data/lab-runs/agentic-engineering-beyond-vibe-coding-methodology-2026.md.

The practical takeaway: agentic engineering is not "let the agent ship." It is "let the agent do more work inside a system that can prove what happened."

For related Effloow context, read the broader trend guide on what vibe coding means for developers, the comparison of vibe coding tools, and the setup guide for OpenAI Codex CLI.

Source Check: What Is Verified

The strongest source for the conceptual shift is Karpathy's "Software Is Changing (Again)" talk, where he frames modern AI systems as a new software layer written partly in natural language and mediated by models. That does not define a full production methodology by itself, but it explains why promptable systems now need engineering discipline rather than casual prompting.

Current tooling sources show the same direction from different angles. OpenAI describes Codex as an agent interface for parallel and long-running coding work, with reviewable diffs, worktrees, sandboxing, and command permissions. GitHub documents Copilot coding agent as a background agent that opens pull requests and pushes commits to branches. Anthropic's Claude Code best-practices documentation emphasizes planning, permission management, verification, and iterative workflows for agentic coding. Research work on agentic AI for software engineering also argues that evaluation and reproducibility are central open problems, not optional polish.

This article does not claim a universal industry standard, a benchmark score, a defect-rate reduction, or a Karpathy-authored checklist. Those would need stronger evidence. It instead extracts an operational pattern that is visible across sources: agentic development needs explicit task boundaries, controlled execution, deterministic checks, traceability, and human approval.

Sources used:

• Andrej Karpathy: Software Is Changing (Again) transcript
• OpenAI: Introducing the Codex app
• OpenAI Codex documentation
• GitHub Docs: About assigning tasks to Copilot
• Anthropic Docs: Claude Code best practices
• arXiv: Agentic AI for Software
• arXiv: Reproducible, Explainable and Effective Evaluations for Agentic AI Systems

Vibe Coding vs. Agentic Engineering

The useful distinction is not whether AI writes code. In both styles, AI can generate large parts of the implementation. The difference is where responsibility sits.

Vibe coding optimizes for momentum. The developer prompts, accepts, tweaks, and visually inspects. That is often the right mode for disposable prototypes, internal demos, learning projects, or early product exploration where the cost of being wrong is low. Its weakness is that correctness depends heavily on the developer's attention in the moment. If the developer forgets to test a branch, review a migration, inspect auth scope, or reproduce an edge case, the workflow has no independent memory.

Agentic engineering optimizes for controlled autonomy. The agent receives a task, gathers context, proposes or applies changes, runs checks, and returns an evidence trail. The developer still owns the outcome, but the workflow is structured so important decisions are recorded and verified. The agent can do more because the system around it is stricter.

That shift changes how teams should judge AI coding tools. A tool that can edit ten files is only useful if it can also explain why those files changed, run the relevant checks, preserve command output, and stop when it reaches an unsafe boundary. A tool that can open a pull request is only useful if the branch is reviewable, the commits are scoped, and the CI result means something.

The Local Sandbox PoC

Effloow Lab ran a deliberately small Node.js sandbox. The project contained a discount calculator, a unit-test runner, and a gate.mjs script. The gate ran the tests, saved a trace.json file with command status and output, and failed the process if verification failed.

The baseline passed:

GATE_PASS deterministic verification accepted release

Then the sandbox introduced a bad patch that looked syntactically valid but changed the discount formula from percentage math to subtracting the percentage value directly. The gate blocked the patch:

GATE_FAIL deterministic verification blocked release

The saved trace preserved the important details:

[
  {
    "label": "unit-test-gate",
    "cmd": "node test-runner.mjs",
    "status": 1,
    "stdout": "PASS zero percent",
    "stderr": "FAIL ten percent: expected 900, got 990\nFAIL round half up: expected 874, got 986.5"
  }
]

This is not a benchmark. It does not prove that one coding agent is better than another. It proves a workflow shape: an agentic development system needs a deterministic acceptance boundary and a durable trace. Without that boundary, the human reviewer has to reconstruct everything from chat context. With it, the reviewer can inspect a small artifact: what command ran, what failed, and why the release should stop.

The Five Control Loops of Agentic Engineering

Professional agentic development is easier to reason about as five loops.

First, the task loop defines the scope. A good task has a narrow goal, target files or modules, constraints, expected behavior, and stop conditions. "Improve checkout" is weak. "Add an idempotency key check to the checkout webhook without changing payment capture behavior, then run these tests" is much stronger.

Second, the context loop controls what the agent reads. More context is not always better. The agent needs the files, docs, failing test output, schema, routes, and recent changes that affect the task. It does not need secrets, unrelated customer data, or write access to every repository by default.

Third, the execution loop controls what the agent can do. Local edits, test commands, package installs, migrations, network calls, and deploy commands are not the same class of action. A serious workflow treats them differently. Low-risk reads can be automatic. File edits may be automatic inside a branch. Production deploys and credential access require explicit approval.

Fourth, the verification loop decides whether the work is acceptable. Unit tests are the minimum, not the whole story. Depending on the project, the gate may include type checks, linters, static analysis, migration dry-runs, security tests, API contract checks, browser smoke tests, accessibility checks, or snapshot comparison.

Fifth, the review loop turns the agent's work into a human decision. The reviewer should receive a scoped diff, test output, known limitations, and any unresolved questions. That review package is what separates an engineering workflow from a chat transcript.

What Current Tools Are Signaling

OpenAI's Codex app points toward background software-engineering agents that can work on multiple tasks, run tests, and present citations from terminal logs and test outputs. That matters because an agent that can cite its own command evidence is easier to review than an assistant that only narrates what it thinks happened.

GitHub Copilot coding agent points toward repository-native work. It can be assigned tasks from GitHub, work in the background, push commits to a branch, and open a pull request. The important design signal is not just that Copilot writes code. It is that the output lands in the normal review path where branch protections, CI, code owners, and pull request review already exist.

Anthropic's Claude Code guidance points toward explicit workflow control. Its best-practices material emphasizes exploration before editing, clear instructions, permission management, and verification. Those are not cosmetic tips. They are the operating rules that keep agentic work from becoming uncontrolled automation.

The shared direction is clear: the winning workflow is not a single magic prompt. It is a controlled path from task assignment to branch, checks, review, and merge.

A Practical Team Workflow

For a small engineering team, an agentic engineering workflow can start without buying a platform or rewriting the entire delivery process.

Begin with task templates. Every agent task should name the goal, non-goals, files or modules likely to change, commands to run, and evidence expected at the end. If the task touches security, billing, data deletion, migrations, authentication, authorization, or public API contracts, mark it as high review risk before the agent starts.

Next, define permission tiers. A useful default is read-only exploration first, repo-local edits second, local test execution third, and external side effects last. External side effects include sending email, charging money, publishing packages, changing DNS, deploying production, mutating customer data, and writing to third-party systems. Those should be separate approval gates.

Then build a verification bundle. For a Laravel project, that might be php artisan test, focused Pest or PHPUnit tests, npm run build, route inspection, migration status, and a browser check for user-facing pages. For a TypeScript service, it might be npm test, npm run typecheck, npm run lint, contract tests, and a Docker smoke test. The exact commands matter less than the rule: every agent task ends with reproducible evidence.

Finally, make review packages boring. The agent should return changed files, why they changed, commands run, failures encountered, fixes applied, and remaining risk. If it cannot verify something, it should say so directly. "Not verified" is acceptable. A confident unsourced claim is not.

Common Mistakes

The first mistake is treating agent speed as proof of engineering quality. A fast patch can still be wrong. Agentic engineering should reward patches that are small, explainable, tested, and easy to revert.

The second mistake is using production credentials during exploration. Agents are good at following paths. If a path includes real secrets or mutation privileges, a vague task can become an incident. Keep sandbox credentials, dry-run modes, and read-only scopes as the default.

The third mistake is asking the agent to self-grade without artifacts. "Looks good" is not QA. A gate output, failed test trace, browser screenshot, migration dry-run, or contract-test log is much stronger.

The fourth mistake is allowing giant mixed-purpose tasks. Agents can edit across a repository, but reviewers still have finite attention. Split unrelated work into separate branches so each review has a clear reason to exist.

The fifth mistake is hiding limitations. If the agent could not run the full test suite, lacked an API key, skipped a browser check, or only simulated a service, the final note should say that. A limitation is not a failure; pretending it does not exist is.

FAQ

Q: Is agentic engineering just another name for vibe coding?

No. Vibe coding is a prompting style optimized for rapid creation. Agentic engineering is an operating model for letting agents perform engineering work inside explicit scopes, checks, traces, and review gates.

Q: Can agentic engineering work without a cloud coding agent?

Yes. The core pattern works with terminal agents, IDE agents, background GitHub agents, or even a local script that enforces verification. The platform matters less than the control loop: task, context, execution, verification, review.

Q: What should teams automate first?

Start with low-risk, testable work: refactors with strong tests, documentation updates tied to source files, failing-test fixes, static-analysis cleanup, or small internal tooling. Avoid giving early agents production deploy, billing, credential, or customer-data mutation authority.

Q: How much human review is still required?

Enough to own the outcome. The point is not to remove human responsibility. The point is to move humans from line-by-line babysitting toward reviewing scoped diffs, evidence, unresolved risks, and production boundaries.

Key Takeaways

Agentic engineering is the professionalization of AI-first software development. It accepts that agents can now do meaningful multi-step coding work, but it refuses to treat generated code as self-validating.

The local Effloow Lab PoC showed the smallest useful version of the pattern: a proposed change, a deterministic gate, a blocked failure, and a trace artifact. Real teams should extend that with richer tests, scoped permissions, review policies, and deployment controls.

For developers already using Codex, Copilot coding agent, Claude Code, or similar tools, the next step is not a better prompt library. The next step is a better acceptance system. Write clearer tasks, restrict unsafe actions, require reproducible checks, preserve evidence, and make every agent-produced patch enter the same review discipline as human-produced code.

That is the difference between asking an AI to code and engineering with agents.