We've been thinking at Wehkamp to do the same, as we have the same challenge:
The main challenge is that end-to-end processes are long and complex, spanning many code repositories. So just asking Claude Code to analyze a single repository wasn’t going to work (and the default /init wasn’t producing sufficient detail even for this single codebase).
So I decided to use Claude Code to analyze the system to map out the end-to-end flows relevant to the domain I work in so that Claude Code (and humans) can use this to handle more complex challenges.
This spiders through your local repos and creates some documentation. The only problem is: we have 1500 repos, so we might need to do some extra to get the right repos downloaded.
This video is an extract for product managers, service designers and others people who make hardware, software or both. It might be good general life advice too!
1. Make your requirements less dumb
Your requirements are definitely dumb.
Its particularly dangerous if a smart person gave them to you as you might not question them enough.
2. Delete the part or process
If you're not adding back then you're not deleting enough.
Don't add requirements just in case, don't hedge your bets.
3. Simplify/Optimise
Don't optimise if it shouldn't exist.
4. Accelerate cycle times
But don't go faster if you haven't worked on the other 3 things first...
If you're digging your grave don't dig your grave faster.
🤔 Interesting read-up on how to incorporate coding agents and testing into a software project:
I proposed “vibe engineering” as the grown up version of vibe coding, where expert programmers use coding agents in a professional and responsible way to produce high quality, reliable results.
Without owning something over an extended period of time—like a few years—where one has a chance to take responsibility for one’s recommendations, where one has to see one’s recommendations through all action stages, and accumulate scar tissue from the mistakes, and pick oneself up off the ground, and dust oneself off, one learns a fraction of what one can. Coming in and making recommendations without owning the results, without owning the implementation, I think is a fraction of the value, and a fraction of the opportunity to learn and get better.
Interview by Dwarkesh Patel with Richard Sutton on LLMs, AGI and why he believes AGI will not be born from using LLMs.
In his essay The Bitter Lesson, he argues for not building AI from mimicking human behavior in our systems: "breakthrough progress eventually arrives by an opposing approach based on scaling computation by search and learning."
Postgres 18 is adding asynchronous i/o. This means faster reads for many use cases. This is also part of a bigger series of performance improvements planned for future Postgres, part of which may be multi-threading. Expect to see more on this in coming versions.
