While reading, I had an idea about how to turn competition between agents into something useful. What if we use competition only at a higher, strategic level: a kind of product committee of agents that argue which ideas or policies to implement, with budget, justification and some form of consensus. Curious what you think about this direction.

I actually set up a Telegram digest for Hacker News using OpenClaw, and today that digest brought me to this very post. Nice little full circle moment.

Awesome! I liked Rust even before it became mainstream, cool that you make it more accessible.

Cool, the idea of leaving comments directly in the plan never even occurred to me, even though it really is the obvious thing to do.

Do you markup and then save your comments in any way, and have you tried keeping them so you can review the rules and requirements later?

Beautifully laid out. Do you have a tactical “how to” for rolling this into a real team with first steps and common pitfalls?

yeah, that is exactly what i do to create in the repo. i will try to create simple github actions that will do publishing to gdocs, linear and pulling comments from those systems back(and maybe even slack). an obviously it should work with other systems too like JIRA and confluence. but i think implementation shouldn’t be hard part and anyone can do custom one quickly

Thanks, this is useful!

I'm currently at the stage where my agentic dev loop is running and feedback is flowing, but I haven't reached true autonomy yet. I still have to control things with manual workarounds constantly. That's exactly why I'm curious about others' experiences.

The most interesting challenge to me is the transition path in practice: how do you get from the messy reality to that clean ideal picture when a team is already mid-project with their own ingrained habits and tooling preferences?

The most interesting challenge to me is the transition path in practice: how do you get from the messy reality to that clean ideal picture when a team is already mid-project with their own ingrained habits and tooling preferences?

-

so what tools team uses now? than the answer can be more concrete

I'm in a similar spot and very curious about the transition path, not just the end state.

We have several projects and different teams. In one of the more “advanced” ones we already run on a fairly standard enterprise stack: Jira for work tracking, Confluence for docs, and a dedicated repo for SDD/technical specs. That’s also the place where I’m closest to getting something that feels like real autonomy: the agentic dev loop is running and integrated into the existing tools, but there are still plenty of manual guardrails and workarounds.

My question is less about wiring up specific tools and more about the change‑management / rollout side. In practice this is a digital transformation: it’s not enough to define the target “agent‑first SDLC”, you also need a sane path to get there from a messy reality with ingrained habits and existing tooling.

Have you seen any concrete adoption patterns or approaches that worked well for teams already mid‑project?

I manage 18 microservices with heavy LLM usage and kept running into the same problem: when I talk to my teams about treating context as a scarce resource, there is no single term for what I mean. "Token efficiency" is a cost metric. I needed a design principle I could name, reference in code reviews, and enforce.

I wrote up what I'm calling the Principle of Parsimony in Context Engineering: https://blog.rezvov.com/principle-of-parsimony-in-context-en...

Core idea: a context is parsimonious when nothing in it can be removed without introducing ambiguity or degrading the result. The goal is not fewer tokens — it's conscious allocation of a finite budget between instructions and artifacts.

Does this distinction hold, or is it just a subset of token efficiency? What existing formalisms would you apply here?