Homomorphic encryption got significantly efficient with the first few iterations, but I don't really see the necessary orders of magnitude savings coming soon. You could reduce this by some partial encryption schemes (e.g., for LLMs you need a handful of basic operations) but a better alternative already exists: multi-party computation.

Source: I did research in this area in the past.

It's like the love child of Polytopia and Conductor. As many other agent management platforms/harnesses, Viberia has been building itself, and honestly this has been too much fun to stop.

- Opus is OP, like OverPowered

- Sonnet is SO, like your significant other (this was more meaningful in Sonnet 3.7 days)

- Haiku is HA, like the reaction to a bad joke

The latest model, naturally, needed three letters: FAB.

I'm now looking forward to ABS and LO

Tell your claude to set this up. Should do it in a single prompt

This is my take on the agent harness. Everything on an isometric map. Agents are grouped into "buildings" that run in a sequence or a loop; e.g., the CodeForge has an agent that writes a PRD, another one that implements, and a third that reviews. Everything is customizable, you build your own buildings/teams however you want.

It's a Tauri app, really light (about 8x less energy than the closest competitor I benchmarked, so it actually runs from a coffee shop on battery). It's macOS only for now, but ping me if you are willing to test the Windows or Linux version.

I've been dogfooding this for months and would love to get some feedback, feature requests, and bug reports so I know what to focus on next.

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

Points: 1

# Comments: 0

I was starting from scratch and mainly relying on Opus/Sonnet 4.

I also kept running into the Godot 3 vs 4 issue before adding specific guidance about this into CLAUDE.md

LLMs are really good at C# (and tscn files for some reason), so that solves the "LLMs suck at GDScript" problem. Also, C# can be cheaper in terms of token usage (even accounting for not having to load the additional APIs): one agent writes the interfaces, another one fills in the details.

Saying this because I had really enjoyed vibecoding a Godot game in C# - and it was REALLY painful to vibecode with GDScript.

Can you actually introduce that into the decision making? That is, you would:

1. Have the LLM come up with N many potential actions

2. Run XMage run in parallel and provide the outcome for each different action

3. Revert XMage to the original state

4. Provide the LLM with the different outcomes and have them choose the action/outcome pair rather than just the action

This would actually help them analyze the counterfactual outcomes more effectively and should prevent 99% of the blunders

If you happen to be token rich, you could even do this in a MCTS manner and have them think really deep

My take was that it’s easier to trace who is doing what (and what the agent hierarchy looks like) when agents’ locations are fixed.

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

Points: 1

# Comments: 0

Agreed, but how else are you going to scale mostly AI written code? Relying mostly on AI agents gives you that organizational complexity.

> Given how long gpt codex 5 has been out, there’s no way you’ve followed these practices for a reasonable enough time to consider them definitive

Yeah, fair. Codex has been out for less than 2 weeks at this point. I was relying on gpt-5 in August and opus before that.

This was my journey: I vibe-coded an Electron app and ended up with a terrible monolithic architecture, and mostly badly written code. Then, I took the app's architecture docs and spent a lot of my time shouting "MAKE THIS ARCHITECTURE MORE ORTHOGONAL, SOLID, KISS, DRY" to gpt-5-pro, and ended up with a 1500+ liner monster doc.

I'm now turning this into a Tauri app and following the new architecture to a T. I would say that it is has a pretty clean structure with multiple microservices.

Now, new features are gated based on the architecture doc, so I'm always maintaining a single source of truth that serves as the main context for any new discussions/features. Also, each microservice has its own README file(s) which are updated with each code change.