Deliver faster, at the expense of understanding?

Every line of code you don't understand is a loan you'll eventually repay, with interest.

Dec 16, 2025

👋 Hey, it’s Stephane. I share lessons, and stories from my journey to help you lead with confidence as an Engineering Manager. To accelerate your growth see: 50 Notion Templates | The EM’s Field Guide | CodeCrafters | Get Hired as an EM | 1:1 Coaching

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

How fast you can ship? LinkedIn is full of it. “Built and deployed an app in 4 hours.” “Created 3 MVPs this week.” “My AI agent wrote 20,000 lines of code while I slept.”

Cool. But do you understand any of it?

I’m not here to be the grumpy old guy yelling at clouds. AI-assisted development is genuinely useful, and I also use it daily. But I’ve noticed something troubling in the discourse: we’ve started treating understanding as optional. As overhead. As something that slows you down.

That’s backwards. Understanding doesn’t slow you down, it’s the reason you’re fast in the first place.

Speed

Something I’ve observed across every high-performing engineer I’ve worked with: they’re fast because they understand deeply, not despite it.

When you truly understand your tools, your codebase, and your domain, you make fewer wrong decisions. You don’t spend three hours debugging something that a deeper mental model would have prevented. You don’t build the wrong abstraction and have to tear it down two sprints later.

Speed is a byproduct of proficiency. It’s not a substitute for it.

People nowadays see fast engineers and conclude that speed is the goal. But those engineers aren’t fast because they’re trying to be fast. They’re fast because they’ve invested years in understanding systems at a deep level, and that understanding compounds.

When you prompt your way through a problem you don’t understand, you might ship faster today. But you’re not building the mental models that make you faster tomorrow. You’re borrowing speed from your future self.

If you’re enjoying this article, consider subscribing to get:

✉️ Free: 1 original post every Tuesday, my favourite posts of the week every Sunday + 10 Notion Templates for Engineering Managers
🔒 Paid: Full archive + 50+ EM templates & playbooks + The EM Field Guide

Knowledge debt

We talk about tech debt constantly. We have entire methodologies for managing it, metrics for measuring it, and quarterly initiatives for paying it down.

But nobody’s tracking knowledge debt.

Knowledge debt is what accumulates when you ship code you don’t understand. It’s the gap between what your codebase does and what you’re capable of reasoning about. And just like tech debt, it compounds.

Example: You use AI to build a feature quickly. You don’t fully understand the implementation, but it works. Tests pass. Ship it. Three months later, something breaks. You look at the code and realize you have no mental model for why it was written this way. You can’t debug it because you never understood it in the first place.

So what do you do? You ask AI to fix it. Which it does, sort of. But now you understand even less. The gap widens.

Every time you let AI handle something without building your own understanding, you’re making a withdrawal from an account you never deposited into.

The maintenance problem

The LinkedIn posts about shipping fast never include the sequel: the maintenance.

Software spends maybe 20% of its life being written and 80% being maintained, debugged, extended, and understood by people who didn’t write it. That’s been true for decades, and AI doesn’t change it.

What AI does change is this: it’s now possible to create mountains of code that no human has ever actually understood. Not the person who prompted it. Not their teammates. Nobody.

I’ve seen this in the wild already. Someone “ships fast” with heavy AI assistance, moves on to the next project, and leaves behind a codebase that’s technically functional but intellectually orphaned. When something goes wrong (and something always goes wrong) the person debugging it is starting from zero. Worse than zero, actually, because they’re also fighting the assumption that since it worked before, it must be correct.

We’re creating legacy code at unprecedented speed.

How about interviews

You still have to interview.

Interviews still involve live coding. They still involve explaining your thinking. They still involve demonstrating that you can solve problems, not just describe problems to a machine that solves them for you.

If you spend two years prompting your way through work, what happens to your ability to write code from scratch? To reason through a problem out loud? To remember the syntax, the patterns, the idioms that used to be automatic?

Skills atrophy. The neural pathways you don’t use weaken. The knowledge you don’t actively reinforce fades.

As a hiring manager I am already seeing this. Candidates with impressive-looking recent work fall apart in live coding rounds. People who can describe what they want to build but can’t actually build it when the AI crutch is removed.

This isn’t sustainable. At some point, you will need to demonstrate your skills without assistance. And if you’ve spent years not building those skills, that moment will be painful.

How to actually use AI

None of this means you shouldn’t use AI. I use it constantly. But I use it in ways that build my understanding rather than replacing it.

Use AI for acceleration. The best use case for AI is when you already know how to do something but want to do it faster. Refactoring, boilerplate, well-defined tasks in domains you understand. You’re delegating the typing, not the thinking.

Treat AI output as a draft, not a deliverable. Read the code. Understand why it made the choices it made. Ask questions until you could have written it yourself. If you can’t explain it, you’re not ready to commit it yet.

Use AI as interactive documentation. This is actually where AI shines for learning. You can ask questions, get explanations tailored to your context, and explore concepts in conversation. But you have to actually engage with the learning, not skip it.

Maintain your foundation. Regularly write code without AI assistance. Not because AI is bad, but because you need to keep those neural pathways active. Think of it like physical exercise, you don’t stop walking just because cars exist.

The long game

In five years, we’re going to have two kinds of engineers.

The first kind will have deep mental models of systems, architectural thinking, and the ability to debug anything. They used AI as a tool to amplify their existing capabilities. They’re more productive than ever because they understand more than ever.

The second kind will be dependent on AI for everything, including things they used to know how to do. When the AI gets stuck, they’ll be stuck too. They shipped a lot of stuff, but they can’t explain how any of it works.

The industry’s obsession with speed is understandable. Shipping feels good. Metrics go up. But speed without understanding is optimising for the short term. You might be moving fast, but you as an individual might not necessarily be getting anywhere.

Take the time to understand what you’re building. It’s not slower, it’s the foundation that makes everything else faster. And unlike the code, that understanding is yours to keep.