When AI went viral, the industry rediscovered a methodology engineers were using some 15 years ago. Spec-driven development, the practice of starting with a written idea, refining it into a shared understanding, and only then executing into code, has become the connective tissue between human intent and machine output. Few teams are better positioned to speak to that shift than the one building the tooling everyone else uses to understand their own software.
Ariel Illouz, VP of Engineering at LinearB, has run the company’s engineering org since 2019, and over the past year his team of about 30 engineers moved from ad hoc vibe coding sessions to a deliberate, spec-first way of building with AI. Alongside him, Ofer Affias, Senior Director of Product, leads AI innovation at LinearB. Together they build the proof and the tooling that other teams use to understand the software they ship. Their account covers how the practice rolled out, how they measure its impact, and what it did to delivery speed.
Spec-driven development turns one skill into a mandate
The rollout started with homework. LinearB’s CEO and founder, Ori Keren, put the team in touch with another startup that had already rolled the practice out across its whole company. Illouz’s team interviewed that company’s architect and senior developers and took away a few good lessons before starting anything of its own.
From there, the team stuck to small, safe steps rather than big changes. An internal AI guild met every other week, and the only skill it began with was one for writing the spec. The skill is interactive. It takes a Jira ticket, starts a conversation with the engineer about the ticket, gathers information, and eventually produces the spec document.
A rule of thumb set the threshold. Any story above three story points requires a spec, with DevOps tasks and similar work excluded because they don’t really need one. Illouz says the rule was framed as a must rather than a nice-to-have, since the team was pushing a big change that engineers could not choose to opt out of. Adoption is measured, with KPIs for teams across the board, and stories above three points that skipped the skill get questions. The team also gathers feedback weekly and keeps improving the skill.
Documentation splits into two kinds of spec. Completed features get locked, with their specs accumulating in a Confluence folder where, as Illouz puts it, they are “frozen in time” once the feature is done. A separate kind of spec describes a service and stays live, continuously updated as the feature, the page or the service changes.
AI adoption measurement demands new cohort-based KPIs
Measuring the impact came next. Affias says the team first looked at the classical DORA metrics and how adoption of AI tools affects cycle time, and like others in the industry it did not see proof of an effect there. The reason, he explains, is that AI speeds up the coding but not the end-to-end delivery, which still has human touches such as review and delivery, so the gains are capped.
The signal showed up in the cohorts. Skilled early adopters, the developers who embraced AI practices the most, compensated by doing more at the same time, and merge frequency showed a spike. LinearB’s AI benchmark report, released earlier this year, points to an inflection point in December of last year, when the models became capable enough. In Affias’s words, the early adopters who use AI the most “more than double, almost triple their delivery rates.” LinearB sees the same pattern internally.
The lesson was that the practices changed and so did the measurement. Treating adoption as one uniform number, as the team had before, was easier, but now it defines cohorts and measures the right KPI for each. That gave LinearB the proof, Affias says, and it supported the transition engineering made.
The pace of change shapes the product too. Affias expects a few more measurements to come, and LinearB set itself the goal of defining a new metric and connecting it to user value in less than a week, across the whole product loop. Illouz says the custom metrics builder, which lets customers build any consolidated, composite or aggregated metric, is already letting the team push new metrics on a weekly basis.
The software factory metaphor reframes engineering as manufacturing
The analogy that frames LinearB’s view of the industry is the software factory. Some people find it intimidating, but Affias, who comes from a background working with actual factories and manufacturing, calls it “something to be proud of” and points out that there is a lot of knowledge there.
He sees agents as the little bots working on that floor. As evidence, he points to coding by humans going away, with testing and reviews by humans likely to follow. Models have also made giant jumps over the last year, improving every three to six months. Affias describes the result as an onion of loops, in which the inner loops are being taken by agents and humans need to adapt and find their value.
LinearB wants to serve that shift in two ways. The first is helping teams optimize the factory floor, a job that was once about AI adoption and is now about the token economy. The second is keeping the business aligned with the factory, and for that the answer is context. As agents take on more loops, LinearB wants to give them the context they need to do more than get the build, the tests or the feature done. The point is to make sure the work agents ship turns into business outcomes and is worth building.
A written spec beats vibe coding on speed and context
Illouz sees little room for debate on the choice between a spec and a prompt. A prompt is short, and you never really know what you will get back. By his estimate, the back and forth of vibe coding takes two to three times as long as building a spec, and there is, in his words, “no question about it.”
Specs are also not written by hand. A skill generates them, pulling in LinearB’s internal software design and the constraints the team works with, so what comes out already knows how the team builds things.
The skill also changes how stories are prepared. Affias says a good design review used to mean summoning a committee for each feature, which was the standard to meet but very hard to reach and not scalable. Now the skill interrogates the developer, who can start thinking and bring questions to product if needed, asynchronously, and almost every story gets that attention. Because most people need collaboration and discussion to think through a problem, he says, AI works well as the counterpart. Every quarter, engineering used to tell product that a big share of stories were not baked or prepared enough. Now he barely hears that feedback, which he calls a very big change.
The proof of concept was the custom metrics builder, the first big story the team built this way. Illouz says it was a six-month project in a world without AI, and with spec-driven development the team did it in less than a month. He breaks the time down as about four weeks, with at least two spent on design and spec docs, around 20 of them for different parts of the system, including a new database, ETLs, and a new pipeline. Once the specs were ready, the team hit enter on Claude and it started generating everything. The remaining work was verifying the components and integrations, and Illouz says it went really smooth.
The pace carries over to the product organization, which moved from big quarterly deliveries to weekly and biweekly ones that the team calls beats. Affias says one recent feature went from ideation to delivery in less than 24 hours.
Adapting is not optional
Affias’s takeaway from that pace is that the industry is on an exponential curve and teams have to adapt, because a competitor that is adapting will widen the gap at an exponential speed. Adapting, he says, is not a nice-to-have. It is what a team needs to survive.
Illouz’s team has already made its choice. The industry rediscovered spec-driven development when AI went viral, and the custom metrics builder showed the team that it is “the right direction.” With a machine producing all this code, he says, it is how you work with AI.
To hear more from Ariel Illouz and Ofer Affias on spec-driven development, measuring AI adoption, and the software factory, listen to the full episode on the Dev Interrupted podcast.
