Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • The Cordis plugin architecture is interesting

    https://github.com/cordiverse/paper

  • As I understood, Cordis is for architecting functionality as plugins that can be hot-loaded and hot-unloaded (without having to restart the parent app such as VSCode). Cordis looks to be a second-layer extension system within the parent system, e.g. VSCode. I understand that Cordis is not tied to VSCode.

    Using memory to track inverses does not scale.

  • I like it, it is beautiful, specially the trajectory tabs, very explicit, detailed on what it does. I like the plugin architecture, I wish they were sorted alphabetically so I don't waste hours looking for a plugin in a sea of unordered text.

    9 out of 10

    Edit: After creating an app it works as expected, no complains, lots to celebrate, being version 0.1 there is room for more surprises but right now it's the perfect tool for those initiating in agentic coding with one of the most affordable and powerful AI. It is really wonderful.

  • Everything is a plugin.

    "this, like all other problems in Computer Science, can be solved by one more level of indirection." Roger Needham, circa ~1981

  • There is such a clear lack of innovation drive in this field. Every lab just copies what the other does. One of the most baffling things to me is how the once-upon-a-time good developer instinct to make everything reusable, testable, and deterministic is just getting lost into a sea of markdown begging a language model to please act a certain way. For example this repository has a "skill" definition that consists in instructing the LLM to run pre-commit checks. But we have solved this a long time ago, it's called git hooks. I do not understand why they don't simply wire those instructions as testable, reusable, deterministic code routines in the git tool call itself. It's like everybody is taking their brains out and putting it in a drawer.
  • Gotta burn the tokens somehow! There’s a lot of these solved problems that devs have forgotten exist all in the name of using an llm for sake of using it.
  • I remember a popular hn thread few yrs ago where a dev replaced their whole deployment pipeline with a prompt.

    it was widely ridculed at that point but now i am not so sure.

  • I actually run into more issue with deterministic hooks. Ie one hook triggering before another and not letting the agent move forward. I agree that there is a place for deterministic hooks. But there also times when you need something closer to a recommendation that they agent can be reminded of but isn’t a hard block. Think of assigning something to a co worker. You can recommend a checklist of what to do before a commit but they will adjust if the situation requires it.
  • Yeah. LLMs have their place and they are definitely super human at short length tasks, but I feel like a large part of the "AI boom" is trying to get the computer to do something in a worse way then it already could.
  • First, cloning a repo doesn't bring the hooks with it - so it's not just as simple as saying "use git hooks".

    Second, if the repo had hooks and instructions for the LLM or user to blindly install/enable the hooks, we'd instead be complaining about security risks and what might happen if the repo is compromised at some point in the future.

    Third, sometimes you don't want to mechanically enforce things via git hooks because it impacts your use when what you're really trying to codify and enforce are the LLM's actions. In that case you can enforce mechanically via hooks at the harness level.

    And finally, git hooks are a great solution for upstream repositories to enforce quality and protect branches. But it means that the upstream is the one running the checks. It makes the upstream a potential bottleneck - better to have the leaf nodes run the checks locally and fix any issues before pushing it upstream rather than push upstream, wait for results, make changes, push upstream, wait for results, make changes.

  • Yes this whole focus on customisation and plugins etc is really just laziness and the absence of innovation. I don't want an infinitely programmable IDE. I already have that it's called my computer.

    I want something that actually has an opinion and gives me productive value without having to spend days reconfiguring it first.

  • Every company gets a limited number of innovation tokens. Where they choose to spend them is up to them. Some companies spend them on the model harness, some, like DS, spend them on the model architecture etc.

    https://mcfunley.com/choose-boring-technology

  • This is exactly how almost every field evolves. We like to think we are so innovative. We aren’t. When someone finally does something slightly different that’s actually useful everyone comments how that was so obvious all along and they could easily have done that too . Hindsight and all. And for every new tech , people will always try to use it for everything, no matter how unsuitable, until the hype goes down and we have a clearer picture of where the tech should be used.
  • Based on what I've read today, DeepSeek Harness seems to be similar to Pi Coding Agent in design. Both are barebones to start out and rely heavily on plugins. However, 3 things make DSH stand out. 1. Plugins in DSH are required to have cleanup handlers, so I guess you could clean up plugins that are no longer used mid-session and prevent it from interfering with the current task? (unsure about this) 2. DeepSeek V4 models are post-trained on DSH. Given how cheap DS V4 is compared to OpenAI and Anthropic models, running DS V4 in DSH could be much more cost-effective while barely losing performance. 3. It's utilized and maintained by a large lab dedicated to open source AI. It's always nice to get new open source tools from large labs so that we are not always relying on small teams doing the heavy lifting.
  • Is there a reason why so many of these agent harness are written in node.js?
  • I'm still waiting to find one written in Rust that I really love. I don't think js/ts makes sense for terminal based applications
  • TypeScript's type system is extremely expressive while still allowing you to retain the flexibility of a scripting language. v8 and JSC also have decades of performance tuning across basically every consumer device.
  • TypeScript is great and its ecosystem is easy to work within.
  • codex is written in rust fwiw

    smol has implementations in Go, Python, Clojure, PHP

    https://github.com/smol-env/smol

    out of the box an agent only needs to be able to do http requests and call tools (which might again be just http requests or shelling out)

    there is no inherent reason for why an agent has to be in JavaScript or Typescript

    but they are popular languages and come with runtimes and libraries for http requests, steaming, TUI (terminal ui) and so on which can help

    by tosh
  • I'm not sure why specifically Javascript instead of something like Python or other options, but using an interpreted environment minimizes the friction for implementing extension systems, which are an important feature in AI harnesses.
  • Probably for the ease of coding extensions — which strikes me as outdated thinking: if it’s open source and you’re outsourcing the coding to LLMs, why not use a compiled, safe language?

    There’s an interesting counter example for DeepSeek called CodeWhale, though:

    https://github.com/Hmbown/CodeWhale

    by pohl
  • 1. it's built for async 2. runs everywhere 3. interpreted, making it fast to iterate on 4. decent performance 5. most popular language, llms are decent at writing it
    by m_ke
  • Because:

    1. The first significant agentic harness was made by Anthropic.

    2. One of the most senior developers of client-side software at Anthropic is Felix Rieseberg, one of the original creators of Electron. [1]

    3. After Claude Code blew up, everyone else copied Anthropic.

    ---

    1: https://daringfireball.net/2026/07/claudes_criminally_bad_ma...

  • But like, what is it? Odd that this reached #1 on HN. The README is pretty bare outside of installation instructions and a link to "Cordis", which is "A Meta-Framework of Spatiotemporal Composability." and "under active development. The API is not yet stable and may change without notice.".
  • It's like pi.dev, or OpenClaw or Codex App.
  • > A Meta-Framework of Spatiotemporal Composability

    Good to know I was not the only one confused. Reads like word salad!

  • A "harness" is basically what you call Claude Code and such, i.e. a TUI to run the agent.
  • New coding harness that seems to have some novel concepts and one of the pretty cool things on their landing page for it here: https://deepseek.com/harness/en/ is the Every Run is Traceable view:

    "Everything the model sees is recorded in an append-only session log: system prompts, reasoning, tool calls and results, subagent scheduling, and every context injection. In the Trajectory view, you can inspect these records by source. Resume, fork, search, and replay all operate on the same event stream."

    Seems pretty helpful - have sort of wanted something similar (I use Pi).

    They also released this research paper that backs their whole plugin composability system that seems pretty cool: https://github.com/cordiverse/paper

  • «It uses an architecture where everything is a plugin» Ok, that's enough for me. I have developped over the year a plugin fatigue.

    Every product relying on "community plugins" for their features implies it works fine the 6 first months, then it's a nightmare of incompatible, deprecated, incompatible plugins, with no consistency and no governance.

    I understand how attractive it can be to companies to think, hey, let's make a very small product and rely on other people to make features, and I hope it works, but I'm personally staying away from that.

  • You're conflating 2 separate issues, plugin architecture is a valid choice for reasons that don't have to do with community plugins at all