# Spec-Driven Development Accelerates AI Engineering

**Podcast:** Dev Interrupted
**Published:** 2026-10-13

## Transcript

Welcome back to Dev Interrupted, brought to you by Linear B.
This one's a double feature with two of our own.
Linear B's VP of Engineering, Ariel Uluz, and Director of Product, Ofer Office.
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 Linear B's engineering org a double challenge because Linear B is going through these agentic transformations just as much as their end users.
So how does Linear B use its own platform to build a software factory?
You're about to find out in my conversation with Arielle 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 Illuz, the VP of Engineering at Linear B, and he's run engineering here since 2019.
And over the last year, his team of about 30 engineers have moved from, you know, 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 Afias, our senior director of product.
And he leads all things AI innovation on the team here at Linear B.
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 host you here today.
Welcome to Dev Interrupted.
Thank you for having us.
Thank you very much.
Excited to be here.
Of course.
Yeah, we're super stoked to have you all over.
I know you've been in many conversations on the show at REL.
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?
As AI went viral, right?
And we started to hear the term like, again, spec-driven development, because this is like a super old.
methodology that we used like, I don't know, 15 years ago.
And then we said, yeah, there is something here.
We need to see how we like pushing that forward.
So we did our homework first.
Our CEO, founder, Ori Curran, put us in touch with another startup that had already rolled this out across the 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 decided we have 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 starts 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 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.
Okay.
So what I'm hearing is a really compact three-part playbook.
So first off, you met with a 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 this stuff that we do.
We have one skill.
This skill is like an interview driven skill that pulls out of your head everything that needs to be in the document.
And everyone goes around and puts more and more and refines it and refines it.
That's the only skill we need.
Because the real insight there is that if you have those three things.
You can make every other skill, every other group, every other practice that you want if you all agree, which is the point.
And so it becomes like a way of dividing up, like dividing up work so that everyone can contribute as well.
So like how did that look once adoption started and you have this practice?
Were there obvious candidates for we're going to try spec-driven development on that for different types of work?
that y'all would do on the engineering team?
Yeah, so we are not, we have like a rule of terms.
We have like something we started with.
This is, you know, this is like a continuous improving.
We are learning all the time.
And, but we had to start it with something.
So we said any story above three story points, excluding DevOps tasks and those kind, you know.
like Tasty, you don't really need spec doc for that.
We said, this is a must.
This is not like a nice to have.
We wanted to make sure that everyone understand this is like a big change we are going to push to the engineering team.
And it's not like something you can decide yourself to do or not to do.
This is, everyone is doing that above three story points.
So we start to measure that.
We also have KPIs for teams that measure that across the board.
And now is everyone using the skill.
We are getting on a weekly basis feedback.
We are improving that, improving the skill and, you know, pushing like improvement continuously.
Nice.
And so I kind of want to open the floor to Ofer here as well to chime in about the experience of.
Being like a product leader and thinking about the engineering team and the product team starting to converge, right, on this shared space of collaboration, the spec.
And I'm wondering what has been the experience like as a product leader, collaborating with engineering leaders, creating these kinds of specs.
How has that helped your own process?
How has it enriched the product?
And like, what have you learned that maybe others could learn from as well?
I want to understand the aspect of...
of the measurement and how you like proves how it, how it looks from, from our, our side.
And I think that when we, when we first started, we looked at the obvious, the classical measurements of, of the classical DORA and how it affects the cycle time.
And we, we wanted like to see how much adoption of this.
tools affect these KPIs.
And we weren't alone.
By the way, we are looking at the industry, we saw this practice.
And actually, we didn't see any proof.
And when we thought about it, we understood that these processes make the delivery, the coding faster.
They don't affect the end-to-end delivery, which still has human touches, like the review, like the delivery.
So it's capped.
And if you look at it, the highly skilled developers, the early adopters that adopt the A practices, the more, they compensated on that with more delivery, doing more at the same time.
And when we looked into these KPIs, the merge frequency, we saw that there is a spike.
And one interesting thing that when we, I think we released, Linear B released earlier this year's AI benchmark report, we show it in the industry.
You see that at a certain inflection point when the models became capable enough.
December last year, you see a spike of like the cohorts of if you take the early adopters, those that use AI the most, they are more than double, almost triple their delivery rates.
And we see it also here.
So I think this was like a learning point.
We understood that not only that software, like the practices changed.
also how you measure it and how you, the need to differentiate between the cohorts.
You can't just like treat it like as a uniform number like we did before, which was more like it was easier, but now you need to like define the cohorts and measure the right KPI.
And then we got the proof and it supported like the...
transition, I think the engineering did.
It definitely showed how the pressure points changed and how you definitely got a lot more output and frequency and capability that showed.
I remember when we did...
We had had that webinar where we walked through these AI benchmarks at Linear B.
And you could see so clearly the spike around December.
And you can see really a gap start to divide between heavy AI practitioners and those that are still dabbling.
And it really spoke to like the experimental opportunities that were available.
And really what I'm hearing too is like, and what's been really interesting is that, you know, we've talked so much about those benchmarks because we aggregate them on an industry.
It's been really fascinating to see how that's actually impacting the way people ship software.
But it's also interesting to me to hear pulling back the curtain and being the team behind that and making that possible and making and thinking about applying those same kinds of AI practices internally.
There's a lot of insight.
that you can pull out of this data and learn from.
And one of them being like the bottleneck of reviews.
And we're going to be talking more about that later as well.
But you called out a really important thing, which is you just get a lot more merge frequency.
People are just generating more text and more code, more sometimes than they can keep in their own head.
So you get a challenge of engineers.
having to trying to remember and understand everything they're writing and shipping.
And then I think this then comes back to the power of the spec, because up until now, you know, code has always been like what we look to to know if something is working, to know the final result.
Code was crafted by a human.
And when you wanted to know how something worked, you went back to the source control.
Now, if you want to know how something works.
The code is just as much of an artifact as the deployment, as the evals, as everything else.
You have to go back to the engineer or you have to, in this case, go back to the spec.
So I'm curious in y'all's practices of developing these specs, like what has that looked like?
in terms of accumulating that information and keeping it like really effective since it's effectively now as important as source control.
Do you have any strategies that help you differentiate it from like a prompt, for example, like how you think about collecting text over time?
So, yeah.
So first of all, you know, there is no question here.
Prompt is short.
You never really know what you're going to get back, right?
All the vibe coding.
If you think about it, all the time we spend on the back and forth with Vibe coding, it's like, I think like maybe two times, three times the time that we will spend less if we build a spec.
So there's no question about it.
A spec-driven development, this is how you go with AI when you have like this machine that produce all this code.
So this is what we think about spec.
This is the full picture.
And we do not write it by hand.
We have scale for that.
And it pulls in our internal software design and all the constraints we work with.
So what comes out already knows how we build things.
At the end, I think the time spent on back and forth, as I said, is much, much longer than creating a full detailed aspect.
So we have a folder in Confluence, which we are...
accumulating all those spec documents which are frozen in time after you complete the feature, right?
And this is one spec methodology that we are ongoing.
And we have another spec which is something that, you know, describe a service.
This is like a live spec that continuously changes and updates while we go and update the feature, update the page, update the service, whatever.
So we have two kinds of spec docs.
Oh, yeah, that's interesting.
It's like not all specs are equal.
And also the idea that like once a spec is shipped or the feature is shipped and it's out there, you lock in the spec.
There's no more edits.
You don't mutate it anymore.
Yes.
Because you treat them with the same level of deference as you would like source control when you would have something shipped and live and up.
You're not going to make a change to it without going through another process.
And in this case, sounds like it's another spec.
This would actually be a new spec that y'all would then go and work on.
Ofer, I'm curious, like, what your thoughts are, what makes for a good spec for yourself when you think about creating these kinds of new tools now in the kind of methodology that Ariel's describing?
Yeah, so I think, first of all, it's the process of the spec.
It made the ability to discuss the feature something one can do by himself.
which is very interesting because before that, if you wanted to do a good design review, you had to summon this committee of per feature.
And this was the holy grail.
But it was very hard to meet with this standard.
And it wasn't scalable, let's say.
And now with the skill, the skill actually interrogates.
the developer and the developer can start thinking and bring these questions to the product if needed.
And all this thought process is happening in an async way.
Moreover, it happens for almost every story.
Like Ariel said, the three points rule.
So if you look beforehand...
The level of focus that we needed as a product to put on stories, it's something we couldn't do.
Now, almost every story gets that attention.
And this is with, you know, with the AI, a relentlessness that makes it like something affordable.
It's consistent.
And for me, like, I think what clearly changed, I was used like that every...
quarter, the main feedback from engineering to the product team was some amount, big amount of the stories is not baked enough, is not prepared enough.
And this led to A, B, C, D this last quarter, please do better.
And it went for years.
It was like the state of the industry.
And now we barely hear that feedback.
And this is for me like a very big change.
Yeah.
It's like it's really what specs have opened up is not only just a way to collaborate as a team, but also a way to refine your ideas because you're rightfully calling out that, you know, summiting that product committee to all weigh in with their perspectives on something is the holy grail.
That's what you want because that's how you're going to get the richest feedback.
But it is really hard to scale that inside of most engineering works.
Going back to the original playbook, if you all have a skill that interrogates, as you said, that really pulls all of the question out of you, you can just work with that skill on a daily basis and refine it and refine it.
And then when you get to this point of, you know, are these, you said, are these story points, like, are they baked enough?
Has enough thought go into them?
Are they ready enough to start moving through the queue?
That then becomes maybe a more viable question.
I do wonder if you, when you take away that friction, you pull these.
pull away those those things that were holding it back is there an issue with noise if any kind of idea can get refined and can get baked and look like it's a good idea to ship through is there is there then more necessity for like a really high level of taste and judgment of knowing yes we should build this or no we shouldn't how has like the proliferation of specs kind of like sharpened how you build I didn't see any impact on that.
Okay.
I think the business intent is already set most of the time.
So it's more about like, I think...
Every idea is a good idea once it's there.
It's about making those ideas as good as possible.
Yes.
And I think that for me, like the understanding that people are not...
thinking by themselves in a natural way.
Like most of people need collaboration, discussion to go through like a thought process.
And in that way, the AI is great at like being the counterpart.
Specifically for your question, I think that at least at the moment, this loop happens more in the engineering loop and maybe we'll discuss it later.
I think it still didn't get like to the outer loop.
at that extent.
But I think once it will get to the product loop and the business loop, so for sure there will be an effect on that, like this, I believe.
Yeah, you're right to say that it's like loops and loops, and you have to start with that smallest, tightest loop before you get the product loop and the business loop.
Curious, Ariel, from your perspective, how did you get the team on board?
Right now we've talked about this is what we're going to do.
These are the criteria.
Above this number of story points, you have to write this.
How do you then get everybody on the same page, excited about doing it, solving any friction that comes up along the way, just being realistic about how teams adopt?
What were things that maybe surprised you about that once you started?
We knew that it's going to be hard.
And, you know, first of all, I wanted to make sure that no one is writing code like manually.
If it's like a story, like if it's like, I don't know, like a few lines, whatever.
I think, you know, me personally, I'm writing code and even like one line of change, I'm going to do that with AI.
This is me.
But some, you know, some engineers prefer, I don't know, to...
keep in shape and to write their reps in, write a little bit of code every once in a while.
I made fun of my friend the other day because they use Claude to clone a Git repo, but I was like, I guess it's kind of the same.
Yeah.
So until now, when I'm, you know, when I'm seeing like commits without co-author of any AI tool, this is like, you know, it makes me, I don't know, amazed.
I think we have like, you know, one or two engineers today that is keeping pushing manual code.
But I think this is also going to disappear.
So we can say everyone, 95% is not, you know, using AI to write code.
This is one thing.
So this is verified.
And I keep saying that, you know, in our meetings to everyone.
And regarding how we verify that everyone is using the skill, and it was like something we did.
This is not something we recommend you to do.
This is something we want you to do.
And we are going to check you.
We're going to measure that.
We're going to see which stories above three story points wasn't, you didn't use that.
And we're going to ask questions.
So everyone is understanding that everything is changing.
So they should adopt.
And if they don't, it's like, it's going to be a problem.
I don't know how to say that.
So, yeah.
You said a bar, right?
You're more so setting a bar and saying that.
This is what we do with this practice.
If this practice isn't followed when we do this, we're going to scrutinize it because we're trying to understand what is holding you back from being able to make that jump.
Is it a tooling problem?
Is it a skill problem?
Is it a context problem?
Like whatever it is, you want to be right there.
You want to identify it and you want to solve it.
Because in the reality is, and as you're describing, most of the team is in this kind of.
loop now where they're they are engaging in this and it's totally flipped their craft on their head but at the end of the day they're still driving their craft because there's a great deal of control that you are still executing through specs your engineers used to write the code now they review everything your software factory creates instead on october 29th at 10 a.m pacific i'm hosting launch darkly's head of ai mark pollux and kate huston author of O'Reilly's The Engineering Leader, for a workshop on where the software factory is heading and what it asks of the engineers who design and govern it, and how engineering health signals in Linear B can distribute that review load.
The link's in the show notes.
I'll see you there.
I want to take now the conversation and bridge this into talking about applying this.
methodology.
We've talked about how we got there, how you start, what it was like to get the whole team adopted.
What are the obvious benefits and drawbacks?
You know, Ariel, you talked about the loops and we all talked about how you have a smaller loop and a bigger loop.
I think there's a really interesting conversation to be had about linear B in general, because our smaller loop, our engineering team is inside of this really interesting other loop.
that we track, you know, the general SDLC of the industry, how everyone else is using AI to impact their tooling, because that's what we build, is the proof and the tooling that they use to understand the software they ship.
It's like a meta conversation.
And what's really interesting is that the practices we get inside, honestly, we learn so much from the industry when we pair those things.
So one of them that's been really interesting to see From most tools, and to our listeners, I know this is going to be pretty familiar with them, is the apps that we use every day are just totally transforming.
You don't go to an app anymore and log in and click a bunch of buttons and dashboards and just get something printed out at you.
Instead, more often, you're going to a place and you're having a conversation or someone's showing up where you do all your work.
and having the conversation with you and it has all of the data and knowledge from where it came from.
And I think Linear B is on that journey as well.
I'm curious what it's been like to kind of like power this kind of transformation inside of Linear B and how do you think about building the tooling to kind of make that possible?
So I want to firstly give a context on the challenge that we are facing because like all the software organizations are having this a challenge of transformation of the change of the craft.
But for Linear B that our customers are these software organization, it's like a double challenge.
And we look at it and we see like the development is going like through a drastic change, obviously.
And it's already went through a change.
I just mentioned it that The measurements that you need to check are different and we are looking forward and it doesn't look that it's stabilized.
Like we understand as a product company that these changes are coming and we'll probably have a few more measurements we'll need to support in the products.
And like you said, also how you consume it.
So I think to give context, we had two high-level goals when we approached that.
One, we wanted to be able to support rabbit adoption.
So we wanted to be able to define a new metric and connect it to a user value in less than a week.
So for example, you want to measure something X and you want to turn it into value to consume it somewhere in less than a week.
The whole product loop, this is like one.
And the other thing is that we understand that there are not only one surface.
It's not like the old dashboards that you log in and monitor, like you said.
There are multiple surfaces.
It's the AI.
Might it be in the platform or maybe you're preferring one?
like your favorite cloud or codex or one of these, or an API, because we also see a surge of agentic processing of the same context.
So I think to set a context, this is the challenge we faced when we started to think what we're doing next.
Yeah, I love how you called it a double challenge.
It's a really smart way of phrasing it.
about how ultimately your customers are trying to understand this same challenge while y'all are grappling with it internally as an engineering team.
And so you're having this double sell.
You as a leader are always in this pivot between the execs and the engineers.
Now you're in like another pivot between then also the industry you're selling to and you're just like spitting around in your chair.
So it sounds like honestly like...
One of the most important things that you need, and Ofer, I love that you identified this, is a really short feedback loop.
You have a theory.
You have something you want to track.
You want to pin something into your product.
whether it's because you need to know it or because the customers need to know it or whoever in between, if you can't ship that and get that showing value in a week, then you're dead in the water because you can't move fast enough.
All of the other loops are going to tear you apart.
So I think that becomes like a really, it speaks to the challenge, I think, of shipping new things.
Ofra, you said also like API consumption is going up.
I think everyone's experiencing this across the industry.
companies are transforming into these consumption-driven services because that's how folks want to consume the information, the data, the context.
A really interesting thing, too, is that then meeting the industry was where it needs you.
Maybe you discover new metrics you want to track.
You create a new idea of how you prove success.
But now you also have to create tooling to put that.
in someone's hands.
They have to be able to ask about something that six months ago, six weeks ago, they weren't even tracking or saying.
So like, what are some of the things maybe Arielle, if you want to chime in about like capabilities that y'all have been building in the platform, thanks to your new spec driven development process, what have you been able to ship faster for folks?
So yeah, so we have the custom metrics builder.
This is like a way for the customer to build any metric, consolidated, composite, aggregated, whatever slice and dice you want to do.
And I think this is referring to what Ofer just said about that, that we will need to provide some tool in order to provide those one week, you know, metric, starting measuring something.
So this is already proving that we are continuously pushing new metrics, new measurements to the custom metrics builder, providing this great, rapid ability to create those new metrics on a weekly basis.
And we have built this feature in spec-driven development.
This was our first big story that we did as a proof of concept.
And I can tell you, this is like a six-month project in a world without AI.
Six months.
And with spec-driven development, we did it in less than one month.
So just a dramatically shortened, compressed timeline.
Dramatically shortened, yes.
Did you find that because...
the bottleneck was about getting aligned or because once you were aligned, then the code was basically free because you could create everything that you needed based on the idea.
Most of the time, if I'm breaking down these four weeks, let's say four weeks, like at least, I don't know, like two weeks, we put on design and spec docs.
All over, we had like around 20 spec docs for different parts of the system.
This is a whole new database, ETLs, a new pipeline, and like a real complex and challenging engineering project.
Yeah.
And just after we had like this, you know, spec ready, we hit enter on the cloud, you know.
auto creating.
Yeah, and it takes the spec off the shelf and it puts it on the line and it just makes all the code.
It plugs in and everything because that's where all the rest of the work was.
Yeah, and then it started generating everything and we had to, you know, verify all the components, integrations and all of that.
So it went really smooth and this was like an eye-opening for us.
That, you know, this is the right direction and this is where we go.
Right.
And Ofer, I'm curious, like, what was a lesson for you in doing the work in this way and working in Spectre of Development as a product leader?
Yeah.
So I think I'm looking on it from the end result.
Like, we shifted the product organization from, like, quarterly deliveries, big deliveries, to...
weekly, bi-weekly deliveries, we call it bits.
So it's high-paced, high-volume deliveries.
I just remember a week ago, one of the features we discussed went from ideation to delivery, actually, in less than 24 hours.
And I was amazed, because...
I think this amount of pace is something that was unimagined before.
And the takeaway is I think that we are at an exponential curve and you have to adapt.
You have to adapt because if you are not adapting, your competitor is adapting and the gap is widening in an exponential speed.
So it's either you adapt or it's like you need it to survive.
It's not like something nice to have.
It's not a nice to have.
Exactly.
It's an expectation.
I like that you called out even getting to a point of doing something in a day.
There's a very like...
Thought-provoking quote from Claire Vo on Lenny's newsletter.
She does like how I AI segments.
And she's a really great leader about thinking about this stuff.
And something she said is a huge red flag for her for any like brand new AI native company person thing is if they can't do something in a day.
The idea is that if you can get your loop down to a day, then like you're more like it makes you extremely powerful in iterating.
And so people are trying to make those loops as tight as possible.
And I think that there's a lot of ways that spec-driven development helps us get there.
But also I'm sure too, like when you're doing it as a team, it's not always going to be perfect.
You know, we described this like magical rack of specs and you pull one off and then it goes down the conveyor belt, but you still have business owners, you still have reviewers, you still have a lot of disagreement that's still going to happen once it's moving down the treadmill, you know?
I'm curious, like, are there any places that you've seen where Spectre development breaks down?
I know we've talked about criteria around, like, story points, but, like, is that a learning around where it breaks down on smaller stuff?
I'm just kind of curious.
By the way, Dev Interrupted is an official media partner of AgentCon, MCPCon North America in San Jose, happening October 22nd and 23rd.
I'll be there with more than 3,500 builders and speakers from Anthropic, OpenAI, Okta, and more.
Digging in the MCP and the agent infrastructure we all build on.
Check out the show notes to learn more.
I think that also, you know, in the DevOps world, we decided to exclude those tasks for now.
You know, most of them are small, then three story points as well.
But also the big ones.
Sometimes, I don't know, in those kind of stories that more about...
architecture, like infrastructure as code, for instance, that is not quite relevant for a spec.
There are some things that are just too big or too encompassing to be frozen into a spec just because of the nature of what they are.
That's kind of what you're hinting at.
Yeah.
And another thing I'm curious about, too, is we talked about the beginning with the skills and you have the one skill, the spec skill.
The one skill to end them all, right?
Use that to make everything else.
Has your own skill marketplace and practices evolved since then?
Do you have more skills?
Do people work together on shared skills?
What does skill process look like at the Linear B?
Yeah, so we have a marketplace.
We break it down into external, like every skill that you would like to share.
So you put in like an external folder.
I think it's a different plugin.
And we have an internal plugin, which is skills that serve the process.
For instance, the refinement skill that I just mentioned, that creating, populating the spec document.
Also, we are pushing now a second skill, the implement skill.
This is something also in motion.
And we have many other more skills.
We have the document.
which QA is using in order to get like a human readable document about a feature.
We have a test planner skill, which populates the tests plan for any feature out there.
We have the troubleshoot skill, which support is using for troubleshoot customer support tickets before they are reaching to engineering.
And this is like a super success, this skill, the troubleshoot.
It saves like 60% or 70% out of the customer support tickets that are pushing to engineering.
Stops there by identifying that this is like a settings or configuration thing and getting back with an RCA detailed in the document.
Yeah.
So it's like you have the toolbox, a curated toolbox of these tools that...
Folks turn to their, you obviously have some measured success from them.
A key part obviously is having a centralized way of sharing and controlling these skills so they stay up to date.
And so I think this is becomes like a really useful playbook for, you know, other engineering leaders that are trying to maybe have the same kind of practice internally.
We uncovered a lot of what it is and yours started with interviewing somebody who was successful.
Now anyone who's just listened to you for the last, you know, 40 minutes is.
basically pulled everything out of your head about what was successful and what you had to apply.
And it comes down to starting with a really small skill, setting a criteria for when you're going to be using this kind of practice, and then having a shared space where everyone can iterate on the specs together.
And ultimately, it's resulted in this world where y'all can have a really tight feedback loop.
You can ship the software that other teams are using to figure out how they're going to ship their AI software.
So you have to...
be a little bit ahead of everybody.
And speaking of being ahead, Ofer, I'm curious, you know, what is innovation, AI innovation at Linear B?
Where's it going next?
What do you see the industry evolving towards?
We've had some really interesting narratives here talking about how software development is going to evolve.
Spectrum and development is just one part of that story.
So what do you think about the future of, you know, innovation with AI?
So I think that we see the way we see the software industry.
It's, you know, there's the analogy of the software factory.
I think some people are like intimidated by that, but me coming from a background working with actual factories, with manufacturing, I think it's actually something to be proud of.
There is a lot of knowledge there.
But specifically, I think that...
We see it going that way because the agents are going to be the little bots working on the stuff.
And for evidence, we all see that coding by humans is something that is going away.
The trends looks like also testing by humans will go away, reviews by humans will go away, and so on and so forth.
And if we look at it with...
with this perspective, we look at models becoming better and what they are doing.
Like every three months, six months, we saw that like this giant like jumps in the last year.
We can think about it as loops.
We talked a lot about this terminology.
So if you think of it like an onion of like from the inner loops to the outer loops.
We are now dealing with this software factory.
The inner loops are being taken by the agents.
As humans, we need to adapt and to find our value.
So agents are taking the coding.
They'll take more things.
And I think as Linear B, we want to serve that from two ways.
One, to be able to help with the factory floor.
Like what's now, it was the AI adoption.
Now it's...
the token economy, we want to make sure that you can optimize your floor.
But from the other hand, we as agents will become more and more like we'll take more and more loops.
We want also to make sure that the business is aligned to the factory.
And for that, we want to serve enough context for these agents.
to be able not only get the build done or the tests or the feature, but also to make sure that there is impact by the delivery and that it makes sense.
And this is how we look at it and this is how we see the coming.
I know, is it good to say something about a few years ahead?
I think for the next year.
Maybe.
It's like it's so hard to forecast what it looks like several years ahead.
But really what you've hit the nail on here is that when we talk about the factory and we have this metaphor, we think of the factory, it's an embodiment of these loops that we're talking about.
The factory is that loop.
And what you're describing is having that context available for that loop to be able to be efficient and understand what it's building and what it's shipping, having the just-in-time.
context about your SDLC is what Linear B is building towards because that is the factory.
And the truth is, is that people have a hard time optimizing their factories without having that feedback loop.
to help the factory understand itself, improve itself, tie back to the business value.
So that's what's really exciting about the stuff that y'all are building.
And it's been really exciting, you know, Ariel and Ofer to dig inside your heads and figure out how you're building this.
So I just want to thank you both for joining us on Dev Interrupted today.
It's been a total blast.
And I'm really looking forward to having y'all back in the future, maybe.
Maybe six months, we could imagine all these factories everywhere and how we built.
And we could touch back in about this conversation and see where Spectre and development has gone next.
And to our listeners, you know, if you've been tuning in and listening and curious about the stuff we've been covering today, we've covered a lot of territory.
We talked about the AI benchmarks that we dropped earlier this year.
It was based on like...
over millions of pull requests for since just January.
And you can see a massive trend in how folks are adopting this stuff.
So you can start there and we'll include links to that in our show notes as well.
And Ariel and Ofer and the team are shipping a whole bunch of really cool, exciting stuff to help teams build and improve these software factories.
So you can check out more about that on our website, Linear B as well, which we'll include.
And if you enjoyed the episode, give us a...
a like, a comment, a review.
Come find Arielle and Ofer and I on LinkedIn and poke us, share your thoughts, disagree with us.
And we would love to hear what you think about your software factory.
And Arielle, Ofer, thank you again for coming on the show.
It was a blast to host y'all.
Thank you.
Thank you, Andrew.