The Engineering Bottleneck Has Moved

Kadhir Mani

(4.8 minutes)

<section data-section-id='f99e031a-87d7-4d28-bab3-c8b339ad3fbf'>For most of my career, I treated engineering decisions like they were carved in stone the moment I made them. Choose the wrong abstraction, and you'd pay for it for years. Pick the wrong service boundary, and you'd be untangling it for quarters. That cost shaped everything:<ul><li value="1">how carefully we specced</li><li value="2">how many reviews we ran</li><li value="3">how long we waited before committing to anything</li></ul> I don't think that instinct is wrong, exactly, but I think it's become less relevant these days. AI-assisted development has made the first pass so cheap that the bottleneck has quietly shifted. The expensive part is no longer writing the code. I think it's now knowing what to write, catching what's subtly wrong, and deciding what actually matters. In other words, caution used to be important, especially at scale, but I think judgment takes its place now. The last few months especially changed how I think about engineering. </section> <section data-section-id='30b3ec62-6f1f-4747-a80d-9b26da2d5104'><h2 id="before-and-after-mindset">Before and After Mindset</h2>Before AI-assisted development, dependency changes and debt cleanup carried a specific cost: attention and risk, not just time. Touching an interface meant auditing every downstream consumer first. Refactoring a core module meant mapping the call sites and absorbing anything that was missed. I guarded the design, deferring cleanup, defending abstractions longer than was healthy, because disruption required effort I couldn't justify mid-sprint. But now, AI makes validation, migration, and refactoring cheap enough to try, inspect, and undo. I can draft a migration path, review the diff, and abandon the approach in an afternoon if it's wrong. No real time or effort lost. Speculative refactors I used to defer indefinitely now happen in the same session as the feature work that exposed them. The real shift for me is where we can spend our attention. When touching code is expensive, you protect it. When it's cheap, you can explore it. Wariness now belongs only to decisions genuinely hard to reverse: data migrations without rollbacks, API contracts with external dependents, architectural choices baked into topology. Everything else is fair game, and that changes how I think about design from the start. </section> <section data-section-id='1cd31f23-9864-4d34-9717-d62f125d60e1'><h2 id="three-specific-shifts">Three Specific Shifts</h2> <collapsible-card data-icon="layers" data-title="Dependencies: patch or fork without fear" data-default-collapsed="true">The old instinct was purity: pin exact versions, avoid forks, treat every upstream dependency as sacred. My new instinct is more pragmatic. AI-assisted validation makes it cheap to test a locally patched dependency against your surface area in seconds. And better yet, the models help make migrating off dependencies just as easy, so you're never truly locked in. "Try it, then move on" beats waiting for upstream, especially because you ask the model to migrate you back to the upstream when it's ready.</collapsible-card> <collapsible-card data-icon="settings" data-title="Debt: lighter, not weightless" data-default-collapsed="true">The old instinct was to hoard cleanup work for dedicated sprints. Debt was expensive to pay down, so you batched it or ignored it. My stack primarily consists of Devin, Cursor and Codex, which makes refactors and style fixes happen super quick. I still like having code that's easy for a human to read, just in case we need to dig into a gnarly bug. That incremental cleanup is now viable between features, not just in dedicated cycles. That changes the calculus: debt is less scary, less something to defer. But it's still real — AI tools compress the effort, not the judgment required to know what to fix and when.</collapsible-card> <collapsible-card data-icon="layout" data-title="Interfaces: stop designing for screens first" data-default-collapsed="true">Chat and agent surfaces punish screen-centric thinking. If your product's core logic is tightly coupled to a specific UI shape, you'll rebuild it every time the interaction model shifts — and right now, interaction models are shifting fast. The new instinct is to treat UI as a thin, disposable layer over well-defined behavior. Build systems that are easy to change or delete. Invest in the semantics of what your system does, not the pixels of how it looks. Over-engineering a fixed interface is the new premature optimization.</collapsible-card> </section> <section data-section-id='22a15ee0-de60-432c-9b91-01f6d81f8893'><h2 id="implications-for-team-practices-and-what-still-matters">Implications for Team Practices and What Still Matters</h2>AI-assisted development compresses iteration cycles, which changes how we strategize in engineering, not just how we write code. Implications for our team so far:<ul><li value="1">Delegate more aggressively. Generation is cheap, so juniors can own more surface area. Your job shifts from writing to setting constraints and reviewing outcomes.</li><li value="2">Review for risk, not style. Code review becomes "what fails at scale or under load," not "how did you write this."</li><li value="3">Choose reversible dependencies. Fast iteration exposes bad lock-in fast. Prefer contracts you can swap in a sprint.</li><li value="4">Design for deletion. AI-generated code gets replaced more often. Modular, bounded design isn't just elegant, it's more practical now than it's ever been.</li><li value="5">Teach taste, not syntax. Mentorship shifts toward helping engineers recognize plausible-but-wrong output.</li></ul> </section> <section data-section-id='c918ae89-a7f7-4ac5-bc2e-fedfe37b4696'>What still mattersAI can write code faster than ever, but that doesn't mean it gets things right. It often produces code that runs without errors, yet still solves the wrong problem. Someone still has to read it, maintain it, and catch those mistakes. That someone is you. A few things haven't changed:<ul><li value="1">You still need to decide what the right solution looks like. AI doesn't understand your business needs as well as you do.</li><li value="2">Code should still be readable. If something goes wrong and you need to step in and debug it yourself, you'll be glad you can follow what it's doing.</li><li value="3">Only real people understand what users are actually struggling with. AI can't feel that.</li><li value="4">Moving faster is great, but the final call still belongs to a human.</li></ul> The tools sped up the work. The judgment is still yours. </section> <section data-section-id='dc64f566-2800-4a1d-b643-f3c5526854b4'><h2 id="final-thoughts">Final Thoughts</h2>AI doesn't remove the hard work from engineering. It relocates it. The hours that once went into untangling legacy code, patching brittle integrations, and maintaining systems that nobody fully understood can now go toward something better: understanding users, designing adaptable architectures, and building things that actually matter. The maintenance tax isn't gone, but it's shrinking. What you do with that reclaimed attention is the real question, and the engineers who answer it well are the ones who'll define what this era of software development becomes. </section>

Published

June 24, 2026

Keep reading

How we extracted standalone HTML files from 7 / 13 AI prototyping tools

We tried extracting self-contained HTML files from 13 AI prototyping tools. 7 worked, 6 didn't. Here's what we learned about each platform — from ChatGPT's clean 3.2 KB export to Canva's 3.5 MB bundle that still couldn't run offline.

Engineering

CRDTs Are Not Enough When Your Coworker Is an AI Agent

CRDTs converge; they do not coordinate. That distinction becomes critical the moment an AI agent joins the editor. Why multiplayer collaboration needs a coordination layer above merge, and the section-level lease protocol we built to keep agents well-mannered.

Engineering

Good code, Wrong feature: The handoff problem

Someone sends you a ticket: 'Add the export feature — you know what we need.' You don't, actually. Why the real breakdown in AI-native development isn't the code — it's the handoff from discovery to implementation.

Engineering