DeepSeek Harness Hit 126k Stars — What Self-Evolution Means for Software (and Observability)

#devops #ai #observability #opensource

A repo on GitHub has been exploding lately. DeepSeek open-sourced an agent framework called deepseek-harness (often shortened to dsh). It went public on August 13; when I took this screenshot, it was already at 126k stars.

GitHub repo page, captured 2026-08-16. Top-right shows 126k stars; About lists 125.9k.

Repo: https://github.com/deepseek-ai/deepseek-harness

Its one-line pitch: Everything is a Plugin. You're not stuck with whatever shipped in the box. The AI can see what it already has, and when something is missing it can add it to itself. They call that self-evolution.

With stars climbing that fast, I wanted to see what it actually does. So I opened the web UI and typed one request.

I asked it to add a sidebar item

Roughly: build a plugin, inject it into yourself. Change the left menu — add a Workflow item above Workspace. Click it and show a complex flow chart; click a node and open a drawer on the right.

It actually did it. Bottom-left showed Cordis Plugin: 1 running. The three screenshots below are from the live page.

Red box is the original prompt. It inspected its own sidebar first — didn't jump straight to editing files.

The left **Workflow* item is live. This ticket canvas wasn't built-in — the plugin it just wrote drew it.*

Clicking the red **External API Query* node: timeout and retry 3/5 in the drawer.*

That extra Workflow entry wasn't in a release. It wrote a plugin on the spot and mounted it.

That made me think about on-call pages

The troubleshooting pages you open on shift are usually fixed at ship time. How topology switches, which metrics sit where, what the drawer shows first — often one team's playbook baked into the UI. Banks want ledger latency; e-commerce wants checkout funnels; one layout rarely fits both.

Changing that in traditional software is hard: tweak a page, wait for the next release. Low-code is better — drag and drop — but you're still picking from the vendor's blocks; step outside and you're stuck.

dsh is different. You say what you need; it adds a piece to itself right then. The block is fabricated on site, not chosen from a catalog.

Fig 1 · Traditional software, low-code, and dsh in one glance

Three capabilities — we've shipped two

We've been thinking about this for a while. Software that takes care of itself, in my view, comes down to three things: self-ops, self-Q&A, and self-evolution. DataBuff already has the first two in product.

Project on GitHub: https://github.com/databufflabs/databuff

Self-ops isn't just flashing a red chart. In our demo, logs were dropping — thousands to fifteen thousand per minute. A human said two things: let it investigate, then allow it on the box. It checked its own self-monitoring, found the write queue capped at 16 batches, bumped it to 32, restarted ingest. After that, write drops went to zero.

Self-ops · SSH to change params and restart ingest; write drops back to zero. It fixed itself.

Self-Q&A: installed but don't know where to click? You used to hunt external docs. In DataBuff, switch to product support and ask: how do I wire OpenTelemetry, where do I set alert thresholds? It answers with menu paths and fields from in-product docs.

Self-Q&A · Ask how to onboard OTel and configure alerts — get paths, not a link dump.

Both are visible the moment you open the product. Self-evolution we haven't built yet. dsh just demonstrated the third.

Fig 2 · Three capabilities — DataBuff has the first two

Self-evolution in observability

Observability isn't a chat window. Collection, storage, query — touch the wrong layer and your data is dirty. dsh can rewrite sidebars and canvases because almost everything lives in plugins. Observability can't copy that wholesale. The ingest/store/query pipeline must not be edited live.

What can grow on demand is the human-facing layer. "Show me UnionPay transactions first" — add a troubleshooting panel or drawer on the spot. The pipeline underneath stays the same.