Data Hacker. CTO and Cofounder at https://nitter.gq/t.co/BiP4BcniIt. CTO at https://nitter.gq/t.co/ncrsKFvzYP
38.895864,-77.042532
Joined December 2006
- Tweets610
- Following1K
- Followers297
- Likes2K
It’s hard to underestimate the leverage we now have to do things “the right way”
Software is having its Industrial Revolution and it’s changing what matters in software frameworks. Today’s frameworks were designed for the crafty carpenter, tomorrow’s are designed for mass manufacturing processes where rigor > conciseness.
Take foldkit vs react/solid, for example. You can argue that foldkit is more verbose or complicated for some use cases compared to the traditional alternatives, but everything doable in react/solid is also doable in foldkit. Everything doable in foldkit is not (or at least not easily or consistently) doable in react/solid because they lack the rigor of command+event state machines with story & scene testing. Getting that back isn’t easy and is a substantial loss for agentic coding.
Before AI, there was the valid argument of picking what humans like best. Humans kinda suck at programming because we are constrained by our skills, taste and (lack of) discipline, so frameworks that worked in this era catered to the lowest common denominator of mass market human developers. While I agree that react/solid are powerful in the hands of humans, that simply doesn’t matter anymore.
What’s best for humans does not necessarily translate to what’s best for agents. Some tasks may indeed be “a bit harder” with foldkit in human terms, but AI is capable of solving all of them in a few minutes, so who cares. Instead of bike-shedding philosophy and taste, just choose the more rigorous (and scalable) option. It costs you nothing and gains you everything.
Effect is another example of this. With AI, now everyone of all skill levels can use advanced programming techniques that are objectively safer and more scalable, but were out of reach for many human programmers. Or didn’t appeal to the stubborn tastes of a particular person.
With humans now out of the way of technology adoption - I think it’s obvious that the following techniques are going to become way more commonplace:
1. State Machines
2. Functional programming
3. Declarative infrastructure
4. Test Driven Development
5. Domain Driven Design
6. Actor Systems
7. Rigorous API schemas
8. Type Safety and Formal Verification
9. Disciplined Operations (monitoring, on-call)
Alchemy is designed to bring these techniques together into a seamless experience for building and deploying applications of massive scale. It is the “rails” and “parts” of the ai software assembly line.
💯this. There’s a meta skill out there that allows enormous leverage.
I'm starting to sense a divide in the tech industry:
- People thriving on autonomy who are reinventing how they work and what tools they use with AI: LOTS of work, but they're enjoying it and getting very efficient
- People used to being mentored / trained / or simply told what to do and how. Frustrated with the lack of guidance from management on what to do with AI; also frustrated by seeing some of their peers thriving; increasingly bitter about AI and the state of the industry, as a whole
Neither group seems to be aware that there's another group, or have empathy for the other group
erik retweeted
I'm starting to sense a divide in the tech industry:
- People thriving on autonomy who are reinventing how they work and what tools they use with AI: LOTS of work, but they're enjoying it and getting very efficient
- People used to being mentored / trained / or simply told what to do and how. Frustrated with the lack of guidance from management on what to do with AI; also frustrated by seeing some of their peers thriving; increasingly bitter about AI and the state of the industry, as a whole
Neither group seems to be aware that there's another group, or have empathy for the other group
erik retweeted
Scrum made sense at companies/teams that shipped a new version of their product every 2-3 months (or less frequent)
As soon as a team got to shipping daily or had CD: they only held teams back
Most startups + Big Tech moved on a decade+ ago, legacy companies remained only
The inference stack is becoming more important.
Turns out controlling Qwen 3.6 reasoning tokens takes token counting and injecting a magic phrase. Most engines don't.
Gory details at entropy-exchange.synaptiq.ai…
erik retweeted
While we are doing lobbying for AI laws, I propose this. All providers of closed source models are 100% liable for their outputs. Copyright, libel, conspiracy, fraud, etc... If you want safe harbor from this liability, release the weights. This is real AI safety legislation.
erik retweeted
Very proud to share that we just release Luce KVFlash. Run your preferred model inside Lucebox at 256k context, without thinking about KVCache and OOM, up to 2.9x faster decoding at long context.
Taking inspiration from OS paging and using our speculative prefill method (Luce PFlash), we managed to make KV vram usage almost constant. Offloading what is not needed dynamically.
Opensource must win now more than ever.
erik retweeted
You can now run @luceboxai engine in a container, with one image for every supported GPU.
Until now the only way to run it was to build it yourself: clone the repo with its submodules, install uv, CMake and a CUDA toolkit, wait around 25 minutes while nvcc compiled kernels for six GPU architectures, then download the weights and figure out the right flags.
None of that is hard ofc, but it is a lot of steps if you just want to try the server. There are now prebuilt images on GHCR, one for NVIDIA cards from the RTX 2080 Ti to the RTX 5090 and one for AMD starting with Strix Halo, so the whole thing becomes a pull, a mount and a docker run.
Details below 🧵
100% this. I'm generally of the opinion that you shouldn't use open source software in a product without being willing to vendor it in -- prepackaged builds are a temporary convenience.
It would help if common packaging tools were more vendor friendly, most are downright hostile,
I really believed a whole generation of developers, who only know open source from npm and pypi, miss how open source actually used to work.
When Debian or a Linux distribution ships a dependency they take responsibility of it. If there is a security issue and it’s not fixed by the developer upstream, they fix it for their users.
Debian and others basically vendor every thing they distribute. They honor the license and they maintain patches. Most of the stuff that you get from your Linux distribution is basically a (small) fork.
The same is true for Apple, Microsoft and others. The open source software they ship, they carry that responsibility.
That doesn’t mean that security fixes are not upstreamed, but Apple or Debian or anyone else won’t jump in Twitter to shame a developer into compliance with their ways. They are not dependent on the health of a packaging infrastructure. They own their software including all the things it depends on.
I want that thinking back. Because it fundamentally makes people feel more responsibility and it shares the burden of issues. It also does not put so much focus and attention on the one overworked developer who just happened to have too much of the world depend on their library. Remember: they carry a responsibility they never signed up to and they never got compensated for.
100% this. Little chunks of reusable content you can use to steer your friendly clanker make a big difference.
I've been using gastown. This may not be the final iteration, but it is the way.
It's been 12 days since I dropped Gas Town. The response has been off the charts. I've been working hard to keep up. Thanks to all the early adopters. I wrote up this survival guide. steve-yegge.medium.com/gas-t…
On the ground at SFO. I’ll be here all week attending #inbound2025. If you want to talk email and AI hit me up!