"How I Learned To Relax And Just Start New Sessions Often"

Might as well just open our pants and wave our wangers, hoping for a better world

For me it comes down to the old standby: just vendor the .cargo build chain into your repo and be done with it. There you go. Lock in the year edition, the version, the features, the quirks, and the bugs. Just like game devs did with game engines or OpenGL or Direct X versions.

Anthropic's "Best Practices" doc[0] for Claude Code states, "A clean session with a better prompt almost always outperforms a long session with accumulated corrections."

[0] https://code.claude.com/docs/en/best-practices

I was very impressed.

This was really all that Agile was ever trying to avoid -- the tyranny of imaginedf omniscience. The bad old way (which I did labor under in the '90s) set up a Gant chart of dependent requirement up front, during a "design phase" which completely de-valued learnings and insights gained along the way as a software system was constructed during the "implementation phase". It was the best we had till then, but many software projects were failing due to their inability to adapt to unforeseen design flaws or to the feedback of stakeholders (once the software finally got into their hands).

I don't know why the ceremonies became ossified and sacred. I guess every movement must confront the danger of settling for form over substance. I do know one thing. You can't build an amazon dot com, a Facebook, or a Grand Theft Auto in a 1-million token context session with an LLM. I'm sure you can do it with many such sessions, but it won't be an LLM that ties it all together properly (again - too much context). And I say this as an enthusiastic user of agentic programming.

A lot of handwaving about hAx in the benchmarks but many of these claims are from people who got their information secondhand (or worse). Actually reading code from the top submissions in the techempower/FrameworkBenchmarks repo (organized neatly under the frameworks/ directory hive) yielded valuable insigthts for me:

* Pipelining SQL requests has a massive effect on RPS for web services that will access SQL databases

* A well-maintained HTTP2/HTTP3 web server written in c named h2o is relevant in 2026, even if it is used as a proxy that delegates business logic to simpler web service workers written in Rails or in python 3 (via Gunicorn)

* For web services that write to a SQL database, the Axum rust stack, now with a healthy ecosystem of middleware modules, may provide up to twice the RPS as the Spring (Java) stack (externally discovered: at lower CPU and much lower RAM usage)

* Even frameworks written in JS (hyperexpress, just-js) or python (aiohttp) can vault into the realm of top-10 performers if they leverage OS-level asynchronous IO and SQL pipelining.