Beads, Better Specs, and Less Rework

So to start, you have your own podcast. So of course you’re talking to and seeing a lot of folks doing agentic engineering. What

Have you seen lately that most intrigues you?

I think a unique point of view that I get at Dev Interrupted is speaking with agentic engineering leaders, but specifically the emphasis on the leader part. They’re folks that are trying to transform not only, you know, personal and their own workflows, but transform their teams. And something that’s been really interesting, a trend that’s emerged more recently, kind of off the tails of like the token maxing phenomenon.

that’s kind of been like, you know, ripping through the industry is the idea that individual gains struggle to translate into organizational ones. It’s like what are the blockers that stop us from distributing those kinds of improvements? That’s what a lot of leaders have been have had top of mind when they’ve come on the show recently.

And

Is there specific techniques that folks have found help scale from individual level gains to team or organization gains?

Yeah, there’s definitely started to be a bit of a playbook that’s a mat that’s emerging from the folks I talk with. So some standout ones for me. I had James Everingham. He was a lead dev infra guy over at Meta once upon a time and during their agentic transformation very recently, and now leads Guild AI, which is like a developer tooling, developer ecosystem tool. And he was on the show and

What he talked about was at Meta, how they were able to distribute those gains across like a huge engineering team, right? Like Meta’s really big. And something that stood out was creating an ecosystem that allowed anybody in the company to contribute a skill or an agent or a workflow. Like very early on, they made a shared space that was safe for experimentation, that had provided instant visibility across the whole company on what people were building. And it gave feedback on.

Folks using and iterating on each other’s tools. So creating that like internal ecosystem has been one really effective thing that’s emerged. And another key ingredient that’s emerged more recently was from Karthik Ramkopal. He’s a distinguished engineer at LinkedIn Engineering. And he was in charge of their agentic transformation within their whole company, their engineering team as well. And what he focused on first was shared memory, like it could having a place where

across the whole company. They’re not repeating mistakes. They’re not building these skills in silos. Instead, there’s a shared context layer that everybody draws from, that everyone contributes to. And he got that in place really early. And that was a key differentiator that allowed folks that were maybe less agentic to begin with to start to tap into things and benefit from their more agentic colleagues. So like those have been some really emerging playbooks that I’ve seen people use with some success.

Yeah, like what’s the stack to do it? I think everyone’s trying to crack that nut, right? Like, what is it that needs to get wrapped together? What we’re discovering is we spend a lot of time building up tooling and frameworks and agentic systems and swarms and ecosystems, all sorts of stuff. And as the models get better, it becomes more rewarding, more you have this ability to take things away from the harness to simplify things. So

It’s almost as like as the opportunity opens, the tooling that you need becomes more about primitives and about base things that are kind of hard to package up in like an open source y way. So like for things like memory, ultimately what you’re talking about is is text that’s shared and can be updated. so like even just maintaining a shared memory can be as simple as like, you know, crud and then something that the agent can connect to or read from. which has I think really been

a hard part is that a lot of it is like really primitives, really like simple, basic stuff. So the tendency to strap it all into one big shiny, this is the full rollout solution is there and it’s very like we want to look for it. But really what it points out is that a lot of what we have to r remember or know about our the ways we work today are assumptions that were built on a way of working that was how we had to do it before.

So we have to go back to the things that we do and take things away and simplify and find ways to break things down into smaller parts. and I think we’re still doing that. So the real like open source tool, like the perfectly like, this is like how these teams they throw one of these down and it’s the agentic center, it doesn’t exist yet. It’s still very like a glove to each organization right now.

Yeah,

how do you justify building or what you invest in? You know, Steve Yegge had a really good article. I think it was like software 3.0 or something. He talked about the new value of software and what makes something that something that you would build yourself versus buy or use an open source version of. And a really powerful example that he gave is grep, for example. For the tokens you would use to build something better than grep, it would just be more effective for you to just use grep.

Which is widely adopted and used. So it’s like it’s found a unique position where the output it gives you, the value it gives you is worth more than the tokens it would cost to build its replacement. And that becomes the new quality that we evaluate, like a lot of open source tooling on now. Because since it is open, it is there, you there’s the easy tendency to look at it, make your own version. It’s like a new version of a fork. We’re like getting the fork and the full development path of what we wanted from that fork all at once now.

And so the tendency to just like bubble off of open source has like never been bigger. Not to mention that then like for big open source projects, they struggle to exist not just because their user base is shrinking and continues to get further alienated from them because now agents are using their tools, not developers. Agents don’t fall in love with their tools like how developers do. And so they’re already starving of the real feedback loop that they used to have. But then they’re also getting inundated by like

GitHub issues and PR requests that just casually bubble up in all of these conversations people are having with the agents that use their tool now. And so they have to like ban AI or they have to like be really specific about the kinds of stuff they let in through the door. And it puts this incredible burden not only on the the pre-existing maintainers that maintain the project, but then the process of finding new maintainers. How do you nurture and onboard folks through a system if you can’t you can’t set up a good first issue anymore, you know?

It’s it’s dangerous territory.

What’s a good first issue? And

if it is a good first issue, an agent’s gonna come along and do it faster. And every open source contributor

Yeah, I think it’s it’s going to be interesting and open source. I think packages were or projects where the cost of getting things wrong or things that are very subtle or have very well defined interfaces like grep or I mean, I worked in the data science world.

Like like numpy, right? Like numerical

Right, no, you’re not making your own pandas. You’re not making your own crypto

function. Right. There are these things that you pick up. but again, these are all really baseline primitives taken for granted, built in, you know, standard lib kind of stuff.

Yeah, the more I think things that operate more on the integration kind of side, that’s where

the framework is gonna fall wayside

The custom code or the tooling.

Frankly, it’s like what I’ve discovered, just like as someone who’s like built up systems that live like on a computer and just revisiting Linux basics even and just understanding like the things you can take advantage of. Like I I I have never in my life set up so many like systemd timers.

in the la like as I have in the last six months. And now I’m like, gosh, this is just like I can do my whole life this way. Like it’s so great. And it’s really funny to really think and reflect. I’m like, this is a pe this is a built-in piece of the operating system that’s just here. It’s like there are so many primitives that we should leverage. and so I’ve had a real I’ve had a a a lot of fun just kind of revisiting that. it makes out even a lot of tooling that I used to you but use before. It’s like I can just

work with an agent to use like my system timers. You know.

Exactly.

And will you do you run these all on your local computer or do you have remote servers going to help with it?

It’s like a mix.

mostly it’s like on a I have like a remote machine where a lot of them work where that data lives more persistently, but I can connect to it from my computer and work there remotely and they bridge together. So like a mesh network has been another really big unlock for me because you can have the spot where your agents work and then you can have your private mesh network with your home computer, with your phone. Like I have a I have an app on my phone that my agent built for me, but it’s a is a it’s a it’s a web app.

You know, it’s just saved to my home screen, but I get push notifications. I can like run all sorts of stuff on there. and that’s only possible because I have like a little mesh network. So again, WireGuard basic, you know, networking principle unlocks a huge gain with working with the tools. I think there’s like a pattern there.

Yeah, precisely.

Like just using just using Tailscale, set it up on my home network. and and I have the machine that has, you know, more RAM. So my and it can run whenever I want. The system timers are scheduled on that. So they run on their intervals and they do the work that they do. And then I just have systems set it up to notify me of them. And up until recently I would use, you know, like the Claude Code app. You know, you can use like the remote control function and basically

Use the app on your phone that controlled a remote session on like your machine. And I would use that to drive a lot of it. But then I found Agent Gateway, which is a really cool project that basically becomes a the central proxy that you route all of your AI requests through. So now that I had a proxy layer, I could do all sorts of like cool tracking and understanding of my AI usage and the models I had and the different sessions and pulses. But in adopting that, I lost the Claude Code.

a dispatchability because like now I was using a middleman, right? So that was what actually led me to then just build my own harness app for my phone. Cause I was like, I want to keep working this same way. Why is it really an obstacle? I’ll just build what I was enjoying using in Claude Code for myself. And I’ve and I’ve been using that now for several weeks.

Yeah,

it basically connects it is effectively a system. It’s a daemon that lives on that remote machine that monitors a bunch of stuff. And it serves this web app over my Tailscale network. So I can open it and it’s basically a live view into really whatever I want. I have tooling for all sorts of things because I use agents to do all sorts of stuff. and I can use this app as like my own super app, right? It’s like I’ve built all of these little lanes I like to go into.

built my own experiences because that’s just been something I’ve enjoying like tinkering with.

Okay, let’s see. Well, at the beginning of the year, after I became more agentic and I was able to start a lot more workflows in the morning that could get things done for my review by like mid-morning, and so which is when a lot of my meetings would often start. So I started like going to the gym more and working out more. And part of the app I was using, it had data support, it had a webhook where it could send out my my workout. So then on the side I started to build an agent that would

look at like these these trends, these macros over time from my my health app. I was already using the track, my workouts, and to like see what I could do with like this extra time I got back in the morning. And it would give me suggestions on like things to do or like give me a nudge when I would like not have a weight increase for a while. And that was a really fun unlock. so that’s like an example of something that runs there on top of the the the data on

top of the system. Cause I just casually wanted that as part of

the flow. And then from there, we I started to realize I wanted to make some diet changes as well. I wanted like a good like calorie and like protein tracker. So we built that in. And now it helps notify me about reporting my meals. And that’s all part of the same data set that it uses to advise me based off of the workout data it sees. And that’s just a casual interaction. Cause it’s like I obviously don’t look at it as being like, you’re my you’re replacing a personal trainer, but you are

nudging me in the ways that I would really benefit from from having like a partner in a workout. So that was like a cool system that came for free as part of building the other things I was exploring.

well so be with the pri

the it’s like a a PWA. So you have the progressive web

app. And if you can save those to your home screen on Android, get and also on iPhone. I have an iPhone, so it’s saved to my home screen and I get push notifications. and so I can see on my phone at a glance if any of like my agent sessions need me or if they’re held up on something. I get notifications if like those pulse those those triggers, those systemd timers don’t run.

all of that goes through the the app.

Right. Right. It’s like my harness on top of my harness.

Right. It’s like a one level abstraction. I think a lot of I’ve I I’ve met some folks who’ve built some versions of these. It’s really like not any different than how people assemble like their software factories or their big orchestrators. I just use mine more as a knowledge worker, as a go-to market engineer and supporting a lot of like content creation as well as engineering.

so I’m just kind of exploring all sorts of different use cases. And frankly, like now there’s very little that I start or do or learn about where I don’t start by creating like a folder and create and like initializing a Beads depot and and then creating like a readme or a CLAUDE.md like or asking an agent to do those things. Like I have a skill at this point that effectively bootstraps that kind of folder. because I find that the process of having

the agent between me and the learning process really helps me upskill and learn faster because we learn together and it can we get there’s like a really good feedback loop that can emerge.

Yes. So the Mise en Place methodology, as as it’s been called, or MEP, as I was told by my my reviewers for the paper to change it to or to abbreviate it to. it emerged out of a hackathon that I did earlier this year. So I participated in a hackathon. I won a hackathon actually that was hosted by The Atlantic. And we were challenged with creating AI-powered experiences that re-envision like their archives and their journalism archives.

Was they had had recently made available in like an API-driven way. So the idea was like creating these new ways for folks to engage with the the news and the things they had. And I created like a digital classroom. and to get to making that digital classroom and showing the three-minute demo and showing the student experience and the teacher experience and the Atlantics experience, like the only way I was able to do that in the three or four hours I had is because I came in with the domain expertise.

Right. Of like I was a teacher. I know also what teachers are looking for in curriculums. I’ve been a student, but also to an engineer. So I understand all three of these viewpoints very well. So what I actually just did, and it was really by accident, is I sat at my computer with Wispr Flow and I just talked to Claude for like an hour or two. We didn’t build anything. We just talked about like how this would work, what failure modes would look like, what a like a acceptance criteria would look like. What are the little tiny

Tricks of the demo we need to have available to show the actual story. like I had one student in the demo who like didn’t do their citation, so they got a citation penalty. Like, we needed to show the whole story. And I talked with it at length. And then from there, by spending a very long amount of time aligning on exactly what I wanted in the beginning, and then turning it into a structured plan that goes back to like the Beads I mentioned earlier, it’s agentic task management. It’s

The graphs in terms of like loops and graphs that folks are talking about these days. It’s the ability for like agents to scaffold tasks and link them together because they’re all nodes in a graph together. And so by using this very simple idea, it turned everything I had rambled at it for like an hour or two into a structured plan. And what the paper I ended up writing about was showing how once you have that initial development that that is

a graph driven shape of the task you’re trying to achieve, your rework rate is significantly lower in than in cases where it’s not. So it’s a way of combating like a problem that we have with writing codes with agents where like you have to go back and rewrite some of it or throw it away, or it invented new code when it should have refactored. And all of these comes out of poor specs and poor planning. So that was what the paper explored.

I think that’s a fair assessment. Beads are bead bead

Beads are Beads are jet fuel. Like I think they’re magic. If you’re not using Beads with agents, then I think there’s a big gap or there’s an opportunity for you. there’s a lot of ways to learn how to use them. They kind of became in vogue back when Gas Town hit the scene. Gas town is built on top of Beads, gas town is how or Beads are is how gas town works. and Steve Yegge himself has.

Built Gas Town, built Gas City, the Wastelands, threw all away, created it all again. He’s made a new thing. He had an article that came out, I think it was on Monday or just very recently, talking about how he has rebuilt the harness. But yet again, Beads are the center of it all. Beads are what make it all happen. so I I would say that it’s like a really key ingredient for sharing knowledge with your agent.

yeah. This is where it gets

this is where it gets really interesting because Beads are, you know, creating and updating and working with Beads, it can get really messy really fast. So a lot of folks have designed interesting solutions for this. You have Chris Sells, who runs Gas City. He’s the CEO of of of Beads. And I guess you could say they have a team hosted platform, a team style tooling that does exactly this, where your agents push and pull to like a remote

store it’s both a git and a SQL database it’s called DOLT. It’s kind of this like weird, kind of like strange hybrid thing. I actually don’t use that version. I just use the the plain text JSON local version because I typically don’t share the Beads themite themselves directly with my teammates. a lot of my teammates as a go-to-market engineer use things like Asana. and so for me what’s worked is actually just having a really clear skill that can translate stuff from Asana

schema to bead schema and back and forth. And my agents can push things up into Asana and pull things down. so it’s just become like a non-issue. Like I my coworkers don’t need to use Beads. They’re not engineers for the most part on for the tasks that I’m working on. So I want to meet them where they are.

Yeah, effectively. Just

like being able to bubble things up is needed. Obviously, if you’re a team and you’re all working on tasks together and pulling from the same Beads store, there become a lot of patterns that emerge. It becomes pretty effective to have like a central or a shared place. But even with like maybe any of that friction it might introduce the velocity that you’re gonna get and the the ability to like actually have really strong situational context is just gonna vastly outweigh any of the friction.

Yeah, precisely.

So it’s like the they had rules and skills already for how to turn ideas into Beads, and that’s really just as simple as just explaining the CLI to them. It’s literally just a CLI that writes some JSON log entries. You know, it’s a they’re gr it’s a graph and that it’s connected by its unique IDs. And so it’s really easy to append and to update and to to grep over it. So agents love using Beads.

So you just kind of give them like a little bit of an inkling and they’re really good at like pushing and pulling from it. So that is what we did. Sat for a while and spoke. Actually, the photographer at the event, they took out they took photos of me sitting at my table all by myself, talking to my computer. Cause it was just most like novel and entertaining thing for them to see in January. and and and then it just like ultimately what happened is everything got scaffolded up and then

I’d finished my brain dump. So I asked them to turn them into Beads. And that was when I started to turn and kind of help other people. like their infra person for the hack for the company behind the hackathon was, you know, testing their Kubernetes setup for making all the inference that all of us and our agents were slamming on the thing. So he wanted me to help with load testing. So I was like spinning up agents while my other agents were working to like hit his machine. And this just became like what I did for the next hour is went around and found other ways to just

collaborate and be present there. And that was a really cool experience because then I came back after lunch and the agents had taken everything, had built out all of the Beads, effectively written the specs, and then had started working through them pretty methodically. And this is back in January when they still needed quite a bit of help with like staying on track and with used doing the orchestration thing. but ultimately, and that’s what the the paper explores is that there was very little rework.

That had to get done. It it relatively well matched my vision.

Ooh, that’s a great one. I don’t think there’s a wrong way.

So it’s like Beads itself is a very simple schema. You have like the title and the description. It can be blocked by other things. It can be in an epic and have children, right? And so, like, there’s a lot of opportunity to bring whatever process already works for you to like that language. And so, really, what I see it more of about is like it is the mechanical.

gates and labels and tooling. Think of it as like you can take any kind of spec process, any kind of planning process, any kind of team process to Jira and find a way to represent it there with the schema and the things. And so you can do the same with Beads. It’s not going to force you into any certain kind of way of working, but obviously treating it as like, you know, specs or otherwise having specs in Beads, I find works well. And

Dan, I I would love to pause there and say why I think it works well because why Beads works well is on a mechanical level for the LLM. And it’s really when I explain this to the folks, I it really kind of helps them understand why you would use Beads versus like just keeping some markdown documents or maintaining your skills or writing that spec, like which is like the I think the natural instinct. And the reason is because LLMs in the harness, for in them to update a a file, it has to read it first.

And the way that they’re gonna read that file, especially if it’s a big spec or or a readme, is they’re gonna grep around and try to find what’s relevant. And then they’re gonna pull a window. They’re trying not to blow out their context window. So they’re trying really hard to take notes and to pull from their notes, but they’re effectively like trying to only see one line at a time or like be very specific about what they’re crawling for. They get nervous. And so when you turn away or if you don’t have a really diligent process, they drift from it.

They don’t go back and update it. So you get this like real clobber of like the readmes and the specs don’t stay up to date. Now, if you use something like Beads, that process, all that friction actually vanishes. Because now instead of having to read a file before they can write to it and grep around and find things or understand the relations of these files by looking at like by calling ls over and over again in all of the directories. Now it is able to create a new bead.

It’s just a a JSON object with a single CLI command. So it can just create a command. You run a single CLI command and know its schema, give it a name, give it a description, assign it as part of a parent or child or blocked by something if it already knows it. It’s gonna get a minted ID, like a a fresh ID, doesn’t have to worry about collision. And now it has all of those connections to the other Beads that exist in the JSON log. And now if it wants to figure out

where that fits into other things or learn stuff, it can look at just the JSON schema, get all of the info it needs for exactly what it wants, and find its neighbors. So now it can crawl around, get exactly the shape of what it needs, add and remove things, scaffold into a plan, and it’s no longer nervous about carefully crawling around in your README files. Now you are actually getting something that’s taking notes and it’s a voracious, like learn.

So you Yeah, they’re complementary,

I’d say for sure. Even Yegge himself, like he puts almost everything in Beads, like myself, like specs and you know, test implementation plans and the implementations themselves. But he still has like markdown files that are can like a central brain or have some references that are more like cold storage. Like it’s stuff you’re not reading and writing to and changing very often. But when you do want to go back to that page, you wanna know it’s accurate and it like reflects something.

that’s like a distilled version of knowledge that I don’t think ever goes away. So they coexist with Beads for me.

That’s

what you use Beads for. It’s for that more transient, that faster. We need this. We found we and like it also then too, it encourages all this great behavior, like you’re working on something, you find a problem, it makes a bug, a quick bead that it labels as a bug, it connects to the original problem, or it just labels it as a bug, and you could have another agent come through later and pick up that bug, know exactly all of everything where it came from, and then go find what it belongs to. So like the cognitive load for you and the agent.

It both goes down. I can trust that my agents are going to trawl through things and probably do a lot of Beads and probably also make a lot of new Beads because they’re going to find new problems, they’re going to find new optimizations, they’re going to see opportunities to fix things. So literally you just kind of get in this thing of like reviewing the Beads, pushing for more, reviewing the Beads, pushing for more. The project starts to drive itself.

Yeah, depending on what it is that its task is, like the Beads can be used for all sorts of different stuff. I mean, for example, going back to like my workout one, it doesn’t really use Beads for anything very substantial. There’s like a few times where like it’ll give me a nudge about increasing like a weight set. So it’ll make a w a bead for that. So that when the next workout comes in, it remembers that agent or that session remembers to compare the reminder with what happened. So like it’ll use it to like.

gracefully persist across sessions and kind of like use it as this transient memory that you’ve kind of said. But for something like that, I make that agent a really good data agent. Its job is to be a DuckDB maestro and to take all that stuff and put it into DuckDB so we can do all sorts of cool like understanding of my of my workout data over time. Just because that was a richer place for the data to go than Beads.

Yeah, the how and the what and

the why not really I wouldn’t use it as a data store. I would use it as a knowledge store and as a task store.

You can just like effectively

put it in there. The whole markdown document could be the description of the bead. And again, the agent’s not going to crawl across it and accidentally blow out its context window on a huge info dump of something it doesn’t know because it’s only going into that bead if it knows what it’s looking for. And if it doesn’t know what it’s looking for, it can search a bunch of Beads and get things like just their titles or just their creation dates or just what they’re related to and not read any descriptions until they get to what they know they want.

So the thing about Beads is that it’s working less on I think it’s just using more like a grep search across the different Beads, and that grep search is mechanical and it returns a list that it then it can paginate from or full pull certain fields from. So then they develop practices of like they know the earliest possible creation date of this thing and they can get a really smart filter by just doing some text searching like mechanically before it even hits their context. So I think in the baseline version,

Something like that. I’ve certainly also seen folks do things like add like a PG vector grep kind of deal to it, you know, and like just vectorize what’s there. It’s kind of a freebie, because it’s already just like ready to be vectorized. I I just haven’t really necessarily gotten to that point. because I find the graph itself is crawlable enough for my needs. and if your agents are diligent about linking Beads together, then there’s typically always a trail to something.

That’s what the graph is for. Like

you’re not trying to search because you’re not like looking over a big dump of stuff. And that’s the other advantage it has over markdown. Is that now everything is a graph. And it’s hard to like say that like abstractly because we don’t think about written out things as being in a graph. But just think of them as being like every chunk that’s written out has a bridge that takes it to another chunk and it expresses their relationship to each other. and that’s just a really important way for them to.

read and work with notes. So if we provide information that way, they they have less friction. They being the agents.

are not very commonplace. I can hardly say where I meet somebody in the wilds who actually is an active practitioner of Beads because I think it’s still so early in people understanding the role that they have to play. but when I do see them, it’s like, hey, there’s like an eye to eye thing because typically it’s another person in in the rare interactions I’ve had with them. It’s another person who’s like on an island that feels like in a very agentic.

Enabled island because it you like feel like you’ve discovered this. I called it jet fuel earlier. And it really does allow this kind of velocity, but this also stability with the way that you work over time. and I’ve seen them just iterate and create some really impressive stuff just by using this the power of the graph. so I would say that it’s not a common practice yet. I think it will be because markdown isn’t gonna live forever. I think you honestly markdown’s already kind of like a stopgap.

I’ve already seen many teams, including like our own at Linear B, where we use Confluence to drive specs. Because Confluence is this nice shared kind of central place where a lot of product oriented engineering teams already pivot as a knowledge base. And it’s already a fairly agentic tool to work with. So it’s actually becomes a much richer place because specs at that stage are all about collaboration. They’re about getting aligned and I just popped out of this meeting with the executive and now this needs to go on here. We have to push back this date or this changes.

But what I think those teams will find is that the most effective way to operationalize that spec off of Confluence would be to leverage something like Beads, because now you can create a graph that represents all of this, these structured requirements that you’ve created in the Confluence. and that becomes like the missing translation layer for folks that we’re still exploring.

gosh.

Scandalous question. I I mean, I love using an agent to write specs. I think it’s important to come back through and review it and cut things out and edit it and play a role in it. but another part too is like treating it as an exercise to get to what you want. I I read this really amazing article recently. It’s from a blog called Robots Ate My Homework. It’s from Mia Kiraki and she wrote this really fun article about

Treating like most folks, whenever they want to like compare models side by side, or you’ll like take a prompt and you’ll give it to Claude and you’ll give it the the ChatGPT and you’ll like compare their outputs and you’ll pick a favorite one. Her point was is that if you compare their outputs and you find flaws and differences and deviations, that’s an opportunity for you to then reflect on your original plan because there is clearly some sort of inconsistency or some misalignment in what you’ve initially done. So

Using them as a reflection of then going back and being like, How did you arrive at this conclusion? showing them each other’s conclusions, understanding how they arrived at different things, and then reiterating on the original idea is like the loop that I think has to happen. so without that, it becomes really hard to translate those those things because if you don’t kind like keep track of like the changing requirements and and also understand.

that the initial document needs to be clearly aligned. If you don’t earn that first, then building is just gonna introduce rework. Is what what I’ve been learning.

And so I sometimes I found working with agents that they’ll dive into more detail right away than

And then it’s if I say I’m like I can’t this is too detailed to send to someone. They’re not gonna r to read this, right?

It’s too detailed. If you won’t read it yourself,

don’t send it to someone else. Don’t be a slop cannon. If you read it and you think, it’s too dense, but I think they’ll get it, they won’t. They won’t read it. If you’ll barely read it, they definitely won’t read it. So that’s like the first thing is everyone has to stamp that out. but using it to create like a spec, it’s gonna be extremely verbose. But this is also then the opportunity for

The spec is for the humans to align. What are what are the acceptance criteria? What are the constraints? What’s our timeline? Who is this for? What are the user stories? Like the humans need to get aligned on that. And then if it becomes like this huge thing, that’s where it starts becoming more operational. You need to then point out into like s you know, like hub and spoke, other documents that then turn into Beads.

and say s save the implementation details for the Beads. Just focus on the goals of the software. It’s like a you know, a c a big big communication task.

That’s the easiest part. I don’t start b now nowadays, I don’t

start building. Before it was like if you they’re talk the the team wants something by this date, there’s something that has to get delivered. Okay, well, we don’t know exactly what we want yet. Yeah, it’s gonna take us weeks to figure it out. I can use these weeks to get infra going, to get the things spec like an initial baseline going to talk about how we’re gonna do it. Like you have all this time. Now I won’t do any of that because.

That whole cycle compresses into an afternoon or it’s a skill that I just run once. So now it’s like I spend all my time getting extremely aligned. If you can’t tell me, if we can’t explain to each other and agree about all of those things I said earlier, including the user stories, then I’m not ready to build yet. Otherwise, I’m gonna build something we’re gonna rework. If we can get to something we agree on, we’ll have it that afternoon. right. And so that’s definitely the challenge now is the alignment.

Yeah,

and it’s all like you’re buffing away things and then there’s a whole bunch of practices that emerge, like that it just starts to get really messy. And that’s what the Mies en Place, you know, the MEP article that I wrote is all about. is that exact thing. It’s like you once you start putting yourself in a situation where rework is inevitable, you’ve already lost when it comes to agentic coding. That’s energy you should have invested up front in the planning process instead.

no, no. You know, I think that like iteration is still important. You know, we have to iterate as a team and share things, and we can get really, really aligned on what we want, and then we can start to build it and then start to use it and realize we were both wrong. We can both be aligned on the wrong thing. So we have you know, the ability to iterate and reflect on it is then what you have to just be like a quick with. So agile.

is very important here. If you can build an effective prototype from your alignment, you know, from a prompt or something, then now you have a great thing to show at the next meeting. Everyone can call out what they hate and what they don’t love. And now you can run it again. that becomes your new agile is that you’re not doing the little tiny blocks, you’re doing the whole thing end to end over and over again, and then figuring out what little levers you have to pull to get the optimal result.

Drastically compressed. Now you’re you’re

not dropping yeah, you’re not dropping products every quarter. You’re not having a big product release every quarter. You’re doing it weekly.

Yeah, it’s definitely he thinks it’s going away. I I think that CI C D will just evolve. It will shift really far left and it will take a new shape. Because now we’re in loops where if the test is running in CI C D, it’s probably too late. There are opportunities to move that kind of testing, that kind those kinds of infra further left into like the CLI, into the IDE, to where the code is created, to where the agents can use it.

And I think that like this, these CI CD platforms and things that are available already in the market have everything they need to evolve effectively into that kind of tooling. I mean, even Circle CI just the other day released a new version of their CLI that is agent-friendly, agent-driven, you know, JSON kind guy. And so like they they’ve already acknowledged that their new user base.

Our agents that or there needs to be opportunities to run CI CD on loops that are happening before they hit a PR. so I think that like what we call CI CD will it will evolve. it will move really far left. And you’re right, that like Steve himself even says there’s a lot of value to it. There’s other things that emerge, like he talked about the merge queue, which was really interesting to read about how he batches merges and and runs them and does do CI CD on these like batched merges. So you’re gonna see these like really interesting shapes evolve.

for big teams, I think. or teams that are shipping a lot of software. Could just be a small team, but you know, teams with a

CI C D is great. Just the ability

to move it local, shift it further left in the process is like really amazing. you know, AI code review is another critical part of that process. Have that having that in your PRs, having a first glance at things is just as important as CI C D. the the the AI PR review is like a really critical part for just having a good nose on stuff.

yeah. So well for for AI code review itself specifically, that’s what a lot of what we do at Linear B provides to teams. So we’re engineering productivity platform. And as part of that, teams need AI code review to understand like their merge rate and get a control on it. And you have these teams where like they huge amounts of agent PRs that pile up, right? And then none of them get merged. So for us, we attack it at the CI C D level, at the GitHub actions level.

You work in the in the pull request, you work where things are getting labeled and delivered. And then you can have you can do things like filter by labeling. You can have other automations that are doing that labeling. You get like the start of like some orchestration.

So you’ll use

another model. Sorry.

Yeah, you’re like a VIP list. Yeah, I know. I I’ve totally

been there before. Anyways, back up for a second. What what did you ask me? No, you’re good. You’re good.

But sorry about that when he started I

was like

Like, what’s the point

of do not disturb that?

yes. So in liney in

Linear B, we run these in in like the GitHub level, the GitHub Actions level, or wherever your your code lives. And it would live in the PR because it’s an important part of the the PR check process because PRs are receipts, you know, they’re parts of compliance. It’s a very important element is to have some sort of receipt you can go back to about the code. And so that’s where the PR lives. But obviously there are opportunities that move that kind of review further left into the IDE. I think every every

good PR should have some sort of formal review by a human or an agent or both that did not write that that that did not write that PR, right? so I think that’s an important step.

see, I kind of like don’t necessarily go into that whole world of like, I use Claude to write the code, then I use Codex the like the review it. Like I know, and I use Gemini to write these specific things. Like I don’t have like a model that I pivot to specifically for I haven’t quite put them in buckets like that for me. I’m perfectly comfortable with having the same model review its code if it’s coming at it from a different prompt, from a different session, from a different perspective.

Or I set it up in an adversarial way. you can you can, you know, have different levels of review that are just like you’re scanning for a good looks good to me, or you’re doing a scrutiny, scrutinizing, or you’re doing like a security kind of review. So I think that it’s more about knowing what you’re looking for and knowing what the could the gotchas could be more than it is like picking the right model. that’s just been my my experiences.

Yeah. Like a year ago I did a I did I made a benchmark for AI code review tools where I compared our tools with some others in the market. And I created an agentic system that basically took an open source project, introduced a bunch of bugs to it and made a big mess, and then opened up all these different PRs and it had these different tools run reviews on stuff and just kind of like looked at what they caught and compared them and

A lot of those tools were using or running the same model under the hood or like the same model family. but they were just vastly, vastly different because the the real secret of the AI code review is the harness and about it understanding your code base really well. so it needs to be like a participant in in your in your in your in your tooling, right? It needs to be able to understand like what’s the kind of code that you write, what matters most to you.

yeah, it’s been a huge superpower for sure. it already felt like one, just being like because I’m always been technical. I’m a self-taught technical person. I participated in open source before I formally worked a tech role. and even before I worked in tech, like I was doing like more like product and website delivery stuff. So I’ve always been like a really technical person. and what I found with classics, which is what I studied, is that it was just a huge amount of like reading and studying and comparing,

like huge amounts of information. Like just reading hundreds of pages of history and translating tons of lines of dead languages and then reading all of these different books, it just constantly had me very curious and also processing this huge compendium of like relationships of like people and empires and places and things, like over literally thousands of years. Like it’s a huge span of time that you study. And what was so fascinating to me is how it exposed like how cyclical like humanity and being a

people and civilization is, and you start to see these really key patterns repeat themselves. and like, you know, all of history becomes like a big kind of loop. so it’s been fascinating to then be in the tech world at a time where you’re able to start to engineer with intelligence and work with tools that can process and think over huge amounts of information because being a super analytical person looking for connections between stuff was always like part of my

background on top of just being really voraciously heavily like read and and deeply curious in like a non-technical way too. So now it feels like I can take those challenges and those questions and those curiosities from before and I can actually apply technology to explore them and to deepen that learning. And so it’s just been like a really big superpower to come in with that perspective because I just feel like I get the opportunity to look at the seams a little more closely.

Then maybe folks who don’t have that background.

I mean I do. It’s pretty transformative how I’m able to think and work with projects, how I just approach my passions, how I think about getting my work done. And I feel like I feel like I have a tutor that can help me learn things so rapidly. So it in addition to being so rapid so heavily enabled, I feel so so well taught, or rather points to resources and just constantly kind of rewarded for

being like that. So I think it’s a huge opportunity because really what it does is it exposes that now that kind of thinking, that kind of knowledge, it can be created into systems. And we can think about our deterministic systems of yesterday. And we have computers with pipes and inputs and outputs and ones and zeros. Now you can send information in that same in those set in that same kind of architecture. So the way that we can even just think about the way we work with knowledge.

It’s just fundamentally going to change. And I think that like we end up in a bubble. Like you and me and our listeners, like, because we’re in tech and tech is getting rapidly like eaten alive and transformed by the whole thing. But this is gonna keep happening everywhere for probably the rest of our lives because there’s so much transformation ahead of us that even if we stopped inventing new models today, we’re in such an overhang of capability that hasn’t been developed in like every industry on the planet that

There’s so much to keep us busy. But yet we keep growing and keep learning, keep going faster. So we have to partner with that intelligence to take advantage of all of that opportunity, I think. which has becomes something that the rest of the world is still even us here in tech are still trying to figure out what that means.

yeah. It’s definitely like you become a manager of things. Like going back to what I said earlier about like working with agents and kicking off workflows in the morning fre freed up a lot of time for me in the morning. So I started going to the gym more. I started like it almost it felt like, you know, like if you’re an executive at a big company, like what do you do? You wake up and you have your morning routine and you s and you read your paper and you’re and then and then you come in and you check your emails and you have the four people who report to you and they have the oversight on the whole company. It’s like that’s

how I started to think of like how could I design my life to work like that. You don’t have to be a CEO of a big company anymore. You can be in charge of all these agents that kind of operationalize your life that same way. So that was like what I the opportunity that that I saw.

And what do you think for developers who are just getting started where you can go and use agents to do everything, but then you’re not getting the experience of getting burnt or getting deep into here’s why a programming language works. Do you think that

We’re gonna be in ten years with people who don’t know how to we don’t have anyone who knows how to build software anymore. Do you think it won’t matter?

I think a lot of that would get abstracted away. I think we’re probably on the cusp of starting to see programming languages that are just purely for agents to write. And we start getting even more abstracted from the code, which was already an abstraction from what is effectively a very baseline thing that the agents could be better at than us. So I do think that you’re gonna see this like stripping away of skills and things. Like we have to remember that.

Like the whole tech industry as it is and how it’s built up since even like the 70s. It’s like we went back to like the Bell Labs, right? It’s like this like system of these like platforms of huge technological achievement that further and further abstracted us from the machine so that us with our human brains could work with it. Now we have to reverse that trend and go the other direction. So you’re gonna get a lot of knowledge loss in the middle. Then the question becomes like.

Is that knowledge lost or was that knowledge that we had to artificially create in order to do this in the first place? And now we can embed it within a different way. And that just becomes a different way of thinking. But you know, once that happens, the engineers 10, 20, 50 years from then, they’ll have their own levels of abstraction that are built on top of all of that yet again. that will come out of all of that opportunity. So there will always be new skills and things to be learning.

And processes from yesterday will go away and get replaced with ten more tomorrow.

But in there they describe it’s it’s in the future, some forward maybe like a hundred years from when it was written. And someone’s programming, but they’re kind of I always think they’re like wearing VR goggles and manipulating something with their hands and things like that and

When I read this I’m like I don’t yeah.

There are so many directions that technology

could go. That was where they thought it would go. Makes me think of like, if you’ve ever read Snow Crash. So Snow Snow Crash is like the same is is the same idea. It’s a hardware future. All of the stuff and all of the adventures and gadgetries and that stuff they get up to. There’s a VR world there too. There’s the motorcycles, there’s like the guns and the parachutes, all sorts of stuff. It’s all and it’s all technology. And it was all like a

How they thought technology would evolve, like the Xerox machines of the world. Everything was gonna be big, clunky yellow boxes with floppy discs and all sorts of stuff. And so it was a really cool vision of a future world that just never came to be because a technology actually pivoted the other way. Software ended up being what scaled, not hardware. And so, like that’s like a fun thing to see in like those all those different ways that technology has developed. And that’s a good one from.

They they’re not even necessary or use them in a yeah, you could use it in a different

way. like going back to like the harness thing I built. Like when you own your own harness, it’s like now I might harness me whatever I want. If I have a mode, I can turn it on to I can do lily pad mode where all my agents now are just little frogs sitting on the lily pads in a pond and it’s very peaceful. So now it’s just like a serene scene. Right. And it’s like, why not? Because it’s you you can customize it and change it however you want.

That’s the power of just being able to modify the software. And now that’s more democratized than ever. So now it’s like you don’t have to rely on an engineer to create this unique experience for you. If you know what you want and how to how to express it, you could potentially achieve it. And I think that’s really exciting.

Mm, that’s really hard to say because I I changes so much week to week, even. It’s like a fast evolution. Like going back to what I would you asked me earlier, like what I would say to like a newer developer or someone starting to experiment with these tools is like if you’re not throwing everything a bunch of things away every week and starting over or adding new stuff or simplifying ever like every week, then you’re probably not iterating fast enough because that’s probably about the the pace at which I change my process or add things.

and just being really, really big about your feedback loops, it can be great to build a whole bunch of stuff that pump out a bunch of outputs for you. But if you keep making the same changes on those outputs over and over instead of fixing the sources, the skills, the upstream stuff, you’re never gonna actually like climb. You’ve just created a new thing you do every week. You have to get rid of that too. And in order to do that, you have to have a lot of taste, you have to have a lot of examples.

You gotta give really cruel feedback, like brutal feedback all the time. and you have to like stop you have to like, you know, obviously not let it over rotate on the stuff you say as well. So there’s like a balance to it as and you’re still actively participating in it week to week. and that’s really important to do.

Yeah, I I think of I mean I know a lot on X or social media is like loops, graphs, and the abstract. But one guest I had on Matt Rocklin who created Dask eventu originally, he had he was re-wrote Dask in Rust. And he was saying how part of what he does anytime he approaches a problem.

Agentic problem is figure out how the agents can understand the system so they can solve problems.

Yes, you’re just building systems. Yeah, it’s

all systems architecting, system building. I completely resonate with that. And honestly, loops and graphs, that is those are the two ingredients. I co I cosign that.

so the I there’s a few forks of it. Like there’s one that Steve Yegge built and that one’s part of Dolt, which is the it’s where you use like a Git store, it’s more like a SQLite Git. It’s it’s like a SQLite and GitHub had a baby kind of deal. And that’s what the the service is. I just use Beads Rust, which is a fork by Jeffrey Emanuel. If you or your listeners don’t know about Jeffrey Emanuel, I highly recommend that you check him out because he’s a very agentic guy.

he runs a whole bunch of systems and I’ve learned a lot about how to orchestrate my own from viewing his guides and his skills. He has a very famous skills library that a lot of folks gravitate to. And he comes from like a computational finance background. So he’s very data savvy. he has a fork of it that’s written in Rust, super lightweight, small and local. And that’s what I use because it’s just simplest.

yeah, my whole stack is open source. So anyone

can find me on GitHub at Azigler. I have a dot files repo where my most of my harness setup, a lot of my skills that I use, including my skills that teach my agents how to use Beads, are all there in the repo, as well as has like the different tools that I install to run my my VPS where I do all my remote coding. so I keep all that in the open. So if anyone’s curious about how my stack works or want to borrow my skills or steal them.

They’re they’re in the open.