Real-world programming with AI. No filler, just killer! github: wesen
Boston, MA
Joined November 2023
- Tweets3.3K
- Following570
- Followers1.7K
- Likes1.3K
It’s not overengineering if it works. The thing to care about is over featuring or building features that are not worth their human cognitive cost, or just engineering too fast.
It’s only gonna become more of a problem in the future.
Now that models are superhuman in basically every dimension related to programming, trying to keep a “traditional” grasp of our code (which was flawed anyway) is just capping the model’s capabilities. And if you disagree, just wait for the next generation then.
Meaning: we have to come to terms with the fact that we will reach (imo have reached) a point where we struggle to understand good code, and spend a lot of effort to turn it into puny human code. The same way I don’t nitpick a compilers assembly in 99.99999% of the cases, i don’t nitpick architectural decisions of the model.
However, I steer it into architectural dimensions, and I think my deep interest in the structure of code (as in mathematical structures) and abstraction allows me to find the right keywords.
For example: this is a window manager like UI to do ggplot style manipulations and graphs, using a clever “anything is a semantic object” technique. Look at the code and you’ll see the core engine of all of this is about 150 lines of code. _superhuman_ . But all it took me to summon this, which could have taken ages of “human brained engineering”, was “make me a grammar of graphics tiled UI using presentation based UI principles (ciccarelli 1984), using a brutalist retro look”
claude.ai/public/artifacts/5…
A lot of what looks like sol overengineering stuff, adding capabilities and providers and executors and what not, kind of really isn’t. It’s a lot for humans at once, but it actually removes complexity from the debugging process, and getting rid of it not only eats tokens, but will cause even more tokens down the road.
github.com/go-go-golems/go-g… goddamn
here's an interesting idea, within a company / team:
- a single person is responsible for all the production code, kind of the way an architect was
- everybody else can slop around as much as they want, the key is that at the end comes out a good document / a good feature (could be just a screenshot or literally 2 sentences: "yes this is good"), and the single integration person is responsible for prompting it reliably into the main codebase, instead of reviewing PRs....
that integration human role can be passed around, or some people will find that they really enjoy it (I know I do), and it removes that whole "review 200kLOC of slop": from the get go you know they're destined for the trash can, so there is no animosity or so.
The responsibility is to get the "core" of your work across.
It's finally getting pretty real. go-go-os with a few generated apps running, each app can be a HTTPS backend or a federated module or a generated piece of code. All code with introspection+docs (for agents and humans), all apps run in a quickjs VM with FRP pattern.
more pretty below 👇
I wish we talked more about prompt engineering. Start with the desired outcome: a set of tokens that contains say, the entire source code of the thing we are trying to build.
Only then start thinking about what the context needs to contain to create said outcome. And where do we get said context from?
I wonder if spending 2 years building context windows by hand (“$(cat foobar .c) using this file create a new file that matches the api: $(gen-api tmpl)”) just makes me default to that kind of thinking, and then map it to agent behavior and figuring out which tools to give them.