Scaling the AI Software Factory from Activity to Impact

Yuval Yeret: As AI agents take on more of software development, our job as engineers shifts towards designing the system they work in. That means rethinking what teams own, how work flows, and how we learn from what customers actually use. Today I'm sharing a LinkedIn Live session on building an AI-ready software organization. We move from vibe coding and spec-driven development to empower teams that own outcomes, a product lifecycle that connects discovery to customer impact, and humans and agents improving the way they work together. I'm Yuval Yeret and this is Scaling AI from Activity to Impact. Follow me on LinkedIn to join live next time and bring your questions. Here's the session. I hope you enjoyed. The first question that I explore with software leaders that come to me for a conversation and for help is: where is your software organization when it comes to AI? Are you seeing activity Is it turning into output in terms of, for example, faster coding, more software? Is it a more effective factory? Are you seeing the impact on organizational performance, customer value? One of the models that I I really like to use for this is to look at the evidence. evidence-based management talks about a couple of key areas of w w what does our organization's capabilities to create value look like. It starts from things like what is our ability to innovate? Do we have capacity to create what matters next? How much of our capacity can be dedicated to innovation versus just to maintain and keep the the machine running? What is our ability to get to the market faster, both for delivering value as well as to sense, to sense and respond, to inspect and adapt. Are we delivering something that's useful? those two internal capabilities can be used or can be can be used to improve the value that we're creating for our Current customers? Are we creating products and features that our customers like? Are we improving the outcomes for them? Is it a sustainable stakeholder experience for our customers, for our employees? And are we able to tap into what we call unrealized value, unmet needs, new opportunities, new types of customers, new jobs to be done? Can we use our ability to innovate and our fast time to market to quickly converge and explore? Unrealized value. Those are four areas, and what you can start doing is think about okay, AI is not part of any of these value areas because they're generic to any organization that is trying to innovate, especially in using software. But AI could help us improve our ability to innovate, could get us faster to market, could be used to create more value, whether it is because AI is helping us with our ability to innovate and time. To market, or because we use AI as part of the current product. AI could create new business models, new ways to deliver value that we were never able to deliver before, and that's unrealized value. AI, when it has an impact, will move the needle on at least some of these categories. So that's so that's a useful framing. That you can think about as you as we go through through this session. So to to rewind a bit, last summer it was the summer of vibe coding. Vive coding changed what was possible. You can just Give a prompt to lovable base 44 cursor whatever, and it created a product for you. And product in quotes, right? It's not really a full product, but can you can explore many more ideas faster. but Vicoing a lot of the time feels like playing the slot machine on the Universal Studio Store. On one hand, it's very random, it's not deterministic, it doesn't have discipline, it can be very frustrating. In my experience, it was very frustrating how often it gets into corners and you can't get can't get out of these corners. How often it's not clear what what it did, what it created for you. It's like playing on you only Live ones mode all the time. And in parallel, when it does work, a lot of time it feels like it's a very cool facade, but it's empty behind the scene. That's why I'm thinking of the Universal Studios tour. And The once organizations realize okay we we can't really use vibe coding to develop our brownfield, our existing legacy systems, it's not really moving the needle on our ability to innovate and create sustainable value. It's a very fast time to market, but it's not really changing our organization. It can help us create more ideas and explore them, but it's it's it's not. Production ready. And that's where the rise of spec-driven development came in. Spec-driven development brings determinism and discipline to the undeterministic world of agentic software development. And essentially, what it is, is an agentic loop of definition of workflow that takes a specific idea. turns it into a spec specification and uses that specification as well as a specification of how we work, what our work looks like, what are our criteria, what's our we even call it constitution in some of these frameworks for how do we get things done here. So even when an agent is running through this, they follow the processes that we have for doing good work in our organization or on our team. There are multiple frameworks that implement this, whether it's SpecKit, Amazon's Kiro, Every's compound engineering. all of them are used to turn requirements or intent into code. For me, the the important thing about spec driven development, it's not that it's driven by the specification of the feature that we want to implement, but it's also that it specifies how do we do work here. It's essentially documenting the operating model, the operating system for our software factory as code. As markdown, but it's still code. It's what are the stages, what are the gates, what are the rules, policies, constraints. Those are defined. Both agents and humans follow them. It's like the definition of done, definition of ready, definition of workflow that we used in frameworks such as Scrum and Kanban. They define how we work, we can change them, but any change is deliberate. We talk about the fact that we want to add additional testing somewhere. If we want to relax a certain policy in order to enable more exploration, it's a conversation around what do we believe will happen if we do that. And we experiment with that. Our operating system is version controlled. And that's one of the beautiful things about Spectre Now it's really version controlled. The definition of how do we do work here is now something that is much more explicit than it used before. The fact that we're giving autonomy to agents to participate in our software factories actually forces a lot of teams to make explicit things that were very implicit before. So one of the things to reflect on is where are you and your organization on this journey? And I'll be curious to hear in the comments: is your organization still in the age of just thinking about this, vibe coding, implementing or exploring agentic engineering? Spec-driven development? Do you have your own harness? Are you using a harness off-the-shelf? Are you customizing one of the off-the-shelf harnesses? let me know in the comments where where are you on this journey? What have you learned, and maybe what are the biggest challenges that you're currently facing? So while you're thinking of that, let's look at a little bit of evidence of what's the AI impact in the in the software world. And and what I'm using here is benchmarks such as the Developer experience benchmark, the Pharos, the Linear B, all of them have access to multiple teams, their actual data as well as surveys. And they try to look every couple of months at what's going on in this space. And I took these benchmarks and looked at them from the perspective of the evidence categories that we talked about earlier. So let's start with the area where there's the most evidence. Time to market. In time to market, we're seeing much faster activities locally, so task throughput per developer, the amount of epics that the developer can drive, the amount of deployments per week. But we're also starting to see where the bottleneck is moving, where the speed trap is. The amount of time in QA has risen dramatically, and we'll get back to that because it's not the first time we've seen that. The average PR size is much bigger. The effect of that is often that it's much harder to review these big PRs. the time to first review in in recent in the most recent benchmarks is actu actually accelerating, which is a good sign. we're seeing improvements in change failure rate. but if we look at the actual results of all of this, is this driving improvements to customer value? Hmm, not so clear. A lot of stuff is going through this pipeline unreviewed. maybe that's what's helping the time to first review number because we're just rubber stamping explicitly or implicitly some of these pull requests. The number of incidents is going up in teams that are using agentic software development, and it's taking people more time to remediate, maybe because they're not that familiar with the code that's in the in the System. Ability to innovate is the one where we're a bit stumped, right? on one hand, developers don't spend as much time coding, so they should have had much more time to innovate and to spend time on new features, but the innovation radio ratio, the amount of time, percent of time that people actually work on new features. stays essentially flat in the teams that Are advanced in adopting agentic relatively advanced in adopting agentic software development. The backlog is still growing much faster. work restarts where you stop, you restart, the effects of working on a lot of work are rising. So this is a big one that we haven't been able to to tackle yet. Unrealized value, are we actually able to use agentic software development to penetrate? new markets, meet unmet needs. It's a split world. On one hand you have the AI native startups which are growing very fast are able to raise money to get to product market feed. So there's definitely the the evidence the AI is making an impact on software development in that space. But when you go to the incumbents, to existing teams that have brownfield, legacy legacy software, is AI enabling these teams to disrupt themselves and penetrate new markets and do things that they were never able to do before. We don't have evidence At least using these benchmarks. And part of it is what these benchmarks have evidence on, what they can measure. But it's also, if you look at the market anecdotally, it's hard to see organizations that are to find organizations that are established that leverage AI to really change their perception in the market, what they're doing, and tap into unrealized value. So still on the fence there. So, going back to that ability to innovate mystery, where has the time gone? Where did the saved capacity for the developer due to the fact that they're using a genetic coding go? So the reality is If you look deeper in what these developers have done before they implemented Agentic Coding, a lot of these things, Agenticoding didn't have a chance to move the needle on. A lot of their time was, anyhow, spent in meetings, coordination, alignment, waiting for dependencies on other teams, integration that's beyond what you know their agents could look like. So a lot of these things were anyhow the bottleneck for these people. And the fact that we created or or gave them a genty coating has not really moved the real bottleneck for them. Uh-on another thing that we're seeing is while we save time on less coding, a lot of the capacity needs to shift to review. So review is becoming the ball neck. And we're seeing that in more and more pull requests, features, specs, whatever you want to call it. That are accumulating in that step of your workflow. Now we're seeing that only if you manage that. One of the important things is to first of all manage the workflow, manage the provide some visibility on where these PRs are in the lifecycle. and a a lot of the organizations that are throwing away their JIRA and saying all we need is to just code these PRs and and drive them through the cycle, they don't have this visibility. They they can look at yes, this is a PR, how much time is it waiting for review? But they cannot look at the end to end and see, you know, what's the What's the relationship? What's the amount of time that work spends in this review versus the the end-to-end flow? So, what do we do about this review bottleneck? It's not the first time that we're seeing work accumulating in a constraint that wasn't what we thought it was. This is you know, accumulative flow diagram that shows where the work is in the different stages of product development from back in 2010. Okay, so 16 years ago. AI, generative AI was a glimmer in you know some advanced researcher's eye. But we still saw work that was implemented, that was coded essentially. it was in this case even code-reviewed, but it wasn't validated yet. The Balnec in this case. Was QA, which brings you back to what we've seen here. Time in QA has grown dramatically. So let's say even we solve the code review bottleneck because developers spend more time on this, or we implement agentic code review tools, or we just trust that you know AI is writing good code and can we can always find it later. The next bottleneck would be something along These lines. It would be we've implemented it, we've code reviewed it, we address the code review issues, but it's not validated yet. So what do we do when we see this sort of cumulative flow diagram? We start to manage the flow. We start to do things to address this constraint. And here is where things like Goldrath's theory of constraints can still help us in 2026. It's not anything new. we first of all identify where is the end-to-end constraint, we we exploit it. So in the case of the code review, for example, we use the existing review capacity better. What does that mean? Smaller batches, smaller PRs, much easier for people. There's much easier for people to actually read and provide good feedback on. maybe do some things pre-review. So maybe we can run some of the tests before we actually do the code review. If code review is more expensive than actually running tests, let's switch things around. Let's explore, let's try things and see can we bring things readier for the code review stage? Can we do maybe some risk-sensitive routing and say this is something that has a lot of risk? We want a full human code review for it. This is something that's so so maybe you know sporadic human review of key aspects. And this is something we trust and we have a good safety net for. We don't need humans to look at it. One of the questions. That you have to look at when you're implementing the Agentic Software Factory is where does it make sense for humans to still be in the loop? And when is it okay for humans to step onto the loop, to step outside the loop? And implement things like sample testing and focus more on the capabilities of the agents to run the loop. than to spend time reviewing the agents for each and every spec. Step three is to subordinate, is to align how we do the flow to the review capacity to understand, okay, if we're seeing so much work accumulating here, let's not start new stuff. Let's tell the developers don't start specifying new things, don't code new things. Let's tell the agents as well, don't spend your capacity creating new work. It's going to waste. Let's limit the amount of work in process and use the spare capacity that we have, whether it's tokens or human capacity, to actually strengthen either the agency code review or the downstream testing or to explore ways to change this system. But the important thing here is that limiting the amount of work in progress generates a s the signal. That frees capacity to innovate how we innovate, to innovate our processes rather than continuing through the motions. And then once we manage to optimize this. It and and see, you know what, every token that we spend or human capacity that we spend is actually optimized for running this process. We can throw more tokens or human capacity into it. Ideally, you know, it depends what what you want to do for each one of these cycles. But the the the important thing here is you don't elevate, you don't throw more tokens at the problem until the point that you know that. your tokens or human capacities actually optimized. And it actually makes sense at this place of the bottleneck. And and eventually the bottleneck will move. Eventually, you know, code review would not be the bottleneck anymore. QA would not be the bottleneck in this process anymore. Eventually get to the point that adoption of the value would be the bottleneck or observing what's valuable so that you can feed it back to the agents to to make them close loops and decide what to work next is the bottleneck. So you'll need To find go back to step one, identify what the bottleneck, the new bottleneck, and follow this process again. So this is how to work with constraints throughout the workflow. The other one that you can see from this from this process, but is is much harder to fix is dependencies. For years now, what I've been working on with organizations is the fact that the way they are structured, even though they're calling themselves product organizations with feature teams and cross-functional teams, when you look at the actual work, there are very few teams that can really run. That are really empowered to own end-to-end outcomes. Most of the work, most of the teams in the organization require handoffs and waiting with dependencies everywhere, even across divisions in the organization or portfolios, whatever you want to call it. You might have. Agro release trains, value chains, portfolios, but they still depend a lot on each other. Which creates more meetings, slower outcomes, going back to what developers and everybody spend time on, they still spend a lot of time on everything but delivering value. And you still require a lot of people that manage these coordination tax. So if you really want to see the The future of the AI-ready, not to say AI-native product operating system, you need to flip this pyramid. You need to shift from coordinating work day in and day out to creating the structure where you have empowered teams that are aligned to the right outcomes and can make their own decisions. We talk a lot about agency and agents. If you want agency, Even for humans, you need to create the right structure. That's a harder change, okay. But it's it's the work that we've been working on for years, even before AI was around. A lot of organizations have actually put that work on pause because their attention shifted to becoming AI ready, AI native, the all of the budget and attention transferred to AI with the hope that the hard work Of flipping the pyramid would become redundant once you move to AI. That's not the reality. The reality is you still need to do a lot of this work, otherwise, AI would be a local optimization. So, what does that work actually look like? As a reminder, you need to reshape the work, you need to focus on smaller bets that will involve fewer teams. You need to consider how we can reshape the teams. to localize collaboration and coordination. Can we create teams with the right knowledge, with the right skills to own the problem, the intent, the discovery, the delivery, closing the loop on evidence of are we solving it in a valuable way? some of the key dependencies are to shared shared resources, complex stuff that everybody needs in the organization. How can we make those how can we help teams consume these shared capabilities in a self-service mode? create platforms provide context, guardrails so the teams can self-service, feel confident self-service, and that the teams that own the shared capabilities feel confident that other teams play in their area. A lot of these things w we knew for years that we needed to do this if we asked you know organizations why aren't you doing this, they they never had the capacity. One of the advantages of AI is that it gives us the capacity to build this runway. AI is actually great at doing some of this work. Creating internal platforms where the users are other systems or other teams, it could be much easier for AI to close the loop on than building customer-facing features or especially validating the usefulness of customer-facing features. AI could be used to reshape the work, to give you feedback about: are we talking about outcomes? Are we creating things that can Be owned by smaller teams. AI can be used if you design the context effectively to give smaller teams more ability to work broadly in the code base in your product portfolio. AI could be used to create safety nets, a lot of automated testing that you can use, so there are less Hebrew dragons areas where people are afraid to go into. All of this raises a question, okay? If if we look at what's going on in the in the world around us, a lot of people are saying You know, because we're moving to spec driven development, because we're working in agentic software development, we don't need stories anymore. we don't need to manage these stories in Jira, we don't need weekly planning, all the whole pace of current ways of working, whether that's agile, scrum, safe, large scale, all of these approaches, even the Spotify model. Are irrelevant in the world of AI. That's what a lot of people are talking about. And a lot of it does seem like process theater that's focused on low-altitude coordination that's irrelevant. And between us, a lot of it was irrelevant even before AI because it was micromanaging, it was project management that survived. The shift to the world of product orientation and agility because organizations just slapped mechanics without fully internalizing the heart of this shift in how we work and the shift to focus on outcomes. But that doesn't mean that an AI-ready operating system or product operating model has nothing to learn from that old world. That it it doesn't need to be recreated from scratch, is at least that's that's my point of view. There's a lot of useful stuff if you take it at the right altitude, focusing on outcomes core to an agile product operating well, core to being AI ready. Your agents should focus on outcomes, not just on requirements. And we'll get back to the fact that a lot of the work that we're doing in spec driven development right now is actually focusing on requirements, not on the right altitude. The way we manage the work should be focused on the right altitude, not stories or tasks, more towards what are the features, and more towards what are the outcomes that we want to create. And we see more and more teams that are when they're advancing through this, they want to get to the point that they give a team or even an agent agency around this is the outcome that we want to see. This is the leading indicator or the KPI that we're focused on on that outcome. We're not gonna feed you features. You can come up with the features that will deliver this outcome. But the team still needs some operating system for running this loop of learning on which features are useful. And if these teams still have dependencies on other teams, they might still need to manage some of that work in between teams. The vision of the tiny team that's empowered to do everything with no dependencies on the other teams is great, but we're not there yet. It's gonna take time for organizations to fully make that shift. While they are navigating this shift, it's very useful, and and that's exactly what I'm the the conversations I'm having and the work I'm doing with organizations these days. It's useful. Two to leaves to know which of the mechanics to to discard, which of the principles to to keep. And to keep even closer than we used to, the principles of focusing on outcomes, limiting the amount of work and process managing flow, creating teams that are self-empowered, creating the right cadence, being empirical about both the value of what you're doing as well as how you're working. A lot of these things are still relevant. Self-organization amongst a set of people that own how they work, how their agents work for them. the But all of that, even if we created an effective software factory, that's only part of the journey. A software factory that is measured where its goal is to deliver software doesn't necessarily mean that the customers adopt it. Doesn't necessarily mean that we've delivered value. The real impact of AI is not in output in more software. That's useless. That's worse than useless sometimes. The value is or the impact comes from software that enables new behaviors for our customers, turning into business value for. For the organization, for us as a company that sells this software, or for based on the use of internal software. So how do we make that shift? If you look at back at spec driven development, most of these frameworks are still, as of October 2026, still focused on output. So what I've done is I've run some some research. Okay. I took, I downloaded, I cloned all of these all of the popular spec driven frameworks, whether it's SpecKit, Kiro, Open Spec, compound engineering and What I've done is I assessed it using a skill that if you're interested, I can share with you. I assessed it on a couple of different criteria. One is is it strong in its orientation around intent? What are we doing trying to do here? Not just focusing on requirements, software requirements, but why are we thinking that this would be youth. useful. What is the outcome hypothesis here? And you can see that most of the frameworks don't really look at that. When who will you know the example of Specit plus Assess Spe it's my it's my additions on Specit. So I created a pull request an improvement for specit, one of the popular specification frameworks, to to actually look at this stuff. it wasn't really merged yet, but you know specit on its own doesn't doesn't really do this. the other piece is let's say we oriented our own intent and outcomes. Are we actually following through downstream? So we've built something. Do we follow through on when we deployed it? Did it actually do make the change in behaviors, achieve the outcome that we said it will or or that we set out to achieve? And what what you can see is this is even a tougher bar for these specialation frameworks to to look at. So one of the things I invite you to do, whether it is just by thinking about it or downloading my my assessment and running it on your own. Framework. If you're using one of these out of the box, you already have the answer. But if you created your own harness or customized one of them, assess them. Are they organized, oriented towards intent and outcomes enough? Are they validating and steering towards outcomes? We want to be on the upper right here. Because that turns the output that we're creating into outcomes or impact, or at least it shows us that we haven't. And that visibility, that transparency enables us to converge. Essentially, what we want to see is the extension of what mainstream spec-driven development focuses on, which is specifying requirements all the way to opening a PR for human review, both upstream and downstream. And I call that the shift from software development lifecycle, SDLC, to an agentic product development lifecycle, PDLC, which starts with what is the outcome? What is the problem? What is the intent? Whether you use a lean product canvas, a lean canvas, septic hypothesis statement, feature, whatever it is. And I have some ideas, and what I do with organizations is for example, one thing we've done is take the lean product canvas and use it to inspire a skill that focuses on let's first establish the the users were focused on the business outcome. That we want to see for the organization, establish a solution hypothesis, and only then check, you know, how sure are we? What level conviction do we have in our hypothesis? Do we need to discover in order to deal with? should our discovery be focused on desirability, viability, feasibility? Or or or do we feel ready and we can bypass this and just go build something? We don't need to discover on everything. We need to discover when it's useful enough or valuable enough potentially, and there's high risk when it's alpha. Okay? Worthwhile risk. But the best approach is to de-risk it. And then we go through the mainstream Software development lifecycle, but then we go back to PDLC when we measure adoption. We go and look at the product metrics, whether it's awareness, activation, retention of using this new capability that we created. Is it creating value for people? That's the revenue, but internally it might be another way to look at the value. are people actually doing something to refer others for it and what can we learn? What can we learn from the work that we've done on this feature for the next features that we work on? But also what can we learn about our process here? Which is the next level. Even focusing on outcomes and closing the loop is not the whole product development lifecycle. What we want to add Is continuously improving the system that actually runs this product loop. Observing not just the specific feature, but how did we work on this feature? Humans and agents together, or agent on its own, in this case, whatever way we worked on the last thing, what can we what can we learn from that? So agents and humans reflect. And it can be an agentic reflection as well, right? And and it's important to consider how often do we want as humans to be part of that reflection, or do we trust agents eventually to run even this MetaStream on its own? I I would suggest that at least initially humans want to be at least in this meta-stream loop of improvement. But it doesn't mean they need to fully run it. Maybe it's agents create pull requests of changes that they suggest to the process and then humans review these pull requests and decide do we accept that do we merge that into the way we work or do we fine tune it what what do we do to what do we do with this change and and those pull requests are on the code that runs our system of work whether it's the skills the constitution files agents the clotum, the everything that the agents look at every time they run and hopefully humans look at every time they run this entire loop. What we want to eventually create is a situation where we are developers of the software factory itself, not the code. And that's exactly the them the story that I've heard from Shy Mendel at Next Insurance. and you know it's it I it's available as as an episode on the scaling AI from activity to impact podcast. Shy story is about how to slow down even right now and understand that as developers, as leaders, as everybody in the software factory, our goal is to build a system that can deliver more features in the future. Our goals are Or OKRs are shifted to factory development, even if it means a slower first quarter. So we shift from being in the loop. Let's say we ran a Gentic, we ran agents as part of the spec-driven development cycle. And the agent decided something that we didn't like. And we find that in the code review, or we find that in the spec review. We have two options. One option is to be in the loop and say, you know what? Let's override what you've done. Take include this requirement in the spec, or this intent in the spec, or use this pattern in the code review, or change this, or change that. That's being in the loop. Another approach, which is the approach that Shai described that they're using at Next Insurance, which isn't easy. And I can tell you from coaching individuals, individual developers and dev managers on teams that are doing this, it's it isn't easy to make that change to realize that actually what we're doing now is we're not babysitting Claude or Codex, is we're coding the way the the code or the context that Claude and Codex actually use. it it's more challenging, but it's actually more interesting. What what we want to do instead of fixing you know and guiding in the loop and saying you know take this approach to say no no no the problem here the root cause is something made Plot or codex, whatever coding agent it is or testing agent, make this decision. What we need to look at is the system that made this decision. We trust that the coding agent is doing the best that it can within the system that and the context that defines this within the definition of the software factory. The problem is not with the coding agent, the problem is with the software factory. The software factory needs to realize the limitations and the capabilities of the coding agents and be designed to guide them, to provide the right guardrails. And if there's an error, we need to stop the line and not just fix it on you know the thing that we've just seen. But go back to the definition of the production line. So, what we want to do is to be on the loop. We want to observe these things, improve the skills, improve the context, improve the system that creates the code, and then rerun and see if it's better. And do that until the software factory and its coding agents work as we expect. We want to avoid hand fixing. And move to a point where we're fixing the system. So to summarize the the journey that we've been on in in this session and that the industry is on. Each organization is in different spots of this journey. AI coding has tons of potential, especially when you shift it from vibing to spec-driven development and Adjentic Engineering. In order for this to really shift from activity to outcomes, to really shift your ability to innovate, to accelerate time to market in a sustainable way, to create value and tap into unrealized value, we need to improve the software organization that is working. that that this agentic engineering leaves inside. We need to flip the pyramid, create more empowered teams. More situations where agents and the small set of humans around them are empowered, they have agency to actually move the needle towards outcomes. We want to shift more and more of our management, our attention towards end-to-end outcomes. And we need to evolve our ways of working to support all of that change. Our ways of working should help us navigate this transition. It's not about keeping the ways we were working. It's not about throwing them away and not needing ways of working at all or coming up from f with new ways of working from scratch. As we've seen, there are a lot of ways of working and ways of thinking systemically about the work in the organization that are decades old and are still relevant, whether it's Goldrath's theory of constraints. Whether it's principles of product development flow, whether it's the thinking of how to create empowered teams that own a complex outcome and are using iterative hypothesis-driven development to converge towards value, whether it's using evidence-based management, a lot of these things are still relevant. While a lot of the manifestations of these things are totally irrelevant for this day and age. And that's the trap that a lot of organizations are falling into, based on what I'm seeing. They're associating the mechanics, the manifestations, with the first principles. And they're throwing the first principles out the door. So we've taken a look at all of these things. Some things you can do with it is take a look at how are you implementing agentic engineering? Do you have the right structure to make agentic engineering work? Are you using the right frameworks and harnesses that focus on outcomes that use self-improving, the meta-stream to continuously improve and disrupt and learn? Thank you everybody keep on scaling AI from activity to impact. I'm Yuval. Have a great day. Bye-bye.