[simonw]

This piece is really good:

> The cost of building has collapsed, but the cost of aligning organisationally has not. If anything, it's gone up. When three different teams can each produce a working solution to the same problem in the time it used to take to write a proposal, the bottleneck moves from engineering to coordination.

We're still figuring out how to productively use coding agents as individuals, the next challenge is figuring out how to productively use them within teams. Coding agents reduce one bottleneck - producing working code - but that just moves the bottlenecks elsewhere.

(Note I said "working" code and not "good" code, that's a whole other thing.)

[CuriouslyC]

I still don't understand why coding agents are silo'd, and chat history is treated as disposable. Everyone on the team should be able to see all conversations and drop in and steer agents at any time, and chat history should be part of organizational memory.

I thought labs would have pushed collaborative steering by now, but I guess people got so TUI pilled they haven't even considered the possibility.

[simonw]

Yeah, I see the chat transcript as an important part of the work, and worth recording.

I've taken to linking to mine in commit messages, e.g. this one: https://github.com/simonw/simonwillisonblog/commit/e781e4eef...

(My favourite feature of the new Codex desktop app is that it has a comprehensive "Copy as Markdown" feature, which I can then paste into a Gist.)

[sciyoshi]

This is essentially what Shopify did with River (https://shopify.engineering/under-the-river), and we built out something similar at our company.

I'm sure the labs are working on this sort of thing - Managed Agents are probably the closest?

[nullpoint420]

I built this at my work and it didn’t turn out too well.

It’s a distributed agentic system on Temporal where all inputs are signals to the workflow. And then each agent has its own GNOME desktop either in a K8S pod or KubeVirt VM.

The biggest problem was context and ownership. The more we kept steering the model the worse it got until eventually it couldn’t complete its task. And on the ownership side, no one clearly owned the outcomes so it was just there… generating slop.

[mupuff1234]

What will chat history give you that the output of that chat won't?

[qazxcvbnmlp]

Was a specific piece of functionality intentional or an unintended byproduct of a previous change? Did someone else remove something but forget to take this out, or is it important? Etc

[sheept]

Context? Without it, it would be like starting a new session for each follow-up prompt

[simonw]

The same kind of value as a good commit history over just the finished code.

[mupuff1234]

But you still have the commit/pr history.

Not sure what adding the ramblings with an LLM will add.

[daxfohl]

One mitigating factor is the increased productivity leads to consolidation, aka layoffs, meaning fewer people to align with. (Leading to further increased productivity, more consolidation, and so on ... Whether this is a virtuous cycle or a vicious cycle depends on perspective).

[Sharlin]

The vibe I got from the article was that now that technical work is faster, bosses expect everything else to be proportionally equally accelerated, even though LLMs either don’t help at all at those workloads or actively make things worse.

[jillesvangurp]

Indeed, when you remove bottlenecks, you just end up discovering new ones.

One simple observation is that using agentic AI coding tools is not a multiplayer game currently. It's all one on one. I think this is a problem because a lot of development work actually involves multiple people. And to be effective as a team you need a shared context. If your agent has a different context than mine, we're not working together effectively. Having meetings to work around this is not a great solution. I call them synchronization bottle necks. Because that's what a meeting is. We drop all work to gather in a meeting where we share information and take decisions. And then once we are synced up, we continue work. OSS development happens mostly asynchronous tools. There are no meetings typically and hence less bottlenecks.

But in large organizations, all decision making bogs down on communication overhead. Miscommunication and misaligned people become problematic. The bigger the team the worse it gets. It's an exponential. You end up spending most of your time in meetings where you are collectively blocking each other from getting stuff done. It's why startups are so effective when they are small and agile. With AI we can move at that speed as individuals. But not if we are spending most of our time in meetings trying to brief everyone on all the amazing stuff that happened when you were talking 1 on 1 to your agent. It's a lot of context to dump in a meeting; it obviously does not scale.

The path to a solution might be very simple: why not have agents show up in team chat tools: make this properly multiplayer. Or, better, make the agentic coding tools proper team chat tools. Now we have shared context.

And then maybe rethink the whole process while we're at it. The whole business of having standup meetings is a good example. Or planning meetings. All of that is valuable context for LLMs. So, make sure they are there or at least have access to the transcripts. Use AIs to summarize, provide digests, track issues, update statuses, etc. They are really good at the detail work.

And you could do more radical things: instead of a scrum master, why not have a scrum agent? Why create issues manually? There's a lot of repetitive around issue and backlog management that POs still do manually.

We haven't really scratched the surface of how AIs are going to change development. Some of this probably won't work. Or it will work completely differently. The point is we have yet to try most of this stuff and figure out better ways of working.

[esafak]

Different teams could already step on each others' toes before AI. If there is confusion over which team ought to develop something it might indicate an organizational problem. Crucially, if you ship something you must be willing to maintain it.

[bot403]

I don't think the author would dispute that. But the problem is the foot is bigger and the stepping is faster.