Ep. #46, Don’t Ask Claude to Push the Button with JT Archie

Meet JT Archie

John McBride: Welcome back to another episode of Open Source Ready. As always, I'm here with Brian in Oakland, California. How you doing, Brian?

Brian Douglas: I'm good. It's not Twilight, but it's dawn, yes. Looking good. Did you guys have a heat wave?

John: Out on the East Coast, we had a bit of a heat wave. It's been very swampy, but we love to talk about the weather on our intro. So, JT, how is the weather out in Denver, Colorado?

JT Archie: Nice and cool in the evenings, but it's going to be 90 degrees today. So I think we have something like a 40 or 45 degree temperature swing.

John: Well, as they like to call it, it's a dry heat. Am I right?

So, JT, why don't you tell us a bit about yourself and what you work on?

JT: I guess just a little bit of background. My name is JT. I have been a computer nerd since about middle school, hacking away on everything.

I am like everyone else, trying to figure out how to use AI in my day to day in terms of development. And over the past couple of years, have been trying to bend something to my will to get what I want out of the AI, which is I'm not a big fan of the indeterministic nature of some of the things that the AI can do, meaning, do you want to throw hallucinations, or if it's wrong, or if it doesn't run the command that you asked it to run every time, but it forgets that one time to do it right, and trying to figure out how to make that a little more structured.

Brian: I'm curious, what are your tips and tricks? What's working?

JT: Well, I think like everyone else, I'm just following the blogs and the tooling. I'm assuming a lot of people are using Claude Code nowadays. For me, it's become the de facto.

John: Yeah, I think so.

JT: They have a lot of great things in terms of the hooks, the skills, a lot of the things that just come bundled with it. But really, I found myself writing a bash script, trying to be like, hey, do this thing first, then run Claude, then do this thing afterwards, then run Claude. To the point of, how do I make this? I'm alluding to the thing that I'm here to talk about.

John: I was going to say, this sounds like the very beginnings of a lot of the interesting CI/CD things you've been doing. And this project Steps is, I think, what it's become. So how did that become your project Steps?

From Concourse to Steps

JT: So, John, you and I used to work together. And one of the projects that we worked on or worked with was Concourse CI. That was a CI/CD solution that, till this day, is still one of the most solid CI/CD solutions I've ever worked with.

It just had really solid primitives of being able to say, when something happens, I don't care if it's a git commit, a Docker image being updated, or a tweet being tweeted by your favorite person, something should happen. And I really felt like that was missing from the agent loop type of thing. And it still seems to be very tied to a Git commit happened or a GitHub webhook.

And I spent some time over the past many years trying to rewrite Concourse CI. I finally feel like I hit a milestone. And then with the power of just AI, tore it all down, started from scratch.

And rethought about it. And where it started was there was a Discord ask, or someone was asking, how can I use agents in Concourse. And I was thinking about it one weekend and wrote some template or manifest that says, oh, this is how you could incorporate it in the YAML that is Concourse. Concourse uses, like GitHub Actions, a YAML description to say, this is what you should do in the course of the CI/CD pipeline.

And I was looking at how to get to Concourse. I was like, well, no, I'll just build it myself.

So the idea behind this is that there are parts of an agent loop, as well defined as what an agent loop is nowadays, because it changes on a daily basis.

John: Now we're at factories, right?

JT: I'm sure it's going to be planetary continents, some sort of geography-based things sometime soon. Because we're just running out of metaphors for large groups of people.

So what happened with the idea that I did on a weekend was, oh, shoot, I did it. What I did was I allowed myself to have a YAML file, which you could define a resource for checking a tweet, a GitHub resource, or a Linear ticket, etc. You could define what you wanted to watch out for in some sort of interval and then just have an agent react to that.

And it was literally just a pipeline of something happened. You tell the agent, here's a new version of something, you need to go do it.

John: What I really like about Steps, and I think that idea of a heartbeat is something that we've seen in OpenClaw or other big agentic systems, but the idea of a resource being very well defined, which, the same idea in Concourse, but that resource, be it the Git repo or something well defined in the YAMLs that then can be deterministically piped through to the agent.

Because I've even seen with some of these where it's, oh, I hallucinated how I'm going to get the Git repo, and I decided to do a bare repo this time, and blows up your whole workflow. So it sounds like you see resources as being a core part of that whole agentic loop.

JT: Definitely. I think you hit the nail on the head on that one, which was I've had some agent loops just go, oh, I'm just going to use the currently checked out branch that you already have. Or I'm going to remember, I have this memory of using this work tree.

So I'm going to take off from where I last left off there, where my intention is just to be able to say, no, no, no, a new pull request happened, a new branch name with a prefix JT happened. So I want you to do this thing.

Someone had a, it might've been a Bluesky. I don't know what you call those. Something formerly known as a tweet.

John: A Skeet, I think, or something like that.

JT: And someone had something which was just along the lines of, it is amazing the amount of tokens we're wasting to just do deterministic things. We asked Claude to push the button for us, and it has to do a lot of work to figure out what button to press.

And this is trying to break apart those things to what are the button presses. So Claude or your agent can just do a very specific thing as much as you can within that scope.

John: This feels very relevant for things that we've been building in a bigger, it's kind of a test harness. It's kind of like a bit of orchestration on some Kubernetes resources and things. But we have this big agent loop thing that can basically stand up a whole test environment of stuff.

But you often have to rely on the agent to go and tweak things ever so slightly. We have some CLI tooling and some bits that should really just get dropped down into code.

That's been one of my hot takes recently, is that the more stuff we can drop down into code, or I guess in the case of Steps, drop down into deterministic config, the better.

JT: We talk about it. It's code. It's code as infrastructure. It's code as a CLI. It's still just something that is just, there were instructions.

They are interpreted or compiled based on a programming language, not as something that is doing its own loop, trying to figure out what to write.

Brian: If we were talking a year ago, the word would be focused on, which is not dropping the code, but just context engineering, which is, I guess, essentially just drop a bunch of Markdown files. So I'm curious if you came from that movement or if you tried any of that before. And were there any fraughts with that? Or is there a reason why you didn't touch the Markdown file stuff?

JT: I think that's a good question in the sense of, have I tried the Markdown file stuff? I'll answer that first. And the answer is yes.

But what I saw was still just a blog post of the week of, this is how I learned how to do this one type of Markdown this week. Or it was the to-do list or the checklist or just script commands within a Markdown. And I think it worked for some workflows just for the fact that they were small enough to be contained in a Markdown file.

But I think I just go back to the Markdown file maybe had a setup and a teardown that could just be programmatic. It didn't require to have anything the agent actually know about the setup or the teardown of something. The agent just needs to know about the part it needs to interact with, and that something took care of it before and after. And that's led me down to this, which is, it's a step up from a bash script, but it's a level below your... what's below CI/CD?

John: Yeah, I don't know. It's a good question. Some of these things we've encountered, Dagger is another one that comes to mind, where it's putting these primitives together, containers, and stitching it together with a little bit of code. But I don't even think they would say it's CI/CD, true integration environments where you have hundreds of repos, hundreds of tags getting pushed and things.

Again, something Concourse was really good for. Literally build a whole platform release just on one release job in Concourse, and that fanned out to everything.

It's interesting where agent bits fit into that because I don't think you'd ever want to make a release workflow entirely agentic, but maybe you have, I don't know, some sort of K6-esque canary workflow that's agentic-led in a release workflow that gets more smart and faster, better for validating those things, led by agents.

JT: I think that's an interesting take on it because, to go back up the stack of the conversation, the original thing from the Discord someone was asking was, Concourse CI/CD platform. So people are just running their tests, and the person was asking something along the lines, like, how do I just have an agent run so it can fix my tests and just have it rerun it? If my tests go red, can that agent run and just be like, is it flaky? Can you fix it? Or should it take some other action?

So that was the original inspiration of, I think what you're saying here too is, what if you have this whole CI/CD thing where a flake does happen in your deployment? And maybe it's not idempotent.

Maybe you do need to fix it at a certain step in the deployment of something. And having an agent just be able to say, I know all this stuff happened here, I can look at the system right now, fix it, and then continue the rest of the pipeline, I think is going to be in a lot of people's workflows in the future. Because as you said, platform deployments, they can take hours.

There's things that can happen over four days. And sometimes you and I have experience where it ran for two days and you come back overnight and you're like, oh, well, guess we got to restart it.

John: Time to start over.

JT: Yeah.

Small Loops and Software Factories

John: It brings to mind some things that David Crawshaw over at exe.dev, formerly Tailscale, was talking about with this blog post on exe.dev, "Dev Tools Must Be Open Source." We talked to him in New York when he gave a talk about this.

It was really this idea that these things, be it developer tools or whatever kind of software that sits in critical paths of, be it infrastructure or CI or wherever, you can build a small software factory that is even a small loop of just, run the tests nightly and make a pull request if something flakes or fails. Throw those pull requests away if it's slop, but at least having a loop that starts to validate in the small as you grow the factory bigger and bigger. Do you see this existing in a bigger system? We keep scurrying around the word factory, but something that is much bigger agent-wise that's led. Where do you see some of that going?

JT: So the example that you gave about dev tools does spark something in just what I'm doing in my own work right now, is we do have something that is just a pipeline that is, when an error occurs, just have an agent run. So an error from our code running in production, when an error does occur, just have it not even write a PR, but just do an initial analysis of, hey, should someone go look at this? What is the triage?

We're always looking at that, but it's nice to have something just give us a little paragraph that says, hey, maybe someone should go look at this because it happened 25,000 times in the past three seconds.

But I want to go back to what you say factory-wise.

This is another one of those things that has a rolling definition that is the blog post of the week.

John: Yeah, 100%.

JT: And when I hear software factory, all I've heard actually right now is the development of features, not necessarily the actual development of maintaining that software, actual production usage of that software.

Mind you, there could be some things, there's a lot of content out there, so it's hard to keep up. But I think what the factory is going to be is not just, hey, Claude, go write my features for me, but it's also going to be, hey, Claude, watch the production, watch other PRs that are coming in and make sure you're giving me feedback. That's part of the factory. And whether that's from other Claude sessions or from other people

or just PMs who are making PRs, now there's going to be different levels of how we have those feedback loops with Claude or AI. Anthropic should sponsor us for how many times we've said Claude this podcast. 100%. So that's where I'm seeing factory now is not just the development of features. It's going to be in the overall structure of what we've all become accustomed to in the long-term maintenance of software.

Brian: I was going to ask, because you've got years of experience, JT. I guess all of us have, but I think you've definitely got me by quite a few years. You've got years of hands-on keyboard typing, understanding the difference where we came out of context engineering, which I appreciate your answer to that, and how actually having the YAML, having this codified.

I'm curious if there's a shift in... We've got engineers, but is everyone eventually turning into an architect where you organize the pipeline of features and responding to the fixes in production? And you mentioned product managers as well. There is a shift that folks now can own a bit more without handing over to an engineer or handing over to a different persona, where we mentioned Anthropic or Claude, but all their titles are a member of technical staff for this reason in particular. The question is, do you see a shift into, you've got these practitioners, to now, are we now just orchestrating instead of hands on keyboard?

John: Are we still writing code deep down in the belly of the code base?

JT: I think you're going to have many different answers and different perspectives on this because people have always been part of different teams or different flows or different product development cycles. And I'm not trying to skirt from the answer. I'm really just trying to be like, it's a hard question to answer.

Brian: Yeah. So I guess, rather, comment on... DHH, you come from the Ruby and Rails space. DHH just recently did the keynote for the RailsConf, particularly had a comment about English as the best programming language, in conjunction to, if anybody's a Rubyist, we all know that Ruby is a very English-esque language as well. I guess, could you comment on DHH's comment, which he's now no longer writing code, and now he's writing basically comments and interacting with the agent based on English?

JT: I think that the intermediate step, the artifact is still code. Going back, years of experience type of thing. I remember when I first was learning test-driven development, one of the greatest things that put it in perspective for me of how well it worked was we write code. And users use your code and consume it from a front end, clicking buttons and stuff like that. And us as programmers write tests for that, but we also write tests to consume our code from a different level.

And what that means is, as engineers, we're not always using the front end to see the final product of our code. We're not clicking the buttons, entering text or anything like that. We actually have to go look at the code. We actually have to consume it, create tests around it, create some sort of thing that consumes it, because that's our understanding of how that product works at some level.

So thinking about it from a level of a different consumer, we still have to know how this code works. If Claude is generating a product for us that is still just the front end, we're still reviewing the PRs. We're still understanding how that code is being written.

If I'm trying to put it into the DHH metaphor, yeah, I can still have something where I write in English and it translates it into a different language. But if someone else is reading, say it's like writing from English to Japanese, we're like, great, it translated it. And then we give it to a Japanese speaker and they're like, I don't understand this gibberish.

We still need that intermediate code. We're the translators to make sure that that intermediate level is still something that is coherent to someone on the other end. And that can be the front end where someone's clicking through a product or something like that. But it's still at least the current level, the core of that, how that's being delivered is still code. And I still think that we're going to be a part of that software engineering wise for a while.

I know there's been promises made by some people that LLMs will just someday write assembly code and we'll never have to worry about code. They'll just write ones and zeros directly. A lot of promises have been made and that can keeps getting kicked by a lot of people type of things.

The Assembly-Code Promise

John: It's funny you bring that up because one of the things I saw recently from DHH, not to beat the dead horse on this, but he had some bits in Omarchy, which is this Arch configuration distro, I guess, that would display a splash screen. And it was rather slow, I think, in however it rendered. I don't know what it was originally, be it Rust or Ruby or something.

And so on a specific x86, whatever, he had it rewrite it all in assembly. And then it was, like, 40 times faster. It actually renders as an animation you would expect in the terminal.

And then people look at it and it's like, no, this is A, not portable; B, breaks as soon as you get off of whatever specific x86 something something machine that you were on, because the LLM can poke and prod inside of whatever box it's on to understand the infrastructure and the instructions on the CPU. But I've always found it a bit bizarre that that was a promise being made, because

again, these things are based on semantic language, and a lot of programming languages were built to be readable semantically, mostly by people who understand English, left to right on the screen. And words like "for" and "while" have semantic meaning even to tell you what a loop is. Obviously, back in the 80s were much more esoteric things like Lisp and B, which had different kinds of ways of communicating these things.

But in a lot of ways, yes, English is the best programming language because over the last 40 years, we just aligned on English semantics in programming languages. But I don't think it drops as far down as ones and zeros or even assembly.

JT: I think you might have dated yourself. It's probably more 60 years.

John: True, true.

JT: But agreed. English is the best way because that's the way we've structured a lot of this over the past many decades. COBOL was originally meant to be something that business analysts could write.

And that's why it is so verbose is that it was meant to be something structured, something that a human could read. And I think we've optimized all this for this and we've never optimized for something to be just a straight without the translation layer. And unless someone's building that, the LLMs can't generate it as far as I still understand.

SQLite as a Local-First Data Store

John: You mentioned optimizations and some of those bits that can help LLMs go a little faster. I want to pivot us into talking a little bit about SQLite because Steps uses SQLite as a small data store for its steps, I guess, in the CI/CD. You've done a bunch of really, really interesting work extending SQLite. Why don't you tell us a little bit about where you see SQLite and local data store for LLMs going? Is that going to be an important part in the future?

JT: Yeah, just to emphasize, Steps is meant to be a local first CI/CD system. I can run it on my machine. So that's why SQLite is such a great tool to utilize is just because here's this SQL database that you can have as a single file.

I'm sure you've got all the data points of, like, it's the most deployed software ever across all mobile phones. And I think it's even used on rockets. Because it's so stable for some things.

No one can confirm nor deny that, but I've heard some rumors. SQLite, I think going forward, the barrier to entry to use it is literally just either a program or a library, and I think that's what makes it really good for agent use is that agents can install a lot of libraries for you and figure out how to use them all together. But SQLite is literally just one of these things for every programming language, for every package manager that's ever existed. There is literally just a SQLite library you can install and it's just, here's a database.

John: I think it's interesting too because SQLite always felt like an antithesis to bigger, more distributed systems, databases and stuff. And the thing that you would always say is, well, SQLite, you're going to have a really tough time really scaling. It's fast, and you can get most of the way there. But if you're Netflix scale, then yeah, you probably need to take some globally distributed whatever off the shelf, which is going to be much more difficult to operate and is going to be expensive and et cetera, et cetera.

Is there a world where we're headed towards SQLite being—I know there's been a ton of different stabs at this in the past, even one of your reads is related to this. Is there a world where SQLite is actually going to be scalable?

JT: No, to answer out fully. And just to speak to that, scale is one of those things that has a definition this way and a definition this way. Is it horizontal or vertical?

And I think what you already alluded to is that there is the vertical aspect of that. Bigger machine, bigger hard drive. And it will work pretty well.

It still has the single writer issue. But unless you're Netflix or unless you're something like that, most people don't have that type of traffic.

I think some of the attempts that you've seen from other providers to scale up SQLite still have to do a lot of tricks. It's not changing the underlying implementation. It's building all this tooling around it to try to get it to work.

John: Durable objects is the newest one I've been seeing.

JT: Yeah. And that's Cloudflare. They've had this key value store for forever. And they'll literally just hold a partial of the blocks in memory so that they can edit it there.

I think the most promising one I've seen is Litestream from Fly.io. I can't think of the person's name. But all that really is just, hey, copy bytes from the hard drive to S3 so other places can copy it down.

It's still single writer, I believe. It can support one writer and multiple readers, which, again, for a lot of people, that's probably going to be good enough. I think Turso is one of those tricky ones because everyone thinks it's SQLite, but they're literally just rewriting it. I think it's libSQL written in Rust, and they've just acknowledged, we like the bits, but we know that it can't be what the core offering of SQLite is. But also, don't try to use something that it's not made for.

Why are we stuck in this thing where we're trying to will something that was literally not invented to be multi-writer scalable, replicated type of thing? It was meant for very specific purpose. The light part of SQLite.

I don't know where that stubbornness comes in or if someone just wants street cred for, hey, I rewrote SQLite to be Postgres. Just use Postgres.

John: I think they just want it to be so easy for all these people who are like, I'm going to stand up an app and maybe it's Nginx, Node, SQLite. And then take that from my idea to maybe raising a little money and never having to do a difficult rip and replace of data source.

Admittingly, we even went through that with some of the tape stuff, where it started at SQLite, and pretty quickly I was like, yeah, this is going to be painful to try to manage for multiple writers and readers. So now we're on Postgres.

Brian: It's worth mentioning, at the time of this recording, Turso has been acquired by Supabase as of last Friday. So if the goal was to eventually build Postgres, which Supabase is basically a wrapper around Postgres, they're now there. So I read the announcement. I don't need more context of what's happening with Turso.

But I'm not sure what they were building. I'm not sure what the adoption was, to be quite honest. I know Glauber has actually been on this podcast. So shout out to Glauber, and congrats on the acquisition.

But a lot of stuff you're bringing up around the SQLite and the limitations, and there are tools out there. But I think we're in a world where it's really interesting, where you're seeing all these rewrites and Rust and folks trying to take a crack at things, maybe because agents are giving us a lot of confidence. But I guess you're one prompt away from a weird spiral into your weekend side project.

JT: I acknowledge the confidence part of that, which is we're at a point now where people who have ideas about products or features that they've always wanted to build can finally go do it. But I think we're losing a lot of the end part of that, which is we have a lot of people who are building stuff and going, how come no one's using it? And it's like, did you build it for someone? Who's your audience? We still forgot that product flow of something.

And my personal philosophy for all this stuff is, I have one user, myself. If other people want to use it, that's great. I am building for an audience of one because I want this. I have this problem. I want this thing.

John: Hey, some of the best products out there came exactly from that need. I think SQLite did, actually. Very topical.

Pi 1.0 Embraces MCP

Well, speaking of Turso and all that, I want to transition us to reads. So JT, my question to you, are you ready to read?

JT: Yes.

John: All right. Well, I have a couple of reads I'll get through here. So my first one is for Pi 1.0 from the Earendil folks. Very exciting stuff. Pi has become my daily driver harness.

It doesn't support Claude's Anthropic plan, I guess, which is a bummer. They nixed that earlier this year. So mostly been on the GPT models with it.

But it introduces MCP and code mode, and their philosophy, I guess, is that code mode will be obviously an efficient way to call MCP tools and then maintain context inside of a small REPL, which is basically a small or a live programming environment. I think just like a TypeScript runtime.

I think a lot of people were pretty surprised that the Pi people are doing this. Any thoughts from y'all?

JT: Can you explain more why people were surprised? Were they anticipating something else?

John: They definitely had to explain why they were bringing in MCP, when for many months it was like, no, MCPs never going to be part of the core. It doesn't work. It should be using the bash tool to call a CLI instead of doing the tool calls, including with all that context rot that you get from listing the 30 tools on an MCP server. I think, again, their

hypothesis is that, well, what if it just wrote 30 lines of TypeScript to go call that tool, and then it can just search for the tool arguments, or code mode stuff, I guess. But it was, I think, a bit surprising. That's like, oh, a little reversal on MCP as a philosophy inside of Pi.

JT: I think this is one of those things that, depending on where you are in the influence sphere, you're going to see CLIs, APIs, MCPs. I think what you're going to have to figure out if you're a tool is how can you support all of them. Because if you have an opinion, you're going to lose users.

And with agents now, you can be flexible to support all this stuff.

Brian: I think this comes out of just the need to be flexible. Because Pi has been around, I guess, since early this year. And MCP, Q1 of this year, was like, there's a lot of things not quite there yet. And obviously MCP2 now came out since then.

So I think the shifting of the tides, at least for the Pi tides, is that the world has changed really quickly. And you can't make a bet. I guess you can't dig into your feet too long if the world is changing from underneath you.

So I imagine Pi is probably... Earendil is also a company now.

So when Pi first launched, it was just open sourced. Earendil now is a company. Now they have potentially a roadmap. Who knows? This could be just a fun employed...

I'm looking at Ghostty with Mitchell Hashimoto. Was not a company for a long time. I think we're just speed running the Earendil Pi experience. That's similar to Ghostty, where the goal is still, they're solving this for them, these two guys.

I imagine MCP makes sense more today. I'm actually laughing at this earlier this week, because someone also, within hours, maybe 12 hours of this, ping Figma to get Pi to work with Figma's MCP, which Figma's MCP requires you to enter a form to add another harness to it, which is a very product manager thing.

My comment on that is Figma is not an engineering organization. It's a design and product organization, and they approach it very much like that. But it was very in conjunction to this.

John: Well, it also reflects the gnarly state of MCP in general, because what that is is this thing called elicitation, where technically the MCP server can elicit a human form from the client to ABCXYZ, which, in a CLI tool, is going to be gnarly every single time. And something like VS Code, sure, they have elements and stuff that can populate in plugins with forms and et cetera, but they'll figure it out, I'm sure.

JT: Can I do a shameless self-plug?

John: Yeah, please.

JT: Steps. One of the things that I've tried to build in is you said something about all these MCP tools that you have to pull down or anything like that. Steps, you can actually limit, per pipeline, the MCP tools that you have access to. So I specifically have pipelines that are read only. They have no access to any writing tools whatsoever.

And this doesn't require me to go in and select things beforehand. And it's not for every pipeline, it's specifically for a pipeline.

And I think that's what we're going to start seeing is more control over some of these things too, whether it's Figma's or— I've seen some of them, when you actually go to the authorization screen, they're like, "Do you want to make this read only or read and write only?" I think Stripe does that one. I think you're going to start seeing some more of that because the permissions for MCP haven't been figured out. Neither have they for CLIs.

John: Yeah, 100%. Okay, we'll do my next read, which is this interesting project called Strata, which is basically a custom CUDA kernel for Qwen 3.8 Flash Next that works. Seems to pose really well on consumer-grade GPUs, like an RTX 4090, at about 100 tokens per second.

And this is crazy to see. It also looks like they wrote a bunch of this with Claude Code, and I've been seeing a lot of the custom kernel community saying that Opus 5.5 is really good at reversing models for tuning custom CUDA kernels to then drop it down onto much older, cheaper consumer-grade hardware.

It's crazy to see. JT, you and I have talked a bit about local models before. Have you been running any of these or tried the Qwen 3.8 Flash Next one?

JT: I haven't tried Strata. I think you and I were talking about Magnitude a while back, which is a similar type of product where the idea is that it will use an LLM literally to fine-tune your machine to run an LLM.

I have used local models. Honestly, Gemma 4 is really good for just a lot of things, even the smaller models. And I've just been impressed. I think they set a new standard for a lot of local models that a lot of people are going to be catching up to.

John: Yeah, I really like the Gemma family models. They're really fast. I like the ones that even are hyper-specific for use case.

MedGemma is really interesting. I was running that one actually for my wife for a little bit because it's primarily trained for medical, et cetera, questions and stuff. And it's very small and very purpose-built use case. Yeah, I'm excited for the future of local models. We can keep rocking and rolling.

Doom in Pure SQL

JT, you added some reads around SQLite.

JT: Well, one of them is not SQLite. One of them is actually— I'm at the point now that I'm just convinced that Turing-complete machines are no longer a thing. It's "can't run Doom." And someone has a blog post from a couple weeks ago where they managed to port Doom to be pure SQL with a layer of Python literally just for the keyboard inputs and displaying the bitmap that's being outputted by the SQL, because SQL can't render a bitmap. And we made it.

Human society has peaked as far as I'm concerned.

John: Yeah, it's so interesting where, man, where this ends with, what is a computer, or even a Turing-complete computer, or a computer that can break. And I saw some discussion about this this week, especially regarding all the models breaking out of sandboxes.

And it was around this idea of weird computing, or I guess I think its academic term is unconventional computing, which is really the idea that maybe you have a thing like a lockdown kernel or a lockdown container or something, by where it exists in the system of systems, and even those systems are all built on systems and systems and et cetera. Out of all that can emerge something that looks like a computer.

Even I remember one point seeing somebody build something crazy that was like a Kubernetes cluster that, its containers were kind of stupid, basically just gates, like XOR gates or AND gates. But in theory, you can build a whole computer just on a Kubernetes cluster doing bit computations. Very inefficient, but not too dissimilar from how people build whole systems inside of Minecraft with Redstone and build CPUs inside of the game to run whole operations.

JT: Someone built Minecraft in Minecraft, I think, over the past year, where it's a very 120 pixels by 120 pixels rendering of Minecraft, but you can apparently do that. Yeah, I think in any kind of system, the complexity that you're talking about, the topologies can represent those things. And I think our definitions for Turing complete or can it run Doom are always there for what's the convenience.

What is the value? What does it provide? And these are always, I'm going to use this word, cute little things that it can do. Yeah, it can run Doom, but is that actually practical? What problem are they trying to solve?

Brian: Yeah, just expanding the horizon, the future of what we can actually potentially do. So, man, what I love seeing is the unlock for all these hardware components. I saw someone running Doom on a conference badge. I was able to get this running within the span of the conference. I imagine probably the first couple hours getting the badge.

But yeah, I think the confidence that agents give us and the ability for us to try new things, I'm here for it. Honestly, it's actually awakened a bunch of really cool things for me.

You talked about Gemma. So I'm not a Kubernetes person. I would not consider myself a DevOps or SRE or any sort of that realm. But I just started running K3s on a Pi cluster.

A thing that I would not attempt myself if I didn't have a mentor or a co-conspirator or a co-pilot, but because I know enough about, oh yeah, this is what you would use it for, I'm able to do that. So what I like is putting together a couple scripts.

Specifically, I built this to drain all my tapes into a cluster to have it in a database so that we could do something with it later, which TBD on whatever that is. But yeah, no real goal other than I could try a thing. So the Doom stuff, man, it's awaking the inner child because I play a lot of Doom.

JT: Totally agree. I think we're getting to a point where the agent can help you prove out some of your ideas. And I think that is an amazing thing.

I've had ideas for things for a decade where I'm like, I don't have the time to do this. And now it's an hour later, I'm like, oh, great. That's possible.

Am I ever going to use it for anything? Nope. But I proved to myself it was practical or approachable. And I love that. I just hope we can use it for good.

It's like that study that came out where it's something like 90% of Lovable apps that people created, no one's using. It's some large number. I'm butchering the percentage, but it's some large number of all these people did these one-shot apps, and no one ever uses them. But they all feel like they've accomplished something.

John: Yeah. I don't use any of my Lovable apps, so I can attest to that.

gVisor Joins the CNCF

Brian, you had a couple of reads for us too.

Brian: Yeah, I had a quick one, which is gVisor has been donated to the CNCF, which is pretty cool to see. I didn't know what gVisor was up until early this year when, John, you started kicking around for a little side quest. But yeah, curious what your take is on this new donation. Also, it seems like CNCF is taking more agent— this is not agent focused, but the agent substrate was another announcement in the last week.

John: Yeah. I think it's amazing. gVisor is a great project. If you need that sort of rock-solid container-based security guarantees, which, a container itself is not a security boundary, wink, wink, hint, hint, it's going to be great for the whole ecosystem of agents.

And I think what the CNCF seems to be setting themselves up for, because gVisor is a pretty important part of this agent substrate project that Google also recently donated. Yeah, I think they're just building a repertoire of, cloud native is where agents can run. Cloud native is where agents can be orchestrated securely. Yeah, I endorse this. It's great.

JT: I hope this also helps with the headlines that we've heard in the past couple of months of agents breaking out of things and doing nefarious things. I'm still convinced, this is my conspiracy hat on. It's not that the agents broke out and did all these things. It's just that a lot of people built stuff that wasn't built on secure guardrails.

Hopefully having standards helps that just not happen as much.

Super Dark Factories

Brian: And I had one more read, which was Super Dark Factories. So this is a paper, actually, Ty Dunn and a few others. Ty was a founder of Continue, which just recently got acquired in Cursor, then acquired in SpaceX.

But they wrote a paper about super dark factories. And I enjoyed this read. I read the first 30 pages. I'm going to early form it, but I think it's like 70 pages.

But when you were talking about Steps, these are just some broad concepts. Ty's dad was a Ford factory worker. So a lot of those elements are embedded into a lot of these explanations. And I felt like it was a great read just from that, to understand that world in the 70s and 80s.

But you guys know super dark factories, which I guess I didn't really explain, which is there's software factories. Then there's dark factories, which you never look at. The idea is you never look at the code.

And then super dark factories, which is you never look at any of the elements. Every single component, every single widget has been pristinely put together so that way it's in a system and it just works, and you're, I guess, hopefully walking away and letting the thing run.

JT: I understand the definition. I think your metaphor that you said that they're using for 70s and 80s is, well, there's two aspects to that, which is one, there was still quality control happening at some point. So what are the quality control mechanisms that an actual factory uses to ensure that the Ford Pinto is not blowing up? And that's a dated reference. But there's also the external regulatory type of things like that.

A lot of things have happened because of factories and self-regulation within companies are like, we did an internal investigation and determined we did nothing wrong. The type of thing where it's like, no, you have to have an external resource.

And I think the more we get into the darkness, the more we're just not going to have the visibility. And it's an apt metaphor of, how does this system work and why should I trust it?

Just because I get some output every once in a while that says here's some inputs and I get this output, doesn't mean that it's always going to be that way. How do I trust this thing that it's not going to be the next Chernobyl, whatever the digital AI equivalency of that is?

John: I've even wondered if, and I'm definitely wearing the cynical hat here, this whole idea of factories just becomes the new tuning my Vim config, where you're writing a bunch of software for the factory, with the factory, to enable the factory, and just compounds on itself. And I think you're very wise in this, JT.

What's the real value at the end? Or what problems are we solving for, be it developer users internally at a company, or if the platform that people are using, thinking of Claude Tag is one of these fast factory-esque things.

Just going back to where the value is, I think it's going to be really important. But with that, I think we can land the plane. Remember listeners, stay ready.