Ask HN: Does anyone keep prompts and reasoning as part of dev cycle?

[sshadmand]

We've never been able to read developers' minds, so we relied on documentation and comments to capture intent, decisions, and context even though most engineers dislike writing it and even fewer enjoy reading it.

Now with coding agents, in a sense, we can read the “mind” of the system that helped build the feature. Why did it do what it did, what are the gotchas, any follow up actions items.

Today I decided to paste my prompts and agent interactions into Linear issues instead of writing traditional notes. It felt clunky, but stopped and thought "is this valuable?" It's the closest thing to a record of why a feature ended up the way it did.

So I'm wondering:

- Is anyone intentionally treating agent prompts, traces, or plans as a new form of documentation? - Are there tools that automatically capture and organize this into something more useful than raw logs? - Is this just more noise and not useful with agentic dev?

It feels like there's a new documentation pattern emerging around agent-native development, but I haven't seen it clearly defined or productized yet. Curious how others are approaching this.

[msejas]

I approach this by always asking Opus to send an agent to explore and trace how a pipeline works. Even better if I have an integration test. Once it's fully mapped out I might ask it to dump everything it discovered on a markdown doc, clear the context and start the task. The docs folder keeps the information intact for future development.

Managing context is by far the most important skill to be effective with LLMS, in addition to having already existing clean code on the codebase.

As they read your files, you are one shot training the LLM in how to write code and how you structure it and it will adapt. With clean codebases, I found the LLMs were outputting well documented, well logged, and even tested functions by default because the other files it interacted with were like this, 'it learns'.

Additionally you have to think how they train and evaluate the model, there are so many use cases to cover, I'm pretty sure in the Reinforcement Learning part they are not going in huge long threads, but are actually benchmarking and optimizing from fresh context starts, and you should do that as much as possible in your tasks.

[sshadmand]

I have a similar flow, but do you connect that back to roadmap, tickets, or workflow for posterity or tracking?

Also, some say they use the tickets themselves for the prompt and have Claude CLI (or alike) just work off the tickets directly.

[sshadmand]

On the same track:

https://x.com/Khaliqgant/status/2019124627860050109

Here he mentions "Store trajectories " is a tent pole to see vectors of work over time which goes back to the point above. But also, will that trajectory be stored in the agent/framweork, or will it also need live elsewhere for us humans?

[sshadmand]

like with most agentic dev I do these days, I go between "I need this" to "I used to need this when humans were involved but is it just vestigial" a lot. In this case, why am I documenting at all if the agent is pretty good at understanding things quickly via the context and indexes it creates from the code itself.

...on the other hand... since we still have humans using the features and interacting with them, knowing what is going on and why it made a decisions (for better or worst) doesn't seem like something to let go of.