amitprasad

Our system somewhat predates ublk; at the time we wrote it, FUSE was the most reasonable option. Moving over to ublk would require re-architecting around block devices rather than filesystems, but is indeed something we're looking at!

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.

Heard on everything else, thank you!

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

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.

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.

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.

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.