Every other engineering post right now is about getting more out of AI. Better workflows, smarter prompts, sharper agent skills… But for many, many months now, the model or the workflow you use stopped being the bottleneck. The biggest bottleneck today is you, the human in the loop.
Despite this, we see very little discussion on building human skills; agent skills get all the attention.
We are moving away from “Read the auth module, find the race condition in token refresh, propose two fixes with trade-offs” to “fix the auth bug.”
What are we losing? Let’s do the math.
The AI Magic Wand
AI is a magic wand. You point it at a problem, and the problem gets solved, without you doing the work or even having to understand it. The wand remembers what you no longer have to: function signatures, library quirks, how a specific service wires together.
Back when I was learning to code, memorizing was part of mastery. The ins and outs of a language, the syntactic shortcuts, the library catalog with all its functions and argument options. You carried it all in your head. As your skillset grew, so did the volume of stuff you had to keep alive in memory just to not forget it.
Most of that is gone now. The constraint has never been how much we could learn; it’s been how much we could keep and carry forward. That constraint is being rewritten. The cognitive space we used to spend on syntax is now free for other things.
Most read that as good news. But the freed space comes with a question: what do you fill it with?
The Hidden Cost of the Wand
A magic wand gives you what you want without you having to understand how it was made. If you understood it, it wouldn’t be magic, it would just be a tool. But the wand has a side effect:
The more it works, the less you need to know.
The less you know, the poorer your judgement will be. It’s a vicious cycle, and the result is skill atrophy. It’s sneaky, it bides its time, and it shows up when you least expect it.
Another problem is blind spots. The AI may not understand the nuances of your domain or use case, leading to errors that you might not catch. That’s why we hear a lot of people saying:
AI does a great job at everything! But in my own domain of expertise, it gets a lot of things wrong.
You can only evaluate AI output where you have judgement. To have judgement, you need to have knowledge and an understanding of what “good output” is.
Without exposure to the internals, we go from builders to operators pulling levers.
Letting the wand always do the work abdicates effort. You stop doing the work yourself. It’s comfortable, somewhat lazy, but recoverable through deliberate practice and study.
Trusting the wand too much abdicates evaluation. You stop being able to tell good from bad. That one isn’t immediately noticeable because it creeps up slowly, and the long-term consequences won’t show up on a velocity chart.
Every craft has two kinds of practitioners: the ones who learned the steps and the ones who learned the reasons. A carpenter who knows the steps can build a chair. A carpenter who knows the reasons can build a chair for a room they’ve never seen, out of a wood they’ve never used, for a person they’ve never met.
With or without AI, you want to be in the latter camp. With everybody focused on improving the AI portion of their workflow, the differentiator is the part that’s getting less attention: the human in the loop.
Don’t Sleep at the Wheel
Attention Follows Effort
Pull requests used to take days, so by the time you opened one, you’d already self-reviewed it three times. The PR you opened last week probably took a couple of hours, and you may have skimmed the diff only once. As the output becomes abundant, attention becomes scarce. Same pattern with documentation. Same pattern with testing. Same pattern with the question of whether the feature was even worth building.
The Velocity Mirage
The constant pressure to ship more, faster, has parked us all in prototype mode. AI excels at the prototype phase. It’s good at getting something working that looks like the thing you wanted. Production-grade software, the kind that survives load, security review, and the next engineer who has to maintain it, takes a different kind of effort. That part still remains a challenge.
So we ship more, but the question worth asking is: more of what?
Velocity charts are looking better than ever. Lines of code, story points, features shipped, time to MVP. Everything’s up. By every quantitative metric you’d put on a dashboard, we are more productive than ever.
The outcome is harder to feel good about. Outages at companies that should know better. Mistakes that should never have shipped. Documentation that feels like either an initial draft or a short novel. Codebases that nobody fully understands. Five features shipped where one was needed, and none of them done well enough to count.
Decisions, Decisions, Decisions…
There’s another side to all this output. Anything can be spun up in an hour now, so choosing what’s worth spinning up has become its own bottleneck. Psychology calls this analysis paralysis. The cost of effort used to be our filter: you couldn’t try ten things when each one took weeks. AI removed the filter, and most organizations haven’t built a new one.
Meanwhile, documentation is starting to play out like a game of telephone with no humans in it. AI writes the docs. AI reads them on our behalf. The shared understanding that used to live in a codebase is quietly thinning out, and when something breaks, the team is no longer sure what was supposed to be true. A paper from earlier this year, From Technical Debt to Cognitive and Intent Debt, names this intent debt: the rationale behind decisions stops being externalized, because the tool making them doesn’t write down its reasoning.
The Diverging Paths
Reading, studying, sitting with hard problems. For the entire history of engineering, these were the price of entry. Now they set you apart, because fewer people invest in them. What used to be a requirement is turning into a moat.
We are approaching a diverging path. Either we put in the necessary effort to preserve the qualities that make us builders, or we accept losing our “hard-won agency” one prompt at a time.
Why Fundamentals Are More Important Than Ever
The work AI did not take is the work that always mattered most.
Breaking a problem into modules with single responsibilities. Deciding which trade-offs are worth making. Knowing when a pattern fits and when it doesn’t. That decomposition was always the hard part. The implementation was the long and tedious part, but the decomposition was the thinking part.
The cognitive space you used to spend on syntax is now free for the part that actually matters. It’s a win that’s not getting enough attention.
Picking up a new conceptual framework used to mean committing weeks to a side project. Understanding was expensive because implementation was expensive. That equation shifted. You can now read about DDD, then have AI scaffold a sample bounded context and walk you through the choices. You can study event-driven design, then have AI generate three patterns side by side so you can compare. You don’t have to write every line yourself anymore. You do have to understand what was written, why this approach instead of that one, and where this pattern breaks.
The theme is understand first, scaffold second. “Build me a GraphQL gateway” is the wand doing magic for someone who doesn’t know what to ask for. Read about GraphQL first. Work through someone else’s repo on GitHub. Understand why certain principles matter and what they cost. Then have AI scaffold a real implementation based on the design decisions you actually made.
You can learn five things at once now. Isn’t that exciting?
The trap to watch is the “you’re absolutely right” echo chamber. An agent that agrees with you is not a peer. It’s an assistant trained to be agreeable. I also find it important to preserve my creative freedom when doing any kind of work. Just because something has been done before doesn’t mean it’s what you need, or that you can’t come up with something better yourself.
Here’s my preferred way of working that helps keep the mind sharp:
- Take a swing yourself first. Sketch the architecture, write the function, draft the migration plan.
- Search for if and how other engineers have already solved this.
- Ask AI, or better, multiple agents in parallel, to do the same thing.
- Synthesize the best parts into one coherent plan.
- Get a real human to review it.
It is slower than asking an agent to “do the thing”. It also produces work you actually understand, in a domain you actually own, with decisions you can defend.
A small refinement to a frame from my last article. I said our role with AI agents is becoming a manager’s. For engineering decisions specifically, it’s closer to tech lead. Managers can be not-too-technical and trust their team’s judgement. Tech leads can’t. The depth is the job, and the fundamentals are how you keep it.
So what does this look like in practice?
My Two Cents
If you’re an individual contributor
Embrace traditional learning. Read books. Take courses. Work through documentation without a chat window open. AI-assisted work doesn’t teach you what deliberate study does, because work is built to ship, not to teach.
Use AI as a thinking companion. There’s a real difference between asking AI to design something for you and asking it to push back on something you drafted. The second is the version worth doing. You stay in the design process, learn from the friction, and end up with code you can defend.
Own the judgement calls. AI writes the code. You decide whether the code should exist, whether the design is right, and whether the trade-offs are the ones you want. Assess carefully when you want to be on auto-pilot, or you might find yourself asleep at the wheel.
Write down the What, Why, and When. AI took over the How, but it doesn’t externalize the decisions behind it. Capture those decisions in writing: what problem you’re solving, why it matters, when this approach applies. Otherwise the next engineer (or you in six months) starts from scratch. Repo-level docs can act as a decent knowledge base for agents.
Refuse the easy path. AI is good at producing answers that look right and sound agreeable, even when they’re wrong or shallow. Sketch your own answer first, then compare. Get a real human to review what you ship.
If you’re a manager or leader
Reserve sprint capacity for the work AI made cheap. Tech debt has always been hard to justify because the work was tedious and didn’t ship features. That equation shifted. AI handles repetitive cleanup work well, which means the kind of stuff teams used to defer indefinitely is now actually feasible to do. Consider carving out something like 20% of every sprint for it.
Schedule learning blocks in every sprint. A half-day per sprint dedicated to exploring new tools, reading docs, or working through a course. Considering making it part of the sprint, not only something engineers have to do on their own time. The engineers who use the time keep the judgement to evaluate architectural choices. Without it, those choices end up made by AI.
Don’t trade human review for speed. Writing code got dramatically faster, but reviewing still requires the same effort, if not more due to volume. The natural response when velocity is up is to skim reviews and trust the agent, but that’s exactly when we can’t afford to do so. If anything, the freed-up time should go into more careful review, not less of it.
Velocity isn’t value. This has always been a hard problem in software. Velocity is easy to count, value is hard to measure honestly, and that gap was there before AI. What changed is that velocity goes up faster now, so the gap looks bigger, and teams that don’t separate the two end up celebrating output that doesn’t actually move the business forward.
You don’t own your AI. We tend to think of AI as ours, but it isn’t. Your team’s productivity now depends on a provider you don’t control. Their pricing, their model changes, their downtime, all of it affects your throughput. Have a plan for what the work looks like when the AI gets worse, more expensive, or unavailable.
Wrapping Up
I wrote this because the discourse around AI is loud on one side and quiet on the other. We talk about agents and how to build their skills constantly. And it’s great that we are exploring the endless ways of working with these tools and figuring out ways to make things better, easier and faster.
What’s missing is that we no longer give the same attention to building our own skills like we used to.
We are getting better agents, but losing individual agency. The comfort may be to our own detriment.
The salesman would tell us that the wand will never run out of charges, it will always get better in time, and that we should never have to worry about doing anything ourselves ever again.
The question is, do you buy it?
Want help thinking about this at the team level? Let’s talk.
Want more content like this? Follow me on LinkedIn.