Agentic Fundamentals

The thing I keep coming back to with agentic work is that almost none of the fundamentals are new.

The tooling is new. The speed is new. The feeling of having three or four tireless junior teammates operating in parallel is very new.

But the practices that make it work?

Not new.

Everything old is new again. Image source: Know Your Meme.

1. Spend Your Time Planning So Implementation Is Boring

The highest-leverage part of agentic work happens before the agent writes a line of code. The Pragmatic Programmer has a section on “tracer bullets” that has stuck with me for years: get a thin, real path through the system early, watch where it lands, and use that feedback to steer. Agentic development needs the same discipline, but the tracer round is usually not code.

It is research.

Then a plan.

Then annotations on the plan.

Then another plan.

Then, eventually, code.

My workflow: I ask the agent for an implementation plan (via a “superplan” skill), it publishes that plan to Proof, I make sure test cases are specified upfront instead of as an afterthought, I add comments and go through a few cycles until it’s fully baked, and then I send it off to the races. The expensive failure mode is not obvious wrong code; it is code that works locally while violating the system around it.

That is why the plan needs to carry the boring stuff we have always known matters:

• what the existing system already does
• where the conventions live
• the exact behavior change
• the edge cases
• the files or modules that are in scope
• the files or modules that are out of scope
• the acceptance criteria
• the rollback or failure mode
• the tests that prove the change works

Especially the tests.

If you know what would convince you that the change is correct, put it in the plan before implementation starts.

Not after.

Before.

By the time you say “implement,” the interesting decisions should already be made. Implementation should be boring. The creative work happened while you were aiming.

2. Ask The Agent To Repeat The Plan Back

One pattern I now use constantly: I ask the agent to paraphrase what it is about to do before it does it. This catches more than you would think. Sometimes the agent misunderstood the task. Sometimes I misunderstood the task. Sometimes the paraphrase exposes an edge case neither of us had quite surfaced yet. Agents are not just autocomplete with a terminal; they are also very good at reflecting ambiguity back at you. If the agent says, “I will update X, preserve Y, and add tests for Z,” and something in your brain goes, wait, what about Q?

Congratulations. You found the real requirement.

Not new: this is pair programming, design review, and asking a junior engineer to explain their plan before they pick up the ticket. The agentic version is just faster and more literal.

3. Manage Cognitive Overhead Like It Is The Bottleneck

The first trap in agentic work is assuming that because agents can run in parallel, you should run as many as possible.

You should not.

You are still human. You still have a context window, and it is made of attention, working memory, and patience. I found my sweet spot was about three agents running in parallel across genuinely separate workstreams. Two left idle time. Four was too much. At four, I was no longer orchestrating; I was thrashing. The limiting factor is not just model latency or token budget or tool access. It is the human operator’s ability to review the work, notice naming problems, catch weird abstractions, decide whether the test is meaningful, and keep the broader product shape coherent. Not new: deep work still matters, context switching still has a price, and Brooks’s Law did not retire because Claude learned how to open a pull request.

More agents is not the goal.

More correct throughput is the goal.

4. Make Verification The Default Loop

Every agentic workflow needs a verification loop, not as a final polish step, but as the shape of the work. The agent should run the relevant tests, inspect failures, patch, and rerun before handing the work back. If the repo has a linter, formatter, typecheck, integration suite, or predeploy gate, that belongs in the loop too.

The handoff you want is not:

I made the change.

The handoff you want is:

I made the change, ran these checks, fixed these failures, and here is what still needs human judgment.

That last clause matters.

Agentic work does not remove review; it moves review up a level. The human should spend less time asking, “Did this even compile?” and more time asking, “Is this the right shape? Is this readable? Did we solve the actual problem?“

5. Keep The Work Human-Readable

The more agentic a workflow becomes, the more important human readability becomes. That sounds backwards, but it is not. LLMs are trained on human artifacts. They follow names, structure, documentation, conventions, examples, tests, and local patterns. The same things that make code easier for a teammate to understand make it easier for an agent to operate safely.

• Clear variable names matter.
• Small PRs matter.
• Good commit messages matter.
• Docs matter.
• Tests that describe behavior matter.
• Source-of-truth rules matter.

If your repo is confusing to humans, it will be confusing to agents. If your process depends on tribal knowledge, the agent will miss it. If your test suite is performative, the agent will learn to perform correctness instead of earning it.

Not new: code is communication.

Still true.

The Actual Shift

The big change is not that agents make engineering principles obsolete.

The big change is that agents punish us faster when we ignore them.

Vague requirements become vague code. Missing tests become fake confidence. Bad repo structure becomes bad agent behavior. Too much parallelism becomes operator overload. Giant PRs become review sludge at machine speed.

Everything old is new again.

Plan carefully. Specify the tests. Control the cognitive overhead. Verify continuously. Keep the work human-readable.

The tools changed.

The fundamentals did not.