August 2026/13 entries

I can now hand much of the mechanical work to an AI coding tool, then spend my time fixing the interesting parts.

This has been my experience with vibe coding too. On the surface, my coding agents can produce incredible apps very quickly. Once I start actually trying to use them, there are endless paper cuts to fix.

Programming becomes part of using a computer, whether the user calls it programming or not.

This does seem true. Not everyone will become a "programmer" in this sense, but many many more people will, the same way many people use spreadsheets or other similar tools to get their work done.

Traditionally, the software industry has optimized for products that can support large audiences: companies, engineering teams, sales organizations, and lots of customers who, in aggregate, will pay enough to justify building the product. That makes sense when software is expensive to build.

This is a really interesting way of putting it. Finding people to pay for your software is always the challenge.

Finding someone to write and maintain a narrow program used to be the primary bottleneck. Now, the challenge is recognizing when a “throwaway” tool has stopped being throwaway.

This is a great way to frame all of the ad-hoc development happening now. LLMs writing code is cool and fast for sure, but it can be very very annoying when you need the software produced this way to actually work.

Before building your next program, I recommend you ask three questions:

1. Does anyone else depend on it?

2. Can it change or expose important data?

3. Would work stop if it disappeared tomorrow?

If the answer to all three is no, treat it like an experiment, not a product. Build it quickly, skip the formal engineering process, and expect to delete it.

If the answer is yes, add only the structure you really need. Give it an owner, list its connections, limit its credentials, and make failures visible. Then, have a plan for how it gets repaired, replaced, or retired.

The amount of engineering process should follow the consequences. A disposable tool can stay disposable. A tool people depend on needs an owner, tighter access, and a plan for keeping it working.

I really love this framework, I think more people should adopt it. These are very sensible guidelines for vibe coding.

This was a great piece about what’s going on with fly.io. It’s by far my favourite way to deploy my apps these days, and I hope they make it.

I’m going to overshare some more in a second, but I won’t leave you hanging. So: we’ve raised a bunch more money. We’re launching a new iteration of Sprites, and focusing the company on them and the problem they solve. And I’m tagging in Scott Johnston as CEO.

Sounds like a lot of big changes all at once! Sometimes that goes really well for companies, sometimes poorly. It’ll be an interesting year for anyone working at fly either way.

Everybody forgets that before Dan Bricklin invented the spreadsheet, every “Excel document” in the world was a computer program, built by a computer programmer. In just a matter of years, every business professional became a programmer, using the world’s most important programming language, spreadsheet formulas. AI is like that, but bigger. Almost anybody will probably be able to build almost any kind of computer program.

I think this is an interesting way to think about software and what’s happening to the industry. It does seem true on some level. The average professional is very likely going to be able to solve their own problems with vibe coded apps in the near future. But I think “almost anybody” is a stretch. Software people forget how non-technical the average person is. The average normal person has no clue how to use a spreadsheet still today.

More importantly, SBD enables drive forking: you can create a template Sprite, and then efficiently clone millions of times.

This is really cool. This would effectively allow you to checkpoint not just code but an agent's environment already set up along with a particular version of your code.. that could be really powerful.

The other big new thing in Sprites is Connectors. Connectors build on work we did to secure our core platform: they let Sprites make authenticated requests to other systems, without giving agents anything useful to exfiltrate. Connectors have fun security properties, but are also much more pleasant to use than manually managing accounts and API keys.

This is also really cool! The other annoying thing with running agents on VPSs right now is auth.. it’s risky and a huge maintenance burden to have keys fanned out as prolifically as your agents. The desire to have fully functional throwaway environments is just fundamentally at odds with the need to sometimes have secrets on them. Issuing ad hoc secrets per env at agent scale just isn’t feasible. This seems like a potentially great solution.

I could write this post without pissing anybody off, but I don’t know how to do that and still have it be worth reading.

I can appreciate the honesty. And this was a great read.

Five of the most dangerous words in startups are “¿Por qué no los dos?”. We do one thing or the other. We don’t limp in on both.

This is vague about what the future of fly’s now-legacy business looks like, and pretty explicit that they’re all in on sprites. I do think people will still need an easy way to deploy all their little vibe coded apps though. I hope they keep fly up and running too. We’ll see.

It's difficult to find reasonable, pragmatic takes on using coding agents these days. Ray Myers is a good voice in that space right now and I thought this was a great survey of what people in the industry are actually saying about reading AI-generated code.

but those seem like weak-sauce countermeasures [my addition for clarity: (training employees to recognize LLM manipulation and deploying judge agents)] if you mean to help someone “fight back” against a “bombing”. They suggest pushing workarounds onto the user and adding more agents. Think for a second. What’s missing?

We could use fewer agents!

This always drives me crazy. More or less every week at work now people are complaining about some negative effect of AI, and the standard answer from leadership is universally and consistently "use more AI". Instead of trying to use more AI to solve our AI-generated problems, what if we just tried using less AI in the first place? Why is nobody asking that?

I understand why the LLM companies don't want us to use less AI. But so far I do not understand why executives who are paying through the nose for their ever-increasing LLM inference bills do not want us to use less AI.

Where are the women?

When we find ourselves citing exclusively men, something may have gone wrong.

I appreciate this take. Most industry conversations are male dominated. My take on this is that it's mostly because being female in public really, really sucks, and speaking up in these conversations is almost never worth the inevitable harassment, bullying, and gatekeeping you're in for. Men simply do not understand what it's like to have their very reasonable technical opinions regularly met with "you should not exist in this industry". I know that's not true, but hearing it too often is bad for my mental health, so I mostly stick to my read-only corner of the internet over here and do not engage in public conversations. I've been bullied my whole life and learned a long time ago that the best way to deal with bullies is to just remove their access to you. You can't get bullied if the bullies can't contact you.

Frowning on those who live in the present is a luxury that evaporates with proximity to the pager.

This is the first time I've seen this "proximity to the pager" phrase, but I love it. I think it cuts to the core of what is so divisive in the industry right now. In my experience, the people who are most enthusiastic about "AI" and agentic coding and all of that stuff are the ones who are nowhere to be found when prod goes down. Conversely, everyone I know who has ever had to work after hours to fix a downed system that people are paying for is much more realistic and honest about the current capabilities of coding agents.

They then hand those constraints down to our department to do their homework for them work out the details.

It does feel strange that OpenAI and Anthropic constantly claim they are building a Superintelligence capable of doing real work, yet most of the industry is now spending most of its time doing the real engineering work of making the LLMs they produce do anything actually useful. Un-guided and unrestrained, LLMs do far more harm than good, but we've all been effectively mandated to use them day in and day out, so now we spend most of our time just learning how to build better harnesses, guardrails, and systems to try to cajole them into doing meaningful work.

Rigorous automated testing is much more feasible than is generally realized. This is largely a failure to budget for coaching and training.

This is definitely true in my experience. At the risk of sounding like a gatekeeping asshole, I do believe that people who write poorly tested code (or did before AI could do it all for them), both fundamentally misunderstand how to write good test-driven software and dramatically underestimate the cost of all the manual verification steps they do instead. All the engineers I know who write bad or inadequate tests spend ridiculous amounts of time manually QAing their own software. There are some true agents of chaos out there who just yolo code into production, but I would say most software engineers, even very mid ones, do want to confidently answer the question "does this code work" before they ship it. I think the people who don't believe that automated testing is the fastest way to do that just don't really know how to do it well and at this point are too embarrassed or set in their ways to admit they need to upskill.

They emphasize speed of code gen as a proxy for value.

This is a really deeply embedded misunderstanding in the industry. The velocity at which your software is produced doesn't tell you anything at all about the value it delivers to users. But because it is easy to measure many teams have massively over-indexed on it and mistake velocity for productivity, which is unfortunate because it's really easy to juice your own velocity metrics while actually causing damage to project outcomes. But that doesn't matter when nobody is measuring outcomes and only velocity is rewarded.

I was recently fixing up the feeds on my website and wanted to make sure a) that they render probably and b) that the filtered ones contain the correct entries, so I built this little tool to preview atom or rss feeds.

This is the best “AI usage” policy I’ve seen yet. I would love it if projects I worked on would adopt similar conventions and standards.

you as an author need to take the time to make sure that all of the ideas in the writing are the ideas that you personally intend to convey (including the structure and wording that determines which ideas are emphasized) and that the documents are a good use of your readers’ time.

The thing that frustrates me the most about how AI is used in the contexts where I’m exposed to it is when people try to pass off what is clearly unedited slop as their own work. Rather than seeing AI as a tool to assist with human productivity, too many people are trying to make it replace human productivity, but all they’re really doing is unloading their work on some other human. I feel pretty strongly that asking someone to read AI generated output is rude and inconsiderate. You are effectively asking them to fact-check, edit, summarize, and distill a jumbled bag of claims that may or may not be true for you. To the author, if feel like they saved a ton of time producing the document or message or whatever they needed to write. To the person on the receiving it’s another chore. To be fair I have mostly stopped tolerating this behaviour.

You will confuse your readers (and waste their time) if you present them things that are not genuinely representative of your thoughts. In some cases, readers will recognize and call out the incongruous parts; in others, they will be misled as to what your actual thoughts are.

This cuts to the core of the issue, I think. I'd strongly argue that we shouldn't be outsourcing our actual thinking to AI. It's so tempting to just post whatever it generates because it creates the illusion of productivity which is highly rewarded in many white collar jobs. Most managers reward velocity and not quality. The problem is certainly that the incentives are wrong in the first place, but until those are corrected we have to rely on our own self-discipline to resist the urge to just ship more slop for the sake of seeming more productive.

Pascal once wrote, “I have made this [letter] longer than usual because I have not had time to make it shorter.”

I love this quote, but I always thought it was Mark Twain's. I guess a lot of quotes are misattributed to him.

If you are producing a longer piece of writing from a shorter prompt, consider instead just sharing the prompt itself.

I like this suggestion.

This was a pretty scathing indictment of the tech industry but I think on point. It says a lot of things that you’re not supposed to say out loud right now but that everyone is thinking. Like:

AI makes projects with weak engineering culture fail much faster.

and

In every team, there are competent people who make the project possible. There are also people who essentially make it harder for everyone else.

I don’t actually think anyone benefits from being mean about it, but this is generally true in my experience. Not just in software but in life generally, sadly.

There used to be a time when people sat down and talked about how they'd do something. Now they can just prompt an agent for a few hours and open a PR.

The most tragic aspect of this way of working is that, to the untrained eye, it works.

It does appear to work and I think this is the most dangerous part. Something I really struggle with lately is finding the right balance between excitement and gatekeeping. On one hand it’s really cool to see more people with different ways of seeing things coming up with software solutions to their problems. On the other hand I die a little inside every time I see what’s under the hood, especially when I’m asked why it doesn’t quite work.

This project has become so convoluted, with so many layers and services, that no one on your team could possibly start to understand what's going on.

So, what do you do?

Fixing it would require such a colossal amount of work that it would be impossible to even start justifying it to anyone in management.

It’s always been frustrating to me that “management” (in my experience it's more often product teams than management who control engineering time, but same concept) don't understand the importance of untangling these kinds of architectural messes. "Tech debt" work often gets prioritized alongside regular product development and engineers are constantly forced to justify its "business value", but this makes absolutely no sense and fundamentally misunderstands the cost and consequences of carrying technical debt.

More often than not there is no direct value (in the business sense) in paying down tech debt, but it's a non-negotiable prerequisite for getting literally anything else done. Like real debt, you don't get anything new when you pay it off -- you already consumed the value when you took on the debt. But until you do pay it off you can't buy anything else.

At some point, someone still has to know what is going on. And that's the most valuable person on the team.

It has become very annoying to be this person. I used to just go in and fix things and make software work. Now I have to stage an intervention first.

I apparently can’t hold a conversation with a friend, post on social media, or even daydream idly without the topic eventually turning to bloody A.I.

It’s not always me who brings it up, but it often is; I’ve rarely known such a “sticky” subject.

This resonates. Unlike Oliver Burkeman I do use AI more or less all day every day at work. But I also find myself talking about it so much more than I need to.

One answer is that the general topic is an unusually powerful trigger for a major disease of our times: overthinking.

This is an insightful take. Whatever you think of AI, it is upending many industries very quickly and has implications one way or another for the future of society. Whether you’re for or against, whether you use it or not, it’s become very difficult to ignore its pervasiveness in day to day discourse anymore. This diagnosis of the reason being that it naturally triggers all kinds of pre-existing neuroses about our place in the economy, the nature of our relationships, even what it means to be human in the first place, seems apt. These are all heavy, anxiety-inducing topics for many people and the way AI is often discussed very nonchalantly by those creating it as though it might ruin all of our lives is a bit hard to ignore.

Whatever the details, this is where overthinking kicks in, because it feels like the solution to the anxious feelings in your body is to scurry off into your head and think some more, read some more, argue some more, maybe use A.I. some more… But scurrying off to your head doesn’t work…

I think this is one of the key things software people get wrong about the world, and the source of a lot of the friction the tech industry is running into with regards to AI adoption. There’s a pervasive tendency among us to really highly overvalue intelligence, but not every problem can be resolved by just thinking harder.

Lives immeasurably fuller and more interesting than can be dreamt of in Silicon Valley’s ideology. Lives that encompass vastly more than what software can do.

I find this vision of what a good life can be so much richer and more appealing than what’s on offer in my tech bubble. It’s important to remember this. At the end of the day computers are just tools we can use to facilitate some of the things we want to work on, but have very little to do with what it means to live a full and interesting life.

I was excited to see that this is the first module in a new Coursera course I'm doing. I've long thought that ethics are missing from software development, and I think it's more important than ever to care about the consequences of what we're doing and building in this age of AI. This course on building agents literally opens with this statement:

This module is for professionals and data scientists aiming to build responsible AI.

I'm really heartened to see that building responsibly is becoming a legitimate concern, at least in some corners of the industry.

By bridging theory and practice, the program empowers you to lead initiatives that prioritize accountability, ensuring your AI systems deliver immense value without compromising integrity or public trust.

I'm looking forward to this.

Well this is awkward. Literally yesterday I wrote “the hard part of software engineering was never writing the code.” I concede that that way of describing what’s happening to the software industry is a bit lazy and exaggerated.

Nobody knows how the AI revolution will play out in the end, but it is clear many aspects of work and life will be transformed—including programming.

This definitely feels true to me. My day to day is already completely unrecognizable compared to a year ago and I wouldn’t have known how to even begin describing the nature of my job now if you’d asked me to only a few months ago.

If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)?

This is answerable though, in terms of economics. How hard a skill is isn’t what determines its price. It’s true that a very small proportion of the labour force is willing to put up with solving abstract symbolic logic puzzles for 40 hours a week, but the main reason software engineers are so highly paid is more because the marginal cost of scaling software is effectively zero than anything to do with the work itself. Lots of jobs are harder and pay less.

I have met many programmers throughout my career, and very few of them want to talk to stakeholders, much less customers (exceptions are freelancers and founders, especially of software development shops). And, “having clarity on the priorities” boils down to “just tell me what to do and don't switch it up every two days

Relatable.

Whoever you are, don't outsource your understanding, judgement, empathy and taste to AI.

This feels like the most important takeaway for this moment. What drives me more crazy than anything else these days is people trying to pass off AI generated output as their own. It’s lazy and inconsiderate to ask someone to read piles of slop on your behalf, but that’s not even what I hate the most about it. It’s the abdication of our unique human ability to relate to other humans that gets me. I wish people would stop pretending like generated AI output could ever replace human interaction.