# Building an AI Operating System

Felix Geelhaar, Just Product 2026, 15:15. Automatic transcript of the livestream (Parakeet ASR, unedited, expect misheard names). Timestamps are positions in the talk video.

[1:21] Oh yeah, the light is quite bright.
[1:24] First of all, I would like to really say thank you, Dave.
[1:28] This was an amazing inspiring talk.
[1:30] I'm pumped.
[1:31] So I will give Dex a try.
[1:32] Thank you so much.
[1:33] And so as it's uh afternoon and probably you the seats are very luxury and comfy.
[1:40] First of all, I would love to give a big round of applause to every talk today that we had.
[1:46] These were so inspiring and so exciting.
[1:49] So give everybody who's had already a talk, give a big round of applause to them.
[1:58] So my talk today is about building an AI operating system.
[2:03] And before I go into more of the details, the interesting aspect as Sebastian said, right, for me having an engineering background, worked in product, and being now in an operations position gives me the also quite comfy situation to observe and learn together with the partners in product, engineering, design, across the organization, GDM, and other areas.
[2:30] And this led me to always rethinking how do we how do we connect?
[2:35] What are the intersections?
[2:37] We have so many good great books and resources out there that talk about how to work together, how to communicate.
[2:44] Scrum as a framework came out to let people in different roles and different contexts work together in a maybe more efficient way, but it always depended on.
[2:54] Well, here's the third time I think, it depends on your context and how you were able to incorporate it.
[3:01] So one thing that you probably had experienced, and I definitely had it when I worked in product or as an engineering.
[3:09] I want to picture you this.
[3:11] Let's imagine Monday is the famous day to start a sprint, right?
[3:15] Right before Monday, you come into the room and think about, hey, hey team, quick one before the planning.
[3:22] I have an idea.
[3:23] And we're gonna need to make this happen.
[3:26] So I quickly wrote up a ticket.
[3:30] Wow.
[3:31] Build the smart filter, drop down tags, CSV export, design attached, this is final.
[3:36] Here's a doc, you can read it.
[3:38] Go ahead.
[3:39] This is you don't need to think about it.
[3:41] Story points, we heard it today also from Verena, is uh you people don't need it anymore.
[3:46] It was mainly for alignment.
[3:47] Now that you get like specs and links to one pager, context travels around.
[3:52] You heard it also from from all the other speakers about this is how context is traveling.
[3:56] You try to bring as much context further.
[3:59] You want your AI agents and your team know about all the information that they possibly can to build a proper feature.
[4:06] But from my angle, when I had to have the opportunity to observe how people work, and especially now that AI made everything so fast, when looking at most of the things, what is happening is this is the low effort work that people don't want to do anymore, right?
[4:22] It's you you look at the stuff and you think a one-pager.
[4:26] Um I just I just talked to a customer.
[4:29] I I literally can give him the gong calls and maybe maybe some metrics.
[4:33] And uh, you know what?
[4:34] Hey, Claude, maybe you write a one pager for me for the team, so they can actually start building it and attach it immediately to the to the to the ticket.
[4:44] Um and if there's no tickets, just create it.
[4:48] So that effort work with the context you give it, and we heard it today, right?
[4:53] You need probably some guard rates and rules and all of that stuff, but ultimately the AI will make stuff up as well.
[4:58] Hallucination, we all heard about it.
[5:00] The models get better, but ultimately it depends on what you feed it, and based on that, it will make up whatever you give it to to do.
[5:09] In that case, a ticket.
[5:10] What it missed though, because you s you gave it the task of hey, give write a one pager and attach it to a ticket.
[5:16] And if the ticket is not there, just add it to the ticket.
[5:18] So, what is happening?
[5:20] What you see is there's a one pager attached, you give it to the engineering team, and the planning started.
[5:26] Okay, you know, already we go and work on that stuff.
[5:30] So the engineering team has no way to ask the why.
[5:33] Why do we do this?
[5:34] They have to read the one pager.
[5:36] What is the evidence?
[5:38] Why why do we do that and what's your data behind it?
[5:41] What naturally happens, and what I see a lot that's happening, and is that when there's a handoff, the first thing that's happening is, oh heck, it says one pager, but it's more than six pages, or maybe even 20 pages.
[5:56] I'm not gonna read it at all.
[5:58] So TLDR, I just give it to the agent to work on it.
[6:02] And so a ticket goes over immediately to an agent.
[6:06] The other people, like design, engineering, they're not even reading anymore the context.
[6:10] They just see, yeah, there is some building a dashboard, building a uh uh uh um a drop-down or whatever.
[6:17] Go and do it.
[6:18] You will you will figure it out.
[6:20] Probably most of the context is already in the one pager that turns out to be a six pager.
[6:25] And yeah, we heard it.
[6:26] Uh AI, the LLM models, Gen AI models, they love getting context.
[6:33] The problem is then how do they digest it, how do they learn from it, what do they make out of it?
[6:38] And this is the way when we don't look at it anymore, we just give it to the agent and expect like if it's wired, it maybe ships it even to production and we don't even know about it.
[6:48] So my theory and what I what we see in the industry, and we heard it today from the speakers as well a lot of times is AI speeds up the wiring you already have in your organization.
[6:59] That means however you already worked with your teams, with your part with your partners like design, engineering, go to market, with your customers, AI will just speed up how you connect and interven, intervene with those functions today in your organization.
[7:17] And as you can see, I I consider there three different things.
[7:21] One is a handoff.
[7:22] A handoff is whenever work changes the uh the uh reaches another function or essentially changes hands.
[7:30] So when product defines a ticket or something similar and hands it over to maybe design, maybe to engineering, and they're gonna do something with it.
[7:39] Then there's the check.
[7:41] The check is usually when something stands in between the customer to verify whatever happened here, whatever was done, does is that good for the customer?
[7:51] Can we can we get give that out?
[7:52] Can we ship that?
[7:54] And then last but not least, is what we heard also as well proof, evidence, signals.
[7:58] What is the customer's reaction to whatever we delivered?
[8:04] In the beginning, when Agile and Scrum came in, most of the things that people were optimizing the organization for was time to market.
[8:11] So how quickly do we get something out the door to the customer?
[8:16] With AI, that changes because you don't want that just something goes out the door.
[8:22] You want to get time to signal faster.
[8:25] You want to learn quicker about what the customer does and how they learn and how they use it.
[8:31] So in my slide deck, you will find that there are three different types of wiring.
[8:36] Number one is a straight yellow line, that means it's fully wired, it's efficient.
[8:40] The thing just goes through, everybody's happy.
[8:55] Sparkling lines are quite often in organizations where something is happening in communication and intervention.
[9:03] And then last but not least is something where there's simply a gap.
[9:07] Probably you heard it when somebody threw something over the fence, right?
[9:11] You had a ticket and you just hand it over to engineering, or engineering threw it back and said, you test it.
[9:18] Then it's not wired.
[9:20] That means it doesn't reach its goal.
[9:22] It's just not connected.
[9:24] So AI will speed up all this wiring for you without you even noticing.
[9:30] It will be just faster, bottlenecks will come up.
[9:34] So I think we saw some of these numbers as well from the um state of product from Atlashian in 2026, which was done with thousands product managers across the globe, mainly US and Europe.
[9:45] And what they already said is the front of the wiring of our systems are very thin.
[9:52] 82% of the teams don't usually have engineering involved already at ideation.
[9:58] That means we as product managers, we sit already back and come up with ideas.
[10:03] We're building up the backlog.
[10:04] We heard it as well, right?
[10:05] We build up a backlog, we try to make work for engineering to happen.
[10:10] We do not do collect with them, get together with them, and then think about hey, how we as a trio work together and can find out what do we want to work on.
[10:20] And even worse is that we have 4% of those people responding said they can't even trace any roadmap decision that they have taken.
[10:28] So whatever we decided, I want this feature to go live to the customer, 4% can actually tie it back to customer evidence.
[10:35] That means signals back to whatever decision we have made are only at 4%.
[10:43] So that means our front, product, handoff wiring to engineering, that's the front connection.
[10:50] When in most of the organizations we still have the trio functions of product engineering design, this is the wiring that we need to look at today.
[10:58] And I call it the front because that's the beginning when we start thinking about work and how do we connect it.
[11:06] But ultimately, I want to look also at every station that gets speed up because the whole product lifecycle is longer than just the front.
[11:16] It's product, it's engineering, there's design.
[11:18] Then there are probably checks, right?
[11:21] Checks to verify it should go live.
[11:24] Um, there might be go to market, marketing, PMM in between as well, and at the end, the customer.
[11:32] So, as this example shows, we have like, okay, we we speed up the functions and we speed up the work.
[11:37] So, engineering now builds 42 issues way faster.
[11:41] They get 42 things now faster with AI.
[11:44] The wiring is not optimal, but it works.
[11:47] They get the work.
[11:48] So they're working on it.
[11:49] And at the next stage, we see already 420 things piling up.
[11:53] So the natural reaction of organizations that try to speed up stuff or the work, their pipeline, their wiring with AI, placed an agent.
[12:02] And that's Steve, right?
[12:03] From the beginning of the video.
[12:04] And Steve says, Looks good to me, let's go.
[12:07] Let's ship it.
[12:08] Because it just does that based on the context it gets, and it stamps, looks good to me, ship it.
[12:14] The problem with that is as fast as it gets, the wiring is not between go to market.
[12:19] So go to market doesn't know that did something ship.
[12:21] Maybe you have a Slack channel where release notes are being published, but 420, maybe in a day or two, nobody reads that ever.
[12:29] So they probably would.
[12:30] Again, try to use an agent to summarize that.
[12:33] So go to market, and we heard it also in other presentations.
[12:37] They maybe find it out.
[12:38] I think it was in Faith conversation about the makers manifesto, right?
[12:43] Maybe go to market just even finds it out because the customer came back and said, Why is this button no green or on the left side?
[12:49] I was used to having it on the right.
[12:52] And then this is the customer signals that the customer just uses this and feels like, and I heard that response a lot in my career is oh, we test in production with our customers.
[13:03] And the customers give that back as response in our production code.
[13:08] So recently there was uh a really cool uh talk at Lenny's and Friends Pot uh Lenny's and Friends Summit, and Geoff Charles from Ramp also said exactly these these terminologies that we heard of us today also today about the bottleneck.
[13:25] AI simply removes the bottleneck but moves it.
[13:28] And when we think again about what does it move, what does it simplify, right?
[13:33] Early when I said we started with organizations for product engineering and design were collaborating and working on uh on stuff, they usually had a mechanism.
[13:44] For example, a backlog refinement.
[13:46] Who of you does backlog refinements today?
[13:49] Oh yeah, that's three, four hands.
[13:51] That's not too many.
[13:53] Right, that was the moment, right?
[13:54] When US functions all together, you had the moment of asking the question why.
[13:59] Engineering, design, whoever was part of it, stakeholders, were able to ask the question why.
[14:05] And this was the slow building that kept us out of the build trap.
[14:10] Because now what we have is the wiring.
[14:13] We are not asking the why anymore.
[14:15] So what's happening is, well, an agent will go and say, Cool, yeah, I sounds good.
[14:22] It's not asking why, it gets the handoff, it goes and executes it.
[14:25] Nobody asks.
[14:28] And at the same summit, for example, Claire Vu from How IAI podcast, she also mentioned the cool thing is now your roadmap gets empty.
[14:36] That's amazing.
[14:30] It gets faster.
[14:37] All the stuff on your roadmap gets done faster.
[14:39] But it also means all the bad stuff is being shipped.
[14:42] Because all the bad ideas are still on your roadmap, and you haven't made the decision to not build it.
[14:47] But as engineering running out of task, they probably just pick up the next thing that's probably there still since 90 days or law.
[14:53] So what they do is agent, go and look at the roadmap, and gonna work on all of it.
[15:01] So how do we bring back a more efficient wiring at the handoff, especially for us as product managers, working together with peers at engineering and design at the front?
[15:16] One of the things that helps, and I think we heard it as well, Dave just mentioned it as well in the in the wiring with proof, right?
[15:23] One of the things is that product provides the front.
[15:27] So you guys here are working on what is the problem.
[15:31] You decide on what's the problem.
[15:33] You bring in the proof.
[15:34] How did you test it?
[15:35] How did you validate it that this is a problem?
[15:39] And in the best case, you even have a prototype.
[15:42] And why a prototype?
[15:43] And this is a practice that Ramp is executing today.
[15:47] A prototype is essentially, as Marty Kagan also mentioned in his podcast in its in its book Transformed, you use a product to immediately falsify an assumption, as Martin mentioned as well.
[16:01] You have assumptions, hypotheses, bets.
[16:04] So you want to, before you even start handing this over to development to test it out to A B test it, you actually want to immediately test this first.
[16:13] So how can I make, and maybe this is a good question to ask: how can I make this assumption to test within a short period of time to come back and reiterate that it doesn't even have to reach engineering because we tested it already with customers?
[16:27] And with that prototype, you have essentially a clickable truth, you have a proof, you have the data, and you can define the problem and prove that this prototype signaled that this is a problem for our customers.
[16:43] So now that we have essentially one of the concepts that help us, right?
[16:49] We we saw that also you can move still contexts with the with the tickets.
[16:55] But ultimately, when we solved the situation with, let's say we wired back product and engineering with a well-defined handoff, and both function feel very well.
[17:05] Product, you test it, you you decided on the right idea, you you validated the assumption, and you know that this is the right thing to do.
[17:13] Engineering looks at the prototype, they click through it, they enjoy it, they find maybe have the same issue with the prototype and say, Yeah, I don't like it either.
[17:21] And it reaches then the state where I'm not talking about pull requests here because pull requests going for the pipeline, and as Dave said, like there are another issues that arise of what is the pipe when the pipeline gets so many things, what is happening then with these things?
[17:38] There's linting, there's other stuff that is a system on its own.
[17:43] What I'm talking about to review here is how can we sense check again?
[17:47] I think in in the scrum time, there was usually this: hey, uh, we shipped it to staging, uh, dear product manager.
[17:55] Can you have a look?
[17:56] Um, you do the end-to-end test.
[17:58] How many of you does still test things on staging or somewhere else?
[18:06] Yeah, there okay, that a few, but also unsure, okay, yeah.
[18:11] But exactly, there's this thing.
[18:13] How could you possibly test if let's say the pipeline is 420 things?
[18:18] Like we saw it in the manifesto as well.
[18:20] How we want to prevent that a customer lands in two betters or more.
[18:23] So, how can we make sure that we test these things and don't disrupt the customer?
[18:27] So, again, people might put in an agent to just speed that up because the agent will just say, Hey, yeah, looks good to me, let's go.
[18:34] Right?
[18:35] So it doesn't make this decision.
[18:37] It can make this decision for you, but if it's the right one or not, that's up to the context it got.
[18:45] So, what I really loved was um what linear is doing, and linear is essentially in order to wire that the check, what they do is specifically events where people, humans attend with agents that do the work, but they wire the check by having specific events like the Quality Wednesday, which is a weekly one fix each trains the eye event.
[19:12] That means product, design, engineering, whoever wants joins and starts working on a fix, a support ticket, a bug you have in the backlog, and you work all together on it.
[19:24] And that helps in reaching a consent of what means quality in our product, what is our production grade level of quality?
[19:34] What do we consider a bug?
[19:36] What is a feature request and stuff like that?
[19:38] You train all together to get a quick better quality, and that the agent ships these qualities as well.
[19:46] And one of the things I really love, and um we we did that as well, is feature roast.
[19:53] Um so before you even ship this to production, and I think these concepts exist before, right?
[19:59] Because usually what you want to do is before I ship it to the customer, I want to dog food it.
[20:05] I mean, Thomas mentioned it as well with the product with their with their automation with the agent OS.
[20:11] We dog fooded it.
[20:12] We drank our own champagne.
[20:14] Why?
[20:14] Because we wanted to understand how does it work?
[20:17] Is it really solving the problem?
[20:19] Does it function behave for us as good as for the customer?
[20:24] So what they do before each beta, they do a fresh pair of eyes, they look, and then the one who's driving the beta decides ultimately at the end, do we gonna ship this or not?
[20:36] And this is another intentional human interaction event to check the why.
[20:44] Did we even work on this in the first place?
[20:46] So it helps to rewire product engineering and again crossify and revalidate why did we work on it, what was the proof, and does this what we have built or the agent has built solve the problem in the way we wanted and anticipated?
[21:04] So, by that, what we now have is essentially we have the wiring between product and engineering.
[21:10] We are the handoff.
[21:11] So product and engineering are collaborating efficiently, they send over the necessary information and they can challenge each other.
[21:21] And AI can speed that up, right?
[21:23] The pipeline, you can wire it, no problem.
[21:25] Then you intentionally, and um, there is a book that's called Wiring the Winning Organization from Gene Kim.
[21:34] He's specifically also talking about when you want to gain speed, you also need to think about slow fying.
[21:39] You need to think about events, interactions or areas where you intentionally need to slow down to later speed up.
[21:47] And these reviews are exactly this moment where you slow down, look at specific events, they will hit your customers, and you don't want too many of them hit your customers.
[21:57] And in that way, you can verify that.
[22:30] Want to reach is you want to make a specific moment where you decide this is a feature, this is a functionality, this is something that solves a big problem for our customers.
[22:39] So we do want to celebrate it with all of you, with the customer, ourselves.
[22:44] And these are specific launch moments you decide as an organization to wire together.
[22:50] And by this way, you don't lose go to market, you wire it in.
[22:56] Ultimately, then when you wire the whole pipeline, what you then get back is the signal from the customer.
[23:02] That's the next thing then to wire as well.
[23:04] Is we want to know what is the proof.
[23:07] And with the handoff that we already have with the prototypes, we get some signals back.
[23:12] But also, as we heard it today in other talks, the problem is we ship it, we launch it, we forget about it.
[23:19] Monitoring and continuing tracking the time to signal and seeing how this feature is perceived, that is an important factor to wire it back and signaling it back into the pipeline.
[23:33] So when a building is no longer the bottleneck, what is product then actually for?
[23:44] And I definitely didn't want it to give that question to an AI because the first thing I will get is great question.
[23:51] Thinking, looks good to me.
[23:55] What we want to do is rewiring the front.
[24:05] Is what can we do to wire the front to make it more efficient?
[24:09] We can bring in the problem, the proof, and a prototype, test it early, falsify it, return, rewire it, and bring it back.
[24:19] And then if you feel strong enough and bold enough, you can go and get the entire pipeline.
[24:25] And by that, I'm ready for questions.
[24:29] Thank you.
[24:35] Brilliant.
[24:36] Brilliant.
[24:37] Loved it.
[24:39] Thank you so much.
[24:41] So I think we have time for one question.
[24:46] Oh.
[24:48] Yeah.
[24:48] That was brilliant.
[24:52] So yeah, this is like this is the look.
[24:54] We are the sailors today from the stage.
[24:56] Trying to see.
[24:58] Do I see one hand anywhere?
[24:59] Yeah, there's a hand in the front.
[25:01] A hand in the front.
[25:02] Brilliant.
[25:09] There you go.
[25:10] Hello.
[25:10] Oh, it's not check.
[25:12] Cool.
[25:13] Thanks a lot for the talk.
[25:14] Enjoyed it.
[25:16] I have a question which is not so much about the tech.
[25:22] I'm interested in the whole, so to say, people part, right?
[25:27] At the end of the day, in Teams.
[25:47] Fear, pushbacks, you know, obstacles you were running into and how you solved them.
[25:57] Well, that's a great question, yeah.
[26:01] I think it's it's the same with with a lot of changes, right?
[26:05] You you first need to experiment and pilot in one area, and you need to set yourself a goal.
[26:11] And by starting bringing your people with you on the journey, that's the most important thing, right?
[26:17] You just don't install AI as a tool, you just don't bring it in.
[26:20] I mean, that's what's happening right now in the industry.
[26:22] They're bringing in AI.
[26:24] We heard it's 10x.
[26:25] Uh go and chase it.
[26:28] But it as I said, AI will just speed up your wiring.
[26:32] It will just reflect and make your wiring the same way, just speeding it up.
[26:37] So to introduce that change and bring people with you in the journey, they first need to understand what does this look like?
[26:42] What's the target picture?
[26:43] Where do we want to go?
[26:44] What does it mean for us that we're gonna be faster?
[26:48] Because speed is ultimately what distinguishes you still from the competitors.
[26:52] It's still up there and will be even harder.
[26:55] So, in order to bring that together, you we spun up a pilot where we essentially got a team together out of different functions, including we used also a lounge for that example, and tried to wire the whole thing.
[27:09] And then we had specific learning moments, we did a lot of retrospectives in between exactly these stages to better understand where did it break and why?
[27:17] And maybe this is intentional, and it's okay.
[27:19] We we make a decision to slow it here to speed up maybe at a later point.
[27:24] And in during these phases, the first thing was also with the team to first draw even this functionality.
[27:30] How do we interact?
[27:31] So we can we had at the end, we had like an interaction model, a system ourselves that we understood who's talking to whom, when and why, what needs to happen in here and here.
[27:41] And it discovered like a huge model of internal enablement, support enablement, then customers enablement, AE, SE.
[27:49] So we had a huge model just to understand how do we even talk together in the company today?
[27:54] And is it efficient?
[27:56] Is it effective, or where does it break?
[27:58] And then we started when with working groups to take one at a time and then first try and pilot this and see does it does it bring the new effect and then see the bottleneck moving?
[28:09] And we we saw the bottleneck moving.
[28:12] Thank you.
[28:13] Good question.
[28:15] We have some time, still some time for questions.
[28:19] I'm telling you why.
[28:20] So we had a couple of technical difficulties on uh the AI workshop stage today.
[28:28] So the talks are running a little slower there than on the main stage.
[28:32] So what we're gonna do in order to adjust for that and to give everybody a chance to come back later for the keynote is that we're gonna move the keynote 15 minutes back.
[28:42] So not uh 430 but 445 gives us a little more time for QA with Felix and a little more time in the break.
[28:51] Um hope that's okay.
[28:54] I know some people have to catch trains.
[28:56] I'm sorry about that.
[28:57] But um, if you have another question for Felix, 15 minutes roast time, yes, roast him.
[29:05] Like he can take it.
[29:06] Yeah, there is an engineer.
[29:08] There's one in the back.
[29:10] I can tell you, engineers are not kind to each other at conferences, meetups, or any place else.
[29:17] Is the box moving up?
[29:19] Do you do you get the box?
[29:22] Uh perfect.
[29:23] Awesome.
[29:23] Hello.
[29:24] Hello.
[29:26] So uh we work in a regulated environment and validation is a whole different sport there.
[29:34] Uh we currently have the problem that our development is quite fast, but validation can't keep up.
[29:41] Do you have a solution for that?
[29:45] Wait a second.
[29:46] No, I can relate to that because I worked at Sneak, which is a cybersecurity company where we did FedRAMP, and it's highly regulated, and I can relate to that.
[29:55] I think the interesting aspect is it's it's following similar principles, right?
[30:00] Because we we see agents that are able to write GRC documents as fast as anybody else.
[30:05] You need probably some redlining, or you need uh definitely a human to check it first.
[30:10] Um I think is the is the bottleneck in the engineering.
[30:15] You said it's engineering is fast.
[30:16] So is it about the evidence collection or is it about the documentation piece?
[30:20] It's about evidence collection.
[30:22] Evidence collection, yeah.
[30:24] Yeah, so I think this is a problem in the industry at the moment that there is no real-time evidence collection when you do and build artifacts.
[30:32] I think there are some uh companies out there that are working towards that that essentially while you build, it already calculates all your evidence for that.
[30:41] But ultimately what we had at FedRamp was essentially the full funny part was we had interviews, humans, no agent, humans interviewed agent.
[30:50] How does your system function?
[30:52] You need to know your system.
[30:53] You need to have a business contingency plan.
[30:55] This is not something that an agent executes.
[30:58] So in a highly regulated environment, there will be a lot of interaction that will be still depending on humans.
[31:03] And I think the interesting aspect will be if you don't understand if you don't know the code, because there is a lot of stuff that's moving, it will be very hard then to un still understand what's happening and how it's being done.
[31:15] Right?
[31:15] So I think a lot of that what helped us was this time was the product security piece that essentially demanded a lot of diagrams, and which is also evidence you need to bring.
[31:25] And with these artifacts, we were able to train essentially internally our teams to better understand what did the agent actually do.
[31:32] Oh, it built another service on the side.
[31:34] That's good.
[31:30] But seems like to work.
[31:37] So I think in highly regulated environments, we will probably at some point see that agents will be able to collect while developing, will be collecting evidence.
[31:47] Um, but we are definitely not there yet.
[31:49] I I definitely don't know that there is a company.
[31:51] I know there is Vanta, for example, which does also after the fact, but there will be probably uh sometimes companies that also hook into that system as well.
[31:59] These are definitely the niches that need to be need to hold and help by this highly regulated environments.
[32:06] But ultimately at the moment I do think you can speed all of this up.
[32:09] I think it will speed up.
[32:10] I think FedRAMP at this time was also converting their whole system from twenty thousand of documentations to a single meeting where now you get interviewed, you show your evidence, and then it will be checked async by an agent from FedRAM.
[32:28] Thank you very much.
[32:29] I like the idea too.
[32:31] Incorporate the evidence collection within the development process already.
[32:34] So that's something that I would explore.
[32:36] Thanks.
[32:37] Welcome.
[32:38] Good question.
[32:38] Awesome.
[32:39] One more?
[32:40] Do we have one more?
[32:41] Yeah, you can throw it if you want.
[32:42] Turn around, turn around.
[32:43] It's coming from the back.
[32:46] Where to Yeah, there we go.
[32:49] There we go.
[32:50] Oh, let him throw it.
[32:51] He wanted to throw it.
[32:52] I can see it.
[32:53] I can see it.
[32:55] It's so much fun to throw.
[32:57] Whoa, and that was a good one.
[32:59] Well done.
[33:02] Amazing throw, but I fucked it up, sorry.
[33:06] Um so we learned today that you need all the context, blah blah blah.
[33:12] And I totally agree.
[33:13] And I wanted to ask if you have best practices of where to store the context, because personally I currently just work in the GitHub with the developers.
[33:36] Like, okay, is it that easy?
[33:38] Or like how to do it?
[33:40] And yeah, just to get your idea of it would be interesting.
[33:44] Yeah, uh, I think this is definitely a problem today, right?
[33:48] Because essentially what what's happening, you you you put in a lot of document, a lot of markdown files into the repos, they just blow up and they might be outdated the next hour.
[33:59] And if there's not like a governance system behind it, they will just just floating around.
[34:05] So what I see in the industry, what's happening and and why combinator is actually funding companies that try to go into that space is a queryable company.
[34:14] Which means you have an intelligence layer, a context layer that can be queried by an MCP, CLI, whatever else, and has contextual information and also how up to date is that information, how much you can trust it.
[34:28] I don't know if there's something about that out there already about that.
[34:32] I'm pretty sure there might be plenty of open source things already because that system explodes, but ultimately what I see is you don't want the context to be necessarily only in the repo.
[34:43] You want it somewhere where people can also access it differently.
[34:46] Thinking about customer signals and that stuff, right?
[34:48] They might live in gong calls, but gong calls in the the whole context of the call, you don't want the whole thing to read again.
[34:56] So you want to digest.
[34:57] So what you want is probably an abstraction that gives you all these signals, maybe builds even correlations about them so that you can chat to it.
[35:06] So what I would love would be I'm having a Slackbot, and then I'm chatting to the Slack bot and said, hey, I'm working, I want to work on this idea, this assumption.
[35:15] Do you see any customer evidence in, for example, support signals, gong calls, customers talked about it.
[35:21] Do you see that?
[35:22] And then you get that information condensed back, linked to the original source.
[35:27] And I think something like that is probably something that we will see evolving in the next year, month.
[35:34] That we need some layer of abstraction that makes it efficient to query, efficient to get the information to make the make decisions for human end agents, right?
[35:44] Because if let's say in the regulated environment, maybe a great example, let's say these artifacts, these architecture diagrams are stored somewhere in this layer, and then whoever starts a new system will be or a new task.
[35:57] The could this will query just the information it needs from that service and says, I know what this is functioning, and it's about to be verified by um a legal in legal um corporation about getting getting, for example, certified.
[36:12] So I need to make sure to follow the following rules.
[36:15] And for example, we we see the it's also so heavily changing, like Boris Cherney, for example, said he's regularly deleting his CloudMD files because they go and blow up, and then the data that's in there is never being cleaned up.
[36:30] So either we find a way to regularly update the context and the information within those inform within those repositories, or we build a system that helps us making that autom more automatically.
[36:45] Perfect.
[36:46] So I hope you were inspired by Felix.
[36:50] I definitely was.
[36:52] Give him a big roaring, clapping, stomping.
[36:57] Applause.
[36:59] Thank you so much, thank you.
[37:05] Thank you.