In September 2024, I spent two hours debugging a Docker configuration that wouldn't run.
I was copy-pasting between ChatGPT and my IDE, trying to figure out why the container kept failing. On the advice of a colleague who watched me suffer for long enough, I finally installed Cursor. Within five minutes, it told me I had a YAML indentation error. Two spaces. That was it. Two hours to two spaces -- because the tool I was using could only see the snippet I'd pasted in, not the full file.
That was when something clicked: the context is everything. Not the model, not the prompt phrasing, not the tool brand. Whether AI tooling makes you faster or slower comes down almost entirely to how much context you can give it -- and how good your surrounding infrastructure is.
Since that day, I've helped friends build and publish a dozen MVPs -- front end, back end, infrastructure -- despite being a terrible front-end engineer who has never wanted to write a line of JavaScript. I've published three apps to the App Store without having written a single line of Swift or Objective-C. I've trained thousands of people in person and remotely on how to work effectively with AI agents. And I've gotten on stage and created and shipped working features live, while an audience watched, in 45 minutes or less -- and had them work flawlessly the first time.
That last one is the one people ask about. There's no safety net. There's a clock. There are people watching. The thing still has to work.
It works because of what's underneath it. Not the model, not the prompt phrasing, not the tool brand. The reason I can move that fast, in public, on a deadline, in a domain where I have no native expertise, is that I've spent years building the habits that make fast movement safe: writing specs before writing code, building tests that actually tell me something, configuring CI that gives clear feedback, knowing what my monitoring is going to catch. The AI amplifies whatever's already there. When what's already there is solid, the amplification is extraordinary. When it isn't, the AI just makes the mess bigger faster.
That's what this series is about.
The Teams Moving Fastest Already Had the Fundamentals
The conventional wisdom about AI-assisted development is that it's a speed game. Find the best model, move fast, ship more. And there's something to that -- the velocity gains are real. I'm seeing 50, 60, sometimes 80 percent improvements in throughput on routine tasks across my teams.
But the teams I see moving fastest are not the ones who turned the AI loose and let it go. They're the ones who already had strong engineering fundamentals in place before the AI agents showed up. Planning and speccing before writing code. Architectural decisions that make codebases safe to change at high frequency. Test suites that are fast, reliable, and run in CI without hand-holding. CI pipelines that give clear, structured feedback. Monitoring that catches what tests don't.
None of this is new. All of it is more urgent than it's ever been.
The Mental Model: Intern on Perpetual Day One
Here's the framing I keep coming back to when thinking about working with AI: it's a really smart intern who is permanently on day one.
Not incompetent. Genuinely capable, fast, and knows a lot of things. But it doesn't know your codebase. It doesn't know your team's definition of "good." It doesn't know that the implicit constraint nobody wrote down in 2019 is load-bearing. It knows what the average of the internet says is good -- which is quite different from what's good in your specific system.
The average of the internet will tell you to delete your tests when they fail. The average of the internet will recommend a package without checking your dependency policy. The average of the internet has never worked in your twelve-year-old Terraform codebase with its idiosyncratic naming conventions and three migrations worth of accumulated decisions.
Managing a brilliant-but-context-free intern well requires exactly the same disciplines that make a good engineering organization: clear specs, reliable feedback loops, standards enforced automatically rather than by memory, and monitoring to catch what slips through. The only difference is that the feedback cycle is much faster. You find out in thirty seconds if your spec was too vague. You don't have to wait a week.
Safety Is Speed -- Not the Other Way Around
The conventional wisdom says guardrails slow you down. Process is friction. The fastest teams ship and ask questions later.
That was never quite right. In an agentic environment, it's demonstrably wrong.
When agents write code without reliable tests, you don't know if it works until a customer tells you it doesn't. When they write code without a clear spec, you get 80% of something instead of 80% of the right thing. When CI gives vague or scattered feedback, the agent can't self-correct and a human has to translate -- which costs more time than the automated check ever would have. When you have no monitoring, the first sign something went wrong is a support ticket.
Guardrails aren't friction. They're the rails the train runs on.
The teams that move fastest with agents are the ones who can let agents iterate freely -- because the safety net is solid enough to catch what they get wrong. You don't get the speed without the safety. They're the same thing.
A flaky test that an agent circumvents to make a build pass is not a speed win. A vague CI error that a human has to diagnose manually is not a speed win. An undocumented architectural assumption that an agent bakes into its code, quietly, is not a speed win. These things look like speed right up until they're production incidents.
What This Series Covers
This is the first post in a seven-part series on engineering fundamentals in the agentic era. Each post covers one discipline -- and makes the case for why it matters more now, not less.
Post 2 is about planning and speccing. The quality of what comes out of an agentic workflow is directly proportional to the quality of what goes in. Spec-based agentic development isn't overhead -- it's how you get from "AI generates something" to "AI generates the right thing."
Post 3 covers architecture. When code changes land faster and more frequently, every implicit architectural assumption becomes a landmine. Backward compatibility, API contracts, blast radius -- the things that made continuous delivery safe at scale are the same things that make agentic development viable.
Post 4 is about testing. Specifically: an unreliable test is worse than no test at all. This is always true. It's catastrophically true when an AI agent is the one acting on the results.
Post 5 covers CI. Your pipeline is your agent's manager -- the primary interface between what the agent produces and your engineering standards. Most CI pipelines were not built with this in mind.
Post 6 is about monitoring. You can't test everything. In a high-velocity agentic environment, you especially can't. Monitoring is your backstop, and it deserves the same rigor as your test suite.
Post 7 pulls it together.
The disciplines aren't new. The urgency is. If you've been investing in these things already, you're in a good position. If you haven't, the good news is that the fundamentals haven't changed -- only the cost of ignoring them.
This is post 1 of 7 in The Boring Parts Matter: Engineering Fundamentals for the Agentic Era.