| > the conversation that generates the code is becoming the true source of our software This is close, but not quite spot on. I've found that I'll test more ideas _with code_ using agentic tools, then before, leading to an excess of conversation history that is no longer representative of the final outcome. A simple example I encountered recently was dealing with performance issues on an iOS application (I haven't written mobile code since before Swift..). If you viewed the chat, you'd dive down a diverging path of rabbit holes, few of which were relevant to the final outcome[0]. To solve this in my own work, I've started relying on "context hierarchy" - which is essentially live documentation that lives next to the source files (using markdown). This approach avoids comments being removed erroneously, and helps codify the intent behind the code and how it relates to the overall architecture. As an added bonus, it also forces the LLM to edit _two_ things instead of just one (which might actually be the biggest benefit). My workflow is currently maintained via some repo level scripts and AGENTS.md prompts, but I've tried to pull it out into a skill for others to use[1]. Candidly, I'm not sure the skill is the best approach yet, as the agent can sometimes get too focused on the "skill" as a separate tool rather than a core part of the workflow. I'm currently exploring other options here (repo bootstrap, side-loaded subagents, hooks, etc.) [0]For more context, I was using a 3rd party library and trying to make it performant during a streaming operation, by removing the SwiftUI view layer (LazyVStack) and implementing a custom rendering path with UIViewController. The final solution ended up as a custom implementation of the 3rd party library, and moving back to LazyVStack. [1]https://github.com/jumploops/chum |