AI strategy, agile waterfall, and spec driven development

I spend my days doing R&D around software development, innovation, and how enterprises can harness the power of AI to solve problems. As someone that has built enterprise software, systems, and run global software development teams, here are some ideas that I'm currently grappling with. Each one probably deserves a separate post, but in the interest of time, I'll share these as-is. If time permits in the weeks and months that follow, I'll expand on the ones people show interest in.

A general AI strategy for most organizations

Clearly, AI can do a million amazing things. However, within the context of business, we are all looking for ways to bring about efficiency, increase productivity, and solve problems that were previously impossible. To that end, nearly every enterprise faces the same set of challenges. To incorporate AI into our applications, most enterprises will have to:

  1. Focus on business processes. When you don't have a clear understanding of what you're trying to do, there's a high likelihood that you'll end up somewhere else. The added benefit of starting with business process is that you'll train your eye on the things that truly drive value for your business and your customers.
  2. Modernize applications to use a micro service, API led architecture, if your applications currently do not. This enables applications to interact with other applications programmatically.
  3. Using what you've learned about your business processes, you'll want to group APIs to create "tools" that can be called by other applications, or by AI agents. Tools are one or more APIs within your applications that have been made available to AI using something called model context protocol or MCP for short. MCP is the glue between AI and your enterprise; and one way to deploy agents that go beyond generic actions to doing meaningful work.

An agile waterfall

Waterfall, as the name implies, is a software development practice where teams move from one step to the next, in a singular direction, much like a waterfall. Teams spend time upfront working on business requirements and validating them before writing code. They hope to "build it right the first time". However, as is often the case, upon seeing a thing built, we often have additional ideas of what it ought to be, initiating change: which has always been costly. Enter Agile: an incremental way of building software that eschewed getting it all right the first time, in favor of short development cycles that build software iteratively. We focused on an MVP (minimal viable product), knowing that it would change, giving users a voice, and thereby increasing satisfaction in the end.

Today, the time required to gather requirements, and the technical specifications that accompany them has been cut drastically; to the point where I now prefer getting all my requirements upfront before writing code. A return to this holistic approach now provides better context to whatever agentic process one might use downstream to build software.

That said, coding can still be done in sprints. But with all the requirements and technical specifications on hand, my agents do a better job planning and executing, with minimal rework.

Spec driven development with AI

Vibe coding is not what businesses do. The idea that we can just "vibe" to build software is novel, but not practical in an enterprise setting where we need greater visibility and transparency. Working code alone is not enough. We need requirements and specifications that can be tested against, to ensure that software works as intended. Many of us also operate in highly regulated and audited environments.

To that end, I would argue that today specs have taken the place of code. Just as we didn't care about the final binary if we had the source code that produced it, I would argue that we no longer care about code either. If we have the specs that were used to generate the code we have, we can always regenerate code. This is why it is even more important to once again take your time with requirements upfront. Make sure you capture them systematically and update them as part of your iterative development cycle. Agents should be instructed to keep requirements in sync with our implementation, as they code.

If you do this right, you'll significantly reduce your chances of accruing technical debt.

Join the discussion on LinkedIn.