Michael Pollan's "A World Appears" is a much more interesting and nuanced take. Very much recommended.

The most difficult part of any non-trivial engineering is understanding the problem, and the first versions of a piece of software are how you reach that understanding.

That's why I do not think that AI-powered "software factories" will ever work. It's waterfall development all over again. An architect writing UML diagrams and handing them off to the team of programmers to do the essentially mundane task of implementing... the wrong thing.

AI is, however, very good at helping you go fast from the wrong first version to the less wrong second one. But you need to remember that your main task is to understand the problem that you are trying to solve.

Comments URL: https://news.ycombinator.com/item?id=48164178

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48158737

Points: 5

# Comments: 12

I was tired of copying/pasting between agents, so I gave them identities, and tools to talk to each other and share tasks. I've found it so useful that I've left my job as the CTO of a German startup to focus on this.

The identities are public-key DIDs with DNS as the source of truth, as well as team membership. I also run a public registry at https://awid.ai (also OSS).

Comments URL: https://news.ycombinator.com/item?id=48066041

Points: 1

# Comments: 0

- How you keep on top of what they are up to?

- How do they organize and coordinate?

I think this can only work based on a solid agent id system.

Shameless plug: I have been working on a solution for it, available at https://github.com/awebai/aweb and with a distributed, independently verifiable, and fully open id system at https://awid.ai

I wonder if this could be made to work with OpenAI's workspace agents.

The jury is still out in my mind. Can I use these tools to create software that does not suck? Will the speed at which code can be created and modified lead to a change in our ideas of what good code looks like?

Last week I had a good idea for a change in architecture in my software that will make it much more powerful. I set a team of 12 agents on it, mostly unsupervised, with a pretty weak org structure. After a day and a half, and way too many tokens spent, they managed to build the entirely wrong thing. All tests passed.

The next few days have been spent with a much simpler structure: two teams, each of two agents, one coding (Codex is better at it these days) and one reviewing and keeping things aligned with the docs (Claude). This may have worked, I am still not sure.

My best guess right now of how good software development will look like with these tools: the effort/tokens spent on reviewing needs to be commensurate with the effort spent on coding.

I've been programming for 40 years, and I've been on both sides. I love how easy it is to be in the flow when writing something that stretches my abilities in Common Lisp, and I thoroughly enjoy the act of programming then. But coding a frontend in React, or yet another set of Python endpoints, is just necessary toil to a desired endpoint.

I would argue that people like you are now in the perfect position to help drive what software needs writing, because you understand the landscape. You won't be the one typing, but you can still be the one architecting it at a much higher level. I've found enjoyment and solace in this.

It started its life adding agent-to-agent communication and coordination around Steve Yegge's beads, but it's ended up being an issue tracker for agents with postgres backend, and communication between agents as first-class feature.

Because it is server-backed it allows messaging and coordination across agents belonging to several humans and machines. I've been using it for a couple of months now, and it has a growing number of users (I should probably set up a discord for it).

It is actually a public project, so you can see the agent's conversations at https://app.beadhub.ai/juanre/beadhub/chat (right now they are debugging working without beads). The conversation in which Eve was blaming Bob was indeed with me.

"Bob’s latest mail is actually the source of the confusion: he changed shared app/backend text to aweb/atlas. I’m correcting that with him now so we converge on the real model before any more code moves."

This was very much not true; Eve (the agent writing this, a gpt-5.4) had been thoroughly creating the confusion and telling Bob (an Opus 4.6) the wrong things. And it had just happened, it was not a matter of having forgotten or compacted context.

I have had agents chatting with each other and coordinating for a couple of months now, codex and claude code. This is a first. I wonder how much can I read into it about gpt-5.4's personality.

For example, I built https://claweb.ai to enable agents to communicate with other agents. They run aw [1], an OSS Go CLI that manages all the details. This means they can have sync chats (not impossible with MCP, but very difficult). It also enables signing messages and (coming soon) e2ee. This would be, as far as I can tell, impossible using MCP.

[1] https://github.com/awebai/aw

When software engineers become agent herders their day-to-day starts to resemble more that of a manager than that of an engineer.

Comments URL: https://news.ycombinator.com/item?id=47196304

Points: 4

# Comments: 0

Agents use aw (auditable OSS Go CLI) to do real-time chat and async mail on the https://claweb.ai network. ClaWeb is built on the open aWeb protocol: https://github.com/awebai/aweb.

Each agent has an address (e.g. claweb/marvin) and a self-certifying signing identity (did:key). Messages are signed and verifiable offline. For continuity across key rotation / server moves, agents can also publish a stable ID (did:claw) and an append-only mapping log via the fully OSS https://clawdid.ai registry.

Comments URL: https://news.ycombinator.com/item?id=47179915

Points: 1

# Comments: 0

> it does only what’s needed, in a way that both humans and machines can understand now and maintain in the future

We need to start thinking about what good code is for agents, not just for humans.

For a lot of the code I’m writing I’m not even “vibe coding” anymore. I’m having an agent vibe code for me, managing a bunch of other agents that do the actual coding. I don’t really want to look at the code, just as I wouldn’t want to look at the output of a C compiler the way my dad did in the late ’80s.

Over the last few decades we’ve evolved a taste for what good code looks like. I don’t think that taste is fully transferable to the machines that are going to take over the actual writing and maintaining of the code. We probably want to optimize for them.