& Continuous Learning

The Problem Was the Prompt

Have you ever handed an AI coding agent a task and watched it produce exactly what you described, and not at all what you needed?

That's the moment most people blame the AI.

I've spent the last several months building specification frameworks inside an engineering organization running AI-generated code at scale. The AI usually did what it was told. The problem was what it was told.

I'm not a requirements engineer by training. I've spent more than twenty-five years across software engineering, Lean, Agile, and Strategic Delivery, watching requirements work, and not work, from a lot of different angles.

In most of those roles, formal requirements were the thing we worked around. The document someone handed us that we'd immediately go talk to a human about. Usually, humans made them work. We'd get a requirements document, find the gaps, and talk to someone who could fill them in. Good teams supplemented the document with conversation. Fast teams often had the conversation first.

I thought I understood where requirements engineering fit and where it didn't. Then I started working with AI coding agents. In interactive mode, an agent can surface ambiguity and wait. In autonomous operation (no human in the loop, pipeline running), it fills the gap and continues. What I found was that the AI-first environment was waiting for someone to show up with that whole arc of experience. What I didn't expect was how much the translation would change the thing itself.

The Problem at Scale

Vibe coding is real, and it's genuinely impressive. You describe what you want in plain language and you get working code back. The problem surfaces over time. At the feature level, it mostly holds. At the system level, across dozens of iterations, across multiple agents running parallel tasks, the drift compounds. Each piece of code is locally correct. The system as a whole starts doing something nobody agreed to build.

The specification was missing.

Every major AI coding platform shipped some version of spec-driven development in 2025 and 2026, all arriving at the same answer from different directions. An AI agent can generate code at remarkable speed. It cannot infer what you meant when requirements are ambiguous. It fills the gap with something plausible.

Plausible at scale is dangerous.

Enter Requirements Engineering

Here's where requirements engineering enters, and why the AI world hasn't fully caught on yet.

Requirements artifacts have to do two things, and most people in software only think about one of them. They communicate intent to a human reader. And they have to be specific enough that an automated check can verify whether the requirement was actually met. Most BA work is written for the first audience only. A human reads it, fills in the gaps from context, and makes reasonable decisions. That works when humans are the primary actors. When the primary actor is an agent making countless low-visibility decisions, the gaps get filled by pattern-matching to whatever the training data suggested.

Writing requirements for agentic systems means writing them so a system can enforce them. That is a fundamental change to the craft. A different artifact entirely. And requirements practitioners are closer to that work than most people in the AI space realize. In Lean Product Development, we called this standard work for knowledge workers. You can't measure deviation from a standard that doesn't exist.

When the Spec Has a Gap

I had a moment early in this engagement that landed hard. I was reviewing a pull request generated by an AI agent against a feature spec. The code passed every automated test we'd set up. It also made a decision about an edge case that had significant implications for how downstream transactions would be handled. The agent operated exactly within the criteria we'd given it. We just hadn't given it criteria for that situation.

The stakes are highest in regulated environments, but the failure mode is the same anywhere an agent makes consequential decisions without a clearly defined boundary. In financial services, that matters. Regulated industries don't have the luxury of figuring out governance after the fact. The audit trail has to exist from the beginning. The requirement has to be traceable to the test, the test to the code, the code to the deploy. If you can't show that chain, the system isn't auditable. An untraceable system is a compliance problem before it is a technical one.

Requirements engineering solves this. It has solved it, in various forms, for decades. The vocabulary exists. So do the patterns and the community. The AI world has been working this problem from the model side for years: alignment, constitutional AI, system prompt design. A completely different path to the same wall. The two literatures haven't crossed yet. When they do, they'll find some familiar ground and some that require a new map.

The Skills Are Already There

If you're a BSA or requirements engineer watching the agentic development space from the outside, your skills matter. More than most people building in this space understand right now. The tools moved faster than the practice, but practice catches up. It always does. And when it does, the people who have spent years thinking rigorously about how to specify intent in a way that survives ambiguity will be the ones who know how to do this work.

This is the kind of problem we're working through with engineering organizations adopting agentic development at scale. The real work is building the specifications, controls, and feedback loops that make AI-generated code trustworthy.

This is the chain every agentic system needs — and almost none have.

A Few Questions Worth Sitting With

• If your current requirements artifacts were handed directly to an AI agent with no human context, what would it build?
• Where in your process do you rely on a human to fill in the gaps, and what happens when that person is an agent?
• What would it look like to write requirements that enforce themselves?

Those questions are the ones I've been working to answer. In Part 2, I write about what that new map looks like, and why a twenty-five-year-old practice from Lean Product Development turns out to have predicted the problem before AI coding agents existed.

If your organization is working through these same questions as you adopt agentic development, Source Allies can help you build the practices and guardrails to do it responsibly at scale.