How to write software requirements with AI: record the call

To write software requirements with AI, do not start from a blank page. Start from the recorded conversation where your client and your team agreed what is needed. Use AI to turn the transcript into a draft specification and a working demo.

An engineer reviews both before the client sees the demo at the next meeting. The transcript stays the record that both sides can check. When the specification disagrees with the decisions in the transcript, you fix the specification.

Why the transcript is now the asset

By the end of a good client call, many of the requirements are already decided. They are in what the client asked for, what they refused and what both sides agreed.

A requirements document written afterwards keeps the decisions. A lot of the time, it loses the reasons, the rejected options and who agreed to what.

That gap shows up weeks later. An engineer asks why a rule exists, and the document has no answer. So someone asks the client again.

At the same time, code is getting cheaper to write. Andrej Karpathy wrote in January 2023 that “the hottest new programming language is English”. In a June 2025 talk he described the split: the models generate, and people verify.

So the bottleneck moves to the work that still needs people. That means deciding what to build, and checking that it works as intended. The decisions, the client’s expectations and the story being built are still hard work.

Those decisions are mostly made in conversations. The code used to be the record of those decisions, and now the transcript is. That is why I treat it as the golden source. Everything else gets checked against it.

How to write software requirements with AI, step by step

The loop has five steps, and it runs again after every client conversation.

1. Record the conversation. Tell everyone at the start that the call is recorded, and why. If anyone says no, take notes and send the decisions back in writing. Limit the call to the client, your product decision-maker and the engineer who will build it.
2. Keep the transcript with the project. Store it in one place that only the project team and the client can open, and link it from the task list. Nobody has to read it all. It is there to settle questions later.
3. Pull out the decisions. Ask AI for a list of what was decided and what is still open. A person checks that list against the transcript. Every decision and every open question gets an owner and a date.
4. Draft the specification and build a demo. AI turns the checked decisions into a draft specification. The engineer uses AI to build a working demo from it before the next conversation. The demo only has to show the decisions. Before the client sees either, the engineer checks both against the transcript.
5. Open the next conversation with the demo. The client reacts to working software they can click through. That conversation is recorded too, and the loop starts again.

For a business of 10 to 50 people, none of this needs a new department. It needs a recording tool, one place for transcripts and an engineer on the client calls. The client then sees their decisions in working software while the reasons are still fresh.

Is the specification the new source code?

Others argue that the source of truth is moving from the code to the specification. In June 2025, OpenAI’s Sean Grove put code at “10 to 20% of the value” a developer brings. The rest, he said, is structured communication.

Grove argues that the written specification is the new source code. GitHub’s Spec Kit, released in September 2025, has a similar aim. It sets out to move teams from “code is the source of truth” to “intent is the source of truth”.

The written specification still matters. I go one step further back. The specification is drawn from a conversation, and whatever the drafting missed is still in the transcript.

So keep the conversation, and check the specification and the demo against it. The transcript is the source, and the spec is a working copy drawn from it.

Your team still estimates from the spec. A written scope is also what lets you check a software development quote before you sign it.

An engineer checks every draft against what was said

AI writes a draft quickly, and the draft reads well. It can still drop a condition the client set, or add one nobody asked for. So an engineer checks every specification and every demo against the transcript.

In a small business, that can be the senior person who holds the engineering judgement. That person also owns the quality of what gets built.

The check matters more as output gets faster. In 2025, Faros AI, which sells engineering analytics, found that AI users merged 98% more pull requests while review time rose 91%.

The engineer who does the check should be in the conversation too. It is far easier to check a draft when you were there to hear the client. I explain why the engineer belongs inside the product team in what to expect from an AI-augmented development team.

Decisions should reach the build without a hand-off

On one engagement, I joined a founder’s sales calls and also wrote code alongside her. The feedback from those calls was distilled into a roadmap. A sellable MVP shipped inside six months.

What buyers said went straight into the build, because nobody had to hand it over first. The loop in this post keeps that link and adds a record both sides can check.

At PIMASI, the same senior person sits in the client conversation and owns the build. Fewer hand-offs mean fewer questions asked twice. A PIMASI engagement is built so your team spends 50% less time planning and re-asking questions that were already answered.

Waiting keeps your team building from memory

Every week the old way continues, your team builds from notes and memory. Questions get asked twice, and your client reads documents instead of using a demo.

Faster coding on its own does not fix that. A successful company in the age of AI changes its whole delivery cycle, not one stage.

If you want to talk through how your team works today, book the exploratory call. The decision in front of you is how your team should turn customer conversations into software, and who checks the result.