Skip to content
Building the software factory from the spec up | LinearB's Ariel Illouz & Ofer Affias artwork

Building the software factory from the spec up | LinearB's Ariel Illouz & Ofer Affias

Dev Interrupted

October 13, 2026

LinearB's software factory spends more time on the spec than on the code.

Speakers Andrew, Ariel Illouz, Ofer Affias

TopicsTechnology

Andrew (0:03)

Welcome back to Dev Interrupted, brought to you by LinearB. This one's a double feature with two of our own, LinearB's VP of Engineering, Ariel Illouz, and Director of Product, Ofer Affias. Over the last year, Ariel moved his teams of engineers from vibe coding to spec-driven development, starting with just one skill and one rule. By sticking to simplicity, the team found a harmonious loop.

Ofer calls their role in LinearB's engineering org a double challenge because LinearB is going through these agentic transformations just as much as their end users. So how does LinearB use its own platform to build a software factory? You're about to find out in my conversation with Ariel and Ofer.

My guests today on Dev Interrupted are really special because they're in the zeitgeist of building the software that everyone else is using to understand the software that they're building. Today, we're doing a double feature. I have Ariel Illouz, the VP of Engineering at LinearB, and he's run engineering here since 2019 And over the last year, his team of about 30 engineers have moved from ad hoc vibe coding sessions like everyone else's to a more deliberate spec driven way of building with AI. And with him is Ofer Affias, our Senior Director of Product, and he leads all things AI Innovation on the team here at LinearB. And both of them are constantly obsessed with addressing the question that you too are obsessed with, which is once you adopt AI, how do we know how it's impacting our employees, our products, our downstream impact? Is it for the better? And how can we make things better over time? Ariel and Ofer, we're really excited to have you here today, welcome to Dev Interrupted.

Ariel Illouz (1:59)

Thank you for having us.

Ofer Affias (2:00)

Thank you very much. Excited to be here.

Andrew (2:02)

Of course.

Yeah, we're super stoked to have you all. Ofer, I know you've been in many conversations on the show with Ariel. We're really excited to have you here for the first time and feature some of your thoughts around spec-driven development. And I kind of want to start there because many teams right now are experimenting with a form of what we are calling in the industry, a spec-driven development. That is starting with the idea and spending a lot of time as a team writing it down in a shared space until you have a really strong mutual understanding of it. And then executing that into code. It really reflects the new way that we make software now. So Ariel, how did your team start doing spec-driven development?

Ariel Illouz (2:42)

As AI went viral, right? And we started to hear the term again, spec-driven development, because this is a super old methodology that we used 15 years ago.

And then we said, yeah, there is something here. We need to see how we pushing that forward. So we did our homework first. Our CEO and Founder, Ory Keren, put us in touch with another startup that had already rolled this out across their whole company. So we sat down with them, asked a lot of questions, interviewed their architect and senior developers, and took away a few good lessons before we started doing anything. Then we started, we decided we have like an AI guild, that we are gathering together every second week, and we did the simple thing we wanted to do. Just one skill that start with writing the spec for the engineer. So that was it. This is the only one skill that we begin with.

We didn't want to go with the big changes. We wanted the small and safe steps. This is how we started. And yeah, now the team is using this skill, which creating the spec doc itself. It's like an interactive thing. It's like getting a JIRA ticket, and then starting like some conversation with the engineer regarding the ticket, gathering some information, and then eventually it's creating the spec document.

Andrew (4:37)

Okay. So what I'm hearing is a really compact three-part playbook. So first off, you met with the team that had pre-established a practice, and you extracted the learnings, the failures. You fast forwarded through a period of time of experimenting. You had another thing too, which is a guild, like some kind of employee group. That's super critical. We talk about that here all the time with leaders on the show, but having a regular shared place and ecosystem, just a sharing space for folks to collaborate is essential for getting any kind of momentum with something like this. And then lastly, not falling into the temptation of making like a Swiss army knife of tools and skills and all of the stuff that we do.

32 more minutes of transcript below

Thousands of transcripts fetched by people building searchable podcast archives

Fetch the whole transcript

The demo key returns a sample episode in full, no card needed:

request
curl -H "x-api-key: pt_demo" \
  https://spoken.md/transcripts/1000651996090

Markdown with the speakers named, for your notes, your knowledge base, or anything that makes HTTP calls.

From $0.10 per transcript. No subscription. Credits never expire. Prices exclude VAT, added at checkout for EU customers. Not what you expected? Email us within 14 days with 20 or fewer credits used and we refund the pack in full.

Using your own key:

request
curl -H "x-api-key: YOUR_KEY" \
  https://spoken.md/transcripts/1000796112534