A software vendor: a method for the AI the team already had

Most companies meet AI tools long before they meet a method for using them. The developers here were ahead of that curve. A code assistant on the machines. A chat assistant in the browser. A few frontier models people had found for themselves. Twenty engineers, each with ten years or more behind them, were already getting value out of them.

What was missing was the shared part. Individual practice does not aggregate on its own. In a regulated market it also has to be written down: what was specified, how it was verified, who signed.

The company saw that early, which is the part worth noting. Leadership had already done the arithmetic. Features were being written faster than they could be verified. On that path the testing organization would have to double, possibly triple. Most companies meet that number late, as a hiring request. This one met it as a question about method, with time to answer it.

A method, not a tool comparison

A feature is described in a specification that people and assistants both read. The tests come from that specification. The state of the work sits in an audit trail, not in one developer’s head. Specification, quality gate, observable state.

The company had a head start here too. It had been writing functional specifications for years, and they were good ones. That discipline is the hard part, and it was already in place. Organized so that only the relevant part reaches the model, the same files become an instrument. They tell an assistant what a module is for, and what it must never do.

Two products, two different gains

The same method had to serve two very different codebases, and what each one needed was not the same.

The cloud-native team moved faster. A newer codebase, fewer constraints, and a method that fits the way that team already worked. The gain showed up in the pace of delivery.

The legacy product was a different problem. Speed was never its bottleneck. Technical debt was, and the test burden that came with it. So the work there went into re-architecting away from that debt, and into easing the testing load it created. That is the slower half by nature. It is also the half that decides what an established product can still become.

The testing question was decided on that side. A team that hand-writes every case cannot scale with a rising feature rate. A team that owns the acceptance criteria and the compliance sign-off can. The cases underneath are generated and reviewed rather than authored. That is a different job, so it was written down as one. What the team owns, what is machine-augmented, what stays manual, and who signs for each category of test.

What outlasted the engagement

The most valuable outcome was not any single artifact. It was momentum. The team picked the method up and kept going. Learning it, adapting it to their own products, improving it without outside help. That is the only durable version of this work. A method that needs its author present is not yet a method.

AI tools reach a development organization long before a method does. The gap between those arrivals is where the risk collects. Most companies notice it late. This one noticed it early and acted while the decision was still cheap. What a company can decide is what it will be able to say afterwards. How a feature was specified. How it was verified. Who signed. Write that down, and the tools underneath become an ordinary procurement choice.