#software-development/5 entries

This is a cool example of the kind of problem that Clojure makes so much simpler to solve. Having a coherent model of time and not sharing mutable state makes parallel computing so much easier, because you’re not trying to coordinate multiple mutators contending for a shared resource. If you just don’t share the resource and let the language level primitives handle serializing operations for you, you can stop worrying about entire classes of bugs and just focus on your problems.

The ideas parallel servers reinvent by hand - immutable snapshot, pure read phase, changes as data - are the language's defaults. If writing from many threads is difficult, then don't write: all game logic is pure functions (fn [world events]) that read the snapshot in parallel and return changes as deltas, merged in one place. The merge preserves order, so the parallel run is bit identical to the sequential one, and no mechanic cares how many cores it runs on.

I think it’s so cool when people experience the benefits of Clojure’s paradigm in real projects. It’s often a tough sell at first but it really is amazing how far you can get with pure functions operating on immutable data. My favourite way to fix bugs is to just make them impossible by default, which often means rethinking the way your program models the world and time. It can be a bit trippy at first but it pays off.

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.

The intersection of AI tooling and open source projects is interesting to me. I’ve also come around to the reality that LLM-powered coding agents like Claude code or codex are pretty clearly game changing when it comes to how software gets produced.

AI is a tool, just like other tools we use. And it's clearly a useful one.

It may not have been that "clearly" even just a year ago, but it's no longer in question today.

I also agree this wasn’t true even a year ago, but the last couple of generations of models have seen some sort of threshold crossed that we didn’t know was there and they are legitimately very useful in my day to day work now.

They also fundamentally change the nature of open source software development. Now that writing code by hand is virtually an obsolete skill, where does that leave maintainers? And what is the point of open source?

Sure, the social angle of working on open source is important and often a very motivating part of the project, but in the end that's a side benefit, not the point of the project.

This was part of it, and a big part of what I love about it. To me it’s really enjoyable working on interesting projects with a globally distributed team of people who also enjoy the work. Part of it was also performative, a way to demonstrate publicly that you could write decent software. I think that is mostly over.

In the kernel community we do open source because it results in better technology, not because of religious reasons.

Maybe that just leaves us with this — writing open source because it produces better results. This doesn’t strike me as universally true though. I guess it depends what you mean by “better”, but I can think of many examples of software where the proprietary version is much better than the OSS one.