The Engineering Bottleneck Has Moved | ProductNow<br>All posts

The Engineering Bottleneck Has Moved<br>byKadhir Mani<br>(4.8 minutes)

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:how carefully we speccedhow many reviews we ranhow long we waited before committing to anythingI 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.<br>Before and After MindsetBefore 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.<br>Three Specific ShiftsThe 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.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.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.<br>Implications for Team Practices and What Still MattersAI-assisted development compresses iteration cycles, which changes how we strategize in engineering, not just how we write code.Implications for our team so far:Delegate more aggressively. Generation is cheap, so juniors can own more surface area. Your job shifts from writing to setting constraints and reviewing outcomes.Review for risk, not style. Code review becomes "what fails at scale or under load," not "how did you write this."Choose reversible dependencies. Fast iteration exposes bad lock-in fast. Prefer contracts you can swap in a sprint.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.Teach taste, not syntax. Mentorship shifts toward helping engineers recognize plausible-but-wrong output.<br>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...