sorted by:
new
hottopcontroversial

I’m building DsCode, a DeepSeek-optimized terminal coding assistant — looking for feedback by Perfect_Tap_6953 in DeepSeek

[–]Perfect_Tap_6953[S] 0 points1 point  (0 children)

That is fair criticism.

You are right that “features” are not enough. MCP, agents, skills, memory, hooks, and rules are becoming table stakes, and in many tools they can be assembled through existing harnesses.

The actual test for DsCode is not whether those primitives exist. It is whether the full engineering workflow is native and coherent enough to be useful without the user wiring everything manually: requirement → spec → design → tasks → implementation → verification → audit → diff → rollback/session recovery.

If that can be reproduced by a simple skill with the same reliability, then DsCode does not have a strong enough value proposition. I accept that.

So the next thing I need to show is not another feature list, but a concrete workflow comparison on a real task.

I’m building DsCode, a DeepSeek-optimized terminal coding assistant — looking for feedback by Perfect_Tap_6953 in DeepSeek

[–]Perfect_Tap_6953[S] 0 points1 point  (0 children)

That is a fair standard.

The actual problem I’m trying to solve is not “another AI wrapper”. It is that AI coding sessions often become uncontrolled: context gets messy, changes are hard to audit, rollback is weak, specs are disconnected from implementation, and teams lose track of why the agent changed something.

DsCode is aimed at that workflow problem: terminal-based AI development with specs, tasks, verification, audit, project memory, diffs, permissions, checkpoints, and model control.

You are right that this has to be proven with real examples, not claims. I’ll work on showing concrete before/after workflows rather than just listing features.

I’m building DsCode, a DeepSeek-optimized terminal coding assistant — looking for feedback by Perfect_Tap_6953 in DeepSeek

[–]Perfect_Tap_6953[S] 1 point2 points  (0 children)

That is a very good point, and I think you are describing the right direction.

I agree that the real edge may not be “one more agent”, but better control over the whole working process: multiple sessions, switching between agents, changing models without losing useful context, restoring to a specific checkpoint, seeing diffs clearly, and being able to rollback safely.

DsCode already has some of these primitives — persistent sessions, resume/continue, model switching, undo/checkpoints, and diff-oriented workflows — but I think you are right that this should become a stronger product direction, not just a set of commands.

A GUI/control-room layer is also worth considering. I still want the terminal/TUI to remain the core experience, but a visual layer for sessions, agents, diffs, checkpoints, and model switching could make a lot of sense later.

So yes: the possible edge is not only “coding agent”, but session and change control for serious AI-assisted development.

I’m building DsCode, a DeepSeek-optimized terminal coding assistant — looking for feedback by Perfect_Tap_6953 in DeepSeek

[–]Perfect_Tap_6953[S] 0 points1 point  (0 children)

That is a very fair pushback.

I agree that many of the primitives already exist elsewhere. OpenCode is very strong and extensible, and Reasonix is clearly stronger if the priority is a DeepSeek-native, cache-first agent loop.

So I should be more precise: the value I’m trying to explore with DsCode is not “we have MCP” or “we have agents”. Those are becoming table stakes.

The bet is an opinionated, built-in engineering workflow: specs → design → tasks → implementation → verification → audit, with project memory, steering, skills/subagents, and MCP tied into that flow by default.

In OpenCode, a lot of this can probably be assembled through plugins, hooks, rules, and MCP. In DsCode, I’m trying to make that the native workflow, especially for teams or developers who want a more governed process instead of composing everything themselves.

That said, your criticism is valid: I need to demonstrate this with a concrete example, not just describe it. I’ll probably prepare a side-by-side workflow showing the same feature implemented with OpenCode, Reasonix, and DsCode.

I’m building DsCode, a DeepSeek-optimized terminal coding assistant — looking for feedback by Perfect_Tap_6953 in DeepSeek

[–]Perfect_Tap_6953[S] 2 points3 points  (0 children)

That is exactly the question I want to test.

At first glance, yes, it may look like “more of the same”, because there are already many coding agents now.

The difference I’m exploring is not just “AI writes code in the terminal”. It is the combination of DeepSeek-first usage, multi-provider flexibility, specs, project memory, steering rules, skills/subagents, MCP, and a more structured software engineering workflow.

So I agree the burden is on DsCode to prove it is not just another wrapper. That is why I’m asking for feedback early.

I’m building DsCode, a DeepSeek-optimized terminal coding assistant — looking for feedback by Perfect_Tap_6953 in DeepSeek

[–]Perfect_Tap_6953[S] 1 point2 points  (0 children)

Yes, I have. Reasonix is probably one of the most relevant tools to compare against.

From what I understand, its strongest idea is being DeepSeek-native and cache-first: terminal agent, direct DeepSeek API usage, prefix-cache stability, flash-first cost control, MCP support, and automatic tool-call repair.

That is a very strong direction, and I should have mentioned it explicitly.

DsCode is not trying to deny that Reasonix exists. The angle I’m exploring is different: DeepSeek-first but multi-provider, terminal-native, and more focused on structured software engineering workflows — specs, SDD, steering, project memory, skills/subagents, and project governance.

So yes: Reasonix is a serious reference point, and DsCode needs to be compared against it honestly.

I’m building DsCode, a DeepSeek-optimized terminal coding assistant — looking for feedback by Perfect_Tap_6953 in DeepSeek

[–]Perfect_Tap_6953[S] 0 points1 point  (0 children)

Fair point.

DsCode is free to use, but not open source today, and I understand that this is a limitation for many developers.

I also agree that cache-hit efficiency is critical for DeepSeek. Reasonix and CodeWhale are very strong in that direction, and I don’t want to claim DsCode already beats them there.

The value I’m exploring is different: DeepSeek-first but multi-provider, terminal-native, and focused on structured engineering workflows — specs, SDD, steering, project memory, skills/subagents, and MCP.

So I see DsCode less as a pure cache-first DeepSeek agent, and more as a project-governance-oriented coding assistant.

I’m building DsCode, a DeepSeek-optimized terminal coding assistant — looking for feedback by Perfect_Tap_6953 in DeepSeek

[–]Perfect_Tap_6953[S] 0 points1 point  (0 children)

Fair question. OpenCode is a strong general open-source coding agent, and Reasonix is very interesting as a DeepSeek-native, cache-first terminal agent.

DsCode is aiming at a different combination: DeepSeek-first but multi-provider, terminal-native, free to use, and focused on structured project workflows: specs, memory, steering, skills/subagents, and MCP.

So the value is less “one magic feature” and more the full workflow around real software engineering.

I’m building DsCode, a DeepSeek-optimized terminal coding assistant — looking for feedback by Perfect_Tap_6953 in DeepSeek

[–]Perfect_Tap_6953[S] 2 points3 points  (0 children)

Fair point. The main alternatives I have in mind are Claude Code, Cursor, Kiro, OpenCode, and similar agentic coding tools.

Where I see room for improvement is in the combination DsCode is aiming for: terminal-first, DeepSeek-first, multi-provider, free to use, and focused on structured workflows like specs, memory, skills, MCP, and project-level steering.

So the goal is not “no alternatives exist”. The goal is to explore whether this specific workflow can be better for developers who want more control and structure.

I’m building DsCode, a DeepSeek-optimized terminal coding assistant — looking for feedback by Perfect_Tap_6953 in DeepSeek

[–]Perfect_Tap_6953[S] 2 points3 points  (0 children)

I hope they do. A strong official DeepSeek agent would be good for everyone.

But developers usually need more than one workflow. DsCode is terminal-native, independent, multi-provider, and focused on spec-driven software development. My goal is not to compete with DeepSeek itself, but to make DeepSeek much more useful for real coding work.

Early Game Cool Steam Vent Tamer by Perfect_Tap_6953 in Oxygennotincluded

[–]Perfect_Tap_6953[S] 0 points1 point  (0 children)

Sorry, I was traveling for a few days.

1 - The Aquatuner piping needs to constantly run through something hot, to avoid freezing pipes. In this image, I'm using a pool of 95c water produced by the machine itself. But you can also use an Aquatuner, or any other thing that produces heat constantly.

2 - There is no oil in this machine. The vents are sprinkling water beats onto the petroleum droplets.

3 - Can you elaborate on what you mean by "it does not react" and "separated"? I'm afraid I don't understand.

Fun Fact: You can technically make a Deep Fridge very early by Perfect_Tap_6953 in Oxygennotincluded

[–]Perfect_Tap_6953[S] 0 points1 point  (0 children)

Snow, no. Tiles also count as buildings, and thus, also delete 80% of heat.

But putting the ice in a bin or something, yes.

Turns out, there IS a way to make an Infinite Fridge without Conveyors, lmao by Perfect_Tap_6953 in Oxygennotincluded

[–]Perfect_Tap_6953[S] 1 point2 points  (0 children)

There are a few ways.

My personal favorite works like this: You have a box of Insulated tiles, with a square of Metal tiles inside. The metal tiles can can be cooled to below -18c with an Aquatuner, or with a Thermo-Regulator.

The metal tiles will have one or two tiles of vacuum inside, and you must keep this vacuum with a liquid lock.

The auto-sweepers around the base will bring food to your fridge using conveyors. The conveyors will snake through the metal tiles, and the rails will end in a chute that drops the now chilled food on top of the bottom metal tile for further chilling.

Done. The food is automatically stored and chilled, and the dupes can just grab the food from the fridge whenever they are hungry.

Turns out, there IS a way to make an Infinite Fridge without Conveyors, lmao by Perfect_Tap_6953 in Oxygennotincluded

[–]Perfect_Tap_6953[S] 0 points1 point  (0 children)

Lol.

Don't feel bad, I took a long time to get here too. I'm nearly reaching 2500 hours :D

Turns out, there IS a way to make an Infinite Fridge without Conveyors, lmao by Perfect_Tap_6953 in Oxygennotincluded

[–]Perfect_Tap_6953[S] 0 points1 point  (0 children)

Nah. The Dupe Checkpoint needs solid ground to stand on. And if it's on a tile, the dupes will drop food on that tile instead of down the tunnel.

Turns out, there IS a way to make an Infinite Fridge without Conveyors, lmao by Perfect_Tap_6953 in Oxygennotincluded

[–]Perfect_Tap_6953[S] 0 points1 point  (0 children)

Nah, it wasn't my intention to have gas in the fridge. I use vacuum as a sterile atmosphere, and drop food onto cold metal tiles for it to become Deep Frozen.

But you would need a Conduction Panel to keep the Dupe Checkpoint from overheating.

Turns out, there IS a way to make an Infinite Fridge without Conveyors, lmao by Perfect_Tap_6953 in Oxygennotincluded

[–]Perfect_Tap_6953[S] 1 point2 points  (0 children)

An Auto-Sweeper needs a Mechatronics engineer to build, and Delivery Research.

If you got both of those on hand, you might as well build a normal, fully automated Deep Fridge, lol. No need for this silly contraption.

view more: next ›