AI Won't Replace Engineering Rigor, Only Expose Its Absence

Everyone talks about how AI will change software development. We need to talk about what won’t change. If anything, AI is forcing a return to first principles, increasing the importance of the SDLC: ➰ If code is generated, specs need to be precise. Bad instructions = scalable garbage. ➰ If output is probabilistic, reviews need to focus on intent, not syntax. ➰ If no one wrote every line, testing becomes your only source of truth. AI is less a replacement for engineering rigor than an efficient machine for punishing its absence. The abstraction is rising, but the surface area of complexity is exploding underneath: more services, more dependencies, more non-deterministic behavior. Someone still needs to reason about architecture, failure modes, and tradeoffs. This isn’t a critique of the technology. It’s excellent and improving quickly. But using it well still requires systems thinking and technical judgment. Generating code is not the same as building software, in the same way producing words is not the same as making a legal argument. Engineering starts after the code exists: validating it, integrating it, deploying it, and ensuring it doesn’t break something downstream at 2AM. Today, everyone can build - but few can build systems that last. That distinction is about to get expensive. Engineering orgs run by non-technical leadership are especially likely to learn this lesson the hard way. Expect a wave of premature cost-cutting followed by rehiring cycles once the Sev 1s start stacking. If you don't understand the distinction between “more code” and “more reliability,” AI will eventually explain it to you in production. This dynamic is amplified by the internal politics of large orgs. Scope gets claimed by overpromising, timelines get pulled forward to win resourcing. AI pours fuel on this - making it easier to show rapid early progress and paper over weak foundations, at least temporarily. The bill still arrives. On the ground, engineers are already seeing the pattern. AI works best in existing codebases with strong patterns - it learns structure and extends prior decisions. But when used to “vibe code” from scratch, it often produces brittle systems: inconsistent abstractions, awkward interfaces, and code that looks fine until it’s asked to scale. So teams have two choices: 1️⃣ Let the system emerge through prompting → fast, messy, brittle 2️⃣ Define architecture and constraints upfront → slower, but durable Most teams are choosing (1). Not because it’s better - but because it’s incentivized. When output is measured in PRs and velocity, there’s little reward for designing clean systems or thinking ahead. Complexity gets deferred and paid back later with interest. AI is making coding easier but it won't make engineering less ‘technical’. Eventually, every builder will be forced to internalize the tenets of the SDLC: version control, testing discipline, structured iteration.

Everyone talks about how AI will change software development. We need to talk about what won’t change. If anything, AI is forcing a return to first principles, increasing the importance of the SDLC: ➰ If code is generated, specs need to be precise. Bad instructions = scalable garbage. ➰ If output is probabilistic, reviews need to focus on intent, not syntax. ➰ If no one wrote every line, testing becomes your only source of truth. AI is less a replacement for engineering rigor than an efficient machine for punishing its absence. The abstraction is rising, but the surface area of complexity is exploding underneath: more services, more dependencies, more non-deterministic behavior. Someone still needs to reason about architecture, failure modes, and tradeoffs. This isn’t a critique of the technology. It’s excellent and improving quickly. But using it well still requires systems thinking and technical judgment. Generating code is not the same as building software, in the same way producing words is not the same as making a legal argument. Engineering starts after the code exists: validating it, integrating it, deploying it, and ensuring it doesn’t break something downstream at 2AM. Today, everyone can build - but few can build systems that last. That distinction is about to get expensive. Engineering orgs run by non-technical leadership are especially likely to learn this lesson the hard way. Expect a wave of premature cost-cutting followed by rehiring cycles once the Sev 1s start stacking. If you don't understand the distinction between “more code” and “more reliability,” AI will eventually explain it to you in production. This dynamic is amplified by the internal politics of large orgs. Scope gets claimed by overpromising, timelines get pulled forward to win resourcing. AI pours fuel on this - making it easier to show rapid early progress and paper over weak foundations, at least temporarily. The bill still arrives. On the ground, engineers are already seeing the pattern. AI works best in existing codebases with strong patterns - it learns structure and extends prior decisions. But when used to “vibe code” from scratch, it often produces brittle systems: inconsistent abstractions, awkward interfaces, and code that looks fine until it’s asked to scale. So teams have two choices: 1️⃣ Let the system emerge through prompting → fast, messy, brittle 2️⃣ Define architecture and constraints upfront → slower, but durable Most teams are choosing (1). Not because it’s better - but because it’s incentivized. When output is measured in PRs and velocity, there’s little reward for designing clean systems or thinking ahead. Complexity gets deferred and paid back later with interest. AI is making coding easier but it won't make engineering less ‘technical’. Eventually, every builder will be forced to internalize the tenets of the SDLC: version control, testing discipline, structured iteration.

Everyone talks about how AI will change software development. We need to talk about what won’t change. If anything, AI is forcing a return to first principles, increasing the importance of the SDLC: ➰ If code is generated, specs need to be precise. Bad instructions = scalable garbage. ➰ If output is probabilistic, reviews need to focus on intent, not syntax. ➰ If no one wrote every line, testing becomes your only source of truth. AI is less a replacement for engineering rigor than an efficient machine for punishing its absence. The abstraction is rising, but the surface area of complexity is exploding underneath: more services, more dependencies, more non-deterministic behavior. Someone still needs to reason about architecture, failure modes, and tradeoffs. This isn’t a critique of the technology. It’s excellent and improving quickly. But using it well still requires systems thinking and technical judgment. Generating code is not the same as building software, in the same way producing words is not the same as making a legal argument. Engineering starts after the code exists: validating it, integrating it, deploying it, and ensuring it doesn’t break something downstream at 2AM. Today, everyone can build - but few can build systems that last. That distinction is about to get expensive. Engineering orgs run by non-technical leadership are especially likely to learn this lesson the hard way. Expect a wave of premature cost-cutting followed by rehiring cycles once the Sev 1s start stacking. If you don't understand the distinction between “more code” and “more reliability,” AI will eventually explain it to you in production. This dynamic is amplified by the internal politics of large orgs. Scope gets claimed by overpromising, timelines get pulled forward to win resourcing. AI pours fuel on this - making it easier to show rapid early progress and paper over weak foundations, at least temporarily. The bill still arrives. On the ground, engineers are already seeing the pattern. AI works best in existing codebases with strong patterns - it learns structure and extends prior decisions. But when used to “vibe code” from scratch, it often produces brittle systems: inconsistent abstractions, awkward interfaces, and code that looks fine until it’s asked to scale. So teams have two choices: 1️⃣ Let the system emerge through prompting → fast, messy, brittle 2️⃣ Define architecture and constraints upfront → slower, but durable Most teams are choosing (1). Not because it’s better - but because it’s incentivized. When output is measured in PRs and velocity, there’s little reward for designing clean systems or thinking ahead. Complexity gets deferred and paid back later with interest. AI is making coding easier but it won't make engineering less ‘technical’. Eventually, every builder will be forced to internalize the tenets of the SDLC: version control, testing discipline, structured iteration.

Everyone talks about how AI will change software development. We need to talk about what won’t change. If anything, AI is forcing a return to first principles, increasing the importance of the SDLC: ➰ If code is generated, specs need to be precise. Bad instructions = scalable garbage. ➰ If output is probabilistic, reviews need to focus on intent, not syntax. ➰ If no one wrote every line, testing becomes your only source of truth. AI is less a replacement for engineering rigor than an efficient machine for punishing its absence. The abstraction is rising, but the surface area of complexity is exploding underneath: more services, more dependencies, more non-deterministic behavior. Someone still needs to reason about architecture, failure modes, and tradeoffs. This isn’t a critique of the technology. It’s excellent and improving quickly. But using it well still requires systems thinking and technical judgment. Generating code is not the same as building software, in the same way producing words is not the same as making a legal argument. Engineering starts after the code exists: validating it, integrating it, deploying it, and ensuring it doesn’t break something downstream at 2AM. Today, everyone can build - but few can build systems that last. That distinction is about to get expensive. Engineering orgs run by non-technical leadership are especially likely to learn this lesson the hard way. Expect a wave of premature cost-cutting followed by rehiring cycles once the Sev 1s start stacking. If you don't understand the distinction between “more code” and “more reliability,” AI will eventually explain it to you in production. This dynamic is amplified by the internal politics of large orgs. Scope gets claimed by overpromising, timelines get pulled forward to win resourcing. AI pours fuel on this - making it easier to show rapid early progress and paper over weak foundations, at least temporarily. The bill still arrives. On the ground, engineers are already seeing the pattern. AI works best in existing codebases with strong patterns - it learns structure and extends prior decisions. But when used to “vibe code” from scratch, it often produces brittle systems: inconsistent abstractions, awkward interfaces, and code that looks fine until it’s asked to scale. So teams have two choices: 1️⃣ Let the system emerge through prompting → fast, messy, brittle 2️⃣ Define architecture and constraints upfront → slower, but durable Most teams are choosing (1). Not because it’s better - but because it’s incentivized. When output is measured in PRs and velocity, there’s little reward for designing clean systems or thinking ahead. Complexity gets deferred and paid back later with interest. AI is making coding easier but it won't make engineering less ‘technical’. Eventually, every builder will be forced to internalize the tenets of the SDLC: version control, testing discipline, structured iteration.

Everyone talks about how AI will change software development. We need to talk about what won’t change. If anything, AI is forcing a return to first principles, increasing the importance of the SDLC: ➰ If code is generated, specs need to be precise. Bad instructions = scalable garbage. ➰ If output is probabilistic, reviews need to focus on intent, not syntax. ➰ If no one wrote every line, testing becomes your only source of truth. AI is less a replacement for engineering rigor than an efficient machine for punishing its absence. The abstraction is rising, but the surface area of complexity is exploding underneath: more services, more dependencies, more non-deterministic behavior. Someone still needs to reason about architecture, failure modes, and tradeoffs. This isn’t a critique of the technology. It’s excellent and improving quickly. But using it well still requires systems thinking and technical judgment. Generating code is not the same as building software, in the same way producing words is not the same as making a legal argument. Engineering starts after the code exists: validating it, integrating it, deploying it, and ensuring it doesn’t break something downstream at 2AM. Today, everyone can build - but few can build systems that last. That distinction is about to get expensive. Engineering orgs run by non-technical leadership are especially likely to learn this lesson the hard way. Expect a wave of premature cost-cutting followed by rehiring cycles once the Sev 1s start stacking. If you don't understand the distinction between “more code” and “more reliability,” AI will eventually explain it to you in production. This dynamic is amplified by the internal politics of large orgs. Scope gets claimed by overpromising, timelines get pulled forward to win resourcing. AI pours fuel on this - making it easier to show rapid early progress and paper over weak foundations, at least temporarily. The bill still arrives. On the ground, engineers are already seeing the pattern. AI works best in existing codebases with strong patterns - it learns structure and extends prior decisions. But when used to “vibe code” from scratch, it often produces brittle systems: inconsistent abstractions, awkward interfaces, and code that looks fine until it’s asked to scale. So teams have two choices: 1️⃣ Let the system emerge through prompting → fast, messy, brittle 2️⃣ Define architecture and constraints upfront → slower, but durable Most teams are choosing (1). Not because it’s better - but because it’s incentivized. When output is measured in PRs and velocity, there’s little reward for designing clean systems or thinking ahead. Complexity gets deferred and paid back later with interest. AI is making coding easier but it won't make engineering less ‘technical’. Eventually, every builder will be forced to internalize the tenets of the SDLC: version control, testing discipline, structured iteration.

Everyone talks about how AI will change software development. We need to talk about what won’t change. If anything, AI is forcing a return to first principles, increasing the importance of the SDLC: ➰ If code is generated, specs need to be precise. Bad instructions = scalable garbage. ➰ If output is probabilistic, reviews need to focus on intent, not syntax. ➰ If no one wrote every line, testing becomes your only source of truth. AI is less a replacement for engineering rigor than an efficient machine for punishing its absence. The abstraction is rising, but the surface area of complexity is exploding underneath: more services, more dependencies, more non-deterministic behavior. Someone still needs to reason about architecture, failure modes, and tradeoffs. This isn’t a critique of the technology. It’s excellent and improving quickly. But using it well still requires systems thinking and technical judgment. Generating code is not the same as building software, in the same way producing words is not the same as making a legal argument. Engineering starts after the code exists: validating it, integrating it, deploying it, and ensuring it doesn’t break something downstream at 2AM. Today, everyone can build - but few can build systems that last. That distinction is about to get expensive. Engineering orgs run by non-technical leadership are especially likely to learn this lesson the hard way. Expect a wave of premature cost-cutting followed by rehiring cycles once the Sev 1s start stacking. If you don't understand the distinction between “more code” and “more reliability,” AI will eventually explain it to you in production. This dynamic is amplified by the internal politics of large orgs. Scope gets claimed by overpromising, timelines get pulled forward to win resourcing. AI pours fuel on this - making it easier to show rapid early progress and paper over weak foundations, at least temporarily. The bill still arrives. On the ground, engineers are already seeing the pattern. AI works best in existing codebases with strong patterns - it learns structure and extends prior decisions. But when used to “vibe code” from scratch, it often produces brittle systems: inconsistent abstractions, awkward interfaces, and code that looks fine until it’s asked to scale. So teams have two choices: 1️⃣ Let the system emerge through prompting → fast, messy, brittle 2️⃣ Define architecture and constraints upfront → slower, but durable Most teams are choosing (1). Not because it’s better - but because it’s incentivized. When output is measured in PRs and velocity, there’s little reward for designing clean systems or thinking ahead. Complexity gets deferred and paid back later with interest. AI is making coding easier but it won't make engineering less ‘technical’. Eventually, every builder will be forced to internalize the tenets of the SDLC: version control, testing discipline, structured iteration.

Everyone talks about how AI will change software development. We need to talk about what won’t change. If anything, AI is forcing a return to first principles, increasing the importance of the SDLC: ➰ If code is generated, specs need to be precise. Bad instructions = scalable garbage. ➰ If output is probabilistic, reviews need to focus on intent, not syntax. ➰ If no one wrote every line, testing becomes your only source of truth. AI is less a replacement for engineering rigor than an efficient machine for punishing its absence. The abstraction is rising, but the surface area of complexity is exploding underneath: more services, more dependencies, more non-deterministic behavior. Someone still needs to reason about architecture, failure modes, and tradeoffs. This isn’t a critique of the technology. It’s excellent and improving quickly. But using it well still requires systems thinking and technical judgment. Generating code is not the same as building software, in the same way producing words is not the same as making a legal argument. Engineering starts after the code exists: validating it, integrating it, deploying it, and ensuring it doesn’t break something downstream at 2AM. Today, everyone can build - but few can build systems that last. That distinction is about to get expensive. Engineering orgs run by non-technical leadership are especially likely to learn this lesson the hard way. Expect a wave of premature cost-cutting followed by rehiring cycles once the Sev 1s start stacking. If you don't understand the distinction between “more code” and “more reliability,” AI will eventually explain it to you in production. This dynamic is amplified by the internal politics of large orgs. Scope gets claimed by overpromising, timelines get pulled forward to win resourcing. AI pours fuel on this - making it easier to show rapid early progress and paper over weak foundations, at least temporarily. The bill still arrives. On the ground, engineers are already seeing the pattern. AI works best in existing codebases with strong patterns - it learns structure and extends prior decisions. But when used to “vibe code” from scratch, it often produces brittle systems: inconsistent abstractions, awkward interfaces, and code that looks fine until it’s asked to scale. So teams have two choices: 1️⃣ Let the system emerge through prompting → fast, messy, brittle 2️⃣ Define architecture and constraints upfront → slower, but durable Most teams are choosing (1). Not because it’s better - but because it’s incentivized. When output is measured in PRs and velocity, there’s little reward for designing clean systems or thinking ahead. Complexity gets deferred and paid back later with interest. AI is making coding easier but it won't make engineering less ‘technical’. Eventually, every builder will be forced to internalize the tenets of the SDLC: version control, testing discipline, structured iteration.