0.1 · The Agentic Engineer

0.1 · 15 min

The Agentic Engineer

You watched a demo where an agent built a working dashboard in forty minutes, so you pointed Claude Code at a real codebase and typed "add Stripe billing." It worked for two days. Then a customer got charged twice on a retried webhook, and you discovered you were about to debug 3,800 lines you had never read, written in a style you didn't choose, tested by tests that encode the same misunderstanding as the bug. Nobody typed that code. Somebody still owns it, and that somebody is you.

What agentic engineering actually is

Agentic engineering is the discipline of directing systems that write and operate software. Not assisting you while you write it. Writing it, running it, testing it, and reporting back, while you decide what gets built, define what "correct" means, and verify the result before it counts.

Claude Code is the tool this course uses to teach that discipline. Per its own docs, it is an agentic coding tool that reads your codebase, edits files, and runs commands. When you hand it a task, it works a loop: gather context, take action, verify results, repeating and course-correcting until the task is done. The product itself is a harness around a language model: tools, context management, and an execution environment that turn a model into something that can operate on your machine.

That word "harness" matters more than it looks. The model is not the product. The system around the model is, and later in this course you will build harnesses of your own. Hold onto that.

Two other ways of using AI get confused with this discipline, and the confusion is expensive.

Autocomplete use is what most developers mean by "I use AI." A tool suggests the next few lines, you accept or reject, you remain the author of every file. It is a faster keyboard. Useful, and not what this course teaches, because the unit of work is still a line of code you personally type.

Vibe coding is the other pole: describe what you want, accept whatever comes back, judge it by whether the demo runs. For a throwaway prototype, honestly, fine. Vibe code your weekend experiment. The failure is doing it with software that has users, revenue, or your name on it, because "the demo runs" and "the software is correct" are different claims, and the gap between them is where the cold open above lives.

Agentic engineering sits apart from both. You delegate the typing, like the vibe coder. You keep authorship of correctness, like the traditional engineer. The unit of work is not a line and not a wish. It is a verified change: a specification going in, evidence coming out.

The skill inversion

For decades, the bottleneck skill in software was producing code: knowing syntax, memorizing APIs, typing implementations quickly. Agents made that skill cheap. What they did not make cheap, and in fact made scarcer, is everything around it:

  • Specification. Saying precisely what you want, including what should happen at the edges, before any code exists. Agents execute ambiguity faithfully. A vague dispatch produces a confident, complete, wrong implementation.
  • Verification. Defining, in advance, what evidence would prove the work correct, then actually collecting it. The Claude Code docs are blunt about this from the tool's side: Claude performs better when it can check its own work against test cases, expected output, or screenshots. The same is true from your side, and yours is the check that counts.
  • Context design. Deciding what the agent can see. Its context window holds the conversation, file contents, command outputs, and standing instructions, and as it fills, early instructions can get lost. What you feed the agent, and what you deliberately keep out, shapes the output as much as the prompt does.

Notice what is not on the list. Typing speed. Framework trivia. The ability to produce a for loop from memory. If your professional value was concentrated there, this inversion is uncomfortable, and pretending otherwise would be lying to you. But judgment did not get automated. It got promoted.

Here is the position this course takes, and you will see it enforced in every lab: agents do not lower the bar for engineering judgment, they raise it. When you wrote 200 lines a day, your judgment covered 200 lines. Directing agents, you might be responsible for 3,000 lines a day that you did not write and are seeing for the first time at review. Every skill that reading code demands, you now need at higher volume and with less familiarity. The typing got easier. The job got harder, and better.

In practice: what the discipline looks like

The difference shows up in the artifact you send the agent before it starts. Compare the two moves on the same task.

Prompt-and-pray

"Add Stripe billing to the app. Make sure it works."

Then: accept the diff, click around the checkout page once, ship it. Correctness is whatever the agent decided it was, discovered later by customers.

Agentic dispatch

A dispatch that states scope ("webhook handling for invoice.paid and charge.refunded only"), constraints ("idempotent handlers, no schema changes"), and the verification you will run before merging ("test suite passes, plus a replayed duplicate webhook charges exactly once").

Then: run that verification yourself. The agent's "done" starts the review, it doesn't end it.

A real dispatch for that task looks something like this. You will learn to write these properly in Part 2; for now, read it for shape, not syntax.

PromptA dispatch, not a wish

Add Stripe webhook handling for invoice.paid and charge.refunded.

Scope: src/billing/ only. No database schema changes. Handlers must be idempotent: replaying the same event ID must be a no-op.

Before writing code, read src/billing/stripe.ts and tell me your plan.

Verification I will run before accepting:

  1. npm test passes
  2. I replay a duplicate invoice.paid event; the customer is charged once
  3. I read the handler diff line by line

If anything in the existing code makes idempotency hard, stop and tell me instead of working around it.

Count what is in there: a boundary, an invariant, a forced planning step, a verification list, and an instruction to surface problems instead of burying them. None of it is code. All of it is engineering.

Where it breaks: the slop problem, stated honestly

Slop is code that is plausible but unverified. It compiles. It reads clean. The variable names are lovely. And it is wrong in ways that do not surface until someone leans on it. Agents produce slop at scale when nobody imposes verification, and here is the uncomfortable part: slop is harder to catch than bad human code, because bad human code usually looks bad. Slop looks like the code a careful senior developer would write. The tells are semantic, not cosmetic, so skimming does not catch them. Reading does.

This is why output volume without verification is negative productivity, not zero. Unverified code is not neutral inventory sitting in a warehouse. It carries a defect probability, and every unverified line transfers cost downstream: to the reviewer who must now reconstruct intent from scratch, to the teammate who builds on top of it, to the customer who finds the bug in production, and back to you at 2 a.m. Someone always pays the verification cost. The only choice you get is whether it is paid cheaply upfront or expensively later. A developer shipping five times more unverified PRs has not become five times more productive. They have become a defect distribution channel with great throughput.

The other break is scale mismatch. Review effort grows with the size and unfamiliarity of the diff, and agents inflate both. If you cannot review 3,000 lines a day with real attention, and you can't, then the discipline is not "review harder." It is constraining scope per dispatch, forcing plans before code, and building verification the machine can run, so your human attention lands only where judgment is genuinely required. That is a system design problem, and it is most of this course.

What this trains you to build for pay

Three concrete deliverables, in ascending order of how personal they are:

  1. Production SaaS. Real applications with auth, billing, and databases, built agent-first but verified like they matter, because they do. Track A ends with you shipping one.
  2. A business Agent OS. The operational layer for a company: agents that handle intake, reporting, follow-up, and internal tooling, wired into the business's actual systems and run with the same verification discipline as the codebase.
  3. Personal harnesses. Your own leverage layer: memory systems, custom verification loops, automation around your own recurring work. The dispatch you read above is a hand-rolled example; a harness is what makes that rigor the default instead of an act of will.

All three are the same skill applied at different blast radii. Specify, direct, verify. The tools change; the discipline doesn't.

You can now name which of the three modes you are in at any moment, autocomplete, vibes, or engineering, and you know the test that separates them: whether verification you defined stands between the agent's output and anything you'd call done.

Knowledge check

Knowledge check

Q1Claude Code just reported mid-task: 'Done. I refactored the auth module and updated all 34 call sites. Tests pass.' The diff is 1,900 lines. What does an agentic engineer do next?
Q2Which single difference most reliably separates agentic engineering from prompt-and-pray?
Q3The 'skill inversion' means some abilities got scarcer as agents got better. Which of these became MORE valuable?
Q4A teammate now ships five times more pull requests using agents, but review time on their PRs has tripled and two production incidents traced back to unread agent code. Why does the lesson call this negative productivity rather than zero?

Sources