Ian CooperMar 3

We have been using coding agents with @BrighterCommand since last year, a few observations.

- As a project, Brighter supports many transports, out/in boxes, schedulers, storage, and distributed locks to fit into environments where it is to be deployed.

Show threadIan CooperMar 3
- This slows feature development because any feature, once designed, needs to be rolled out to all relevant implementations. And frankly, it’s often not exciting work once we have the theory of this new feature.
Show threadIan CooperMar 3
- We have 30 or more feature requests in the backlog. We work to keep a half dozen or so contributors at a time, but it’s part-time, so not everyone can contribute all the time. Couple this with rollout costs above, and it’s often slow to crack this backlog.
Show threadIan CooperMar 3

We now support using agents:

- We support a specification-driven process that mirrors our work issue ⇒ ADR ⇒ tasks ⇒ code with a strong emphasis on TDD and observing the loop. (We believe that for production code, the loop is observed).

Show threadIan CooperMar 3
- Exploring the theory of an issue has a high design cost, which involves requirements and ADR. The ADR is key here. Success is helped by mocking out interfaces, being clear where functionality will be implemented, algorithms, and data structures.
Show threadIan CooperMar 3
A coding agent can help here, but it’s a dialog. This is critical to quality.
Show threadIan CooperMar 3
- If the engineer can’t write the ADR because they don’t have the theory, call back to TDD and code by hand until you do, then update the ADR to reflect it. We often work with our in-memory versions for this.
Show threadIan CooperMar 3
I think this is really important. We are surrounded by messages that emphasise “coding is dead” but we should emphasise that good design only happens when it is developer lead, for anything non-trivial.
Show threadIan CooperMar 3

- We break up ADRs by concern, implement that concern; you drive the design.

- TDD is how you drive quality, both verification and spotting design issues; they are now easier to fix, go back, get the agent to fix the ADR and tasks, and adjust the code that has written.

Show threadIan CooperMar 3
- The cost of change has fallen, which makes quality easier. Iteration is very low-cost now, and iteration improves quality. Agents are relentless but can be wrong; relentless iteration is what drives quality.
Show threadIan CooperMar 3
- The speed once we have that in place is faster. The LLM understands the capabilities of transports and boxes, it is often more able to translate the requirements to idiomatic code than we are, without a lot of research. We go faster. We can contemplate tackling our backlog
Show threadIan CooperMar 3
- Contributors who struggled for time are back! The agent assistance and burning tokens overnight make it viable for them to contribute again. The “big tail” issues are less scary in terms of time commitment.
Show threadIan Cooper
- With good specifications and ADRs in the repo the documentation process has become considerably simpler - point the LLM at these, the code, and the existing documents and you will soon get the documentation you need.
Mar 3 at 12:07pmWeb
Show threadIan CooperMar 3
Most developers treated this as a chore, but eve coding agents can’t help if you don’t have docs for them to read.
Show threadIan CooperMar 3
Whilst I see some commentators predicting the death of OSS - why use OSS when you could generate - this view is the usual low-thought grifter nonsense. OSS projects can use these tools to accelerate their road maps.
Show threadIan CooperMar 3
They already have considerable theory for the agents to work with (agents who read our ADRs eagerly), and so we can go faster than in-house implementations.
Show threadOrchun KolcuMar 3

@ICooper

What goes into these ADRs (especially interesting to me because you said they are editable by LLMs)?
Is your use of the word agent deliberate somehow or were you just pointing to LLMs, since agents tend to imply no human in the loop?

Thanks!

Show threadIan CooperMar 4
@orchun Agent as in coding agent. Typically, I tend to believe in "human in the loop". Long blog post coming on that.
Show threadMattias Karlsson (he/him)Mar 3
@ICooper see it from fairly senior people, one thing though, with OSS you're not just getting lines of code, you're also getting days in production, and that will always be zero with generated. Maintainability is also something rarely taken into account by these people.
Show threadPeter Ritchie🌍🍁Mar 4
@devlead @ICooper Even with OSS with agentic contributions, those projects have established road maps and a context (including ADRs) built on experience and tacit knowledge. I've seen teams skip OSS and "write their own" prior to AI with expensive results. It will be the same with OSS. Even with agentic contributions quality OSS takes human participation and maintenance.