# Agentic Workflows, Citizen Developers, and AI Governance

**Podcast:** Engineering with AI
**Published:** 2026-10-05

## Transcript

Viewers of the podcast may remember Pete Hudson.
He's not related to me.
We have the same last name and it's not a usual last name, but I promise we're not related.
And I think you'll see that during this episode.
Pete has been one of the most popular guests we've had.
He does really, really well on the podcast version of the show and also the YouTube and so on and so forth.
He said some really smart things.
We had him on early, so he maybe got to say some things before other people said them.
You know, one of the benefits of being early.
But yeah, he's also just a great person to talk to about all these things.
So we're having him back for a second showing on the Engineering with AI podcast.
Pete, how have you been?
What have you been doing?
I've been good.
How are you, Kyle?
No relation.
Do I overemphasize that?
No, it's fine.
I think about it.
I think about it every time I have a conversation with you.
I have been good.
I've been good.
I've been busy, but good.
Yeah.
Yeah, new digs, if I remember right.
How is the new thing going?
Yeah, it doesn't feel new, but I guess it is relatively new.
It's probably new since the last time that we did a podcast.
So I'm now the head of technology for agentic tooling at a firm called Tribe.
So Tribe's always been into AI before it was cool, back when it was called machine learning.
services firm and um we work really closely with with the lab so we kind of see ourselves as like an extension of um the applied a for the applied ai folks that like anthropic and google gemini open ai um and uh what i'm doing there is is focused on this thing called uh ai assisted engineering i don't know if you've heard of it uh but kind of relevant to the podcast so i'm helping i'm helping kind of large enterprise organizations roll that stuff out for engineering organizations.
But I think what's actually been super fun for me is also starting to see how people are using the same kind of agentic workflows in non-engineering contexts.
So when I first started there, co-work didn't exist.
But already at that point, I was doing workshops with engineering organizations and talking to them.
about how to, you know, how do you use Claude Code, for example.
Yeah.
The product managers that were in these trainings were like, well, can I use that?
And like, we're like, okay, so here's the terminal.
And do you have Node installed?
And they're like, I don't know what you're saying.
And so we went through this like really painful process for some less technical, like some designers, product managers, project manager, Scrum Master type people.
of getting like them to run flawed code doing these trainings i thought that they were just going to be like it wouldn't wouldn't be worth it for them and they would just be kind of like this is too i don't know what the terminal is right what's happening here what we saw kind of like not intuitive to me was some of the most excited and activated um people coming out of those trainings were the product owners or the tech adjacent kind of what i called them folks who were like whoa, so I can get this to like pull a Jira ticket and then, you know, figure out where the gaps are in the Jira ticket and fill in the thing over here.
So they were like really kind of like getting switched on.
Whoa.
And like on a plane ride back from one of these workshops, I was thinking to myself, you know, someone needs to make like a, like this is great, but like the activation energy to get it installed is brutal.
Someone should make like a GUI.
that's like kind of like Claude Coe, but so, and literally on the plane, like Amphropic announced co-work.
And I was like, huh, I knew I was, I knew I was right.
So I deleted that repo and, but, and yeah.
And so, so, so anyway, very, very long, long winded way of saying what we've seen.
Yeah.
So we've seen more and more of the work that we're doing is actually how do you like enable a lawyer?
to like automate their workflow using using co-work or how do you use like uh like gemini spark to as if you're like a customer success person or a um like someone in accounts receivable or kind of workflows it's just it's actually like super super interesting um fantastic you know most of my most of my time i'm i'm focused more on the sdlc and how do we how do we kind of um accelerate that stuff but um Yeah, it's super interesting to think about the broader picture.
Cool.
So you're reminding me, through the magic of podcast time travel, I have an episode recorded but isn't live yet, so you can't have seen it.
But it will come out before this one.
Rob Zuber, Chief Technology Officer over at CircleCI, right?
Yeah, yeah.
Who, they've got a pretty big perch from which to be watching all this stuff.
Oh, yeah, I bet they do.
And one of the questions I asked him is, like, what are you seeing in terms of, like, because sometimes when I ask guests, it seems like they sort of...
accidentally paused hiring.
Like once they hired on AI, they haven't done much.
And we know in some of the large enterprise class, it's become fashionable to do AI layoffs.
And so there's been a bit of that.
So I was kind of asking him, like, what are you seeing?
Are you seeing like, oh, because there's so many startups, like it's growth overall, or is it shrinking or is it pausing?
He's like, well, he had a similar situation where one of his customers, he went into like a quarterly business review or something.
I don't remember the story and said like, We see that you guys have been hiring lots of developers and they're like, no.
Well, yeah, but no, but all these new usernames and CircleCI.
Oh, yeah, yeah, yeah, yeah.
That's the designer and the product manager.
And everybody is contributing now, right?
Because Claude lets them.
I shouldn't say, shouldn't over focus on anthropic models.
But this new tooling allows them to, right?
So that totally like lines up with what you're seeing.
And it's showing up in the numbers in the large, which is interesting.
Yeah.
Yeah, it's super interesting.
And there's all sorts of like really interesting kind of second order effects from that.
Like a lot of our systems are built assuming it's an engineer who's kind of operating the system and they understand things like database backups and upgrading libraries of things and kind of like...
code review as a thing or like compliance, like, you know, all of these kinds of things that we've somewhat internalized as professional software engineers.
And now you have a salesperson somewhere that threw together this awesome app.
They didn't even know it was an app.
They were like asking, asking their coding agent of choice or whatever to kind of like help them with something.
And it built them this little app and they're like, hey, how do I share this with my team?
And then they end up deploying it somewhere.
And now they're like, There's a product, there's a software product out in the world.
And it has at least some of the same challenges that every software product has of like, it needs to be updated if there's like a security vulnerability.
It needs to have a database backup maybe.
And at least, you know, you need to kind of like have controls over who has access to what things.
And like the salesperson does not even, it's like second order ignorance, right?
It's not like they're like, I don't want to do this stuff.
They're like, I don't know.
Didn't know that it's a thing.
So yeah, I think the term of art that I've heard used is kind of like system developer.
And I think that there's going to be a whole industry around how do we build the internal platform for these system developers?
How do we make it really easy for that salesperson or the partner in finance to pair up with their coding agent?
and kind of fall into the pit of success where like by default, the thing that they deploy is already authenticated.
It kind of like has guardrails around data access.
It has the security updates and stuff happen without the person even knowing about it.
It has a CICD pipeline.
It has a database that's backed up and doesn't randomly use Postgres even though everyone else is using MySQL or whatever.
Like all of these things, I think just like a lot of enterprises just spent the last.
five or 10 years talking about developer platforms.
I think now we're going to start talking about citizen developer platforms and people are already building them, right?
Like I think the further ahead folks are already feeling the pain of like, oh my gosh, we now have these 500 unmaintained mini apps.
Like what are we going to do about it?
Everyone else is walking up towards the same problem, I think.
It's almost like when Microsoft introduced Access or something like that.
And all of a sudden, you know, everyone could.
But Access was so opinionated, right?
Like if you think about it, so my first job actually was like building software with FoxPro.
Shout out to FoxPro fans on the call, which is very similar to Microsoft Access.
But like when you look at it, they were these super opinionated platforms.
There was one way to do things, right?
There was one way to have a dropdown.
There was one database to store things in, access.
There was one kind of deployment pathway.
And that's actually, those constraints, I think, are actually super valuable, particularly for like the sales gal doesn't care if they're using like Next.js or whatever else.
They just like want the thing that's worked.
So I feel like something like Retool, and probably I would guess Retool is probably well aware of this and working on it pretty heavily, but like...
Something like a retool that's extremely agent first, where the agent is building all the primitives, but it's building on top of some very opinionated one way of doing things primitives is the way I, yeah, if I had like, you know, a couple of clones of myself, that's the startup I would be.
Yeah, yeah, yeah.
Well, and shout out Microsoft Access.
We're literally maintaining it right now in my day job.
There is a, we're not even sunseting it.
We are sunseting other things around it, but we are actually leaving that one in place.
It's got a SQL server back in.
I guess that's fine.
Yeah.
Anyhow.
Okay.
So moving on from that, I'm also trying to think about like what might've changed since we last talked.
Right.
And, and maybe a couple of things, you know, I think, you know, token pressure, but, but also Stripe buys open router.
Like what the heck?
Like, of course there's this whole thread about, okay, maybe tokens are the new currency and they're a payment app, but.
I don't think that's what's going on here.
I don't think that.
I mean, I think it kind of, I mean, it's not like all birds turning into an AI company, right?
Fair enough, yes.
I mean, that's a very low bar.
I mean, I think, so I had a similar reaction.
I am not like, you know, like a business strategy VC wannabe kind of like person.
If I squint and look at it, the thing that I do see is like Stripe abstracts away from payment platforms.
right?
Like you just want dollars and you don't care how the dollars are coming and going.
There's certainly every company wants to abstract away the models.
So I think that makes sense.
And I also, what, so yeah, it kind of makes sense, I guess.
I think in terms of like, is this a thing that is needed?
Absolutely.
Like, absolutely.
Very, very, very common thing that I'm hearing out there when I'm, when I'm talking to customers is, a desire to like manage token spend.
Right.
And, and I think what it comes down to a lot of times is the appropriate token for the task at hand.
Yeah.
So, so, well, there's, there's a meta question of like, should we be using AI for this or is it actually like not useful?
Like am I getting a positive ROI on my tokens?
But then I think for a while, people who are building AI powered software, have been talking about, you know, like don't use Fable for like everything.
Like if there's a customer, if there's like a customer query coming in and you want to categorize it of like, is it a, are they asking about changing their booking time or are they asking about kind of like, um, some like, I don't know, like some billing question.
Yeah.
Thank you.
Thank you.
Um, then, you know, that kind of basic classification, you probably want to use a smaller model.
Yeah.
And so there's a whole kind of understanding around that.
for AI-powered products.
I think we're now starting to ask this or trying to do the same things for agentic workflows where like, you know, I'm a coder and I'm coding something up.
Do I need to use Fable 5 for this part?
I'm interested to hear what you've got to say about this.
The way I think about it right now, the natural fit is like, I want to talk to a Fable or an Opus, depending on how big a story it is, depending on how big a feature it is.
Maybe depending on how much research I want to do, right?
I want to talk to one of those two, right?
Like maybe Fable if I need to research, maybe Opus if it's less of that.
But I don't want them to code.
Like I get the sense that they're almost going to get sidetracked in the actual coding world.
I want like a sonnet.
Haiku maybe for very small things, maybe.
And just to use the anthropic terms again, but similar things apply, you know, and I'm looking at building out something on EC2 instances where I'm going to.
you know, rent some H100s.
And, you know, we're looking at using Memo 2.5 as like the, I'm talking to it about the plan and like Quen 3.8 probably as go and execute, you know, which maybe Quen 3.8 is too grand for that.
But I see that as a natural breakdown, right?
And if you're thinking about this, you might be thinking about something more automatic than just like the big one farms out to the small ones via subagents.
Yeah.
Like how do you see this going?
I think today, what you're describing is totally the right approach.
And I think further along than a lot of people are.
I still think, like with many things in AI, we're still actually figuring it out.
And there's these contrarian approaches, which maybe both make sense or maybe different ways of doing things.
I've heard some people talk about like, oh, I use a smart model for routing.
or for the kind of orchestrating and then a dumb model for dumber model for implementing other people like no no no like the orchestration is actually pretty easy i use a dumb model for orchestration and then that that kind of like goes down to a bigger model for planning and then that goes oh i see i mean so so i think there's and there's different ways to do it and you know like uh the first rule of software engineering is as we all know follow your heart so yeah you know if it works for you it works use your evals of like how is your heart feeling I think, yeah, so I think we're figuring it out, but I think something like that is where we are today.
There's a future world where all of this is being done by the harness, right?
So you've got like a classifier that's looking at the size of the problem and saying like, oh, it looks like you're doing some planning.
Let me route that to Fable.
Or I think to get there, we need a lot more maturity around how we break tasks down into different context windows or sub-agents.
Yeah.
I don't know if you want to talk about it.
There needs to be more structure around that so that at the point that you're passing stuff down, you can be picking the model because you only want to pick broad generalizations, but you only really want to pick the model at the start of the context window.
Shifting models mid-context window has a bunch of challenges and cost implications around caching.
I think where we should get to in a context specifically just in terms of writing software is we've got more structure around the harnesses kind of like doing more of this kind of breaking stuff apart.
It's less like us manually doing this.
I imagine in a couple of years we'll be like, remember when you had to like pick?
Yeah.
Like do the planning yourself and like point the agent to an MD file that's going to feel like ridiculously manual.
So I think we push more of that stuff down into the structure of the tools we're using.
Then the structure of those tools can start to say, can kind of start routing.
to different models, all that kind of stuff.
And that's just for building software.
And even for building software, I actually think it's pretty unreasonable to expect every engineer to have internalized all of this stuff.
Eventually, maybe, like, we'll be good at it, but definitely where the industry is today, expecting the average engineer to be like, oh, well, I've found that Opus 5 really has just a compelling way of planning.
But when it comes to implementation, I like the go-to-work attitude of Sonnet.
Do you know what I mean?
Like, it's like all kind of model sommeliers.
And I think the average person just doesn't have time for that, and they're just, like, going to shift it into automatic and just, like, hold down the gas.
And that's just for engineers.
And imagine like the sales person or the finance person.
Forget it.
Yeah.
Yeah.
It'll be largely like whatever you read in the seat back of the airplane kind of decision based.
I don't think it's even going to be that.
It's no one.
People are trying to do their work.
They're not trying to like think about AI.
To be honest.
The other thing it reminds me of is like there was the year that I decided to like pick my own stocks, you know, instead of.
Yes.
And for like a year, it was like, okay, I'm actually all right at this.
But then at some point it was like, oh, yeah, yeah, yeah.
I don't want to look at that this week.
I mean, if you want it to be as a hobby, sure.
But I could only go for a while.
I couldn't go forever.
And I don't think any of us want to go forever.
Yeah.
Except for those specialists who that's all they're going to do.
Yeah.
Or they enjoy it and they like nerding out with their friends about, you know, like the nuances of 4.8 versus 4.7.
And, oh, do you remember when it used to do that?
Yeah.
Yeah.
Or when I was first buying an electric vehicle, I could tell you like the exact range of the Tesla Model 3 versus the Ioniq 5.
I can't anymore.
Like, that's too much to keep up with.
Like, it's valid for a little while.
That interest is enough to keep up with for a little while, but not forever.
But this is also kind of bumping up against like the whole, you know, tokenpocalypse.
And I think you were calling it, you know, this, this.
We've all kind of gone from, you know.
Jensen says we should spend as many tokens as possible.
The guy who owns the donut factory is saying that all his engineers love eating donuts.
Shocking.
Yeah.
Yeah.
And so I think that's been this really interesting trajectory, right?
Because so for engineering, we speed run through.
If I cast my mind back 12 months, maybe, we were in the heart, I think, of a debate of like, does this actually work?
Like, is it worth?
like can it can ai actually write code like in a meaningful way fast forward to like you know december of last year everyone kind of came back from christmas like oh crap it can't and you know not everyone because some people were like dude i'm saying this was six months come on well and now they're still saying like you know yeah do you know how many bottles of water it takes every time you search gemini okay sure sure but for a lot of us did so for coding i think the conversation went from How do we justify that this works to, holy crap, this works, we've got to get everyone up to speed.
And I think now we're getting to a point of like, okay, I know it works, but do I really want to give a budget of 10 grand a month to every single engineer?
Like at some point, particularly outside of Silicon Valley, outside of software companies, if you're at an insurance company and you're the CIO, you do need to have a conversation with a CFO to justify the spend, right?
And you need to be able to tie it back to metrics and to return on investment.
And that's for engineering, where I think it would be really, really hard to argue at this point that it doesn't work.
Like, does it work?
But go to another part of the organization where people are starting to use these agentic workflows.
And A, it's way harder to measure ROI in general or measure kind of like productivity or value of...
an employee or something in general compared to something like software engineering where we are actually pretty objective.
We do actually have some pretty good objective measures around kind of cycle time and story points and all that kind of stuff, right?
So that's one thing.
And the other thing is it's actually not as clear that it actually really is super strong ROI in all cases.
And we're still early days of figuring out where does AI work, where does it not work, where is it no breakthrough, et cetera.
So, so yeah, I think there's a lot, a lot like very, very common conversation I'm having with clients at the moment.
Very, very, very, very common is like this conversation around ROI.
And I think the other thing that's happening is the models are getting better.
And so if you think about like the surface area of like, like the, the, the frontier, right.
Is like the, like where the model can, can do stuff.
And over time, that frontier is being pushed out.
So stuff where six months ago, you would have been using a frontier model to do it.
It's now like totally possible using a non-frontier model.
Open weights, yeah.
Yeah, so we start having a really serious conversation around like big chunks of coding, coding, not software development, not the whole thing.
I think that's very different, but like the actual like coding, like implement this feature are now solvable.
like you said, like with a sonnet, right, or something like that.
And so the cost is really different.
And when I look at organizations that are spending like 10 grand a month, where you've got engineers spending 10 grand a month, when you look at how they're using those models, I think they do tend to just be using Fable for everything, which is maybe is a strategy.
But like if you go to an insurance company with 10,000 engineers and you say, hey, that each of those engineers wants to spend 10 grand a month on tokens, that's not that.
You would literally be laughed out of the room.
Right, right, right.
It's one thing to say, you know, developers are working on something which is already on a CapEx budget, you know, and just calling this part of that CapEx budget.
That's one thing.
But yeah, if it's like a knowledge worker who, you know, reports to a director, it starts to look like maybe, I guess, if you're a cost center, probably not.
But, okay, this economics question I think is weirdly interesting right now.
I'm not normally into this kind of question, but I am right now.
So on some level, right, if you, and pick your brand, there's probably, you know, for me, it's Anthropic and the 20X Max Claude Code plan.
I can't, okay, I can't go past the limits of that.
Like, that's enough for me is what I'm trying to say.
You know, and that has a certain price.
I'm pretty sure if I summed up the amount of tokens that I was using, per day and like figured out what it would cost on the anthropic api it would be a lot more maybe not the 10k a month yeah it's a lot but four or five yeah it's it's way they are subsidizing the heck out of that thing correct on some level like i can see why like i can see different reasons to want to get out of that one might be like okay You know, if they start to take that for granted, you know, we might be stuck.
And if they raise that to 400 a month and all of a sudden their anthropic bill doubles, like we want options.
I can see that kind of thinking.
But why would – and for the enterprise where, like you said, we are using an agent to route.
You know, this incoming request, this one goes to the billing department, that one goes to the rebooking department.
That is not a developer.
So that can't be attributable to, like, a subscription.
So I get that.
But who's spending 10K a month on a developer?
Like, why would you do that?
They're all, they're being pushed very hard towards, in enterprises, you don't get to do max plans.
You're paying per token.
They're all being pushed.
Because Anthropic would like you to pay per token.
I don't know.
I mean, like, that's, Anthropic is one example, but I can't tell you.
So they're hitting their limits or something?
Must be.
I can't tell you.
I don't know.
Right.
I don't know the specifics of it, but my understanding is that either it's literally not an option.
If you've got an enterprise plan with Anthropic, you're going to be upgraded whether you want to or not.
There's very compelling reasons for you to upgrade.
That's interesting.
And what can I say about that?
Personally, I use a personal one-person max plan.
I'm aware of a team where it is what they're calling the team, not enterprise, but team.
Yeah, the team plan, yeah.
And that appears to be just a whole bunch of personal subscriptions, but I can't see the billing control panel behind it.
So I'll be honest, the world in which I live, where I'm talking to folks, larger enterprises it's just a hundred percent the enterprise and and there's a bunch of stuff interesting there's a bunch of stuff you get so the interesting thing is um wherever you're going there's also the fact that if you're um a in any kind of regulated industry you're wanting to go to you're probably wanting to to do your inference in your own uh kind of bbc so you're wanting to use like Bedrock or Foundry or Vertex.
I think they renamed Vertex.
For both kind of like...
That I get.
...reasons, it's also easier for me.
I'm in GovCloud.
I have to run it all in GovCloud.
Exactly.
I get that.
Zero data retention.
I don't want Anthropic ever seeing my tokens because they have customer data and it's a lot easier.
They just never leave my estate.
I, a large number of, I think probably the majority of larger companies that I talk to, they're, they're doing that.
And so if you're doing that, then you're, you're paying per token because you're paying AWS.
Yeah, yeah, yeah.
Yeah, of course.
You know, you're paying Google or you're paying.
Yeah.
Well, and, and maybe, who knows, maybe Anthropoc managers have for you, but they can't, they can't just sort of like distribute the cost across their entire pool.
So you're now in your own pool.
So yeah, you're going to be paying a different rate.
Interesting.
Okay, thank you.
That's helpful.
Hmm.
Yeah, the economics are weird.
We're looking at OpenRouter2.
I know some teams which are doing that, which we already talked about.
And there's also other, you know, besides the kind of like the literal routing of tokens, there's some real benefits of having an inference gateway and being able to get observability, like really good granular observability on...
on what your tokens are being used for.
If you're in a regulated industry, you can also do kind of like data exfiltration detection.
You can do a kind of SIEM things.
So I think that's going to become more and more common is having your in-house inference gateway sitting in front.
And this is one of those kind of things where like certain tech companies have been blazing the trail on this for years, months or years, like I think Shopify.
we're talking about having an inference gateway in front of all of their developer inference for like at least a year, I think.
So I think that's going to become more common.
Either you do it yourself or you buy a product.
That kind of gives you that control, that kind of choke point where you can put governance in place, right?
Because governance is a thing.
And so if you've got a choke point where you can do governance, then that's very useful.
Interesting.
Interesting.
What else are you hearing?
Getting into the new role and meeting new customers and things like that?
What else is coming up for you?
So the governance thing is a big thing.
A lot of conversations around how do we, like we're seeing the lift in engineers, in implementation, we can write a bunch more code.
How do we make this work with, how do we, like, but we're also seeing huge bottlenecks upstream and downstream.
How do we fix that?
Like we're getting a 10x boost in coding output.
coding output lines of code or whatever but it's all being dissipated by either slamming into the wall up downstream or um we're kind of we've we're kind of pulling stories faster and the stories can be created upstream so they're all like interesting interesting things but yeah the the number one that actually number one thing recently is that that governance that governance piece it kind of goes back to the thing that i was saying at the beginning of the conversation around kind of non-technical users starting to use things like ChatGPT for work or co-work, those kind of class of tools for serious work.
And the organizations are trying to figure out how do we empower that, but with kind of controls in place so that people can do stuff.
And I think it's a similar kind of...
story to a lot of other things in large companies where you really want to kind of, you've got these required, you need to meet these kind of expectations around kind of governance and control and making sure people aren't doing bad things and encouraging people to do the right things, but you don't want to just totally stifle innovation.
You want to kind of empower grassroots.
grassroots stuff so i mean it's it's a really it's a really interesting challenge i mean it comes down to to put it in much more concrete concrete terms everyone is either struggling with or is about to struggle with kind of skill sprawl um when you've got 10 different teams have all written their own skill that reads a jira ticket and turns it into a whatever like kind of take one example or a jira or a skill that like accesses our our pre-production environment and pulls observability data right and so you've got these thousands of flowers blooming everywhere but there's a lot of kind of downsides to that in terms of just people people are reinventing the wheel right people aren't able to discover things that are there in other teams that they could be using yeah and and there's too much of this stuff to get controls around yeah yeah and so those kind of folks were tasked with managing and controlling and kind of governing are like overwhelmed.
Yeah.
I'm thinking back to in the consulting days, this is maybe 2018, something like that, 2017 maybe.
And it was sort of that time where, okay, this team is using Chef and that team is using Puppet and this team is using a bunch of Bash and that team is, you know, put together their own thing and that one's on Terraform and this one is on Rancher.
And it's like, oh, that orchestrator is like, wait, that's different.
And this one's on like their own little Kubernetes that they kind of hand built themselves.
And yeah.
And at some point it was like, wait a minute, enough.
And like we said that Polyglot is good.
Polyglot developer, Polyglot database.
Like, yes.
And there is a certain point at which it's like, slow down.
We don't all need to be thinking about how to build and deploy software all of the time.
Like, and out of that, we get the platform team, you know, and delivery infrastructure platform starts to start to say, like, I don't care how it works.
Just give me a YAML file where I put in there what I'm looking for and somebody else makes it happen.
We're not there yet, I don't think.
But maybe to your point, like maybe we're getting there.
We're getting there.
So what I'm seeing, almost everyone realizing they need to build or starting to build is like an agentic marketplace.
I don't think we have a shared term for this, but like a skills marketplace and an agent marketplace, whatever, like some centralized place where you can kind of do those two things, right?
Of like empower people to build and share things, but then also put kind of governance and a promotion pathway in place.
And it's like, so what's driving it is really interesting because I think what, if you're at a big company, particularly if you're at like a large established company, If you think about like, what is your competitive advantage as a large company?
It's not moving fast, right?
Like you're getting lapped by startups in terms of just like being able to move fast.
But you have like these true, really competitive and institutional advantages around data, like the knowledge and data that's in your systems and institutional expertise, right?
So you've got these two big advantages.
And if you want to take advantage of those, in the context of like an agentic workflow, you need your agent to be able to access the right data, pull in the right context into its context window.
It's like the thing that you just end up constantly thinking about if you think about AI is context windows and how do I get good stuff but only the good stuff into that context window?
And how do I insert judgment, taste, et cetera, into that agent's kind of workflow?
So how do I get...
that human expertise and that human understanding of like at company XYZ, here's how we do KYC.
Like here's how, here's the standard operating procedure for blah, right?
And so if you want to kind of roll out AI across your organization, you have a bazillion places where you need to figure out how do I get the knowledge into the agent's context window?
How do I do the connectors, right?
The MCPs to simplify it.
And how do I write the skills that codify the way this team works?
Not the way we think the team works or the way the wiki says the team works, but the way the actual team works, right?
And so one way of doing this is you build some central team and you send them to all of those 10,000 places with clipboards and they do it one at a time and it's only going to take 10 to 15 years and eventually you'll get it done, right?
Probably.
Or no one's going to do that.
Yeah, no one's going to do that.
People are trying.
And maybe for the real core parts of your system, you do do that, right?
Because there's also this kind of graduation of you start by building something in co-work and then eventually you pull it up into a true custom-agentic system.
And once you're doing that, you don't want your accountant to be kind of doing the prompt engineering there.
But for that grassroots stuff, the key is the grassroots thing, right?
You empower all of these teams.
ability to connect to the systems they need to connect to, to write these skills.
And that's how you get this long tail of productivity lift.
If you think about all of the places in your organization where energetic workflow can help, there's a bunch of places where it can give you a 5% lift.
And the area under the curve there, I think, is actually way more.
than like going into the two strategic use cases and fully automating that with like a crack team of FDEs who are going to, you know, knock it out of the park.
So then the question is, how do we empower that grassroots work?
And that's why governance is important because you need to give those people on the ground the ability to try out and experiment with the right connectors in a safe way.
to write skills and share them amongst themselves without this huge kind of barrier to entry, but without them accidentally publishing something that kind of does like a injection attack or whatever.
So like, so when I think about like governance in general, I mean, governance has, I think I've been pickled because I don't feel like governance is a dirty word anymore.
I used to like roll my eyes when people talk about governance, but like what it is really is about empowering that grassroots.
innovation.
And so that's why everyone's building these systems because without them, in a regulated environment, what you end up doing is you end up saying you cannot install anything.
Like MCP, we know that MCP connectors are bad.
Sorry, let me state the whole thing out.
We know that some MCP servers are risky.
We don't have a way of controlling which MCP servers you're using.
Therefore, no one can use any MCP servers.
And there's literally like a large company I work with where that's the current policy for all of the engineers because they haven't got the controls in place.
If they can put the controls in place where they can say with auditable confidence, it is not possible.
Like engineers can only install these approved MCPs.
Now you can start approving MCPs and like that subset of MCPs can start to grow.
And if you also build.
a promotion pathway where an engineer can experiment safely on certain things using an MCP or an engineer can write their own skill and publish it to be shared just inside of their team.
Then they can start doing that.
And then you've got like this central place where you can start saying like, oh, look at this.
This skill is like really well used by many engineers or this skill.
We audited this team and they told us this skill was the one that you could pry from their dead hands.
They absolutely love it.
Let's find those five things, focus our firepower on making those really strong, promoting them across the organization, et cetera, et cetera.
But you need the kind of like the platform in place.
You need that kind of governance system in place in order to do it.
That's interesting.
Listeners might remember I've talked about how one of the teams that I serve built this tool around GitHub Sneak, right?
The vulnerability detection.
And what it would do is it would go and see like, okay, sneakers reported the following five things and it would like try to fix it.
And then it would run their E2E test suite.
And which that was kind of one of the cool values is their E2E test suite was always too flaky before.
But this one would fix the E2E suite before it would do that.
Anyway, so it's kind of two birds.
Anyway, point being, this team got it to the point where they just had this thing kind of going in the background.
And it still shoes up a fair amount of their time.
But before...
It was chewing up a lot of their time and they were falling behind.
And now they're like actually getting ahead of it.
You know, they're actually hitting their stride.
And then, but they tried to like advocate for another team using it.
And the other team just built another one on some level because it's so easy, right?
Yeah, yeah.
Yeah, and that's the challenge.
Is that wrong?
I mean, maybe not entirely.
Like, both teams are moving forward.
And the idea of virus was helpful.
And I think at some point we might need to decide, like, oh, how do we make one that can handle most of our teams?
Maybe not the Kotlin team, but all the TypeScript teams, for instance.
Maybe we should.
But it seems not quite there yet.
There's only the two right now.
Yeah, I mean, I think it's kind of like software engineering, kind of the rule of three kind of thing of like...
Don't generalize.
Don't rush to generalization.
Build it a few times.
Figure out what are the hotspots that are different.
What are the common things?
And then generalize.
And also, you know, like, I think, like, really much, and this is leaping to a different analogy maybe, but, like, I think really good kind of architectures involve embracing kind of bounded contexts and kind of, like, different domains, right?
Like just because you have the definition of a user in your billing system, you don't have to make sure that it's fully generalized so the user in your billing system is also the user in your marketing platform, right?
Like does this engineers love to build the one true generalization?
And there's going to be this strong...
Yeah, it doesn't...
Your identity team is going to have one idea of what a user is, right?
And then the actual app team is going to have a very different idea of what the user is.
Yeah.
And you can, you know, I mean, like just throughout my career, I've always seen this like super interesting, comes down to kind of like culture of teams, right?
Where like some organizations love to empower like as much autonomy as possible.
And they eat the cost of like multiple people doing the same, multiple teams doing the same thing.
And it works.
Some organizations love.
kind of hierarchy and like the one true way of doing things and they make it work for them.
And it's not that that one is better than the other.
As with all things, the extremes kind of generally suck and somewhere in the middle is probably where you want to be.
But yeah, and I think it's the same thing with governance of skills, same thing with like, do we have the one true way?
Like, do we send all of our traffic through the same inference gateway?
It's probably another version of just the same question.
Very cool.
Another thing that's coming up for me, Tiet, one of the, another interview that I've already got waiting that's also not been released yet.
Our guest, Ian Johnson, who's writing a book on LeanPub about harness engineering, he talked about how his team is already doing like software factory.
And I stopped and thought and like, Have I ever had a guest say they're doing that?
And I think of folks like Tim Cochran talking about his NITS pipeline, where if he has an idea for like, oh, there's a small annoyance here, he'll just go like, and an agent will just chew on it.
And so maybe he was, but we weren't calling it that, right?
And then I've had other guests like Hari, who is working on like the OpenSpec framework to be able to do like spec-driven development.
And he's very interested in factory.
But he talked about it as like, oh, no, we're not doing it yet.
But then this other guest, Ian, is just like, oh, of course we're doing it.
And I'm like, wait a minute.
I'm not.
Like, how?
Are you seeing that out in the wild?
Are you seeing a lot of?
For sure.
Yeah?
For sure.
And it's like the classic, you know, the semantic diffusion, the term that Martin Fowler coined of like people are using different words for the same thing or the same word for different things.
So this software factory term, like the.
There's a lot of messy overlapping concepts.
So there's harness engineering, there's software factories or dark software factories, and there's kind of like spec-driven development, and they're all kind of swirling around the same space.
Absolutely, lots of people are trying to figure out how to give bigger and bigger chunks of work to an agent.
Another way of thinking about it is we're just trying to figure out how we can pull ourselves further and further out.
of the loop right and we're building new loops to to partly as a way of kind of controlling our agents but also as a way having points that we can pull ourselves ourselves out of right so we've if you think about like what is a coding agent part of what a coding agent is a coding agent harness whatever is a new loop an agentic loop which is i don't say it's not a back and forth chat between me and an lm it's right a goal that I give to the ALM, and then it churns and churns, makes tool calls, does things totally outside of human control or inside of this inner loop, and then comes back to me and says, boop, I'm done, right?
So that's this new loop that we've had for a while.
I think anyone who's used a coding agent more than a few times sees that new loop.
I see these kind of like things like spectrum development, software factories, as we're building a loop outside of a loop further out, where you're giving like a larger chunk of of tasks and like you know this is why people also talk about loop engineering i think it's another overlapping term um what we're doing is we're trying to figure out how can we for certain things pull ourselves out of the loop one level up and just give a ticket or a spec yeah yeah yeah and i and i think what and not run a terminal at all and not like not yeah correct correct and and and um I think it's super interesting.
It's such a cool time to be just seeing all the stuff.
Like the amount of like innovation and different ways of doing things is just like, I love it.
It's also just really, really hard to keep on top of and keep track of it.
And I want to say like to people who are feeling stressed out about it, don't worry.
Like it's fine.
You don't need to keep up with all this crap.
Like just basically like.
It is a perfectly acceptable strategy to just do whatever everyone was talking about six months ago and now they finally agreed that, oh yeah, that was dumb, this is not dumb.
You're not going to be a member of the permanent underclass if you don't figure out what loop engineering is in the next two days.
There's a lot of noise and swell, but if you're into it, it's super interesting.
I think like one of the things I haven't, I haven't listened to the, uh, the Tim Cochran conversation, but, um, several different versions of that I've been hearing a lot of recently is this kind of idea of like, um, so, uh, Dex Horvey, who's a great person to follow for this kind of stuff talks about this as the slow loop, but certain finding like, like kind of tech debt type work or like knits or.
incremental improvements, keeping the campground a little cleaner, your codebase evergreen type work, and having that just kind of gradually going in the background.
That type of work lends itself to less human in the loop.
Untended.
Yeah.
Because the problem space is easy to specify.
Yep.
And the solution space is easy to specify.
And it's easy to verify, right?
The agent knows.
If the agent thinks that it got into the solution space, they're probably right.
Versus, you know, me filing a ticket with an agent and saying, implement a to-do app, make no mistakes.
The solution space, right?
And then just like give it to the dark software factory and it poops out.
The solution space is...
huge yeah be a mobile app could be a voice app the the radius on the to-do app like button could be five pixels or six pixels right there's like this huge unspecified solution space and so what we experience as engineers is like i didn't want you to do it that way uh you we specified the solution space was so large that the agent went to a part of that space that we didn't want it to go to but these nits these right It's a smaller space.
Upgrade the library, right?
Upgrade the library is a really good example of like, does it still compile?
Do all the tests and et cetera still pass?
Then it's probably fine, right?
And it's not like, oh, I didn't mean upgrade the library to this version, to that version.
It's not hard to specify.
Right, right, right, right.
And so I think that's, I think, a much more interesting place where everyone should be going, building that kind of software.
But if you're super AI-peeled, then you're building these dark software factories where you're saying, I'm just going to specify the feature I want to build, and I don't even need to be an engineer.
The CEO can just specify the feature, throw it over the wall to the dark factory, and now the other side is going to poop the feature in production.
That's the most extreme example of this, right?
And I just don't think that works.
I don't think it works for the same reason that those of us who lived through the kind of outsourcing era, There was a period in time where people thought that a business owner or like a business analyst or something could write a detailed spec and throw it over the wall to a team somewhere and have them come back with finished software.
The people that had the worst experience with that were the people that thought that you could build a really detailed spec and not talk to the people while they were building it.
and then iterate on it once it came back.
That is basically what we're re-implementing with these dark software factories.
People that have success with those outsourced teams, if they can, they at least are getting on the phone with them every day, right?
And having some kind of feedback loop.
The human is in the loop, right?
In this case, it's not human, but you've got this feedback loop.
You've got this in modern parlance, you've got back pressure, which is just a fancy way of saying a feedback loop.
You've got this feedback loop where you can steer and course correct as the agent is, or agents are solving their problems.
Specifically, I like the product level, right?
I think you're bang on.
And part of what we lost in that outsourcing era was not just that, you know, that that's like a bad plan, but...
But the other reason that it was a bad plan is that any learning that would get built up would be sort of bifurcated, you know, like the remote team might actually get better at understanding parts of their business than you do.
Yeah, you get these weird situations where this team actually, like, knows your customer pretty well, which is way better than, you know, the current state of the art with agents is, like, you know, every...
every few hours, like everyone on that team is disappearing and a new team is being hired in and like starting from scratch, right?
And like, just make sure the document, make sure the onboarding docs are really good, right?
That's our current way of solving this.
And maybe we'll make part of our team constantly updating the onboarding docs so that when a new person arrives, they'll be onboarded really well, right?
That's basically like, that's actually what we're doing.
And it kind of works, but it's kind of wild.
It kind of works, but yeah, so.
But that's also part of why I prefer the interactive.
Like earlier today, I found myself like in Google Docs writing stories and with acceptance criteria.
And I'm like, why am I doing this?
And I realize because I don't normally.
Normally, I'll sit down with Claude and like prose, you know, like paragraphs.
especially if it's a problem that I haven't fully thought through.
Like I'm thinking as I'm typing, I'm fixing my typing before I hit enter.
And I want Claude to come back and say like, what about this?
What about that?
What about this other thing?
And like, we get to a better place together.
But with this one, I'm like, nope, I know what I need.
So I just went into Google Drive and just like, given when then, you know, as I would like.
So that's, and I'm like, I'm just going to paste all of these like one by one.
And as soon as it finishes, or I'm going to say like, hey, here's five things.
Go start five agents and please just go do them.
It would be perfect for Gastown.
Maybe I should turn Gastown back on.
Anyway, like in every now and again, work is like that.
Right.
But not usually.
Right.
Like normally there's some element of the unknown and you want to be part of the learning.
You need to be part of the learning.
And so when Ian talked about how they are doing factories on the economic side, I asked like, how are you?
doing this and not having it cost a million dollars, apparently Anthropic Agent SDK, right, means that it's basically coming out of the developer's subscription anyway, which, magic.
But the other thing is they're not handing it, like, stuff that is like, let's build a whole new feature.
They're handing it, like, here's a bug fix, you know, library upgrades, like you're saying.
The solution space is constrained, right?
Yeah, exactly.
The problem is very well defined.
Yeah.
So that there's only really a few different ways of doing it.
And when you do that, like, A, it's going to land in that.
that solution space easier and b it's not going to have to churn and churn and churn and think about things and also like those types of problems are things where already today agents ai lms are actually better than most humans like there's a ton of stuff that where yeah like i feel a lot of job security but debugging like some weird issue like figuring out what's the root cause for some weird bug agents are amazing at that kind of or like upgrading a library An agent is going to do that better than me.
There's no world I'm going back to where like...
It's power tools, right?
I mean, when we had a screwdriver like this, I could do so much drywall per hour.
When I have a screwdriver, I can do it like that.
I can do more drywall per hour, you know?
And this is higher level than that.
But it's still, it's kind of the same old tools, but much faster in a way.
Yeah, very much.
Yeah, and there's still this real skill in knowing...
how to use, like when to use those tools, what purpose to use them for.
Yeah, how, when, where.
Yeah, like don't do the ceiling before the wall when you're drywalling or probably, I know there's probably, I'm like, not a drywall person.
If I was an LLM, I would just do it whenever, but if I actually knew what I was talking about, I would probably like, you know, I watch YouTube videos about construction and it turns out that there's a bunch of tips there that you don't know unless you've been doing it for a while.
Yep.
Anytime I've got to replace like a kitchen faucet, I'm doing the same.
But to your point, like that does not make me a 20-year plumber in any way, shape or form.
And similarly, I think we are still, I think at the moment anyway, we're still helpful.
Yeah, I'm confident.
I'm a weird contrarian.
I am confident.
I'm confident that we're going to stay relevant.
I mean, it comes down to verifiable domains, right?
So software.
Writing code at a low level is an extremely verifiable domain.
That is why these models, when they started doing reinforcement learning from verifiable rewards maybe a year ago, we suddenly got this huge boost in the ability of agents to code because it's a verifiable thing.
Does it compile or does it not?
Do the unit tests pass?
Do they not?
Once you get into the realm of like, is this code maintainable over time?
that's not as verifiable.
Is this architecture going to work for future changes?
Literally, the only way you verify that is you make a bunch of changes and then you look back at the architecture and say, was that a good idea?
And that feedback loop, that verification loop is much more ambiguous, much more expensive to run.
And so if you want to do millions and millions of simulated runs and verify, was this good design?
That's kind of what you've got to do.
if you want to get kind of maintainable software.
I think when you look at a lot of the improvements that we've had in the last year or so with LLMs in general, a lot of it comes down to that verifiable rewards thing.
It's also why I think they've gotten worse at writing, like where if you have certain models, it's like...
That's a load-bearing statement.
Well, the blast radius of that does not.
Yeah, exactly.
Right.
Yeah.
Like, like, you know, I carried through the gates for the, but it's like this whole new language, right?
And it's what actually matters.
Okay.
You're right to push back on that, Kyle.
Yeah.
All of, all of these things.
Right.
And it's because of, um, It's because of the post-training.
Like, I'm pretty sure I'm not a machine learning person.
I'm pretty sure it's because they're just putting so much pressure on the connection between the neurons to fit into this particular shape for post-training.
And we're creating, like, I kind of, like, it's a...
very stretched analogy but it kind of feels like we're creating like neurodivergent like models that have like a very idiosyncratic way of talking they're really really good at solving certain problems but they're also they they think about things in a very idiosyncratic way right so i think it's it's there's a real constraint there and there's a just a huge constraint around in uh it's like in not in context learning um it's called the right word but like like uh continuous learning so yeah agent learning on the job um if you think about like like where are we today we're at the point where a model can do a problem that takes 16 hours or like i think like uh i can't remember it's babel or mythos is part of saturated the meter benchmark of like it can do 16 hours of continuous work and get it right 50 of the time If you think about like most humans, we expect them to be working on things that are going to take at least multiple months, if not years.
When I'm building software, if I said to my boss, like I'm 50% confident this is going to work in a month, they would not be super stoked, right?
And for humans, we don't think about the fact that we're constantly learning.
And we don't think about the fact that we're building things and like building up context.
for the right things in our memory as we go.
If you think about it in that way, we're on like one long running task.
Like I'm on like a 25 year old task of getting good at software engineering and I've been learning along the way.
And so if you like, we want agents to be as, it's a, yeah, I don't know.
Like I kind of feel like, like if you can't have the ALMs learn as they go, then they need to be, then you have to say like they could do this entire task kind of one shot.
Right.
And that's a long task, you know?
Yeah.
Yeah, yeah, yeah.
For sure.
And it's funny, you mentioned the sort of Opus 5 voice and I started to pay attention to it.
And like, yeah, at least mine, like I wonder if all of ours are slightly different, but mine seems to be like anytime it'll do a bunch of stuff and it's gotten quieter, you know, it used to sort of like dump out a lot of logs and a lot of like what it was thinking about.
And it seems to be doing a little bit less of that.
Are you using concise output mode?
I don't know.
It might be what's changed.
At the end, it'll try to summarize what it did.
And its summary sentences are so terse that it's like they're nearly meaningless.
And I'm often having to stop and say, like, okay, you said this.
Do you mean that?
I'm doing that all the time, right?
So maybe I did turn this thing on.
They're speaking, to some level, they're speaking LLMEs, right?
They're speaking in a language that they understand.
Again, because of this reinforcement learning.
We are starting more and more in programming at least to do the thing you were talking about earlier of Opus plans then hands the task down to another agent to implement.
If like we're doing reinforcement learning, we, the labs are doing reinforcement learning on is this system working good for this setup?
And so they're starting to form.
a kind of, you know, this is spooky kind of into the sci-fi kind of realm, they're starting to form their own kind of very succinct language that other models can understand.
And they're being rewarded for that, right?
Because if you can succinctly describe the task to another agent, the humans, like we're not reading.
we're reading like it's not just like we're not reading the code all the time so we're not reading the instructions yeah exactly i'm skimming them yeah yeah if i read them at all and i think now we've hit this really awkward point where i wonder if the wheel's going to come off we've hit this awkward point where we can't read the plans like certain models i can't i like i can't hold this in my head i'm like it's not like I can literally read the words, but it's like when you're reading a really badly written novel or something, you just stop reading after a while.
That's what it feels like.
I wonder what the next step of this is going to be.
Because of all the stuff I was talking about, about when to use a software factory and not to, I don't think the solution is just going to be like, take our hands off the wheel.
No.
Just not look at it.
For certain problems, yes.
For other problems, no.
And so we need some way of being able to talk to these models when we do need to talk to them, but not have them, but have them also be able to kind of orchestrate between themselves.
Right.
It's like you were saying before, it's not never to use factories or always use factories.
It's when to use factories.
I mean, and I think more, I think what I think ideally we'll get to is a place where we can just turn the dial for every single task as to where we need to be in the loop.
and where we don't need to be in there.
And I don't think it's...
And we'll be surprised from time to time, but yeah.
Yeah, but that's a bit of being able to dynamically do that, right?
Just like a manager that's handing a task off to a team and they're keeping an eye on the team and they're kind of like deciding how much they want to kind of put their hand on the wheel based on what they're seeing the team doing.
And if the team has clearly got it, they're just, the manager's going to wander off and do whatever it is managers do.
ice cream, I assume, or something like that.
Certainly.
But if that's what they're doing in those conference rooms, they've all got like freezers underneath the tables.
They're reading through the Rob report about which yacht they're going to buy.
Yeah, exactly.
Exactly.
Exactly.
All these high-flying middle managers.
But if they're not like, if you're not seeing...
If you're seeing things go a little bit sideways, then you want to kind of put yourself into loop more and like have a daily check-in with the team rather than a weekly check-in or whatever.
I think that's kind of like level we're going to get to ideally with these software factories.
And I definitely, I think we might finally, the two things I think we might finally get to after my whole career, us talking about doing it.
One.
like moving away from text-based IDEs, maybe.
Maybe we'll stop using the terminal.
Even as everyone else learns how to use the terminal, the engineers are going to be like, oh, see you guys.
The terminal?
We were just kidding.
Green text on a black background?
Oh, so last year.
Okay, well, welcome.
Yeah, yeah, yeah.
Maybe we'll get away from that.
And maybe we'll finally get to cloud-based developer environments.
Right.
Where I don't have to literally walk around with my laptop cracked open because the compute is happening on my laptop.
Like what?
Like, I swear.
Hold on.
Let me turn on the Wi-Fi hotspot on my phone.
It's like it's walk out to the car with the laptop.
The start of my career.
people had like servers underneath their desks that were running parts of production, right?
Like you'd have literally like the email server for the office was like underneath IT.
We're back.
Later it was a build machine, right?
Yeah, yeah, yeah, yeah, yeah.
I hadn't thought of that, but that is actually the perfect analogy, right?
It used to be the build machine was like underneath the build engineer's desk.
Eventually, and it took a long time.
Eventually we got to the point that almost everyone is now running.
these things in the cloud.
And a lot of them, we're not even thinking about the machines they're running at all.
They're running GitHub Actions or CircleCI or whatever.
Is it a machine?
I don't know.
We still haven't managed to get there for dev environments.
Yeah, that's right.
We've been trying for a long time.
Did you know the first iteration of Heroku was a cloud-based IDE for Rails development?
No.
I did not know that.
They were into it way before it was cool, and then they pivoted to being a platform service.
But yeah, their original thing was like a cloud-based IDE.
It was very purple.
And yeah, so we've been trying to do this for a really long time.
But that's the big constraint now for most engineers, or for most engineering teams.
The biggest constraint of them getting to a software factory is running the thing.
Interesting.
Running a development environment reliable.
So one of the last things I worked with Claude on was actually a bunch of, you know, sort of network management and Kubernetes stuff, which I'm, as you may know, not expert in.
Like I was a pretty good Unix system bin way back in the day.
So I know the concepts, but do I know like which Cider Group's object in Kubernetes is the best one?
No, no, I do not.
Like I was barely aware that it had such a thing.
And I'm sitting there orchestrating and I've got this old, you know, Intel MacBook Air over here and I've got it as a syncing into that.
And I've got a VMware or not VMware, but UTM or whatever.
Some another Linux VM on the desktop.
And I've got a Raspberry Pi that it's as a syncing into.
And it's literally controlling all of them, like setting up this big cluster.
It was great, you know, for being able to figure out, like, is it going to be able to, because it was some game of, like, if you touch this port, then you should be allowed to see that API.
Yeah, yeah, yeah.
I mean, I guess I could have done that in a GitHub action, but that's also not a common use case.
Like, if it's, like, let's add a text field to the web page, then no, you don't need all that stuff.
Yeah, I mean, but the thing is, you kind of, like, you shouldn't, but...
For most codebases out there, I would guess, you know, I would bet like 70% of codebases out there, you can't just drop them into a Docker container and run.
Oh, 100%.
Yeah, and run like the end-to-end test.
Like the kind of like the normal, like the gate for me, the load bearing thing for me is can you run the end-to-end test suite from just a clean Git checkout in a container?
That's normally not possible.
And then the next one, the next one level up from that is like, can you run the end-to-end tests like somewhere, somehow, without there being some special thing?
And can you do like multiple ones at the same time?
Yeah.
That's where it falls down.
Like a lot of developers are running into this.
And the reason I think we're finally going to get there is because a lot of developers are now running into the future.
Because, yeah, there are work trees.
And there's like the multiple...
Work tree solves the hard drive problem, but not the network port problem.
Exactly right.
And so there's multiple YC companies trying to solve this problem that we've been trying to solve for a really long time of basically like, how do I not have...
my development environment need to be physically kind of like a one-to-one with me as a human.
So I'm hoping we'll get there because it's been a pet peeve of mine for literally decades that like it's just, or at least a decade, that like I have to like have stuff on my machine and not be able to take it to another machine or not be able to run two versions of the thing side by side.
Like it's silly.
It's silly when you think about it.
Maybe in the end, Worktrees will be like vagrant.
It's like, it's pretty good, but just go to Docker, y'all.
Just build it in a container.
Yeah.
Oh, for sure.
Worktrees is a horrific workaround.
I think we'll look back at it and think it's kind of funny that you had to worry about it.
What were we doing?
Yeah.
Yeah.
Yeah.
Cool.
Pete, you've been really generous with your time as usual.
I wanted to ask some more general questions though.
So yeah, I mean, what's something you're proud of these days?
I can't remember what you said last time, but I wonder if it's changed.
Oh my gosh, I hope it's not the same thing.
It might be the same thing.
Something that's totally unrelated to, well, adjacently related to AI, kind of.
So I'm on the governance board for a CNCF project called Open Feature, which is the open standard for feature flagging.
And that has been making really good progress over time.
But this year...
We've had a really interesting inflection point where we've had multiple really big vendors come on board with the program.
So we've got, oh my gosh, I'm not even going to be able to remember all of them.
Google now have an open feature compliant product.
PostHog are using it.
Unleashed has several official providers.
There's a button, like literally more than I can remember.
So it really feels like we're hitting this kind of inflection point, similar to open telemetry, where it's just become like kind of like a no-brainer to rather than each point solution solving for another point solution.
Let's just have an open standard.
Everyone can build to that open standard.
And you go from like an N times M problem to an N plus M problem.
Right, right, right, right.
Yeah, yeah.
So that's really cool.
That's really cool.
It's great to see.
Yeah, it's like a, I'm super excited at the idea of just solving a problem for the industry that just someone needed to do it.
And I feel like we might have done it.
So that's great.
Well, and maybe at some point you've got the corporate sponsors that are doing the annual conference in Hawaii.
I mean, we kind of already do.
We have, you know, because we're part of the CNCF, we get...
We get to ride on the KubeCon kind of coattails and things like that.
But we also have just for, I think a year ago, two years ago, Open Feature had a summit, a mini conference inside of Cloud Native Con.
And we had several vendors who were kind of sponsoring things.
And so, yeah, we're getting there.
Not Hawaii yet, but that's pretty good.
Yeah, you've got a hall in the giant conference.
Salt Lake City is a pretty nice venue.
I hear it's beautiful there.
Yeah.
Yeah.
Well, and what's something that's giving you joy right now?
I am.
So it's a really exciting time to be a software engineer.
Really exciting time, like I was saying, to kind of like all of this crazy innovation.
I am trying to find ways to touch grass and not think about AI.
I'm actually, totally candidly, I'm actually losing my...
love of building software which is weird because everyone else is like really i feel like everyone is talking about like how they're just working on all their side projects and keeping laptops cracked open something happened to me in my life my my just something happened in my in my brain or my way of thinking where i've just i've lost that love that i used to have of of building side projects and stuff in software for right now um i think it's just i'm working really hard on on ai most of the time And so I've been really getting into other hobbies.
So I've been getting into woodworking and building, yeah, building, building things out of, out of, out of wood.
It's super interesting.
What I love in general about a hobby is resetting to being a beginner at something.
And like the learning curve is so intense.
Like the, the, the, the rate of making dumb mistakes is like super high.
Yeah.
But like the, the, the learning curve, like that kind of dopamine hit type learn, like, like, ah, like there's a thing that I didn't know that now I know.
That's like my thing I love.
Just like my lifelong thing I love.
It sounds like I'm in a job interview, but I love learning.
Like I really do.
No, I'm with you.
Yeah.
Like learning.
Those are the happy moments.
Yeah, exactly.
So it's been really fun to do something with my hands.
It's also kind of like, maybe ironically, maybe not, something that doesn't really get easier with AI.
Like the AI doesn't actually give you good advice on woodworking.
Ah, good to know.
I mean, it gives you the kind of mediocre advice that it gives you in many things.
It gives you okay advice, but not thoughtful, nuanced advice.
And there's probably hand-eye coordination, muscle memory stuff.
Yeah, and the actual kind of doing, actually wielding a chisel for now, until the bots come along or whatever.
But it's a cheesy analogy, but there's this kind of like the thing you were talking about, about power tools, right?
It really is true that the pneumatic hammer came along, or the nailer came along, and no one needs to swing a hammer anymore.
But it doesn't mean that people aren't building houses.
You don't need construction workers.
They're just doing a different...
It's just kind of raised the level of abstraction.
So now they're shooting nails into the side of their hand and screaming in agony rather than whacking their thumb with a hammer.
So, yeah, like this is kind of like woodwork kind of like feels the same where I'm not going to be building IKEA furniture better than the robot at IKEA can.
But I can build something that's like totally unique, one of a kind, has loads of flaws and errors.
But like they're my flaws and errors and no one else knows them because no one else knows what's going on.
So, yeah, it's just it's super fun.
It's amazing.
It's bringing me joy.
Do you have like an ambition project, a dining room table or a stool or I don't know?
That's a good question.
I think, yeah, I think I want to get to the point that I can build a large piece of furniture.
I've built like small things, like I built like a little like plant table thing, it's like this big.
My next, my current ambition is to build like a little piano bench because like basically it's like the biggest thing I could build with the tools that I have.
Like I don't have a big table, so like, you know, I have certain pieces of equipment, but I can build like a little piano bench.
That's my current goal.
We'll see if I ever get that, but that's the current aspiration.
Awesome.
Pete, thanks again.
Appreciate you being on the show again.
Thank you so much.
Yeah, it's super fun.
I love talking about this stuff with my non-relation.