It's interesting that you’re using Linear tickets as the primary context source. From my experience so far, one of the biggest issues with coding agents is context drift. Ticket says one thing, but the codebase has changed since it was written. How did you solve? fresh RAG pass or use something like ctags to map the repo before it starts the implementation, or does it rely entirely on the LLM's provided context window?

▲

ubercore 3 hours ago | parent | next [-]

We don't have this kind of tooling built up, but we've been using Linear as a source of truth alongside a human written prompt adding context. It's worked really well for both feature development and bug hunting, and helps keep us honest with tickets (good LLM context is still good human context) as well as maintain some level of consistency between LLM passes on the same issue.

▲

yzhong94 3 hours ago | parent [-]

100% on using linear as the source of truth! We went a bit further and just use Linear as the prompt. So there isn't a human written one adding context that lives elsewhere

	▲	jmathai 3 hours ago \| parent [-]
		This has been great for me too. Every feature starts and completes with /gh-issue <issue number>. Every issue is created with /spec and a conversation with a human. Once the spec is materialized as an issue it’s sufficient for an agent to implement. Everything is documented. It’s amazing.

▲

yzhong94 5 hours ago | parent | prev [-]

We don’t believe PM or eng can write the best prompt or spec, so we don’t ask them to.

One real Linear ticket from a few months back that we assigned to broccoli:

Store post-processing run outcomes in a versioned, append-only audit trail so re-running the same processor on the same audio file produces a complete history (who/when/what changed), while keeping an easy “latest result” view. Add an admin-only UI.

That’s it. As a part of the sketch step, broccoli does its own repo discovery and online research before planning the execution.