Ep. #80, Augmented Coding with Kent Beck

Kent Beck: I had a bad day vibe coding yesterday. It was the first time I ever shaved yaks with my power tools.

Jessica "Jess" Kerr: Is the agent your power tool?

Kent: Yes, the agent is my power tool. And actually I don't like calling it vibe coding. We can talk about that too, but let me get through this part of the story.

I was working on an iOS app, 'cause I have got so many ideas, and I hate the note taking apps that are currently available, and so I'm making my own, but working with iOS apps is not the easiest thing, even for agents to do.

And so, yeah, it took me two hours to get my icon to show up, and it took me four hours before I gave up on the finite state machine for my user interface, and just said, "Oh, right. There's only one state. Nevermind."

And like that, so it was not the best of days, but today's going much better, so. I caught myself...

You know, I use index cards for all kinds of stuff, and I caught myself writing down my to-do list on an index card, and then I realized, "Oh, this is a memo taking app. Come on."

Jess: So you should be dogfooding.

Kent: I am absolutely dogfooding. Everything's in there. So, yeah, making progress today and just having a blast.

Jess: You don't sound super excited. Tell me about your last week.

Kent: Oh my goodness. So two weeks ago I went to a workshop, and I met Steve Yegge for the first time in the flesh, and he has been doing a bunch of vibe coding, and he's nearly as excited as I am.

In terms of who gets to be the most enthusiastic person in technology, I think we're kind of neck and neck in that. And I caught it and came back.

It was a hardworking workshop for three days, ended on Friday. Saturday morning, I thought, "All right, let me give this stuff a try."

And I just kind of disappeared into it.

Jess: From the world?

Kent: Yeah, I'm waking up at two o'clock in the morning going, "Oh, that's how I should have instructed my agent."

"Oh, yeah, I better go try that now," and, you know, working for a couple of hours, and I'm like, "Oh, I got to sleep some more."

And here's the thing. I'm a boomer geek. About 20 years ago, I stopped having patience for all of the minutiae.

You know, my favorite programming language is going away, having to deal with dependency L, like, ugh.

So I kept having ideas, but I just didn't have the oomph to push through all the details necessary to even try the ideas out.

And this was emphasized to me about six months ago. I was like, "Well, let me download a model and run it locally," and two days and about 14 hours of work later, I still hadn't gotten the dependencies worked out, and I gave up.

I'm just like, "FTS, I just don't need this." So, as a geek, kind of a part of you dies when you realize, "Oh, you know, I can't implement stuff anymore."

I still have great ideas. You know, I'll have an idea, and a year later I see somebody's actually done an inferior version of it.

I'm like, "I had that idea before." You know, I feel like a man shaking fist at cloud in that moment. And here's the thing.

Augmented coding means never having to say no to an idea. It may not be a good idea, you may not know, but do you want to start it? It's a choice.

Now, currently I've got four projects kind of going at the same time. No, five with the MCP server I started working on. Oops. Oops, I project again.

Jess: That sounds like a yak.

Kent: No, no, no. It's actually interesting. I have this vision, a Rent-a-Kent. I want Rent-a-Kent.

I want to be able to like expand my reach by having a model that people can talk to and get answers that are better than generic answers about software development.

Jess: Okay, to understand that, you better tell people who you are.

Kent: My name is Kent Beck. I have been programming since before you were born.

Statistically speaking, the four of you here who are my same kind of age, you know, I'm not talking to you.

Ken Rimple: I'm 56. I'm there. I'm somewhere near there.

Jess: Except you, too, could make your ideas a reality.

Ken: I shake my fist at Cursor.

Kent: Exactly.

Jess: So, what kind of wisdom will Rent-a-Kent impart?

Kent: Work in smaller steps and get more feedback.

Jess: Ah. How do you impart that to an agent?

Kent: Well, I don't know yet.

Ken: Jess has been trying to tell me this for about six months.

I like to think of myself as the character in "Hot Rod" that like jumps over the pool and then doesn't make it over the pool on a regular basis.

That's me. So, I tend to take big swings at things with AI agents, because I'm like, "Let's see what it can do."

And that's probably the wrong approach, by the way. But it's not bad to experiment with, undo it, and then come back to it again, is what I keep finding.

Kent: Yes. So, Jess and I tend to work in Abstractistan, you know, in the world of ideas.

And so if you take a step back, what we have here with augmented coding is this non-deterministic system that is sensitive to initial conditions, in the chaos theory sense, that a small change is the beginning.

I keep doing projects over and over again, just to see how differently they're going to come out, even though I think my prompts are exactly the same, and the results are quite different.

So, anytime you're dealing with a non-deterministic system that's sensitive to initial conditions, the only way you can get any control over it at all is by pulling in on the reins, slowing it down, creating some kind of inhibiting feedback loop that keeps it from just going, doing whatever it wants to do.

What I realized over the weekend is I want coding agents, I want a Freudian coding agent.

I want the id that's just going to go and try stuff, I want the superego who's sitting there throwing new test cases in and saying, "No, you can't do that, and you can't do that, and you can't do that."

And then I want an ego, which is remembering that what we're trying to accomplish is building a database, and I want all three of those working together.

Now, I'm not sure if that's an actual architecture, but you know what? I can try it. I can build that myself right now. Six, now I have six projects.

Ken: You need one of those clickers, that every time you have an idea, it's like, "20, 48, 103, 2,000."

Jess: You never have to say no again, but sometimes you have to say, "Not today."

Kent: Absolutely.

Jess: So currently in your interactions with the agent, are you playing the role of superego?

Kent: Yes, very often. "Here's another test case, and now you have to pass this. Oh, oh, you commented out a bunch of tests? We don't do that here. If you try that again, I will shut you off, and I'll never turn you back on again."

Jess: I had to tell mine yesterday, "We don't do logs here. Add that attribute to the trace."

Kent: Yeah, exactly. So yeah, I feel like I'm pulling the reins.

I'm with you, Ken, on the like, let me just try a prompt that's like ridiculously large, and see what happens, and be prepared to go back a step.

Ken: Man, Git is your friend with this thing. So many commits.

Kent: So many commits.

Ken: Such a great idea to like just pull back.

Kent: I love small commits, and I always have, and people say, "Yeah, but how do you write the commit messages for all those little tiny commits?"

I'm like, "Ha ha, my agent does that for me." I have machines to do that for me. It's so great, 'cause it's like actually the commit log is not bad.

It is like, "Oh, we did this and this and this and this and this." Oh.

Jess: Yeah, and then this morning I did a Git rebase -i to the last commit that I made, and deleted all of its commits from the list, applied the rebase, and, poof, they're gone.

Kent: Yes.

Ken: So, you had mentioned that you don't like the term "vibe coding." I don't either, but...

Kent: So, I think it's fantastic that it came out.

There was a concept that needed to be named, and that word caught on. It's like a seed crystal in a supersaturated solution. The world was ready to have this concept.

And the problem with it is it just sounds like you're rolling a fat one and sitting in a hot tub, which you could also do, but that's more of a personal choice.

I prefer to think of it as augmented coating.

Ken: Yeah.

Jess: Yeah, 'cause it's not relaxing you. In fact, it's getting you up at 2:00 AM in your excitement.

Ken: Yeah, the vibe is variable, isn't it?

Kent: Yes.

Ken: You got a good vibe, or you got to, "I want to take this computer and throw it out the window vibe," or, you know.

Kent: Okay, so this is another theme that's emerging for me is the intermittent reinforcement.

It's a slot machine. "No, not like that. No, not like... Oh, that's cool. No, not like that. No, no, no. Holy crap."

And so every time I walk past my computer, I could just do one more prompt. I'm a poker player. I know this feeling.

Ken: Oh wow, that's really interesting. Yeah.

Jess: Okay, okay. And you also approach it like gambling, as in, "Nope, try again. Nope, try again."

You don't have this expectation of continual progress and of deciding on the way to do it before you go in?

Kent: Correct. The details of how we're going to accomplish this thing, yeah, it's fine.

Jess: Do you like iterate on your prompts in between?

Kent: So, there's this concept I've talked about for a while called "making making," which is that--

Not only do we make stuff, we also create the tools and the workflows by which we make stuff. So I'm constantly doing that. I'm refining the prompts to the agents.

Well, what if we tell it to do this? Every time you make a change, run the test. If the tests pass, do a commit. No, we don't comment out tests that are failing.

Never, never, never ask my permission. So I'm constantly not just working on my project, I'm working on the process of working on my project at the same time.

Ken: So one of the things I ran into, and it's something that's probably obvious after about a month or two of working with tools like this, but is the discipline, it needs to be stronger, I think, for most developers engaging with a tool like this.

You can't get hypnotized into assuming the tool's going to do too much for you in a particular session.

And I find specifically when I'm talking about Cursor now, that the overwhelming amount of output you get from Cursor as you're kind of in the zone playing around with things and seeing how far you can get, is addictive, like you said, it's hypnotizing, and you may play too long with it and realize you're too far down the well, and you'll have to go back too many chunks.

So, having enough discipline to know, "All right, I'm going to break it down into small pieces."

I might take a bigger swing and see how far I get, but then I might go back and then do it in smaller increments, then say, "Okay, I like that, but let's do this in small steps."

Seems to be like a really big deal for kind of grasping how to use a tool like this.

Jess: I've found that the limitation on how much change I can let it make at once is how much code I'm willing to look at in the Git-show to see what it did.

Ken: Mm hmm. Yep.

Kent: Yeah, at first I wasn't looking at the changes it was making on nearly a regular enough basis.

It would report progress. It would say, "Okay, yeah, I implemented that," and, you know, like the commenting out tests thing, and I just didn't notice that, and I don't even know how long I didn't notice it before I saw it.

And so I actually, I want another agent out there, like a sidebar that says, "Here's what's changed."

Ken: Yeah.

Kent: "Here are the changes I made." I don't really trust its...

Jess: Description?

Kent: So I'm using Augment Agent as well as Cursor. I kind of go back and forth some, and Augment Agent will go and do a bunch of stuff, and then it comes back and says, "Well, here's what I did for you."

But it's kind of the... That's the press release of what I did for you.

Ken: Superficial. Yeah.

Jess: That's what it wants to have done for you.

Kent: Yes. Yeah, yeah, exactly. So I want something that tells me, "No, no, no. Here's what actually happened."

And I want to be able to instruct that with things like, "No, we don't just delete tests or ignore tests that we don't like."

Ken: Is your feedback loop for that, changing the settings in Augment Agent, like kind of like a prompt settings or...

Kent: Yeah.

Ken: Okay.

Kent: Yeah.

Ken: Cursor rules in this world that I'm working in.

Kent: Yeah.

And here's the good news. Nobody knows what any of these things should be so everybody who's using these tools right now should be experimenting, 'cause your version of it has a non-zero chance of being the one that everybody ends up using.

Jess: Oh yeah. Especially if you blog about it.

Ken: Right, and you share that with people. That's true. There's a really good, like Git Awesome Cursor prompts, one that I was looking at.

I'm not sure how good the prompts actually are for my case, but they're interesting jumping off points.

Kent: Yeah, I saw one for refactorings the other day, and I went like, "Okay, yeah, I want to try that."

And those are the things that, at moments like this, we should all just be reflexively trying everything.

We shouldn't be trying to get as much done as we can. We should be trying to advance this workflow as fast as we can.

Jess: Okay, so it's a time to be making the making, both in the agents that we're working with and in ourselves.

Kent: Yeah, 'cause like I'm rewiring my brain. And I was talking with somebody from Anthropic, and I asked him some questions.

He's like, "Around here, we ask Claude those kind of questions." Not to be rude and dismissive, but you just need to learn to get into this habit of asking Claude anytime a question pops into your head.

The other day I'd published something about oscillations and systems, and somebody came on my Substack and said, "Oh, oscillations are caused by systems that have complex numbers as eigenvalues."

And I thought, "Oh God, eigenvalues." Like, I know matrix math, but I just never dove into eigenvalues. And like, "Oh God."

You know, my first response is like, "Oh, there goes somebody into Abstractistan." And I'm like, "Oh, well I'm supposed to go into..."

And then I thought, "Claude." So I said, "Claude, tutor me on eigenvalues." "Oh, blah blah blah blah blah."

"Hey, what about this?" "Oh, no, you're right. This is a better example." "Blah blah blah blah."

"You know, we pump the numbers through this theorem, and then if we take a square root of a negative number, then you're going to have oscillations." "Oh, okay."

And what I realized is, I have those questions. I want Claude... You know, Siri uses "Siri" as the prompt. I want Claude to use, "I wonder" as the prompt.

So if I just ever say, "You know, I wonder if the Rolling Stones tour is coming to Seattle," I want a little, "Yep, yep. They are coming." Whatever it is.

Jess: Right. When they finally make the voice assistants good.

Ken: Yes.

Kent: Yeah.

Jess: So are you going back into like toddler mode, where we used to ask, "Why, why, why?"

Kent: I do ask for explanations, and my agent thinks I'm being passive aggressive.

Ken: How's it respond? What's it say?

Kent: Oh, I say, "Well, why is this file so big?" "Oh, I'm sorry, I'll fix that."

I'm like, "No, no. I actually wanted to know why you put these four classes in one file instead of separating them out."

Jess: Like how do we get it to be less obsequious? One instruction it refuses to follow, no matter how many times I tell it, is "Stop telling me I'm right."

Ken: Oh, I hate that. Or that, "No, I've got it." My favorite one's, "No, no, I've got it. This makes sense. Now I understand."

Five "Now I understands" in a row, and you're back to the first way it tried to solve it again, which makes me crazy.

So you're in this loop, right? I never thought I'd get into a go-to loop with a chat bot, but here I am.

Jess: But see, that contrasts with what Kent mentioned he did, which is back it up and tell it to do the same thing again, not proceed from where you are.

Don't keep betting on a losing hand. Fold and continue with the next hand, fresh start.

Kent: And the cost of that is so much lower now.

Jess: Oh yeah, the sunk cost fallacy.

Kent: On the other hand, sunk cost fallacy does kick in pretty quick, 'cause you can have something that looks pretty much like the system that you were trying to build so quickly, and then it goes off the rails.

And then you're like, "Hmm, one more prompt, one more prompt, one more prompt," as opposed to, "You know what? I'm 47 minutes into this project. I'm just going to start over."

Jess: Yeah. Is the second one better?

Kent: I'm still working on it. That's the sensitive to initial conditions thing, right? That's the butterfly effect, and it definitely applies.

Ken: So you're in the middle of a vibe coding, sorry, of a, what'd you call it again?

Kent: An augmented coding.

Ken: Augmented coding session. So you're going through this process and you're working on something, and you realize, "Wait a second. This is not implementing the features I wanted the way I wanted."

You dump out, you start working on your test, and you improve your test, and you find out that it missed the condition 'cause it was completely in your head, you couldn't express it, and you fix it that way.

I think that part of the thing that I got a lot of power out of the other day was just jumping back and doing plain old coding, and then like using my favorite IDE, getting stuff done in IntelliJ.

I'm rollin' on my Spring Boot project for my demo tomorrow, and I'm getting a lot done because I realized that when I told it to implement, like the order processing part of my app, it stubbed it all out and didn't do anything.

I threw telemetry on it, and it went, "I ain't doing nothing over here." And you're like, "Wait a second."

It just stubbed it, right? Stubbed it from the front end and nothing's happening. So then I'm like, "All right, let's go in."

And I asked the agent to build me some tests, and it did them poorly, and that's fine. And I knew what was wrong 'cause I looked at the test. "Well, that's stupid," and they fixed it.

But then I reengaged, and it was like you could exit the loop anytime, and you can come back in that loop anytime. You don't have to be stuck in a mode.

Kent: Right. So another observation I have is that the clickbait version is "programming languages are dead."

'Cause I am doing projects in languages that I've never learned. I have a project in Rust. I have another project in Swift. Never touched either language.

I can edit Rust code, I can edit Swift code. You know, if there's a test and I want a variation on the test, I can figure out how to type that in.

I just don't know where the colon, colon, ampersand, asterisk goes.

Jess: The minutia.

Kent: Yeah. And I just don't care. So here's a question.

You know, every programming language is a set of affordances for human beings. What if we just didn't care about that anymore? Is there a new kind of programming language that offers affordances for agents, and we just don't care if human beings can understand it anymore or not? That's a possibility.

Jess: Maybe, maybe.

Ken: The next leap of abstraction, so to speak, where syntax is less relevant.

Jess: Yeah. I made a change to the Honeycomb MCP yesterday, 'cause it wasn't doing what I needed it to, so I just went in and told the agent to make it possible for me to configure it some other way, and it did.

And I realized later, I don't even know what language that's written in. Didn't even look.

Ken: By the way, can we pull back and say what's an MCP for people?

Jess: Oh, good idea. Kent, do you want to define MCP?

Kent: Model Context Protocol, clever name, kind of goes with the whole vibe coding zeitgeist, and the idea is, so we've got these general purpose models and we'd like to extend them, but the way they're built is so monolithic that it's really hard to, and we have some options to do that, like RAG.

MCP is a structured way to add capabilities to models.

Jess: And not like build them into models.

Kent: No, no, but they can be called out to, so you have actions where you can, you know, if you want, I don't know, you want your model to control a robot, you could have an MCP that offers that, if you're-

Ken: Dr. Evil.

Kent: Yes, exactly. It's got prompts, so it can go and fetch prompts that work in specific situations, and content, which is the thing I'm most interested in playing with, is 'cause I've got a million, 2 million words of content out there, I'd love, that's in this Rent-a-Kent kind of world.

Jess: Oh, okay. So, Rent-a-Kent is imparting wisdom by offering certain content?

Kent: Maybe. That's the project. We'll find out if it works. I'm a few hours into it, so yes, of course I have something working. I just don't know if it's useful or not.

Jess: Yeah, that's still the question that always falls to us, right, "Is it useful?"

Kent: Yeah, yeah. Yes you can. I mean, that's the old jazz saying, just 'cause you can doesn't mean you should.

Jess: So, adding an MCP and giving it to the agent, it's almost like it grows fingers and can manipulate or explore the world?

Kent: Correct. I have a daughter who's in medical research. This is going to start to get scary, and lab automation's a big thing.

So you could have an MCP that knows how to go and do experiments.

Jess: Oh yeah. And then you could ask it, "Well, what happens if we inject this gene?" and it could go try it.

Kent: Yes.

Jess: That is scary.

Ken: So we end up with minions.

Kent: Minions are the perfect engineers.

Ken: Aren't they?

Kent: You tell them what to do, and they go and do it, and they have no concept of the consequences. They bicker enormously, but then they just get shit done.

Jess: So shall we call it minion coding? Minionated?

Kent: Like opinionated?

Jess: Right, right.

Kent: I don't know. We are at a moment that is sensitive to initial conditions, so just start calling it whatever you want to call...

I just started calling it augmented coding, like a week ago, and today was the first time somebody came back to me and said, "Well, I was trying augmenting coding, and blah blah blah..."

Like, "Oh, all right." Maybe that'll catch on. We'll see.

Jess: Yeah, so I love spinning up a minion to shave yaks. This is my favorite part. I love yak shaving. For instance, I asked it to do something, it did it wrong.

It was like adding a span, and I was like, "Oh, actually you're using my OTel wrapper. How would you know the right way to create a span here, because I never documented it?"

Open up that project, spin up a minion. "Hey, document this." Boom. Increment the version and publish it. I have to log into NPM, but that's it. Yak shaved.

Kent: It feels like magic, and it's not.

Ken: Yeah, right? So you have this great podcast episode, what was it, on Distributed, back in February, that went into a lot of different topics around junior developers.

And I'm curious what this is going to do to a junior developer. In some ways they have so much more information at their fingertips, but I know in a lot of ways they don't know why and what they're asking about when they're junior.

But with a skilled senior engineer at the helm, do these tools help or hurt things for juniors?

Kent: So there's an analogous problem in medicine, where junior surgeons would like hold stuff back for the senior surgeon to do things, and now a lot of those tasks are being done robotically, and so the younger surgeons don't have that.

The phrase I like is "legitimate peripheral participation." So, it's participation. You're in there doing the real thing, it's legitimate.

This is a job that needs to be done, but it's peripheral. If you screw it up, you're not going to screw everything up.

Jess: Or in this case, kill somebody.

Kent: In that case, kill somebody.

So, one way to think about this is a junior programmer is, you know, senior programmer writes some tests and the junior programmer goes and makes 'em pass or whatever.

That option's not available anymore. Here's the thing.

There's going to be a generation of native augmented coders, and they are going to be so much better than we are at using these tools that we won't be able to understand even how they're working.

That's my guess. I want to have control of this, right? I want that, "Just implement one test. I'm going to give you the next test case, and then make it pass, and don't you dare do anything else," right?

I want that level of control, and, you know, which it's like snowplowing down a very gradual slope if you're skiing, and what's the downhill skiing version of that, where people are just flying, seems crazy.

These tools are capable of going a lot faster. Maybe they can be influenced instead of controlled. You get much more of the upside with very little of the downside.

It feels to me like I start a bowling ball rolling downhill, and then I have a hockey stick, and I'm trying to, you know, whack it over a little this way, but it's just a hockey stick, and it's a bowling ball, so it doesn't work very well.

I get a little bit of influence, I get a little bit of steering, but I'm not at all sure that... A little bit of steering, but I'm not at all sure that that's the most effective way to use it.

That's just the way that my brain can conceive it. Imagine that you're eight, and you're learning programming, and you're minionating, and you just never have that sense that you ought to be in control.

Jess: Oh.

Kent: So.

Red and green for tests is just not interesting for any interesting system. There's always going to be stuff that's kind of broken.

And like knowing where you are red or green is an input to understanding where you are, 'cause you can make mistakes that are definitely mistakes, and you like all those to be green.

But the system as a whole, you know, "I just made this change. Is the performance red or green?" Well, it's better in these cases and worse than those cases.

Is that better? I don't know.

Jess: Okay. so you can't have control. That's a thing. We don't have control when our minion is a real person, but we still have responsibility.

Kent: Sure.

Jess: And that gets back to those constraints you talked about. Your job is to put constraints around it, as the superego, and say, "No, don't do that. Not that way."

Tests are the way we have to do that right now. What's another way? And can we get there through observability?

Kent: Woo. Nice.

So if we're looking for emergent properties, like, "I made this change. Did the performance get better or worse? Did the error rate go up or down?"

We need to learn how to be explicit about those expectations in a way that models can then check and use those as a feedback loop.

Jess: Yes, and the Honeycomb MCP helps with this, 'cause I can have it go and retrieve the trace.

One of the first things I did over the weekend was have it add a service diagram to the README in my repo.

This is the Memeinator, so it has like five services, and it drew one based on the code, and it was wrong.

And I said, "Okay, let's run the app and look at a trace," and it retrieved the trace from Honeycomb with its fingers, and then it drew it again and it drew it right.

Kent: Hmm. Yep.

One of my augmented coding projects is a graph database backend, and it's already grown a fair number of options, like configuration options, and I don't know, okay, if I deploy it on an AWS, blahdy blahdy blah, what's the best configuration option.

I think, not trying to figure that out myself, but just deploying it, putting it under simulated load, letting the agent observe its actual behavior, and then tune the parameters from there is way better than me trying to memorize, "Okay, if the cache size is this, then the disk cache has to be this percentage of that."

Like why am I trying to figure that stuff out?

Jess: There's a place for reasoning these things out, and there's a place for, "Eh, just figure it out."

Kent: Yeah, and so the reasoning it out, the example I've got now is you can't just kind of bumble your way to a good concurrency model, figuring out, you know, where the semaphores go, and...

No, that requires real thought, and the models aren't great at that. They just kind of back you into deadlocks, and then not know how to get out of them.

Jess: Yeah. How's that going with your database?

Kent: Not so good.

Jess: I love that you tried to have it write a database in Rust.

Kent: Sure. So this is going to be one of my first screencasts is going to be writing the database, but I think I'm going to use Go, or maybe I'll do it in Go for two hours and then I'll do it in Haskell.

Jess: Oh yeah, yeah, yeah. Does Haskell really offer the constraints that you need?

Kent: Yes. I'm curious, will this actually work? For Haskell, I want...

So, a limitation now is if I'm working on iOS, my iOS app, and I'm using Xcode, the compile errors don't feed back directly.

Jess: Oh no.

Kent: And so I'm copying and pasting whenever it gets compilers. I really need that to be automated, and in Haskell that would be even more important to have it be automated.

Jess: But all you need is a VS Code language server.

Kent: Okay, which I could implement if I wanted to.

Jess: No, no. Those exist, for Haskell, and presumably for...

Kent: Oh, oh yes. Yeah, yeah, for that. If I wanted to connect it to Xcode, I could build something that, you know, took screenshots.

That's the other amazing thing. The inputs can be so rough, I can just sketch something on a piece of paper and go, "Here's the architecture," and it'll go, "All right, here's the user interface. Okey-doke."

Ken: That's cool.

Jess: Wow.

Ken: That's very cool.

Kent: Yeah. kentbeck.com got a refresh thanks to Claude, and I literally just, I drew a circle with a stick figure in it and put some topics around it, and then it went and generated a bunch of HTML for me, and there it is.

Jess: Nice.

Kent: Yeah.

Jess: We've talked about how we need to give it constraints. We need to make our expectations explicit, and then give it a way to measure those.

Kent: Yep.

Jess: I think that's where observability comes in, because then you can also see what's really happening in prod. Do you have any concerns about the quantity of code generated?

Kent: A lot of it's crap.

If you treat code as an asset, having a bunch of code, even if it's crap, is a better thing. There are organizations, though, that are really good at treating code as a liability and reducing the liability as much as possible, consistent with getting the outcome you're looking for. We have to rewire our organizations to be happier to throw code away.

Jess: Hmm. Yeah, ourselves and our organizations.

Kent: Yes.

Jess: Right? Because I agree, code is a liability. You're responsible for its outcomes.

Kent: Yep.

The responsibility doesn't go away just 'cause the code's easier to write.

Jess: Exactly.

Ken: Right, but with observability, you can actually see what's going on, so, I mean, you've got this giant code base, you're not sure what, everything that it's doing in production. You need to observe it, pay attention to it.

You can't possibly know every possible case you can create a test for, 'cause users are going to do weird, strange things to the code that you didn't write.

Jess: Yeah, you're right. We have to let go of deeply understanding every bit of code and feeling like that's where our control comes from. We do need to make the code report to us.

Kent: Right, to become more aware. Here's a side project for you guys, Honeycomb in an hour: Re-implement as much of Honeycomb as you can in an hour. It's kind of like a speed run.

Jess: That sounds fun.

Kent: So you could have a contest, and you could say, "Here's this list of 100 features. How many of them can you get running in an hour?"

I'm a big fan of the reinventing the toy version as a learning experience, and that's something that is completely within reach for everybody now.

Oh, you think observability platforms are easy to implement? Go ahead, implement one for an hour, and then you'll understand why the professional version is actually worth money.

But you'll know a whole lot more after you've done that.

Jess: Oh yeah, Martin said he plans to implement Honeycomb querying in the Aspire dashboard, which is like, it just fronts locally in memory and shows you OTel output, shows you traces and stuff.

And, yeah, so Martin plans to do that exercise, of implement Honeycomb-style querying on top of that.

Kent: Nice.

Jess: Maybe he can do it in an hour.

Kent: The nice thing about time limits is it keeps you from going too far down the rabbit hole.

Ken: Yeah, right.

Jess: Okay, so, Kent, if people want to hear more, where can they find you?

Kent: kentbeck.com gives you kind of an overview of the many, many, many different kinds of things that I do, art, music, poker, writing, et cetera, et cetera.

My newsletter, which is my main business, is tidyfirst.substack.com, and I write about software design, I'm writing about my augmented coding experiences, I write about personal growth, incentive systems, just whatever kind of pops into my head.

We have a fantastic community there, people talking about similar kind of people writing software.

Jess: It's a good newsletter. Can recommend.

Kent: Thank you. There's those. I'm available for consulting and giving talks. I love giving talks in internal conferences, so if that's something you're interested in, let me know.

Jess: Great. Thank you so much for joining us.

Kent: Oh, thank you so much for having me. It's been a delightful conversation, and the world of possibilities, for you, for me, for everybody, is just opening up, and I couldn't be more excited to be part of it.