Live data from Hacker News

DeepSeek Harness developer preview

deepseek.com

171–180 of 346 posts

Re: DeepSeek Harness developer preview

#171
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.

Re: DeepSeek Harness developer preview

#172

Hi I'm one of the authors of DeepSeek Harness. It's just an early developer preview version we're presenting in MIT license currently. Expect lots of rough edges and compatibility-breaking changes. Any feedback and suggestions are more than welcome!

Tell me more about the ideas behind Cordis the plugin system. The paper is a bit too mathy to consume and I think it deserves a more accessible post or something.

Best non-mathy framing I found: a context is a bag of services (ctx.tools, ctx.llm, ctx.sessions...), a plugin is an object that claims some of those keys and registers reversible effects on mount - unload unwinds them. Dispatch has four modes: emit (observe), waterfall (around-middleware, next() to delegate), parallel, serial. And the "everything is a plugin" claim is literal: model adapter, tool registry, session log and the agent loop itself are plugins.

One consequence we liked: since plugins are just Cordis bundles, the same registry can be exposed to any MCP-speaking agent. We built a small MCP server that searches the dsh-plugin topic, inspects bundles, and can install/run them (catalog plane works without dsh installed). github.com/bobleer/deepseek-harness-plugin-mcp

Re: DeepSeek Harness developer preview

#173
post #26

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 think the paper is really worth reading for anyone working in software. As far as understand it is a software architecture paradigm where everything is a "plugin", and as plugin, I can plug-it-in and plug-it-out, if I understand it correctly. They called it "revertible effects", where software can strip out live code without a restart or system reboot. They give the example of VS Code, which requires system restarts whenever an extension or plugin needs to be updated. To help myself understand it, I created a quick video, using NotebookLM: https://www.youtube.com/shorts/LtR7DRlZJ0M.

Re: DeepSeek Harness developer preview

#174
post #143

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…

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.

Re: DeepSeek Harness developer preview

#175
"Every run is traceable

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."

That's a killer feature, IMHO, and one that US models won't allow you to do, as their traces are encrypted, obfuscated, etc. and have to be extracted via various workarounds (that violate the terms of service).

If you want to be able to improve your tools that work with models, you have to be able to assess what the models think is happening, how they think about and interact with the data you give them. And, the US models won't let you see that.

Re: DeepSeek Harness developer preview

#176
post #111

Earlier quoted context omitted.

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 reque…

I'm interested in this but why those four separate languages Edit: okay I read the code, it's actually four separate implementations

Yes it's separate implementations of the same minimal idea

I'm currently working on more 'feature-full' but still minimal variants

e.g. a python variant with automatic compaction + truncation of sh output

https://x.com/__tosh/status/2087606344035479632

i also got quite a lot of requests to provide the code in non-golfed form to make the implementation more approachable and idiomatic in each language (will do!)

Re: DeepSeek Harness developer preview

#177

Earlier quoted context omitted.

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.

Well, that makes one of us. Replacing deterministic processes that work with lossy processes makes no sense. You’re literally reinventing the wheel every single time, what are you talking about?

It's because things change, things break, they are misconfigured etc. Yes, if you have perfect deterministic tools in an unchanging and perfect environment, sure. But the deterministic tools need constant maintenance, fixing, reconfiguring, adapting to external changes, dealing with unexpected failure types etc. Not saying you should use LLMs for everything, but LLMs equipped with tool calling can often fix things. And they can also fold it back to a robustified script. That's the strongest use case. LLM checking errors, fixing the scripts, and the routine runs are via those scripts. It just checks that everything ran to completion or what kind of hiccup happened. I know this sounds terrifying from a job security perspective, but it's going to be a wild ride for all of humanity.

Re: DeepSeek Harness developer preview

#179
post #161
post #143

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…

Product-wise... maybe. I'm also seeing a lot of genuine attempts to reinvent programming around some form of new agentic paradigms. But at the core science/tech of AI it's probably the most amount of innovation I've ever witnessed in a field. The pace of new developments is staggering.

Is it staggering? Given the amount of money being poured in it doesn't seem all that impressive at all. And the constant overhyping is not helping either.

Re: DeepSeek Harness developer preview

#180

«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…

These types of projects can have a happy ending, but only if the product is popular enough and the plugins are essential to the core functionality. Plugins usually die off because the sole maintainer loses interest, but popularity and necessary can bring new maintainers to carry the torch.
Post reply on HN