Bennett retweeted
For years, maybe a decade, I've wanted to build a writing tool that just did a few things I couldn't find anywhere else.
A system that mimicked how I think when I write. A system that provided clear affordances, features, and places to do the things I wanted to do. A way to play with my writing as I'm writing it. A way to settle into just the right way to say something.
It never made sense to make it a 37signals product because it's not commercially viable, nor would it be worth pulling people off their other work to hack on this. Plus, it would have taken months the old way.
So this weekend I just made it myself, with Claude's help.
It's called Write_On and the short video walks you through it.
Essentially it's "alternative control" at the word, sentence, and paragraph level, plus a way to dim stuff back, and stash stuff near by. Not version control, but alternative control. You'll see what I mean when you watch the video below.
So here it is. Write_On.
Bennett retweeted
For example, I recently wrote a mock postmark server so I can E2E test all my email flows (and test various failure scenarios) github.com/benclmnt/postmock…
Bennett retweeted
you might be the first person talking about the data over the architecture! 🥲
we consider ourselves a data research lab! the vast vast vast majority of research was on making data that is truly general (ala a cognitive core) and 100% of our data is synthetic (but not the type of crap that is just spit out from an LLM obviously)
Bennett retweeted
🐄 NEW @afterimage work for @turbopuffer
How do you explain a complex technical product to a wide audience?
Obviously: with a cow.
How we got there… (a winding road)
Investing in arch/docs/lints/tests helps everyone's agents. Garbage collection help catch missing ones.
But I still do up front planning for new features.
Opinions on agentic engineering appear to be converging into two camps:
"You should put a lot of planning up front, all the way down to program design, then let the agents cook", aka the @humanlayer_dev way.
vs
"Do a shit ton of investment in architecture/linters/LLM checks/automatic verification upfront, and then let agents rip. Garbage collect periodically", aka the @poteto way.
I currently land somewhere in-between:
- A bunch of research and planning up front, but skip program design unless I identify that a net-new abstraction will be needed, or I know I'm working on high-stakes/core code.
- For "every day" stuff, I lean heavily on guardrails.
- Frequent sampling of PRs that have been landing on main to spot problematic code that should've been caught by a guardrail. Add more guardrails to catch it, burn down the offenders.
- Frequent sampling of hot spots in the codebase, to detect when human intervention is needed, e.g. an abstraction has grown out of control. Maybe I oughta build a heatmap visualization for this?
- I also love @poteto 's take on the tier of guardrails (opinionated architecture > static analysis > tests > LLM checks)
TFW @Cloudflare just blocked you and your attempt to send feedback to them is also blocked
Bennett retweeted
Today we are releasing Cloudflare OS, a chatbot with connectors, just like every other tech company is doing.
Except actually, it's different. This is a remake of Sandstorm[.]io, my startup from 10 years ago, except this time built on Cloudflare Workers (the platform I've spent the last 9 years building) and deeply leveraging AI. This is more or less the culmination of my secret 10-year master plan.
This is a full-on personal app vibe coding platform, in which the sandbox is so secure that you can pretty much go wild -- the AI cannot introduce a significant security bug. We believe a company's security team can feel comfortable giving non-technical users permission to vibe code and then sleep soundly at night.
How is that possible? It's the Sandstorm security model, revisited. A "Gadget" is the same thing as a Sandstorm "Grain": a fine-grained app instance. For example, if you have a document editor app, each document runs as a separate instance of the app, in a separate sandbox (one "Gadget").
This means two things, both of which I think are Big Deals:
1. The platform can manage all access control, by controlling who can access the Gadget at all. There is no way the Gadget can accidentally leak itself to an attacker -- even an attacker who has access to other Gadgets based on the same app.
2. Since everyone is running their own copy of the code, everyone can freely *modify* their copy of the code.
Think about #2 a bit more.
What if, when you wanted a new feature in the software you are using, you could just prompt your agent to add it?
This doesn't work in the cloud Software-as-a-Service model, because you are not running your own copy of the app.
Sandstorm tried to change that 10 years ago, but the world wasn't ready, because not enough people had the skills or patience to actually modify their software. AI has changed that. Now you just ask the agent -- the same agent that you are using to help you interact with the Gadget can also modify the code of the Gadget.
And it is so fun.
github.com/cloudflare/cloudf…
Bennett retweeted
Built a distributed DNS server in ~a week. Rebuilt twice on purpose. Shipped -> went on vacation. DNS incidents a month later: 0. How we did it (hint: the answer isn't vibe-coding): blog.exe.dev/claude-is-not-a…
Bennett retweeted
We're going to be sharing more about how people use exe to build cool stuff. First up—a conservationist who turned 40 terabytes of public data into a video game: blog.exe.dev/meet-the-conser…
Bennett retweeted
At first AI seems to reduce the cost of software development, so people lower the bar on what projects seem worth it. So more software gets developed. However, it turns out that costs may not be reduced, just the illusion of cost through faster delivery. We can move faster, but that speed requires tokens (which is money). The other thing is that with more software comes more responsibility. If too much software gets written, we face catabolic collapse as we get crushed by the sheer amount of software we now need to support.
This all tells me the following. 1) AI can speed up delivery but not necessarily save money. 2) We can't just write software because it appears easier to do, because else we drown in low value software that must be supported. 3) Low value software may help with tactical issues but not strategic ones as strategy cannot be built on commodity. 4) If AI doesn't save money and a high volume of (lower value) software is bad, then we should use AI instead to work on harder projects with clear ROI. Projects that might have been unviable due to the complexity and risk of implementation and/or lack of expertise. The lesson is that we should continue to apply sensible constraints on what we build, and leverage AI to do harder more strategic projects (as well as fast prototyping).