I completely agree that requests are what should be charged for. But I think there are two things, given that requests aren't all going to cost the same amount:
1. Estimate free invoicing the requests and letting users figure it out after the fact.
2. Somehow estimating cost and telling users how much a request will cost.
I’m being a little reductive and ignored Guix purely based on adoption; but you’re completely right. I believe the core argument is that there is a (relatively small) category of these tools of which Nix is the most well-known representative.
Just because you or I may invest effort into deep-thinking, it does not mean that others will.
I'm not worried about this at Modal, but I am worried about this in the greater OSS community. How can I reasonably trust that the tools I'm using are built in a sound manner, when the barrier to producing good-looking bad code is so low
We’re already there. Seeing OpenClaw and the new thing LocalGPT on the front page. It’s clear these projects are pretty heavily vibe coded and I have no trust that they are tested, secure or even work as advertised. It’s going to suck when all projects become that. When you can’t trust that a library works as advertised.
To be clear, I am also having the most fun I've had when it comes to side-projects and even more exploratory things at work. I don't derive all my joy from "Good Code" -- that's silly! I would much rather ship tangible products and features and/or tackle things at home that I wouldn't otherwise.
On the other hand, the other responsibilities of being an engineer have become quite a bit less appealing.
I would be extremely happy to be proven wrong! I love using agents for exploratory prototypes as well as "rote" work, but have yet to see them really pay off when dealing with existing tech debt.
I find that the flaws of agentic workflows tend to be in the vein of "repeating past mistakes", looking at previous debt-riddled files and making an equivalently debt-riddled refactor, despite it looking better on the surface. A tunnel-vision problem of sorts
Right: Having "Good Code" is an investment into future velocity.
IMO we shouldn't strive to make an entire codebase pristine, but building anything on shaky foundations is a recipe for disaster.
Perhaps the frontier models of 2026H2 may be good enough to start compacting and cleaning up entire codebases, but with the trajectory of how frontier labs suggest workflows for coding agents, combined with increasing context window capabilities, I don't see this being a priority or a design goal.
>Perhaps the frontier models of 2026H2 may be good enough to start compacting and cleaning up entire codebases
I don't think this will happen - or rather I don't think you can ask someone, human or machine, to come in and "compact and clean" your codebase. What is "clean" code depends on your assumptions, constraints, and a guess about what the future will require.
Modularity where none is required becomes boilerplate. Over-rigidity becomes spaghetti codes and "hacks". Deciding what should be modular and what should be constant requires some imagination about what the future might bring and that requires planning.
Paying down tech debt doesn't necessarily take any knowledge of future changes. Code with tech debt didn't even handle past changes well. You can usually make future changes easier just by improving how the code does what it currently does.
There's an opportunity-cost here. I use agents to be more productive. As many have noted, "Good Code" doesn't rank highly compared to actually shipping a product.
The tragedy, for me, is that the bar has been lowered. What I consider to be "good enough" has gone down simply because I'm not the one writing the code itself, and feel less attachment to it, as it were.
It's hard to say. Perhaps LLMs of tomorrow will become capable enough to fix the mistakes of LLMs today. If so, great -- I'm worried about nothing.
If not, we could see that LLMs of tomorrow struggle to keep up with the bloat of today. The "interest on tech debt" is a huge unknown metric w.r.t. agents.
If you're not looking for GPU snapshotting the ecosystem is relatively mature. Specifically, CPU-only VM-based snapshotting techniques are pretty well understood. However, if you need GPUs, this is a notoriously hard problem. IIRC Fly also was planning on using gVisor (EDIT: cloud-hypervisor) for their GPU cloud, but abandoned the effort [1].
Kata runs atop many things, but is a little awkward because it creates a "pod" (VM) inside which it creates 1+ containers (runc/gVisor). Firecracker is also awkward because GPU support is pretty hard / impossible.
Ohh this makes sense now. Firecracker is good for compute related workflows but gvisor is more good for GPU related workflows, gotcha.
For my use cases usually, its Firecracker but I can now see why company like Modal would use gvisor because they focus a lot (and I mean a lot) on providing gpu access. I think that its one of their largest selling points or one of them, for them compute is secondary customer and gvisor's compute performance hit is a well worth trade off for them
Generic data stores often don’t have this luxury — if you’re designing a system in which data is relatively opaque, you’re often forced to work with bytes. (e.g. rocksdb, etc)
author here -- agreed on all fronts. Mentioned this in the other comment but I approached the topic from a relatively narrow perspective (I was working on a specific project at the time)
I think it's worth including these things in a future update to the post, but I didn't have the time / need to explore it back then.
Sure, not all posts want to be the end-all of the topic. :-)
And yes, the Joel post is a good introduction, if a bit old by now. Notably, of course, it doesn't say anything about _processing_ Unicode text. (E.g., don't sort by code point, don't break in the middle of a grapheme cluster, etc. etc.) But I believe that this is outside the scope of his intention.
(disclaimer: I work with the author)