ramoz

Aside from the opus5.5/fable + sub-lockin arguement...

Building an exceptional harness requires exceptional understanding of the technology you are harnessing.

Ant is building Claude Code in a place of frontier knowledge and advancement - everything surrounding the tool at Anthropic is something that does not exist within any "open source" organization. OC has recruited exceptional developer and new-media talent, but they have largely developed from a "catchup/copy" and designer-led process, and have consistently been behind in terms of capabilities and/or have misaligned implementation due to what I would classify as disadvantages of not understanding the underlying technology fully. I think this has led to a lot of unintended bloat - maintaining a plugin for it has been consistently very head-scratching experience.

- Pi was a refreshing welcome to the OSS arena with thoughtful design to enable simplicity and ecosystem-based development

In October 2026 - Claude Code feels further stretched ahead. The orchestration/projects model you get with sub agents either in the cloud/remote or local is the strongest capability I have experienced in awhile. Beyond the model intelligence the harness has been consistently refined and now includes things like Mods for robust customization. OC is pushing through big milestone release, not advancing on the front in terms of agentic engineering ux. Who came up with MCP, Slack/Claude Tag interface paradigm (less about slack), dynamic workflows, durable subagents, agent-to-agent communication across the harness, etc

Interesting on Instinct, I have to often tell it "just do it"

I actively use all harnesses and maintain popular plugins across them

If you tell me I should OpenCode over Claude Code in October 2026 - then you have no idea what you are talking about.

What are discussions?

Iroh released something similar awhile back

https://www.iroh.computer/sendme

I dont have that problem with opus5.5. I dont even take the screenshots anymore (it does all screen recordings)... I tell it a simple narrative and it follows through. e.g. https://x.com/plannotator/status/2108589088139886769?s=20

AI is a tool. And I don't see the point of this argument other than a bit of a `boomer rant` , as someone who sort of fanboyed rich, like many on HN, earlier in my career.

Plannotator Inbox is an optional runtime using the best of plannotator annotation capabilities.

While all your agents work they constantly bombard you with decisions that need to be made. Those decisions get lost over time, Claude might hit you with "I need your 2 answers to X and Y" which was asked 2 days ago. Think about all the remote pi durables to come basically... how can we surface all the important stuff we need to review...

The chat ui thread, imo, is becoming outdated very fast. We need a new way to interface with agents and surface the things that matter in an intuitive way. Plannotator Inbox is a stab at that.

part of the free/open source capability at: https://github.com/backnotprop/plannotator

Also feel free to show your love or hate on the x announcement: https://x.com/plannotator/status/2108589088139886769?s=20

There needs to be a balance. It feels off, today & consequences of future, that technology has led to the collapse of privacy.

And as we progress we will need to rationalize what it means for private companies, AI, to know everything about you and for the government to have a tap into that. I hope balance lands in favor of things like privacy preserving underpinning.

Why should we not treat AI like critical infrastructure

AI is becoming critical infrastructure. Laws will follow. Ie similar to ISP/communication infrastructure laws

With this logic, ISPs should be monitoring all texts and internet traffic. Might as well extend an open line to the gov’t to ensure it escalates even more appropriately and faster

a less intelligent decision is not "more reliable"

A few months later and I've committed to this structure even more. It's been very good.

Early on I had to smooth out some rough context drift problems, but with the right structure and written rules and better models they maintain drift on their own as they go.

So much rich history, provenance and references all existing as greppable files... folders full of mini prototyping and questions and answers and planning, spec docs, etc. Shared libraries amongst repos all sitting next to each other

I think with enough structure (written rules and good folder layout), poly/monorepos are the way.

https://backnotprop.com/blog/context-monorepos/

  - Better models can keep the drift in check.
  - What's super important these days is having all historical context, historical decision making, prototypes and whatnot.
  - all projects and their worktrees located together
  - all reference docs, code, etc - a folder away

When I ask "what happened to x?" ... the agent has everything it needs to give me that answer. When it plans the next feature it can validate assumptions against previous decions made in my `decisions` folder.

fixed it

You still have to orchestrate these things and the wholistic system architectures, pull the slot machine handle many times to get the right thing, and review/verify the working output constantly.

That said, I think we need to be prepared for how a simple prompt like "make it faster" will work in a relatively short timeframe - and where the AI is able to adequately refactor/re-platform/be done in a way where even the architecture becomes obscure to us.

Idk what adom is, but somewhat related I had jev play poker and it was abysmal. https://backnotprop.com/blog/jev-poker/

Jev created accessible/programmatic ergonomics around a general purpose classifiers, and did it very well; ie intuitive api and structured data approach.

Anyone can copy that and apply to an array of models - stripped down LLMs or already slim/highly performant traditional classification architectures (just wrap inference with an api that inputs/outputs the same structured data).

Jev, I think, would say their advantage is the intelligence of their models and training data including calibration: https://medium.com/code-applied/calibrated-classifiers-makin... (which i still struggle with in the general application... there's no free lunch with these things).

Sign-in with sub accounts seems big. This is how I thought this was always supposed to be - the providers acting more like an OS/ecosystem-enabler.

Extensions into codex also seem cool.

The provider also eating the application stack at the same time, doesn't make too much sense. I don't want my team going all in on one provider versus the other. (things like the docs/slides/sites).