# AI Agents, Vibe Coding, and the Enterprise Last Mile Gap

**Podcast:** Dev Interrupted
**Published:** 2026-05-15

## Transcript

Did you use AOL or were you like an ICQ or an AIM or MSN person or Yahoo?
Were you a YIM person?
I was definitely an AIM person.
I was heavy, heavy into AIM with all the customized profiles and emojis and the games that were built into it.
I love that platform.
That was basically my teenage years.
That was what made Yahoo and MSN so fun too because you could do all the custom.
I mean, they all kind of had that.
But AIM was definitely the first one with like.
The sound effects, like the door opening and closing, like that is rent-free in my mind.
And it's like AOL will always be there.
Man, that's some nostalgia I haven't tapped into in a while.
Well, you know, it's really awesome because now AI agents get to experience the early era of AOL and instant messengers and stuff like that.
You know, I'm personally really happy that they get to experience this.
But yeah, I'm talking about this new open source project that we came across this week called AOL.
Agents online.
Pretty cool.
It's like just a chat room for agents to work together in with a really kitschy name.
So I just wonder, like, what's the agent version of ASL?
Like, you remember this from like the chat?
Oh, yeah.
No one does this anymore because it's like doxing yourself.
But everyone asking for your age.
And of course, today it wouldn't be S.
It would be a gender.
They'd ask for your gender.
And then.
your location like who are you where do you live like that kind of stuff that was back when version of that oh absolutely i was back when like your internet persona was just the word on the screen you didn't even have like a profile people literally had no idea who you were and hs live in that world too i would guess that their their asl is like what model are they What's their context of Windows currently filled at?
What capabilities do they have?
Oh, yeah.
And then what NCP servers are you currently connected to?
That would be like their ASL handshake.
Well, we do definitely need this.
You know, yeah, as somebody who is both like that former AIM user and a former AOL employee, like I think this is absolutely necessary.
Like this is if you want to be on the Internet, you have to experience like that sensation of these like early chat rooms because it really was like.
Such a fundamental component of the early internets.
Precisely.
And what's fun about it is that...
Like, even though it's nostalgic, it's not a joke either.
The underlying principles of how it works really link back to how agents do collaborate and corroborate with each other.
The idea that they can set statuses, they can see each other's work as they do it because it's like a status in the messenger, as well as send, you know, obviously information back and forth on a local server.
Kind of an interesting concept, a way of giving them some more presence, I think, on the internet.
Now, it's only to think if maybe they bridge out of that into a message.
humans.
It's not just agents online, but we're all online with them.
Yeah.
Yeah.
Well, welcome to the Friday Deploy brought to you by Linear B.
We got a lot of awesome news like that to share today.
I'm your host, Ben Lloyd Pearson.
And I'm your host, Andrew Ziegler.
All right.
Today, we are covering the growing convergence of VibeCoding and agentic engineering, Andrew's new agentic development research.
build-first development processes, the evolution of technical interviews, and enterprise AI's last mile failure.
So we've got a lot to cover today.
Let's start right at the top with how VibeCoding and agentic engineering are getting closer than some people might like, including Simon Willison.
What do we have here, Andrew?
So Simon Willis then once again in our lineup we can't get enough of what Simon writes about he's on the edge of everything with AI adoption especially for large teams and how open source folks are thinking about it and really connecting the dots between those two worlds so in this article Simon admits like that his vibe coding experiences and his agentic engineering experiences, which are supposed to be, you know, the more formalized version of that.
They're starting to converge.
Just as AI work just becomes more reliable across the board, vibe coding starts to enter a impossible to fail territory where you don't have to do as much of the discipline that we now call agentic engineering.
And this is happening because harnesses are evolving.
It's happening because the models are getting better.
But he admits that he's stopped reviewing.
every line of the AI-generated code even for production systems because the coding agent's more like a trusted external team.
And while that shifts and makes them uncomfortable, it's proven to be consistently reliable, which is an early sign for like the new mode of reliability we might be shifting into for AI output.
And what's interesting about this is that at the same time, the scale of code produced by these agents is going up.
So we're trusting it more.
and it's writing more code.
So there's a compounding effects of it just like being able to do more longer without making errors.
And the last thing that he pointed out was that It's like really easy to create really polished looking repositories with documentations and tests that are really impossible to distinguish from what he would call, you know, quote unquote, vibe coding projects.
And so it really hints to like why the reliability is so good under the hood.
The capabilities are just getting higher for everybody.
What do you think, Ben?
Yeah, I'm definitely feeling a lot of the elements of what Wilson is describing in this article because, you know, we hit.
I've found a lot of workflows that I can almost completely trust AI with handling it and its ability to execute on it.
And it's getting to the point actually where I think it's even getting harder to identify work where this isn't the case.
Like I'm so comfortable just throwing more and more work at AI.
When it fails, the failure modes are becoming less obvious as it gets better and better.
You know, to the point where like last year, I felt like, you know, most of my time with AI was spent.
determining where the models failed, obviously, like they would do something that was clearly wrong, that I would have a strong understanding of how to go back and correct it and put guardrails in place.
But now I'm spending more time validating whether or not the AI was successful.
And this is a very subtle difference, but I think it has really big implications because obvious failures are very easy to spot, but a single failure mixed into a long list of successes.
is substantially more difficult to spot.
The humans just struggle to identify the needle in the haystack versus a pattern that is mismatched as a whole.
So if you scale this problem up to a team or an organization level, you need awareness from everyone within that team or organization about how to spot those AI failures.
Because naturally, these are stochastic systems.
They will eventually produce failures.
It's basically a guarantee.
that eventually the probabilistic system will encounter a probability that is wrong if you give it enough time, like that's how these things are designed.
So you either need to have automated systems in place to catch those failures, or you need humans who have a strong awareness of what failure looks like so that they can quickly pass judgment on it.
And there was a closing line in this article that really stood out to me.
because it's a topic that we've been discussing a lot recently, and that is rolling your own SaaS solutions.
Today with agentic coding, vibe coding, it feels like you could just go out and build whatever you want, whenever you want.
We have been exploring this through our own, we have this build versus buy workshop that's coming up next week that is going to get really dive into this topic of like, when do you determine whether or not you should put AI to building something versus just buying something off the shelf?
And, you know, and we tried to vibe code in engineering productivity platform and really learned a lot about the importance of domain expertise within these these agentic workflows.
You know, an enterprise grade SaaS company has accumulated years of domain expertise that inform how their platform is built.
And the current technology of AI just simply can't replicate that.
And, you know, the organizations that are using AI well.
you know, sort of quickly learn that the humans operating these AI systems are now more valuable and more important than ever.
And this was something that Willison touched on in this article is that he feels like his role as an engineer has never been more important with these AI systems.
And, you know, in a well-built AI system, I think handles the toil of a lot of people's jobs and frees that human operator up for higher order challenges.
which, you know, is a really great thing to have.
So, yeah, I think, you know, as always, Wilson's doing a really good job at just being attached to the zeitgeist, you know, helping us understand the forefront of agentic work.
And I think anyone who's operating in this space should go out and check out this article.
Yeah, I agree.
All right, Andrew, you're a published researcher now.
First of all, congratulations.
But now let's talk a little bit about like what's your research about?
Well, thank you.
Yeah, so I had an experience earlier this year where I did a hackathon that I talked about on this show that I won.
And in doing that hackathon, I spent a lot of time planning with my agents before we wrote any code.
So after the hackathon, I reflected with my agent in the same task planning artifacts that were left behind, and we turned it into a research paper.
It's called Misan Plus for agentic coding.
And it dives into the deliberate preparation as a context engineering methodology.
I actually submitted it for a research conference called Vibex.
It's the very first international vibe coding and vibe researching conference, and it got accepted there as a discussion paper.
And so it's on ArcSiv now, and we'll include a link so you can go check it out.
It follows a little bit of stories of some of the stuff we've been covering here on Dev Interrupted and some of the practices that I've been talking about here as well, especially, as you know, my obsession with beads, which makes a very prominent display in this article.
It's a lot of fun to write.
Yeah, I don't think anyone needs to be reminded of your obsession with beads at this point.
No, it's definitely established.
Yeah, but for our listeners who aren't familiar with this term, mise en place, it's a term that comes from French cooking.
So it's this idea that before you start any cooking action, you should spend your time preparing to cook.
So you prepare your ingredients, you get them measured out and organized in an order of operations.
You make sure that you have all the stuff in place that you need to create the dish before you start any work to actually create that dish.
And the benefit of this practice is that it allows you to just rapidly create, you know, if you're thinking about a kitchen that's, you know, operating a system to get food out to a bunch of patrons, they need to be able to very quickly create these dishes on demand.
And if they're spending all of their time preparing while trying to cook, it just causes a lot of chaos.
So we apply that same sort of practice to agentic coding.
And in fact, you know, I just mentioned our attempt, our recent attempt to use AI to build an engineering productivity platform.
I would estimate that about 90% of our time was an effort was spent just gathering context, building a plan and informing our agent about the things that we actually wanted.
And then the so-called cooking phase where we were actually producing the code for this took less than an hour.
You know, it was.
It was a day or two of planning leading to only about an hour or less than an hour of development work.
So, you know, and that's really the benefit of this is that you spend all of your time making sure you're prepared to be successful.
And then the actual act of making that success reality becomes very simple.
So, yeah, it's a great practice.
I'm really excited to know that we have we now have a researcher in our presence and on our show.
It was a lot of fun to write and you did a great justice there with its summary.
And the article itself kind of goes into the collaborative.
process that I do to brainstorm it.
It was a really interesting exploration of task management for agents.
So if you've been trying to figure out how do I plan and execute at scale with my agents, prevent them from getting misaligned, how do I take my very specific domain expertise and encode it in a way where agents can act on it quickly, this article might give you a good starting point.
And my agents even left you with a few open research questions that maybe you could take and expand on my paper and we can continue to understand.
what that design process might look like in the future.
Yeah, and I also just, you know, just as an aside, I think this is a great example of how AI can enable people who are domain experts at one area to sort of expand the scope of their capabilities.
Like, you know, I think before the age of AI, you probably wouldn't have thought, put too much thought into being a researcher as well.
But now it's sort of just a thing that we can just add on to our skill set because we have tooling that makes it a lot easier for us to do things like this.
Wild times we live in.
Yeah.
And speaking of ways to build things with agentic AI, we have another article from friend of show, Zach Lloyd, who's the CEO of Warp, where he argues that AI coding agents have fundamentally changed product development.
And they've done it by making it faster and cheaper to build solutions rather than spending all of your time, you know, aligning teams on specifications up front.
Sort of getting into, you know, what we're describing with the effort we spend on planning, the actual act of creating a prototype or a functional MVP is now very simple.
And, you know, traditionally a company would produce some or would approach something like this with things like meetings.
PRDs, discussions around them, you know, all to make sure that the team is aligned before any effort is spent creating the thing.
But Warp is, you know, they're restructuring their development process to be, to align discussions after the build is complete, rather than trying to align people around hypothetical implementations that.
people might envision differently.
Like it's different when you have something tangible in your hands versus you're imagining something that will be a reality in the future.
So Warp has been applying this approach when launching some of the recent coding agent features.
Zach really recommends that all engineering leaders out there, now is a good time to audit your product development processes to see.
If you're aligned with the realities of this agent-led development work.
So yeah, Andrew, what do you think about this article?
This article is fascinating.
It actually kind of stands a little bit against some of the article that we just talked about a moment ago, the research that I put together.
There's definitely some parts that we completely agree on, which is being aligned on the core problem you're solving before you do anything.
Definitely, if you're in a position where you don't know what you want and you don't know what...
The problem is that you're not really going to be able to identically code a solution.
You're probably going to identically code a bigger mess.
And so that's like the very first incredible thing that never goes away, no matter what you want to do.
If you want to do the really deliberate preparation method that I'm talking about, if you want to do this build fast talk later method that Zach is doing, you still have to align up front on what the problem is.
I do agree with him that in...
In team environments where typically you would have maybe weeks or several cadences of planning and discussions before you ever touch a prototype, a lot of that is going the way of the Dota.
The prototype comes out a lot faster now.
It can be easier to throw together a prototype from a meeting transcript even.
And so the ability to iterate rapidly is, it probably cuts that kind of meeting cadence down to literally just figuring out what the problem is.
That said, though, it's like his methodology is really great for also getting out like a lot of possible solutions and then like picking which one might be best for different solutions, which could serve better for different types of problems you're trying to solve where you want to throw a lot of stuff at it.
And they talked about how they applied this approach with like building their own coding features.
Open source recently has become, or Warp has recently become open source as part of its development.
And so they're kind of like restructuring their whole development process to allow people to come in and quickly ideate and ship and build a verb.
It's a really interesting shift to see because I think more folks are going to be doing this, this build than align.
But then I also do think that for very specific domain-specific problems, like the one that I solved in the research paper that I used, my preparation methodology for.
It required me spending a lot of time explaining stuff to the agents that they wouldn't have had a way to know.
It lived outside coding space.
It wasn't something they were quick and grabby and good at because I was teaching them how to make an educational platform.
Whereas in Zach's world, it's like he's using agents to build an agentic orchestration system.
They're speaking their own language and so they can probably build it probably more fluently than we can brainstorm what they think they need.
Yeah.
Yeah.
And, you know, and we're seeing this sort of exact thing play out with content as well.
Like here at Dev Interrupted, you know, when we have new ideas, sometimes it's easiest to start with the final draft rather than like an outline or an overview of what we want to cover.
You know, we establish the high level of what we want to cover in the content.
And then we just go straight to a finished product and adjust from there.
Yeah.
But beyond that, you know, we've seen other examples here at Linear B where...
Like, for example, someone on the marketing team uses AI to build a prototype of something that we want to deliver to our customers.
And then the dev team works backwards from that prototype to implement it within our platform.
So, you know, even outside of software engineering, the function itself, you know, there's a lot of opportunity for non-engineering roles to do the build aspect of this.
And yeah, our engineers, they're also starting to work this way in some cases, too.
And this is not for everything, but sometimes it makes sense to spin up a prototype as one of the first steps for a new capability that we want to build.
So again, so that the organization can have that tangible thing in our hands to give feedback on.
Instead of starting from the same PRD doc, we're operating on the same platform and able to give very explicit feedback about where we see opportunities for improvement.
You know, and that approach in the past consumed tons of time, so it wouldn't have been practical, but I can definitely see it becoming our default approach more and more, particularly when we're building like substantial new features, you know, something that we've never done in the past or something that is a brand new capability.
It definitely does make sense more and more to just go straight to that final product and sort of reverse engineer it for lack of a better phrase.
Yep.
All right, let's talk about the tactical interview.
Andrew, has AI killed it off?
Is that another thing that has been wiped out in the AI era?
It is definitely getting wiped out.
You know, it's funny that we keep saying all these things that are getting wiped out, going the way of the dodo, because even just last week we had, you know, Brian Bischoff on the show talking about, you know, software stack and how things are constantly dying week after week and what we're supposed to mean by that.
And what we mean by that is disruption.
And disruption is certainly coming for...
the technical interview world.
It's already shaken up how folks prepare for getting hired in a tech role.
But an interesting part about this article is it points out how obviously startups are moving way faster at this than enterprises.
But you might be surprised that the interview process at fame companies have...
largely unchanged since AI has hit the scene.
But what's happened is that 67% of startups report that AI has changed their interview process in some way.
So either interviews are handled where there's like a coding process that's done like with a screen share or there's a live coding project or they ask them about the tools they use and kind of shadow their process.
Understanding how employees use AI is critical now in hiring them.
This is a really interesting expansion because I think always for technical interviews, like the puzzle-based approach of doing like the leak code challenges and then humping in and doing like the coding challenge was always flawed.
We were always talking about how that was flawed.
It doesn't quite highlight problem-solving skills.
It doesn't...
properly showcase your ability to collaborate and code on a larger scale, which is what you would be doing in your role.
But more importantly, it stresses the importance of just like memorizing a bunch of like...
edge case situations in code and knowing how to handle them, which in the old world was knowledge that you needed in your organization because if it wasn't in a human's head, you couldn't ask an agent.
But now because that knowledge is so accessible, it's less of something that you need to screen for in a candidate.
What you need to screen for are problem solving skills, the ability to break a problem down into smaller parts, understanding where to start, having taste in AI skills, knowing when to throw something away and when to iterate.
There's so many little gotchas in working with AI that can either waste a lot of time or make you super productive.
And the value between them is massive.
And so that's what employers now are evaluating is how fluent is this individual at using these tools?
How well can they use it to enact their will?
But more importantly, how well can they collaborate with others?
with it and working on like brand new problems.
We're going to be seeing an explosion of AI skilling and up training that I think is going to shadow the world of like leak code before it, especially because engineering itself is going to become a more accessible field for folks that traditionally weren't, you know, studying those quiz questions over and over again.
Yeah, and we'll include a link to this lead dev article in the notes.
It's chocked full of a lot of really great comments and quotes from industry professionals and how the skills they're evaluating for really haven't changed.
It's just the process for doing it that has changed because of AI.
You still need engineers who can explore problems, understand and validate code and communicate well.
And additionally, you know, system design and judgment of technical tradeoffs are increasingly important in AI driven companies.
You know, you need people who can build and manage complex AI workflows and then quickly pass judgment on what's best.
Like you said, we've highlighted a lot of the issues with interview processes in the past.
Some people today say don't use AI at all.
You know, even I think Anthropic really discourages the use of AI in early stages of.
of their interview process.
But, you know, I think, and maybe you can justify that in some situations, you know, particularly for like, you know, if it's a low level technical interview for like a junior engineer who's looking at their first role, you know, you might want to evaluate their basic competency with their tech stack and do it in an environment where they can't just go straight to AI and ask questions.
But, you know, when we when people interview at Linear B, you know, we tell them use whatever AI tools you want, you know, get the best outputs that you can with them and use leverage it for all the advantages that it gives you.
And, you know, we want to test you on whether or not you can understand the value of those outputs and why they were built the way they were built.
You know, those are the skills that we really need.
And it's skills that AI can't easily replicate or fake, you know.
I think these trends are going to continue to shift.
I think interviewing in particular is very much being disrupted significantly by AI.
And maybe we'll even get to a point where AI starts to run more of the interview process itself.
Let the person use AI, but they'll be challenged by an AI agent that sort of forces them to walk you through all of those higher order skills that you want to screen someone for.
You might find it flips differently.
You might find that the process becomes really deeply human, like what Anthropic is doing.
I think that that could be another direction that goes as well.
It would be interesting to see kind of how it shapes up.
But I think the other really interesting part of this too that stood out to me was as the engineering interview process gets less technical and more communication collaboration focused, other interviews around them are becoming more technical because we're all meeting in this new middle.
And so there's this interesting thing happening with like, you know, you're applying for a PMM role, right?
In the days of the past, like in no world were you probably going to be asked to like do some sort of technical assessment or put together a technical project.
You might be tasked to put together like a product launch or a pitch or a positioning thing.
But you probably were not tasked as much with doing something technical.
But now that's an expectation for most PMM roles.
And so you're going to get quizzed and trained on like how fluent are you?
How well can you go from that positioning plan to having an actionable thing?
How can you use AI to convert that into action?
And so on the flip side, you're also going to see all these roles around engineering get increasingly more technical in how they're screened.
Yeah, almost like these...
outside of engineering are becoming more engineering led.
I can think particularly like product managers, you know, that's a role where I think there's an increasing demand to have technical competency and the ability to use AI to build things end to end, you know, because you might be that product manager that is tasked with building prototypes of products, you know, before they've even had any development work on them.
So, yeah, I think that expectation is...
is really, really high now.
It's like if you're a PMM and you have an idea, it's almost the expectation that you can create some initial prototype.
Going back to even what you were talking about with Zach earlier, because you were aligned on what you needed and it was faster to make a prototype to talk about than it was to have meeting cadence about it.
That's the real unlock.
And PMMs who go into these hiring process, engineers too, who go into this hiring process, understanding that are going to stand out like...
head over tails above everyone else.
And so if you're applying for those roles, keep that in mind.
I'm sure you're already thinking about how can you showcase your technical skills.
So Ben, what's this last one about?
Yeah, our last story today is the last mile where enterprise AI dies.
And this is an article from Andre Savin.
It's a really great breakdown of a survey from McKinsey where they surveyed 10,000 engineering or executives.
And this survey revealed that While 88% of organizations are deploying AI, less than 20% are seeing significant bottom line impact from that.
And 86% of leaders feel unprepared to adopt AI in their day-to-day operations.
So some pretty stark numbers there.
And the core problem seems to be this quote-unquote last mile gap where AI technical capabilities need to be integrated with actual business operations.
Companies might have hundreds of pilots and high adoption rates and all these experiments going on, but they're not seeing the downstream productivity gains because most of those benefits have been trapped within individual workflows rather than organizational improvements.
Savine argues in this article that organizations have over-invested in AI technologies while under-investing in the production layer.
So that's things like governance, verification, redesigning their operations, as we've been talking about today a little bit.
And McKinsey's recommendation is that companies should be spending about five times on people versus what they're spending on technology.
So spend five times more on people and processes than AI technology.
And the result of poor last mile planning is that AI value is primarily being captured through layoffs rather than redeployment.
And I think we're seeing this with all these companies who are coming out and announcing layoffs.
I mean, we have Atlassian, we have AWS, we have WiseTech Global cutting 30% of their workflows, Block.
The list kind of goes on.
A lot of these companies that are explicitly tying reduction in forces to their AI transformation.
And it kind of seems like this pattern is going to continue in the short term.
And we've been covering this a lot here at DI, you know, this awkward transition from AI experimentation to AI impact.
And it is a very difficult chasm for many organizations to cross.
And even for more nimble organizations, I think it's, you know, the success of doing this has been pretty mixed.
You know, sometimes experiments turn into something that has bottom line impacts, but...
Other times the productivity gains are isolated to a really small component of a larger system.
And I'm definitely sensing this like universal pressure to do more with AI, but not everyone's stopping to evaluate whether that work is actually translating into business gains.
And the thing that I just keep coming back to like time and time again, mentally, is this statement that came out of last year's Doar report.
And that is that upstream...
productivity gains are being lost to downstream chaos.
And that's that describes that last mile problem.
And, you know, and I think the unfortunate reality is, is this is this article argues is that it's leading to more layoffs rather than reinvestment into the organization.
So, Andrew, what do you think about this article?
It's a really great summary of what I think is going on here.
And, you know, I do think that it's an interesting situation where companies find themselves.
wanting to rapidly buy and adopt these tools, and then they struggle with a workforce that isn't quite skilled up on how to use them.
They're still in these growing pains of how, you know, the new normal, new level operation is going to be.
And in all of that thrash, that chaos, as the Dora report calls it, you know, I don't think any of us have a really clear grasp yet on what that virtuous cycle of employee and AI automation, all working together and shipping things like there are companies that are AI native.
you know, with one employee and they have like a whole bunch of agents or something that are exceptions to this.
They kind of have that thing figured out.
They're the companies of the future.
But for companies that are inheriting this, that already pre-existed with a lot of already enterprise, you know, applications and process and people, it's a huge challenge to come in and like...
Unfossilize that is kind of what it feels like and then start to move around the pieces.
Enterprise's strengths is that they've taken a bunch of things over time.
They've cemented them together into this incredibly robust foundation that has lots of layers of management and process and tooling and skills.
And by like...
turning it to stone and making it as hard and as big and broad and as great as possible that's what becomes the really sturdy platform that other companies and themselves could build on top of and so that you know being that strongly aligned and being that rigid was their strength but in today's market moving really fast being nimble and resourceful is what is being rewarded and enterprise companies want to be part of those games they have so much to bring to those environments, but they kind of lack that celerity.
They don't have the ability to move as quickly or as fast.
And so, unfortunately, you get in a situation where, like, the employees...
in their minds, they feel stuck.
And so the option is either I can rapidly upskill them or I can restructure my headcount and bring in new people who are thinking this way or get rid of folks that I don't think that we need their role anymore.
And so you get these massive disruptions and enterprises that don't happen other places.
And that thrash.
It burns trust, it causes burnout, and it really creates this death spiral of, oh, we're not going to use AI well, or I don't want to be part of this.
That is, I think, plaguing a lot of these big companies right now.
And you just see it in headlines like this week after week.
But ultimately, it comes down to employees not perceiving the same benefits from AI.
that their employers are.
It's a cognitive disconnect between what employers see as ultimately numbers on a spreadsheet that they're optimizing for, which is their job.
That's like their stakeholders.
They're reporting to a board.
They have some fiduciary responsibility.
They kind of are in this very high level position where they're so far removed from the problems that they...
lack the language and the ability to break through and really kind of convey that with employees.
And then on the flip side, employees feel like a number in that spreadsheet and they don't feel like they're supported and they're upskilling.
But more importantly, And I have felt this before as well.
It's oftentimes like no good deed goes unpunished.
The better and the more efficient and the more elaborate you can get with your AI workflows, the more we'll get asked of you to do more of that, to teach others how to do it.
And then that becomes a really big burden for your...
Your AI-enabled folks within your org, they burn out.
They don't have the resources.
They need to upskill everybody.
And it creates also like an us versus them dichotomy within your own employees because you have folks that are getting lots of gains from AI.
Maybe their process or the job they do.
can just be really largely done by AI.
But maybe you have folks that are like maybe like in design and that's not their world.
Their tools are still very immature.
And so no matter how good and how AI forward that designer is, they're not going to be able to match maybe some of the level that the engineer can get, right?
So that disparity as a baseline is really discouraging.
for a lot of folks.
And I think that's the biggest challenge that we have internally is creating an environment where you're not making a pressure cooker, but rather you're having open, honest conversations.
And when you are finding things that work, you don't, don't glom it, right?
Like if you find, if you find that little flickering candle within your org, don't snuff it out.
Like there's a way to do this well and listen with your employees.
And that starts by building trust and having open conversations.
Yeah, you know, a lot of organizations hear about these like fabled product managers, you know, getting back to our conversation on the interviews and how they're changing.
Everyone wants that fabled product manager that is like the 10x person that can do it all.
They can go end to end with coming up with the idea for a new capability, implementing it with AI, building all of the assets to enable your organization and go market it to the outside world.
They want those superhuman people that are just operating on top of AI agents that can build all of these things that used to take a team to build.
But the challenge is if your organization is not set up to facilitate a single individual doing all of that work, you are just creating, maybe some people are savvy enough, they can navigate all of the enterprise complexities and find a way to operate within that.
Your typical worker probably can't.
They're probably struggling to understand how to translate those individual improvements into things that the rest of the company benefits from.
So, yeah, we've been covering this a lot.
You know, we talked about the messy middle of AI development last week, and we've been talking about token maxing leaderboards.
This is a common thread that I think we're going to keep touching on in the coming weeks.
So, Andrew, what are your agents up to this week?
Well, my agents, I've been on site at AI Council.
So there were a few really cool data science booths that were here.
In particular, I've been learning from them from their different handouts.
What I love to do when I go to these events now is to walk through the expo floor and do spoken word to my agents.
I'll be like, everything I see, I'll let them know, and I'll grab some brochures, I'll take pictures for them.
I'll do a little expo hall exploration, and then my agents will go and do some research and be like, oh yeah, this might be relevant to you, or this looks cool.
But the tools here are really amazing.
In particular, I really loved all the DuckDB stuff here.
Hex as well.
You've got Databricks.
Some really big, really smart data companies that are leading the charge.
And so I've been having a really great time learning from them and passing that on to my agents while I've been here on site at AI Council.
What about you?
Yeah, speaking of passing things on to my agents.
So, you know, we covered a few weeks ago the Carpathie method of using agents to ingest raw sources and build its own wiki.
Goal to have it.
to, to, to help your AI be informed about the topics that you wanted to focus on in that moment.
So yeah, I've really been embracing, uh, you know, letting my agents build, uh, content maps around like token maxing, for example, just so I can get a picture of who, who's saying what about it out in the space, what companies are doing certain things.
And it's been really cool.
Yeah, I've blown a few of my Claude Max sessions completely on just having to do deep dives into some of the stuff that's in my data sources.
But yeah, it's pretty cool because I'm using Obsidian for this, as I think a lot of people are today.
And it's really neat to see how I can use AI to sort of take all this disparate information and structure it in a way that helps me take action on it a lot more quickly.
I'm using it for content, for understanding the projects I have going on, for helping me navigate work with people on my team.
It's actually a really cool method.
And I do want to point out that when we covered this on the show, I think it was just a tweet that sort of went viral.
But now he has a whole markdown file that explains to your AI how to do this system.
So it's been a pretty fun journey this last week.
Yeah, if y'all are listening, if you have not experimented with keeping your own knowledge graph or your own knowledge system with AI, it's a huge, huge unlock.
If you're in a situation where you don't keep logs and journals of your thought process and what interests you and you don't accumulate those things over time, you're going to have a hard time hill climbing in the future.
Right now, we're all experimenting and throwing things at the wall, but eventually there will be a providence that needs to be established.
And those that have spent this time cultivating and building.
up this corpus of this is who I am, this is what matters to me, or this is what's interesting to me, even in a one-off way.
This creates a knowledge graph that kind of takes what's interesting to you and captures it in a navigable format for an AI to operate on.
This becomes your context fluency layer between you and your AI, and you need one of these in the future.
Maybe you don't need one now, but you should always be investing in your future.
So this is a good shout out, and it's great to hear that you're building that.
Yeah.
Sweet.
All right.
Well, that's the Friday Deploy presented by Linear B.
Make sure you give us a like on whatever platform you're listening to us on or watching us on.
Thumbs up, subscribe, all the great things.
It really does help this show out and help us get more attention on these challenges that we're bringing to the industry.
So thanks for joining us this week.
We'll see you next.
See you next time.
AI is everywhere in software engineering, but most teams still can't prove its impact.
That's where the Apex framework comes in.
Apex is a new operating model for engineering productivity designed to measure AI where it actually matters at the pull request level.
It connects AI activity to delivery outcomes, not just tool usage.
Apex is built on four pillars with AI leverage, predictability, efficiency, and developer experience.
Apex helps you increase throughput without sacrificing delivery confidence or burning out your team.
Because speed without predictability creates chaos and faster coding often shifts bottlenecks downstream.
If you want to operationalize AI the right way, Linear B and Apex gives you the system and the cadence to do it.
Download the guide and start measuring what matters.