From ad hoc AI use to spec-driven delivery

The challenge: adoption without a shared method

We began using AI with developers, then gradually expanded to the wider team. Early use was inconsistent. Developers sometimes found that the tools did not produce the output they needed. We worked through those examples together, improving the context supplied to the tools and how people reviewed the results.

As Head of Solutions Engineering at PMC, I lead 30+ engineers across development, QA, and automation. My role in this change was to define the direction, mentor people through adoption, and set expectations for delivery evidence and measurement.

The approach: a spec-driven development playbook

Once the team was familiar with the tools, we introduced spec-driven development for each story. The product owner prepares a master initiative in Confluence. Business analysts develop sub-initiatives and stories in Jira. AI helps produce these artifacts; people verify them before the work moves forward.

Subject-matter experts and architects use AI to support architecture documentation and high- and low-level designs. Grooming and story-point estimation remain team discussions without AI. When the sprint starts, the team invests time in AI-assisted design and implementation plans, breaking the work into tasks before coding.

Developers carry out implementation with AI assistance. In parallel, QA uses AI to prepare test cases, automation designs, implementation plans, and tasks. This gives quality work a place in the delivery process from the start.

The controls: human judgment at every decision

AI performs an initial pull-request review, followed by human review. Developers verify their code and test the happy path before handing work to QA. QA runs manual and automated tests, with AI supporting defect detection and logging. People retain responsibility for review, approval, and release decisions.

We record the delivery artifacts and decision evidence in Jira. I ask the team to examine review effort, AI coding time, defects and their root causes, defect density, and the delivery indicators we already use. Tool usage alone does not tell us whether delivery is improving.

What changed

The team moved from ad hoc tool use to a more consistent process. We began seeing fewer requirement gaps, more unit and automated tests, and greater confidence in releases with less reliance on manual testing.

The leadership lesson was that AI adoption needs coaching and a working method. Giving people access to a tool was only the beginning. Helping them supply context, challenge its output, and own the result made the adoption useful.