I don't think I have a "burnout", but LLMs are really exhausting due to amount of pressure they generate. No one is really pushing me to increase my workload, but at every moment there is always something ready, done by my clankers or clankers of other people that I could be unblocking. In the past (before LLMs) it was already hard to keep up, but now it feels like there's 10x more things waiting at any given time, and there could be 10x more if everyone just "optimized" and streamlined processes fed the AI even more tasks in parallel faster. It just being a bottleneck of everything, all the time is tiring...
I am happy about all the little side-projects, and ideas it help my realize, and I enjoy exploring this new world, but I've noticed LLMs feed my unhealthy "don't want to take a break and waste time being idle" mindset, and I need to correct it.
W.r.t. article's main complain - I think the similar thing happened due to factory manufacturing automation. What used to be a varied skillful craft in a shop became standing in a single place of an assembly line doing the exact same thing whole day. LLM took away the more creative and variable part of the work, and left the repetitive QA rubber-stamping. Probably some of the mitigations used back then could be rediscovered today.
Nah. My beliefs are actual truth, so if provider is shaping their models according to my preferred political narratives that's correct and only moral thing to do. Anything else would be morally bankrupt.
That's pretty much the architecture I'm using in my personal coding harness Tau (tau-agent.dev) . There are some other points in here, but there are relatively minor. I think the observation that event log / event sourcing / cqrs works perfectly for harnesses is not very novel.
From UX perspective modal editing is all I care about and I just got used to Helix. And it's very feature complete and relatively stable, so hacking it and maintaining bunch of patches is not a lot of churn in practice.
My prediction is that there will be a Cambrian explosion-like event in software practices for 5-10 years (assuming continuous broad affordability availability), because LLMs can afford us a lot of freedom in trying a lot of new things including writing new tooling and changing the process. There's a lot to explore and I guess we'll collectively see what sticks.
1 year ago Claude Code was relatively new, and a first polished tool that really fitted my CLI-centeric dev-views. I used Aider before, but Claude Code was just much better. The autocomplete AI coders did not seem useful, and didn't have good integrations with Helix text editor. However even the frontier models were relatively bad in practice. Useful but not trustworthy at all. Being wrong/stupid 5-10% of the time compounds quickly.
6 months ago agents became really robust at just writing code they were told to write. Around that time I started really leaning into LLM-assisted coding, which require some skill, experience and adapting own workflows and tooling. And it takes time and effort.
Right now frontier models are really productive and robust. Sure it's still a fancy-autocomplete under the hood, so one needs to plan around that, but it's more common for Slopus finds bugs in my old human-written code, than I find bugs in its new code, especially that one can now easily write and maintain tons of tests which otherwise would never get done. LLMs don't have context and good judgment, so it still takes a lot of designing and steering the agent to write the right thing, but that's OK. And as the productivity bottleneck shifted very heavily from writing code to all other thing around it, it makes it very apparent that it's not that the clanker now that needs to get better, but the process around it.
I'm currently running on a fork of Helix text editor, which I heavily gutted to replace the block cursor with a beam-style (like one in insert mode, but just all the time). Since the maintainers are drowning in PRs (472 open ATM), I understandably don't expect them to have time for my weird ideas. Then I pile on top whatever PRs I want that I find useful out of these 472, and with a little bit of LLM help I have a very different text editor than the upstream.
If you read the post till the end, I am open for lots of forms of collaboration. Its just sending chunks of code diffs around is becoming increasingly like sending diffs to resulting binaries. Just inefficient.
Yes. At this point a prompt that produces the desired result is more useful than the resulting code in a PR. Effectively the code starts to have properties of a resulting binaries.
E.g. most peoples don't really think or ask that their tap water be free of cholera and other harmful substances, and yet we might want to make sure that continues to be the case. So it's not strong argument worth arguing about.
The real argument is - how much a compromise a replaceable vs non-replacable battery is. And I suspect the biggest part of non-replaceable batteries is actually superficial vanity considerations (gee, is it 7mm or 6.5mm), and planed obsolescence making more money. But the technical aspects are still a valid debate.
I wish I had your problems. :D . Problems that are really only a mild inconvenience, and can be solved with a single line in hosts file.
My biggest and possibly only problem preventing me from going IPV6-only is that Github doesn't support it, and there's just too much darn software I need to needs Github. (Yes, I know NAT64 exist - it's just extra complexity for something that is not even my problem in the first place).
> In my experience, the most natural way to write things in Rust is usually the fastest (or close enough) as well.
Well, a lot of C/Odin/Zig people will point out that Rust's stdlib encourages heap allocations. For actually best performance you typically want to store your data in some data-oriented data model, avoid allocations and so on, which is not exactly against idiomatic Rust, but more than just a typical straighforward Rust just throwing allocations around.