Everyone assumes AI kills the requirements doc, but what I saw last week suggests the opposite.

When I first started Glossa, the goal was to create really good requirements to hand to a dev team, so they could configure and build. We knew agentic builds were on the horizon, but they weren’t quite there yet.

Last week, I met with two teams that each built AI "config agents.” They ingest structured requirements and output configuration. Consultants are still involved - they’re still customer-facing - but I was hearing wowza numbers like 7x faster.

For me, this is an interesting inflection point. Requirements now have two audiences: human consultants, and AI config agents. (And soon, I imagine, AI data migration agents will be more widely used too.)

It’s tempting to say the trajectory is a straight line - that requirements will just be written for agents going forward. But requirements play a dual role: they’re also the client’s way of understanding the work, and the consultant’s way of shaping it. Until clients have their own agents, we’ll still need a lot of human involvement.

What does this mean for how requirements need to be structured going forward? The two audiences need almost opposite things: agents need detail that’s contextual, clear, and well-structured, and humans need summaries that are digestible, concise, and in client language as much as possible. Perhaps humans get user stories, and agents get detailed, structured requirements? (both of which Glossa creates!)

Requirements docs obviously survive - but they will look different. In the meantime, it also opens up a new challenge: how do you make sure the human-facing summary doc and the agent-facing spec stay in sync as a project progresses?

Reply

Avatar

or to participate

Keep Reading