I'm 100% fully in the cloud and strongly recommend it to others. I'm building (AQ.dev) so I'm obviously biased, but almost every single one of our customers ends up bringing their own VMs to the platform instead of using the Managed solution. There's definitely a pull in that direction in my opinion.

What clouds exist? And are they all electron?

We still create a ton of end-to-end tests and run them a lot. What changed for us is the review process. While our whole team uses agents to do reviews, we also ask other team members to review the coding session itself rather than the diff. That team member can ask the coding session questions about the architecture decisions, scalability, edge cases, ..etc.

Disclosure: I'm building AQ (aq.dev), which is partly why I'm deep in this. We wrote up the session-review practice here: https://aq.dev/guides/how-to-review-an-ai-coding-session/. The practice works with any agents too, nothing tool-specific about it.

I'm not against open source. However, if I were to guess, I think less than 1% of people actually review, let alone modify the open source projects they use. I don't really buy this argument.

I think we're seeing a new modality of openness now with open weights, or being able to modify agents with md files, skills, and so forth.

Before LLMs the barrier to modifying software was much higher - in skill and time investment required.

Now we're getting to the point where any user can say "Claude, I don't like that. Please fix" and have it fixed. Configurability/extensibility can work in some cases, but having source code makes it much more powerful.

> However, if I were to guess, I think less than 1% of people actually review, let alone modify the open source projects they use.

I've done this a lot when trying to squash bugs

I think it's pretty common in software companies to maintain own custom fork of an open-source tool/library.

Love seeing this direction along with Buzz.

The hardest problem in multiplayer agents, at least for us, has not been the agent loop. It is scoping and QM's per-person scopes plus shared rooms is a sane answer for a company-wide assistant.

I build in the adjacent lane, AQ (aq.dev), a multiplayer coding harness where teams run Claude Code and Codex together), so seeing YC ship "a multiplayer agent harness for work" is validating and a little surreal.

look into .worktreeinclude

Agreed. I had to solve this at the harness layer myself. It just makes more sense to me this way. We basically created hooks around these operations and you can configure what happens at these calls.

Disclosure: I'm building AQ (aq.dev) a multiplayer coding harness.

Checked it out, it doesn't particular talk to me but for sure other people, looks like a cool project! Wish you best of luck and success!

Ugh .. what do we do now? jk

Local AI is going to win. Not because it's cheaper btw.

I'm thinking a lot about this recently as I'm building AQ.dev (Multiplayer coding harness). My instinct is to keep it simple and not trying to do too many shenanigans with these files and let engineers maintain control.

The most interesting part is Boris' recommendation to delete your Claude.md every 6 months to see what the model is capable of. The link in the post sends you directly to that moment.

Seems like something they should work on, not customers. Reinventing my workflow every six months because a company/product is lazy is not high on my list.

What I read from that is that there's a chance claude gets worse using a claude.md and that's a usability issue on their side.

I've seen this particular in the post and others from Anthropic make similar claims of "oh, just do this or that", and I've always been of the opinion: "isn't this what everyone is paying Anthropic to do?".

It would have been nice to hear about how to be more efficient, task/token wise, especially with Opus 5.

Most users are on a subscription, and aren’t able to run dynamic workflows, spinning up 1000 agents or leaving a bun rewrite going for weeks. Don’t get me wrong… I like cake.