Thorsten Ball
· 6 min · Original

Joy & Curiosity #105

One of the strangest things nowadays is how everyone lives on a different timeline. Some people haven’t spent more than a hundred thousand tokens with the latest frontier models and conclude that agents can’t write code. Others have spent billions of tokens with them, in just the last week, and say that agents are now better at writing software than humans. In a few months, the first group will catch up. And that’s just the most obvious example, using the latest models to write code. There are many more things like that. Once you try them, your view of software development will be completely changed. Except not a lot of people have tried them and we all talk about software development as if it’s the same thing for all of us. “The future is already here – it’s just not evenly distributed.” I keep thinking of that quote. For me, the game has changed three times this year, with three different practices we’ve established at Amp: Going all-in on remote development and moving everything into orbs. You have to try it to believe it, but it is a change so fundamental that you will start to question everything: from the role of the operating system to what software even is. Asking agents for “irrefutable proof”. Made me question everything again: the value of tests, the value of looking at code, what it is we do when we “review” something, what specs are and what not. If there’s a 10x game changer, it’s this one. Letting the agent control the full SDLC. At Amp, the agent can ship things to production, monitor their rollout, read logs, turn on feature flags, send emails, grant credits, investigate database issues, check graphs, … Everything that I can do, except writing to the database. The models have become too good to keep them boxed in as smart typewriters. Let them see what…

Thorsten Ball
· 9 min · Original

Joy & Curiosity #104

Friends (and foes, of course)! No intro this week, for I do need to clean up the aftermath of a Halloween party and sneaking into my office and saying “I have to write my newsletter, people are waiting for it” can only work for so long. So, without further ado: here’s a bag of links to things that spark joy or feed my sense of curiosity. We don’t usually hire, but now we are: we’re looking for exceptional engineers to join Amp Labs in Sydney. I asked Oz, who is part of Amp Labs, what it’s like working there and he said: “It's honestly the most fun I've ever had. The problems are big and hairy and frankly feel impossible some times... unless, maybe, we point the agent in just the right way? I wanted to work with exceptional people, and to test the limits of this new way of working in highly consequential ways, and that's exactly what's happening here!” New Raising An Agent! This is, in a way, a follow-up to the previous episode about the Company of the Future. We respond to a lot of the questions we received since publishing that one: “How do you avoid slop if everyone can push to main? How do you do big architectural changes if you don’t have PRs or RFCs? What do you think about unit tests? And can’t you only do all of this because you have so many tokens and are only 21 people?” It’s all in there. Plus a bit where I explain that I count pizzas in pizzas (that’s right). Someone said it might be the best episode so far. “Our companies made strange bedfellows.” from building slack: Salesforce - Part one and two. I can’t believe someone finally did it and wrote an honest account about what an acquisition of this magnitude looks like from the inside. If you ever worked at a startup, I think you’ll enjoy reading this. You need to read this one. Yes, it’s long. But still, if…

Thorsten Ball
· 9 min · Original

Joy & Curiosity #103

… and we’re back! I spent the last two weeks travelling. First a week in New York City, then a week in San Francisco. I did many things in those two weeks, but not a lot of reading or writing, which is why you didn’t hear from me. But now I’m back! So, without further ado this week (my daughter is waiting for me to build a Lego truck), here’s a bag of links. We recorded a new episode of Raising An Agent, in person, in San Francisco. I think it turned out great. In fact, I said somewhere else that this might be the most important episode we’ve recorded this year. It’s about nothing less than the company of the future. Highly recommend watching this if you’re in any way curious about how Amp — the team, the company — operates. While in New York, we visited a large customer of ours, an investment bank. I gave a talk there about how I use Amp and what I think have been the biggest 10x multipliers when working with agents. In San Francisco I then recorded the talk and it’s been received very well, so here it is: How I Use Amp. Adam Mastroianni is truly one of the best in the game right now. Everything he puts out is incredibly good. This newest one, Claude, don’t touch my lump, is no exception. It might be the most convincing argument for why AI won’t lead to unemployment I’ve read so far. The only counter-argument I can see is that, well, there will be jobs in the long term, but what about in the next five years? “I’m 38. If You’re in Your 20’s or 30’s, Read This.” I’m also 38 and when I first saw this title I went “ugh”, because hey, feels like I’m only just starting. But it’s surprisingly good, even though it’s a bit Buzzfeed-y. Maybe because it quotes the life-changing Jason Pargin post? PhotoCraft: An open-source, photo editor written by scratch in pure Rust. I saved…

Thorsten Ball
· 10 min · Original

Joy & Curiosity #102

At the airport, on my way to New York to meet the rest of the Amp team, so no big intro this week. If you’re around, you should come meet us. The Next Feature Fallacy: “For people who love to build product, when something’s not working, it’s tempting to simply build more product. It leads to the launch-fail-relaunch cycle that I alluded to in a previous essay, Mobile app startups are failing like it’s 1999. However, this rarely works, and when you look at the metrics, it’s obvious why.” So, Google released Gemini 4 Argon. There’s a whole bunch of numbers and percentages in that post and most of them I don’t care about or trust, but this paragraph made me purse my lips as if to let out an impressed oooh: “A team of Argon agents analyzed fleet-wide profiling telemetry to autonomously identify and apply memory optimizations across Google’s data centers, freeing up over 300 TiB of memory once rolled out, with an estimated 500 TiB to 1 PiB in total savings.” Daniel Lemire with a fascinating perspective: “There is a divergence in society. Some of us have been frustrated by the lack of progress. We don't like what has been happening to our civilization since 1970. We expected lunar bases, rejuvenation cures, cancer cures, space trips... and all we got was Twitter. […] I feel that the people who love stagnation got enough of what they wanted and I hope that we are at an inflexion point where we finally break free from the oppressive rule of stagnation.” I’ve had similar thoughts before: if you walk through this small town in which I live, nearly everything looks like it did thirty years ago. One reason for that, of course, is that we now all spend many hours per day staring at screens and those screens contain large portions of our lives and no one has their screens sitting on…

Thorsten Ball
· 12 min · Original

Joy & Curiosity #101

Last week I was on Matt Swanson’s podcast and we ended up sharing thoughts and vague predictions about programming languages and frameworks. Matt said that he’d be going to Rails World the week after and that he wouldn’t be surprised if DHH said “Rails is over.” Prescient. DHH didn’t exactly say that Rails is over, but, well, some people did call the keynote a “funeral.” But that shouldn’t be surprising, right? The way we’ve treated languages and frameworks for the past, say, twenty years is at odds with the fact that writing code by hand is on its way out. I am not sure how exactly this will play out, but here are some loose thoughts: Frameworks are no longer the biggest developer productivity lever. Agents are a hundred times bigger. Syntax doesn’t really matter anymore, as long as agents can write it well. Tool ergonomics don’t matter that much either, do they? Previously, I loved that go comes with go build and go test and go run, but now I wouldn’t care if those commands were seventeen times longer. But I think shared abstractions are still worth it. A framework gives you a pre-defined way to access a database, to do auth, to divide things into production and development… That’s still handy. Not because it would cost tokens to build it myself (won’t matter in the future, see below), but because I just don’t want to think about it. What will matter a lot in the future: performance characteristics, resource usage, failure modes, observability, debuggability, deployments, rollbacks. And all of that needs to be legible to the agent. I’ve tried developing something with the often praised Cloudflare Durable Objects, on which you can run JavaScript, and it was a disaster: the agent constantly thought it was writing normal Node.js JavaScript; it didn’t know the runtime…

Thorsten Ball
· 7 min · Original

Joy & Curiosity #100

It’s the week of Jev! I’m really, really, really, really excited about it. I mean: really. It’s like someone blew up a confetti bomb in the world of LLMs and now you realize how grey everything looked before. But Jev is not an LLM. It’s a model “built to make fast, structured decisions that software can use directly.” TypeSafe says we should think of Jev “as a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out.” I explained it as a “smart if-statement” to someone and my only slightly longer explanation is this: Think of how you’d get an LLM to decide between a fixed set of options. Then imagine it orders of magnitude faster and cheaper. “What’s the best label for this?” “Should I click here or there?” “What’s the next line I should look at?” “Do I go left or right?” “Invalid or valid?” “Which of these widgets should I show?” I had Amp build a little Copilot-style autocomplete for a shell, with Jev picking the next most likely command from shell history. Then Amp built a Neovim plugin (and called it hunch.nvim, which is a great name) that uses Jev to predict the line you next most likely want to jump to. Now, let’s linger on this a bit. Two years ago, that was what Cursor was famous for. Yes, Cursor did and does more than that and the quality isn’t close, but… when we were working on Zed’s Edit Predictions we had to fine-tune a model to get into the same league! Now it’s a single API call and the latency is 200ms. That is incredible! Then I built a prototype that uses Jev to turn the Amp Dial, switching between models based on your prompt. Yes, all of this was possible before, but it’s so fast and so cheap that I still can’t believe it. Sometimes a change in cost and performance is what creates a whole new category of…

Thorsten Ball
· 4 min · Original

What I believe about the future of software development

This was originally posted on X and blew up. To plant my flag, to say that these are things I believed in September 2026, here it is on the blog, non-ephemeral. Some of these predictions are just observations, they’ve long been true at companies like Amp. Others will take some time to play out. Code review will die. I mean: it’s already dead. But in the future, humans won’t find a bug or an issue with the code produced by a model, at least not in a reasonable time. Humans will only review the system and its composition, but it won’t be in PRs and it won’t be by looking through every line of the code. Unit tests might die too. Why have training wheels if you never fall over? I’ve had models write 900 lines of Arduino C, compile it without a single error, and send it to the device, where the program ran perfectly. 900 lines will be nothing in the future. The craft of writing code will disappear. Yes, there are still Italian shoe makers around. But look at your feet. The craft of building software will be more important than ever. Knowing how to solve business problems with software, how other software did it and why and why not, when and how to ship it, how to get feedback on it – that’s the new game. Most bugs won’t be “coding” bugs. They’ll be “you asked for the wrong thing” bugs. Open source in its current form doesn’t make sense anymore. “Given enough eyeballs, all bugs are shallow” is still true but now we have artificial eyeballs. Performance critical contributions by humans will stay what they are: an edge case. In 99% of software it does not matter that you could’ve written a faster algorithm or picked a better data structure. You have no customers, no users, no one’s executing the code. It does not matter. When it matters, the models can fix it. Do not compare…

Thorsten Ball
· 17 min · Original

Joy & Curiosity #99

Something changed with these latest models, with Fable 5.1 and GPT-6 Astra. The benchmark numbers (79% instead of 65%!) don’t capture it, and neither do the benchmark words: this model goes on for longer than this one, this one is “most aligned”, that one the least “sycophant” (the ultimate benchmark word, no?). At this point? Yeah, whatever. But it feels like we’re now flying at a higher altitude, that we have to concern ourselves even less with earthly matters such as a single unit test or how to juggle thirteen commands to get this into that format and over the wire. That’s down there now. Up here, we’re now free to talk about what we want: “I want you to go and test this end-to-end, I don’t care how, and give me irrefutable proof that this works. Dazzle me. Give me a video as proof, or something.” And thirty minutes later, when I have awoken from the nap I had earned with all that typing and pointing and wanting, I look into the shed and, wouldyoulookatthatWOW, the golden goose laid the golden egg: a 60fps video that runs for 47 seconds, in which the golden goose itself clicks through everything it had built, end to end, navigating the application better than any user could, knowing exactly how to show me, provide proof, that this actually works. “This one now lays golden eggs”—that’s what I want to see in a benchmark. That’s an actual prompt I used. Here’s another one: “Go and spawn three other agents in three separate orbs and ask them to test this. Obviously, do not tell them that we changed the AGENTS.md file or that we added this tool to test database performance; just ask them to do something — like add new database queries or something — so that they ideally end up using this new tool to make sure the performance is there. Then check that they did use the…

Thorsten Ball
· 10 min · Original

Joy & Curiosity #98

Here’s the start of Chapter 7, ‘Naive Intervention’, from Antifragile: Consider this need to “do something” through an illustrative example. In the 1930s, 389 children were presented to New York City doctors; 174 of them were recommended tonsillectomies. The remaining 215 children were again presented to doctors, and 99 were said to need the surgery. When the remaining 116 children were shown to yet a third set of doctors, 52 were recommended the surgery. […] Let us call this urge to help “naive interventionism.” Goodreads tells me that I read the book in 2019. I honestly can’t remember too much about it, but that paragraph has really stuck with me. From time to time, when a friend or relative would say something like, “My doctor said I should …”, I’d pull it out of the closet in the back of my head and try to sound smart and say, “Well, you know, there was a study once…” Then I’d fumble the numbers, of course, and I’m pretty sure that multiple times I made it about wisdom teeth and not tonsils, but the point I would try to make is that people whose job it is to do X are biased toward thinking that doing X is more important than not doing X. And now I’m wondering: is this what’s going on? Is this what’s happening when engineers look at the output of a Sol or a Fable or an Astra and say “it writes bad code, it leaves all these dumb comments”? Bad code? Dumb comments? Really? Or did it just knock out a feature, end to end, in the 20 minutes you weren’t looking, including frontend and backend changes, including internal and external documentation, and tests of course; and didn’t it test it fully, running through the whole thing in a headless browser, presenting you with a video recording of the run-through as proof? But the comments are dumb? Some loose, sweaty, post-gym…

Thorsten Ball
· 9 min · Original

Joy & Curiosity #97

How many bugs are you willing to tolerate in your codebase? Don’t tell me it’s zero, because we both know it’s not zero. It’s also not a four-digit number. That’d be too much. But there is a number, or a range of numbers. Because we all know that it’s theoretically possible to get to zero bugs, but so far the cost-to-benefit ratio made it not worthwhile. And, on the other end, if the number is too high then your software becomes unusable and you lose customers. (It’s worth mentioning, though, that how high that number can go also depends a lot on context: no one drops their banking app because of five bugs they ran into, as long as the money’s where it’s supposed to be.) Now here’s my question to you: when was the last time you adjusted that number? With agents, bugs are faster to find and to fix. You can start bug investigations asynchronously and in parallel. You can find and fix bugs in areas of the codebase you never would’ve debugged before. You can throw an infinite number of agents on the same bug. Imagine it’s 2018 and in your engineering department’s office a genie appears and says: “Nice to meet you. Usually there’s this whole thing we do now, but we can skip that. I anticipated your biggest wish and here it is: a team of ten world-class engineers that have specialized in debugging and can find and fix bugs in any language, any framework, any platform. They don’t sleep. They don’t grow frustrated. They don’t want to build features. They live to fix bugs.” You’d of course look around and wonder whether anyone else is seeing this, but then you’d say: “Wow, okay. I didn’t even know I had that wish. But… I’ll take it, I suppose? Can I even refuse?” The genie disappears before you say that last word. And then you consider what you can do now, with that team…

Thorsten Ball
· 7 min · Original

Joy & Curiosity #96

When I compare the first 10 years of my professional life as a software developer to the last two it’s mind-boggling how many things that seemed foundational, or: institutional, in the life of a software developer from, say, 2008 to 2022 are now anything but that: GitHub and open source contributions (maintainers are closing down pull requests; who cares about their GitHub contribution graph anymore? When was the last person hired due to their open source contributions?), StackOverflow (you just said “ahh, right, StackOverflow”, didn’t you?), O’Reilly books, FANG as the hottest place to work, 2-week sprints (2 weeks, man! You know how long that is now?), TDD (I wrote books that use TDD! I loved TDD! And yet at some point in the last 2 years I wrote my last test by hand), text editors (man, I had heated arguments about text editors; I worked on a text editor; I was close to getting Vim tattooed on my body at some point), … It’s like Lenin said: “There are decades where nothing happens; and there are weeks where decades happen.” My Laracon talk now on YouTube: How I Prompt. What an intro from Aaron. I swear I didn’t pay him to say all of that. I love this idea for a Greasemonkey 2.0: “Modern coding agent + browser use + a custom personal extension that allows you easily modify your most frequently visited sites. Have extension track which sites you visit and then coding agent proactively suggests modifications to make sites less distracting / more efficient.” I just checked, though: 2.0 was released in 2014, so this will need to be called Jellymonkey 1.0. This is the best and most beautiful and most inspiring and most thought-provoking and humbling thing I’ve read this week: Canon. There are many great things in this post, but here’s one special snowflake of a paragraph…

Thorsten Ball
· 9 min · Original

Joy & Curiosity #95

In the last two weeks I’ve shipped: a new experimental provider backend for our orbs, an in-product bug reporting feature (not released yet) including an admin area where we can triage bugs, disk and memory warnings for orbs, visible setup logs when orbs are starting, a full Comet Busters-like game that’s hidden as an easter egg on our website, a microphone selector for our dictation features, a new work-in-progress page that explains what orbs are that has a bunch of handwritten text and videos and other stuff I put in there by hand, user preferences for themes, and a few smaller things. I also fixed around twenty bugs and removed 5k lines of code that we no longer need. “We get it, man, you shippe—” Nah, nah, nah! Not the point. The point is this: I have not used my local development environment for any of this. I’ve done all of this remotely, using Amp, in orbs. Everything! Backend for remote machines; messages sent across three services to warn about system resources; landingpage. The freaking game is probably the least surprising thing here, isn’t it? And it’s a game with custom assets! Isn’t this wild? No, I know, it is, that’s what I’m saying. “Surely some things you want to check or test locally, no?” Nah, not really. I mean, yes, that’s probably what I would’ve said half a year ago if you’d told me I won’t need my local dev setup anymore. Turns out that, no, you don’t. You can just ask the agent to give you “irrefutable proof” that something works and if you have an orb and it can do whatever it wants and install whatever it needs it will find a way to give you that proof. Orbs are malleable, the agent can shape them to fit the task by installing and running whatever it needs and and then you get a bespoke made-for-exactly-this-task machine in which an agent…

Thorsten Ball
· 10 min · Original

Joy & Curiosity #94

What a lovely week it’s been! Nearly the whole Amp team met up in Munich. We all stayed in the same hotel and in the mornings floated down to a big meeting room in which we then hacked, asked each other questions that are so easy to ask in person, actually used a whiteboard, talked about the future of software, shared anecdotes about agents, and just generally enjoyed each other’s company. The evenings we then spent nearly exclusively in beer gardens, which were, I’d say, a perfect showcase of Munich in summer. In between all of this, we recorded a lot of videos, and as part of that I spent roughly eight hours on the rooftop of the hotel, interviewing my colleagues, asking them how their workflow had changed in the last four weeks. The big non-surprise: orbs changed everyone’s workflow; no one cares about the local dev environment anymore. We all had to wipe our laptops three weeks ago, and at least five people told me that they had forgotten to port their dotfiles over, simply because they only work in orbs now. The actual big surprise that I guess shouldn’t be a surprise: everyone, without exception, was so eloquent, so thoughtful, so nuanced, and so full of curiosity when talking about agents and how we work at Amp. “Wait, you’re surprised that your colleagues are smart?” Nah, man, I’m saying that they exceeded all expectations! Show me another size-twenty team in which everyone you ask does a great job in front of a camera while being asked how their workflow has changed in the last three weeks and how their own expertise is now reflected in these things we call orbs. Good stuff. I wrote about the biggest puzzle I have to solve right now: What I Want to Tell You About Orbs. Someone called it a “a strangely beautifully written ad” and wondered: “maybe i should get…

Thorsten Ball
· 9 min · Original

Joy & Curiosity #93

Friends, yesterday got back from Boston where I gave a talk at Laracon about how I prompt Amp. Tomorrow I’m taking the train to Munich, where I’m meeting with the whole Amp team. Here’s some telegraph dispatches from this week, imagine someone saying “full stop” after each line. Laracon, what a pro operation! The A/V setup backstage was mind blowing. So many helpers! Going on stage felt like I was about to go on live TV. Few things as enjoyable as getting to see proper professionals up close when they do their job. A moment of these times: Taylor presented latest changes in Laravel live on stage (man, I don’t think I’ve ever seen someone be calmer and cooler while giving fantastic live demos) and started by saying “well, I don’t write that much code by hand anymore, but yeah, maybe let’s look at the code.” And then we all looked at the code and I couldn’t stop thinking about whether these abstractions in a framework are useful or not. Can’t the agent one-shot these helpers to display images? It could, I know that. But isn’t it useful to have these primitives in a framework? Maybe? He also showed some helpers around queue management, such as debouncing. I know what debouncing is, I can instruct the agent to add debouncing, I don’t need the helper. But what if you don’t know what debouncing is? What if you don’t even thinking of asking the agent for it? It would help to have these primitives in the framework, no? I finally, finally got to meet Adam and Aaron in person! A self-driving Cybertruck chauffeured me through downtown Boston. How are they not going to win this? Serious question. Finally had Raising Cane’s chicken fingers. Good! Very good even, but… not life changing? I kinda expected it to be life changing. At times I felt like a heretic. I would watch a talk and…

Thorsten Ball
· 7 min · Original

Joy & Curiosity #92

This week was busy: we shipped a lot of things, recorded quite a few things, I worked on my Laracon talk, chatted with amazing programmers in different timezones, and our local public swimming pool celebrated its 50th birthday. There wasn’t a lot of reading this week, but a lot of thinking and wondering and questioning and aha!-ing. And I kinda can’t shut up about it. So… Some of you might remember my original description of this newsletter: “It’s very informal; it’s what I’d send you if you were to ask me what’s on my mind this week in an email.” Now, here is what I’d say if you were to ask me what’s on my mind this week, on a phone call: Finally: Amp now has subscriptions. Yes, you read that right. Go there, get a subscription, pair it with your ChatGPT subscription so you get infinite GPT-5.6 tokens, and spawn those orbs. We also shipped agent-to-agent communication in Amp: agents can now spawn other agents — anywhere you have a Amp instance running or in an orb — and then send messages and files to them. The number of “holy shit, it just …” messages this produced in our internal Slack is insane. To give you a taste: this morning I was hacking on something in our orb, but the agent in the orb lacked the permissions to upload an asset to our bucket. So the agent said: hey, start amp —no-tui on your machine, where you have permissions, then I’ll start a thread there, send it that asset, and ask it to upload the file. And… it fucking did it! Exactly like that! I started amp —no-tui, I saw the new thread being created, I watched both of them, and saw how they sent messages to each other. Wild! Raising An Agent is back! Here’s the first episode of the new season: The Local Dev Env is Dead. Or listen on Spotify. I know what you’re thinking: “Thorsten, your voice… I need…

Thorsten Ball
· 9 min · Original

Joy & Curiosity #91

Last week, my 9-year-old started using iMovie on the iPad. She doesn’t know anything about editing. She doesn’t even know what editing is. But we opened iMovie after I told her, “You can use this to cut out the part of the video where you see my hand.” She said, “What do you mean, ‘cut out’?” So we cut the video up, removed some parts, moved others around. She then figured out how to add sounds and a soundtrack. Then, together (me, her, ChatGPT), we learned how to make the soundtrack play only at certain points in the video and so on. While we were doing that, I kept thinking that a model or an agent could probably do that. Or maybe in a year. And then you could just say what you want and it would edit the video. Cut here, cut there, make this the first scene, move these around, and so on. Then it hit me: she wouldn’t know what to say, would she? She doesn’t know anything about editing. She’s seen movies before, sure. That means she’s seen J cuts, L cuts, jump cuts, other types of transitions, title screens, and end credits; but she doesn’t know what those things are, does she? So how could she ask for them? By pointing at something else? “Make this look like that”? Would that work? Would that lead to the same results? And that, of course, made me think about software engineering. I hope it does the same for you. You can now remotely start Amp agents anywhere you can run amp: Agents, Anywhere. We spent a lot of time this week talking to customers and after demoing the things in the Agents Anywhere post on Monday and Tuesday and one person saying “this is the best thing I’ve seen today, I need this” we decided to get it out as fast as possible. And here we are: agents, anywhere you want. We also launched The Dial which resonates a lot with people. I’m still surprised by…

Thorsten Ball
· 5 min · Original

Ownership

The following is an internal Slack message I sent to my Amp teammates after I had a conversation with one of them about ownership. It’s only lightly edited. I shared it before, but not here, because I didn’t think too much of it. Then today, someone said their CTO shared my post with them and I thought: well, now I have to put it in the newsletter, don’t I? So here we are. Below, after the Slack post, I added some thoughts on juniors on how I see this advice applying to them. Just had a (great) conversation about ownership and engineering here and I realized that I often use the phrase “ownership” or allude to it, but haven’t explained what “ownership” means to me in a while. So, ownership. If I ask you “can you own this?” or “can you take care of this?” or “are you on it?” — what I’m doing is I’m asking you to own it, to own the solution of a problem from end to end. From “we have a problem” to “we don’t have to think about it again.” That means, when you say that you’re owning something, the expectation is that you… Think about what the problem actually is. Maybe you already have a solution in mind, without having thought about what we’re actually trying to solve here. Maybe you think “the problem is that we need to migrate from using X to using Y”, but that’s not a problem, that’s a solution. The problem is likely something like “performance is bad”, “it’s not stable”, “it fails for customer x”. Maybe there’s other possible solutions to that? Think about those. What are the tradeoffs? What’s the best solution to go with considering these tradeoffs? Think about edge cases. What are they? Which ones are important? Which ones can we ignore? Think about failures. Network failures are a given, for example. How do we handle them? Retry? Well, how often? How long? Think…

Thorsten Ball
· 8 min · Original

Joy & Curiosity #90

… aaaaand we’re back, ladies and gentlemen! That was a nice three week break and I’ve thought quite a bit about what to do with this newsletter when I come back to it. The result: I’m going to double down on having fun with it. I think I’ve gotten into a bit of a rut, after trying to follow the recipe every week for years. I don’t know what that means exactly, but hey, you’ve been warned. We released Agents in Orbs this week. This has been a long time in the making and now it’s finally out and people are already starting to say “in an orb” as if it’s a common phrase, I love it. I truly believe that remote agent— excuse me: agents in orbs, will play a big role in the future. Why? One reason is that these models are incredible when thrown into a sandbo— I’m sorry: an orb. I mean, look at this. There aren’t any magic strings being pulled behind the curtain. If there’s ffmpeg, a model will find a way. These agents need less and less handholding and that includes the handholding by a bespoke development setup. They’re productive in these remote machines. The second reason is that something changes when you can start many agents in many different orbs in parallel. I tried to articulate that in that post up there but based on the conversations I had in response, I think it’s something you really have to try for yourself. But I can add that the more I use agents in orbs, the more I believe that thinking of remote agents as “agents that I can remote control on a different machine that’s similar to my local machine” is the wrong way to look at it. The fact that the orbs are ephemeral changes what you do and how you do it. Just like switching from a single build server to a build system with VMs changes things. State is no longer an issue. Resources and runtime is no longer an…

Thorsten Ball
· 8 min · Original

Joy & Curiosity #89

Friends, Joy & Curiosity is going into a bit of a summer break. Two, three, maybe four weeks. I’m not sure yet. But it’s now been three years of writing this newsletter on my weekends and I feel a need to not do that for a while. I want to have some unstructured time: to play, to experiment, to write or maybe not write, to do something different on my Sunday mornings. But today I still have for you, a bag of links: Unlike what seems to be most of the Internet, I still don’t know what to make of this document that Anthropic published: When AI builds itself. It is remarkable, for many different reasons. For example, some say that the intention behind publishing this is to hype themselves up before an IPO and this section here does have a smell of “everyone but us must be stopped”: “If it were possible to effectively slow the development of this technology to give ourselves more time to deal with its immense implications, we think that would likely be a good thing. But if a slowdown simply lets the least cautious actors catch up technologically, it could leave everyone less safe.” But those concerns are founding maxims for Anthropic, so I don’t doubt they’re sincere. And if they wanted to hype themselves up, would they share all these concerns about AI’s progress in the future? “The evidence we’ve laid out here suggests that we’re likely heading into this scenario. But speeding up one part of a process often just shifts the bottleneck elsewhere […] But achieving recursive improvement alone does not suggest an immediate change in how industrial production occurs, societies organize, or markets function. More intelligence can’t learn what a drug does over decades of use, can’t hold elections sooner than a constitution dictates, and can’t turn a stranger into an old friend…

Thorsten Ball
· 6 min · Original

Building Software Is Learning

A few weeks ago I shared the following as an internal message with the Amp team. I showed it to a friend while talking about feedback loops and he told me to post this publicly. So here we go. Unedited, straight up copy & pasted from our Slack. You know what’s rare? person a: “we need this feature” person b: “yes, let me build it” ... person b: “done.” person a: “fantastic, exactly what I wanted.” That’s basically NEVER what happens. At least not when you’re building something new. It might happen when you fix a bug or when you port something that already exists in another app to a new language or framework, ... Or when you’re building after a spec. But when there’s no spec, and when you’re building something new? Here’s how that works: person a: “we need this feature” person b: “yes, let me build it” [...] person b: “done.” person a: “hmm, actually, that’s not what I meant. what I meant is: [...]” Or this: person a: “we need this feature” person b: “yes, let me build it” [...] person b: “you know what... There’s 3 ways to do this, actually, and I’m not sure what the best way to do this is?” person a: “ah, I see, I think given that we want to ship this tomorrow, let’s go with way 1” Or: person a: “we need this feature” person b: “yes, let me build it” [...] person b: “done.” person a: “Don’t like it” Now why does that happen, again and again and again? Because building new software is learning! If you’re building something new and you don’t yet fully know how exactly it’s supposed to work, you will learn what exactly it is that you’re building as you’re doing it. Let me repeat: building new software is learning. So far, so good, right? But here’s the very important bit, the one bit I want you to take with you into this week: there is no way in hell, absolutely zero…

Thorsten Ball
· 5 min · Original

Joy & Curiosity #88

It’s been a fantastic week. The Amp team met in San Francisco and together we hung out in a beautiful house, drank coffee and diet coke, ate way too many snacks, and hacked on Amp. A single timezone, many overlapping hours, synchronous communication with even the option to tap someone on the shoulder. You could feel the clock rate of the team go up. Our #shipped channel was busy. What a team! But I didn’t get a lot of reading in. And now the sun is up, the coffee’s finished, and I’m going for a run. Amp Neo is now Amp. It’s out, for everyone. Generally available, fully released; the infrastructure scaled, the clients resilient. It’s been tested on three cross Pacific flights already. Go and try it. Try the plugins, try the remote control. I’m very proud of this architecture and this team and that we made this work — infinitely scalable agents, running everywhere. And it’s only the start. Fantastic little post by Patrick: Fast is better than slow. There’s between ten and fifteen things I want to quote here, so go read the whole thing instead. Then go and read the section about being fast on nat.org and and Patrick Collison’s Fast page. Benedict Evans on Predicting AI job exposure: “The counter-argument to all of this would be to say that, yes, well done, there are important exceptions, as there always are, but directionally and in aggregate, it is ‘surely’ correct to say that jobs that involve a lot of repetitive clerical work are most exposed, and this is how many jobs that is, and by how much. That sounds good, but you don’t know if the exceptions are bigger than the rule. Suppose we’d looked at the internet in 1995 and said that this would destroy the value of physical distribution for media - this was ‘directionally correct’, but in practice that meant totally…

Thorsten Ball
· 9 min · Original

Joy & Curiosity #87

Travelled for roughly 16 hours yesterday and now I’m in a different timezone, with my family, everyone fell asleep at 8pm yesterday, and everyone woke up at 4:30am today (not complaining: that’s good!), and I started writing this at 5am, and the Airbnb we’re staying in is lovely but has one downside: as of right now, it doesn’t have any coffee in it. What I’m trying to say: that’s all I got for an intro this week, friends. I need a coffee. Enjoy the links! This week we announced Amp Labs. Our team has been working with some exceptional companies for a while now, but now we’re entering a new phase, starting in Sydney, Australia. If you’re exceptionally good and want to help bring artificial intelligence to a global finance player, let me know. Software After Software on the Amp Labs website. What we at Amp believe about the future of software and why Amp and Amp Labs exist. I was a guest on Mayank Gupta’s podcast and we talked about everything, really: how I got into programming, why I got into programming, how I ended up going from training to get better at Vim thinking that it doesn’t really matter that much anymore, to being a co-founder of Amp. That was a really pleasant conversation, you can tell that I was a bit tired at the start, since we recorded late-ish my evening, after a long day, but then got more and more excited because Mayank’s questions were fun. Also: what an intro. Also, also: wow, he really went there with that one image in the intro. Seems like I’m behind the world by three weeks, but I’ve finally started to use hunk to review diffs before making commits. Since I’ve read about the Emacsification of Software right before, I forked it and added Gruvbox Dark Hard. John Gruber: AI Is Technology, Not a Product. I really enjoyed this one, especially this…

Thorsten Ball
· 9 min · Original

Joy & Curiosity #86

There it is: light at the end of the tunnel. After a week of scaling, tuning, and modifying our infrastructure, Amp Neo is now rolling out to more users. Update your Amp and watch out for a welcome screen that, some people say, “should be marked NSFW” because it’s so sexy. Boy do I have stories to tell. Here’s a very 2026 one. We were debugging database issues in production but could only see symptoms and not what caused them. Spike on this graph correlates with spike on that graph alright, but why? What causes it? If you’ve ever done any sort of investigation like this, you know that there are a lot of things you can check: are processes restarting? Is the rate of errors going up? Is a CPU pinned? What’s the memory usage look like? And so on. But it’s 2026, isn’t it? So what ended up happening is that we’d send runbooks to each other. And runbook here means “prompt”: a long Markdown document, created by an agent, that instructs the reading agent to check a series of metrics and data points. You’d take a prompt, paste it into Amp, Amp would go off and compile a report. It would say something like “this cluster looks healthy, except for the otel collectors which are OOMing, but that’s benign for now, the smoking gun is the log messages that say … because those correlate with … showing up at the same time, which means …” And then you’d take that report and send it to a fresh Amp and that fresh Amp would say that yes, that’s right, let’s fix this, and you’d sit there and think that there’s no way, no way that you would’ve dug through the logs and metrics at that speed with that precision, but it’s 2026 so the agent did it for you. antirez with a “short story of a long development”: “Because I had AI, I took no compromises, and I decided to go the extra mile.” This is a…

Thorsten Ball
· 3 min · Original

Joy & Curiosity #85

We launched a completely rebuilt Amp this week. Amp Neo (it started as a codename, but I’ve grown really fond of it) is remote controllable, supports plugins as a first-class feature, has compaction you don’t have to worry about, and is a lot more efficient and faster than the old Amp. It is one of the most elaborate systems I’ve ever worked on. A coding agent split into three parts: the tools here, the interface there, and the loop in an infinitely scalable system over there. Some day I’ll hopefully write about building it. I learned a lot about programming with agents in the last two months. We’ve spent the whole week scaling this system for the demand and are still working on it. “Scaling problems are good problems to have” definitely feels like a fortune cookie laughing at you when you’re staring at graphs and logs every hour of the day. People love Neo and can’t get enough of it. We’re now the “ferrari of coding agents”. But I also barely read anything this week except logs, so this edition of the newsletter is very short. This is beautiful: “For thirty years I programmed with Phish on, every day. In 2026, the music is out of phase with the work.” What a nice piece of writing and, man, this idea that some people find out early what they want and what’s enough for them and know that it won’t ever change has stuck with me: “Other kids my age were figuring out what they liked, trying things on, growing into and out of phases. I was watching them do it from a desk. I had picked early. I started writing code as a kid. I heard Phish for the first time at thirteen. By the time I was fifteen and had a professional gig, the picking was settled. I had two things, and I didn’t want a third.” I somehow missed this earlier, but Aphyr’s The Future of Everything is Lies, I Guess…