How to Solve the Right Problem in the Age of Agentic AI

The post How to Solve the Right Problem in the Age of Agentic AI appeared first on Towards Data Science.

Introduction

Before AI, implementation capacity was scarce. A bad requirement might waste a few engineers' time. With AI, that capacity expands dramatically. A bad requirement can now produce hundreds of wrong changes very cheaply. The bottleneck therefore moves upstream: towards problem definition, context, constraints, decisions, and validation. If the direction is wrong, all that extra speed just gets you to the wrong place ten times faster.

It's a fact that you're going to have to address uncertainty surrounding a project at one point. Why not do it when change is still cheap? It's much cheaper to change a blueprint than it is to rebuild whole parts of a building. This article's goal is to provide you with the tools to reduce uncertainty as much as needed before implementation.

This article introduces a practical framework that does exactly that in 6 steps. Each step produces one short document that makes the decisions explicit, durable, and usable by both humans and agents. It's a shared record of what's understood, decided, and agreed. With the framework you build:

• The right thing: a solution that actually solves a real problem.
• The right way: without wasting money, time, or resources.
• As efficiently as possible: with enough clarity during development to prevent backtracking, waiting, or guesswork.

The outcome is alignment. Both humans and AI agents work from the same playbook: a clear, shared understanding of the problem and intended solution. This prevents guesswork, rework, and surprises.

Why This Matters

The hardest problems in software development are rarely purely technical. They're about communication and alignment: key components in turning a vague problem into the right solution. Even the best engineers can't salvage a project if stakeholders can't agree on what they're building, why, or for whom. Misalignment slows teams down and burns out good engineers because they lack the structure and direction needed to do their job.

Involving agents makes these risks even bigger. A single engineer heading in the wrong direction for a day can do limited damage. That same engineer deploying an entire fleet of agents can do a lot more damage, faster: one wrong assumption doesn't stay in one file anymore, it gets copied into every agent-generated change that touches the same pattern before a human ever reviews it.

Yet many teams treat requirements as a one-and-done event and then sprint into development, assuming the rest will sort itself out. You wouldn't build a house without blueprints. Why would you build a software project without proper preparation? Yes, this takes investment up front. But "we don't have time for that" often turns out to be a very expensive sentence once you count the cost of compliance violations, reputational damage, competitive advantage, and rework at scale.

The Cost of Being Wrong

Spend effort where it's needed. Not every decision deserves the same amount of analysis. This is one of the principles behind the framework:

• The more expensive a decision is to reverse, the more uncertainty you should eliminate before making it.
• Choosing the label on a button is highly reversible. Decide quickly, adjust it later if needed.
• Choosing a data contract, system boundary, or integration architecture may not be, and getting it wrong is expensive to undo. That's where the scrutiny belongs.

This doesn't mean predicting everything up front. It means spending your preparation effort where a wrong decision would actually cost you, and deliberately leaving the rest flexible.

When to Use This Framework

Not every software change needs six documents. A bug fix, a small internal script, or a disposable prototype usually doesn't justify this level of preparation. Applying the full framework to every change would create bureaucracy rather than clarity.

The framework becomes valuable when the cost of getting the direction wrong is significant. Use it when several of these are true:

1. Multiple stakeholders or teams need to coordinate.
2. The problem or desired outcome is ambiguous.
3. The solution depends on existing systems, data, or organizational constraints.
4. Important architectural or data decisions will be expensive to reverse.
5. Several people or AI agents will work in parallel.
6. A mistake could create significant financial, operational, compliance, or reputational damage.
7. The project is large enough that rework would materially affect its outcome.

You also don't have to use every step with the same level of detail. For a relatively small project, the framework may be a few pages of decisions. For a large, complex project, each step may require substantial discovery and discussion. The point is not to complete six documents, but rather to reduce the uncertainty that matters before you start implementing.

Use the framework when coordination and the cost of being wrong justify it. And the framework is not a substitute for experimentation. When an assumption is uncertain, a prototype, spike, or other experiment may be the fastest way to reduce that uncertainty. The result should then feed back into the relevant step rather than silently changing the direction of the project.

The Framework

The Project Preparation Framework systematically reduces uncertainty by working through one decision domain at a time. Each step builds on the last, bringing the most consequential questions forward while the cost of change is still low. Interpretations, assumptions, decisions, and reasoning are documented in a shared file that the relevant stakeholders can review.

The framework is sequential, but it is not a waterfall. Later discovery can invalidate an earlier decision. When that happens, go back, update the affected artifact, and make the changed decision explicit. The goal is not to prevent change, but to prevent unacknowledged change.

The first four steps establish what we know and what we intend to build. These steps already involve decisions and decision ownership. Step 5, therefore, does not introduce governance. It turns the decision structure that's needed for the build, launch, and operation of the solution into an explicit agreement.

People should be able to challenge a decision, but disagreement should lead to a decision owner making a call, not to the decision sitting unanswered in someone's inbox.

The Framework, Step by Step

In this chapter we go through the framework, step by step. Each details the goal of the step, a "war story"/example, lessons learned from that war story, and instructions on how to create the document. The Project Preparation Framework Repository on GitHub contains one-pagers about each step in the framework and some "war stories." The intention is to make this a community project, so contributions of inspiring stories, improvements, or additions are welcome.

1. Business Prerequisites

Laying the foundation for solving the right problem. This step addresses one of the most expensive project failures: solving the wrong problem. It makes sure you focus on the real business problem, one that stakeholders actually want solved, with a clear scope. It secures buy-in and alignment early and prevents wasted efforts on something nobody needed. Engineers can read the resulting document to understand the "why" behind their work, which makes day-to-day decisions easier and development clearer, with less ambiguity and fewer risks.

The webhook. A customer once told us they urgently needed a webhook. We dropped everything and started building. When we finished, it turned out the customer didn't really know what a webhook was and that they actually needed an API. We delivered a flawless technical solution to a problem that didn't exist.

Lessons learned. The customer owns the problem, you own the solution. If you let the customer define the solution you're not doing your job. A short interview on the business goals would have caught this immediately.

How to: Create PID.md (Product Initiation Document), defining the business problem, goals, users, and success metrics. Read the guide - Use the template.

2. IT Prerequisites

Can we solve this within the existing environment? Almost every solution has to be integrated with existing systems and processes. How well it succeeds depends heavily on what the existing landscape can actually support. This step assesses the feasibility of solving the problem within the existing environment by understanding the data, systems, and dependencies. We make sure every stakeholder is aware of what's possible and what isn't before development starts.

The real-time dashboard. We spent several sprints building a system to process real-time data for a dashboard. It turns out that the data source couldn't provide real-time data at all, only a batch every 12 hours. The product worked perfectly, it just couldn't be plugged into the company's existing ecosystem.

Lessons learned. This is exactly the kind of thing you want to fail on early. Ideally, we'd have discovered we were "building a train for an organization with no railroads."

How to: Create discovery-report.md to surface technical surprises proactively, before they derail the project. Read the guide - Use the template.

3. Functional Requirements

What must the solution accomplish? Here we define what a solution must actually be capable of doing. We aim to understand users, expected behaviour, frequency, and scope before optimizing implementation. User stories help greatly with this. Clarity here also makes the next step much easier, since well-understood capabilities and goals are far simpler to translate into technical decisions. This is the step I've seen skipped very often. Passionate engineers get carried away by what's technically possible and lose sight of what the customer actually asked for.

Essential automation. We once spent several sprints fully automating a process that everyone was convinced was essential. In the end, we spent 100+ hours automating something that took 10 minutes to do manually, once a month. Additionally, a beautiful UI was created. The first question was whether an API was available instead. They were developers themselves and never meant to use the UI.

Lessons learned. Skip functional requirements and you risk delivering a Ferrari (with a Ferrari price tag) when the customer needed a bicycle. Before opening an IDE, make sure to understand who the user is, how they want to use the solution, and how often. The conversation that would have caught this takes minutes while the rebuild took weeks.

How to: Create functional-requirements.md and summarize all requirements there. Also add a list of user stories that determine who, how, and how often certain users aim to use the solution. Read the guide - Use the template.

4. Technical Requirements

How can we make the solution real? With the documents from the previous steps in hand, most of the fog has already lifted and the direction for your technical choices should be fairly clear. Still it's essential to turn that into a concrete plan and make deliberate technical choices, tying every previous step together: "Our business goal is to X, our existing systems do Y, our functional requirements say Z, so here's what we need to build". Architecture happens before the build, not during. Skip this and you get open-heart surgery on a half-finished product, changing direction mid-build or patching gaps that you should have spotted months earlier, at midnight, to make the deadline.

Database open-heart surgery. We chose PostgreSQL because it was our team's default. Only later did we discover that the domain model was fundamentally different between customers and changed frequently. We had already encoded these assumptions deeply into our schema and application. The eventual migration wasn't difficult because PostgreSQL was a bad database. It was difficult because we had made an expensive architectural decision before understanding the domain.

Lesson learned: The right tool for the job isn't the one you know best but rather the one that fits the problem. A few conversations about the data model and how it was expected to evolve would have saved weeks of rework and a database migration.

How to: This step is all about choosing the best technological fit for your solution, within the constraints of the organization. Summarize your findings and the reason