Why AI Makes Engineering Discipline More Important, Not Less

Everywhere you look, the conversation about AI in software engineering is the same. Faster coding. Higher developer productivity. Smaller engineering teams. More features shipped. Those are headline-grabbing benefits, but the conversation is incomplete. The process of developing the next disrupting tech involves more than a developer sitting down with an idea and coding it into reality. In fact, there are usually a whole group of people coming up with an idea, sometimes on the back of a bar napkin, and it’s what happens between the napkin and the keyboard that’s being forgotten when we talk about the magic of AI-assisted development.

Modern software development at a company usually starts with a product or feature idea. All the details of this idea are gathered in what’s commonly known as a Product Requirements Document (PRD) so that the team has a reference point for what needs to be built, why it matters, and how success will be measured. Then comes the Technical Requirements Document (TRD) that defines how the solution will be designed, built, integrated, and operated. Some organizations may have different names for these, but the importance remains the same and the practice dates originated in the 1990s. There are some very logical cases where this practice doesn’t make sense — bug fixes for example — but for new products and features it’s a must. Yet there are teams who elect to be less rigid with this documentation using Agile as justification. The result: misunderstanding, defects, and rework.

Every engineering organization wants to move faster and that’s been the case for decades. Faster delivery gets a new feature in front of your customers before your competitor and, in some cases, disrupt an industry. Speed has become the digital advantage and over the years it’s come through better methodologies and tooling, like Agile Development, DevOps, and CI/CD, it’s been achieved thanks for the efficiencies these bring. But they were never meant to reduce engineering discipline, yet it’s been my experience that teams eliminate the loathed tasks — detailed requirements gathering, design discussions, documentation, and architecture reviews — instead of eliminating waiting, handoffs, manual work, and redundant approvals. Ironically, this decision optimizes away the prevention and drives correction.

Now let’s come back to AI-assisted development. As with anything AI touches, it serves as an accelerator. It takes work a human can do and does it at lightning speed. But AI doesn’t always distinguish between good and bad work without providing the proper blueprints. In software development, AI can and has dramatically reduced the bottleneck that used to be humans interpreting requirements and typing code, limited by cognitive load and typing speed. Now, a thousand lines of code can be generated in seconds. But what happens if that code is generated without clear requirements or standards by which to create? That is the point when an organization that suffers from slow delivery takes a technology that was meant to speed them up and slows them down instead. And this time, the velocity of code means those misunderstandings, defects, and rework multiply at the same speed and the organization can no longer absorb the work.

As I talk with engineering leaders at companies of all sizes talk about their frustration with delivery speed, I remind them that the problem rarely exists in the coding skill of their team or the tools they use, it’s often somewhere between the bar napkin and the keyboard. DORA metrics provide a great mechanism for identifying where your delivery system is underperforming and are far easier to implement than people believe. If you’ve eliminated the wrong work in the name of speed, this might be a great first start. It may seem like spending time getting requirements documented and architectural standards defined may not be time you have. But if you consider the speed at which you can deliver successfully with AI-assisted development, you’ll realize that a small re-investment of that time to get these foundational practices polished will be eclipsed by your new delivery velocity.