A Discussion That Reframed Software Development
I was having drinks with a former co-worker I had worked with for many years creating video games and then creating high-definition automotive-grade digital maps. As it happens with most of my coder friends these days, the subject of AI doing software development became a hot topic of discussion. My friend smirked at me and said, “This AI stuff is going to kill agile development because now it's all about creating requirements.” I kind of brushed this off, thinking that he was saying developers wouldn't need to take big projects, plan short-term, iterate, re-plan, rinse, and repeat. Then I thought, maybe he has a point?
If one creates a group of documents for a specific design, technical architecture, and coding parameters, a working prototype can be created very quickly. Iterations can be adjusting the requirement documents and regenerating the project from scratch. So build the whole thing, not just pieces, try it, fix the requirements, and iterate again. I don't think we're quite there yet, or that agile development doesn't fit into this picture, but we're headed to a place where the better the stated requirements, the faster you can create and iterate, which feels new to me. You can see this already with prototyping tools being able to export working prototypes, vibe coding, and the automatic creation of boiler plate frameworks.
The Developer's Role
I know most companies haven't thrown writing technical requirements completely away, but I have to say I haven't read a really good technical requirements document that included all the specifics, edge cases, interfaces, structures, and definitions in a long time. I'm not saying that future software development will be done by folks iterating on the requirements documentation. If my time in games has taught me anything, it's that you can have the best design on paper, but you don't know if it's fun until you can play it. But what I am saying is that software development is moving to a place where the better you can articulate your requirements, the faster you can build and iterate. Soon, writing good requirements will be required. Now that I’ve written this without AI lets see what ChatGPT has to say 🙂
ChatGPT -> Requirements: Write me a blog post in my tone of voice that talks about me talking with a friend about the new importance of technical requirements now that AI can understand them and generate code. The setting is my friend and I sitting outside having a drink and a discussion. Use a conversational story telling style.
The Rise of Requirements: A Conversation Over Drinks
The other evening, I was sitting outside with a good friend, the kind of friend who’s been around long enough to remember when “requirements” meant a Word doc nobody read and a Jira ticket everybody interpreted differently. We had a couple of drinks in hand, the weather was surprisingly cooperative, and naturally our conversation drifted (like it always does) to tech.
He asked me what I thought about all the hype around AI writing code. “I mean, isn’t this the moment developers just… disappear?” he said, half-joking, half-curious.
I laughed. “Developers aren’t going anywhere. But requirements? Requirements are about to matter more than they ever have.”
He raised an eyebrow. “Requirements? The things everyone pretends to write but actually copy from the last project?”
“Exactly,” I said.
Because here’s the thing: AI can interpret well-written requirements frighteningly well. Give an LLM a clear, structured set of constraints and it can generate boilerplate, plumbing, scaffolding, and even a large chunk of business logic without breaking a sweat. But give it the usual half-baked bullet list, 'System shall do X' with zero context, and you get exactly what you’d expect: confident nonsense wrapped in well-formatted code.
The real shift is this: we’re moving from an era where engineering filled in all the gaps to an era where the cost of ambiguity is amplified by machines that will happily assume whatever you forgot to specify.
My friend took a sip and nodded. “So you’re saying we’ve been underestimating requirements because humans are good at filling in blanks?”
“Exactly. Humans bridge ambiguity automatically. AI doesn’t. It just picks a direction and sprints.”
We talked about how, for years, we built teams that compensated for unclear requirements through constant communication. This included standups, refinement, whiteboards, tribal knowledge, and hallway conversations. But now? If AI becomes part of your engineering pipeline, the weakest link is no longer developer productivity. It’s the clarity of the input.
Requirements as Engineering Leverage
Well-written requirements essentially become force multipliers. They speed up onboarding. They accelerate prototyping. They eliminate entire categories of rework. And once AI becomes a first-class citizen in software development (and it will), writing crisp, unambiguous requirements becomes a core engineering skill, not a side quest.
My friend laughed. “So now product managers need to learn how to talk to robots.”
“Yep. And engineers need to get comfortable collaborating with something that never sleeps, never complains, and happily generates code at 3 a.m. without any caffeine.”
We finished our drinks as the sun dipped. The conversation shifted to other things like life, work, the usual. But the thought stuck with me:
For the first time in decades, the bottleneck in software isn’t building systems. It’s describing them.
The better we get at defining what we want, the faster AI can help us build it. Requirements are no longer bureaucracy; they’re leverage. And in this new world, they’re not just important. they’re strategic.
