The author's high-value flowcharts vs Steve Yegge's AI art is enough of a case-in-point for how confusing his posts and repos are. However this is a pervasive problem with AI coding tools. Unsurprisingly, the creators of these tools are also the most bullish about agentic coding, so the source code shows the consequences. Even Claude Code itself seems to experience an unusually high number of regressions or undocumented changes for such a widely used product. I had the same problem when recently trying to understand the details of spec-kit or sprites from their docs. Still, I agree that Gas Town is a very instructive example of what the future of AI coding will look like. I'm confident mature orchestration workflows will arrive in 2026.
For me, the killer feature would more be _autocomplete_ for art. I love to cartoon and doodle, but don’t have the time/patience/skillset to build professional digital assets. If I could go from my pencil drawn sketch to a flashy png, that would be awesome! I think it’d be a nice use of AI, since it just allows me to do more with my own creativity.
Unfortunately whenever I’ve tried uploading a sketch to ChatGPT or Gemini, it seems to fixate on details of my sketch, and recreates my mistakes in high fidelity. It fails to take a creative leap toward a good result. I’ve heard some professionals have gotten good results building custom workflows in ComfyUI.
No, seems to be about "turns X into Y", while what parent seems to want, is something that just makes making X easier/better, instead of doing those sort of "transformations" which is usually where the human feeling gets lost.
This is a great consolidation of various techniques and patterns for agentic coding. It’s valuable just to standardize our vocabulary in this new world of AI led or assisted programming. I’ve seen a lot of developers all converging toward similar patterns. Having clear terms and definitions for various strategies can help a lot in articulating the best way to solve a given problem. Not so different from approaching a problem and saying “hey, I think we’d benefit from TDD here.”
I recognized the need for this recently and started by documenting one [1]... then I dropped the ball because I, too, spent my winter holiday engrossed in agentic development. (Instead of documenting patterns.) I'm glad somebody kept writing!
I will ruefully admit that I had also planned a similar blog post! I am hoping I can still add some value to the conversation, but it does seem like _everyone_ is writing about agentic development right now.
I believe there are valid critiques to be made of prediction markets, particularly on the morality of allowing bets on events with serious/market outcomes (the market could create an incentive for an insider to actualize that bad outcome, hence we should ban the market as it increases the odds of a bad outcome occurring) or on the negative repercussions of gambling addiction. Instead of making either of these valid arguments, the article instead decides to critique the epistemic value of prediction markets. It comes off to me as ill-informed handwringing and tribal signaling, rather than bothering to engage critically with the topic and offering a meaningful critique.
I appreciate the Fly.io team’s enthusiasm and am optimistic this will mature into a product I’d pay for, but my initial impression was of a lack of polish.
Documentation is sparse, or not even available? The API docs don’t tell you much about the service itself, and a Google search for docs returns an inaccessible website as the first result (https://docs.sprites.dev). Blog posts and forum threads and Claude skills shouldn’t be a substitute.
The snappiness of the sprites is very cool and I can definitely see it integrating into future Claude Code workflows. But the lack of a base container images means you’re still doing setup work on the sprite before you can begin development. I understand the philosophy is that sandboxes should be persistent, but Claude Code sessions also work better when isolated from each other, so it’d be nice to have some precepts to get a workspace setup quickly (given agentic coding is clearly a target).
I also found the CLI unintuitive but maybe that was just me!
So very cool idea but left with the impression that the Fly.io team’s should have spent a couple weeks on polish before shipping.
You're not wrong. The documentation actually had a hallucinated link to an Anthropic dependency in it when we shipped. Right now the attitude is mostly "if we have to document it extensively, we're doing something wrong". It's been in the works for awhile, with a small team, and we're just getting it out there right now.
I've been needling Kurt for several months now that if we wait until it's polished enough that we don't see comments like this, we're doing it wrong.
For what it's worth, I evaluated Fly.io during a divorce from Heroku some time in mid 2022 (I think), found the platform was... way too rough around the edges at the time to want to migrate any real workloads. I kept it on my radar and shipped an MVP with it in 2024, found it was a lot more polished, and now have multiple production apps running there. I'm genuinely pumped about Sprites and have started building against the API—I did notice the weirdness with the docs, but you guys have been doing well on the "this thing that {was broken|I didn't like|was missing} now works the way I'd hoped it would" front.
Appreciate your perspective and totally understand that at some point you just have to ship it! From the outside it looks like a bit less time on XYZ feature and bit more time on marketing polish might have been a good call. But can only speculate what the trade offs were internally. Best of luck maturing the product!
The main things i think are missing is (1) how much am i spending and (2) why isn't my sprite paused, and (3) how can i get my stuff out (it would be nice to be able to mount in either direction or else integrate with git/git worktrees).
I ended up using it (and enjoying yolo mode!) but then my sprites weren't pausing and i was worried about spending too much so i deleted them.
I'm sure this is a difference-of-learning or whatever, but I'm usually unwilling to try a product until I can understand it and how it works from the documentation
Understandable. Our current take is that there's not really much to know, and that the people this will really light up are good with that. Of course, we'll flesh out documentation!
I'm really jazzed about this particular product as a product (I just really enjoy using it), but the post is mostly about how we built it, and deliberately not much about how best to use it.
I hate being negative but it sounds like par for the course for fly.
Incredible (truly, incredible, world-class) engineers that somehow lack that final 10% of polish/naming/documentation that makes things...well, seriously usable.
I remember last time I tried them the bizarre hoops/documentation around database creation. I _think_ they solved that but I remember at the time it felt almost like I was getting looked down upon as a user. Ugh, you need clarity? how amateurish!
+1. This thread, the thread about documentation, and the thread about turning off Sprites, when taken together, thoroughly illustrate why I'm not currently a Fly user.
For everyone defending these actions on the basis of Maduro's own corruption and the desires of Venezuelans, I would encourage you to research the history of American intervention and regime change in Latin America. It is impossible to anticipate the second and third order effects of this change, and how it will be absorbed in the local politics. We are witnessing the return of American military intervention in Latin American, nothing more and nothing less.
To everyone proclaiming that we should turn to Venezuelans to assess these actions, how dare you assert that Americans have no autonomy in the actions of their own government. It is tremendously unfortunate that congress has forfeited all decision making authority to the executive branch, but as our democracy was intended this would amount to an act of war, which would require authorization by congress.
The author makes effectively the same comment that twenty minutes late is normal for Germany (below). I don’t have any statistics, but anecdotally I’ve had worse experiences with DB than in the UK. DB does not just run late, but has a bad habit of teleporting you to random German towns, from which you must quickly route find to your original destination (as is the exact story of the post).
> It is twenty minutes late. I consider this early.
The TL;DR is: regional trains are usually on time, long-distance trains usually are not. If you need to travel between cities, plan with an hour buffer time. Basically, "show some adaptability".
The one good thing about frequent long-distance delays is that you might be lucky and catch an earlier delayed train and actually arrive a bit earlier than planned ;)
(also JFC, does the author like to whine about nothing - I'm travelling frequently with DB for about 25 years now, and while shit happens from time time, most of it is merely a slight inconvenience).
Plan with a ~40% of travel time buffer if you ought be there, and travel the day before if you must be there.
I travel from Basel to Hannover and back every two weeks on DB. Trains south are almost always late, trains north usually late. Frequently the train is already late in Hannover having come from Hamburg. The worst was when I was kicked out in Frankfurt and had to stay in a hotel. The delays were so bad there were no more trains left that could connect me to the last train out of Basel.
Things have been getting better for the past couple of months I think though.
reply