---
title: "Integrating Open-Code-Review with DeepSeek Harness"
url: https://stacklist.com/card/3cd93748-cb8c-4548-a8a0-f7b2ba584e5c
source_url: "https://lnkd.in/p/exSPeY78"
stack: https://stacklist.com/c/technology/stack/1659549d-373d-4391-ba12-5a14d40c19ed
summary: "Mitko Vasilev discusses integrating open-code-review with deepseek-harness to build a hybrid system where deterministic code handles file selection and scheduling while AI agents focus on semantic analysis and risk detection. The approach emphasizes owning private AI infrastructure and combining models, harnesses, sandboxes, and review engines into a software factory system rather than simple prompt-to-LLM workflows."
tags: "code-review, ai-agents, llm-architecture, deterministic-pipeline, deepseek, open-source, software-engineering"
key_entities: "Mitko Vasilev (person), Jonathan Kuzmanko (person), Nils W. (person), Bernard Sia (person), Mike Cecconello (person), Luis Coimbra (person), deepseek-harness (technology), open-code-review (technology), DeepSeek (technology), ArchGenerator.com (technology), deterministic-pipeline (concept), sub-agents (concept), reflection-stage (concept), LLM-as-a-Judge (concept), LinkedIn (organization)"
classification: "transcript"
content_hash: "sha256:d2ae796a1f9fb15378aed129ef2cb32539e059e138911fc9bade5ec3b073e3a1"
acp_version: "0.2"
token_counts_approximate: 1399
visibility: public
agent_accessible: true
status: "final"
---

# Integrating Open-Code-Review with DeepSeek Harness

Mitko Vasilev 1d Report this post I’ve integrated open-code-review with deepseek-harness, and I really like where this architecture is going. The more I build with agents, the less I want the LLM doing everything. Some things simply shouldn’t be probabilistic. Selecting the right files, splitting the work, matching rules, scheduling reviews and figuring out exactly where a PR comment belong -> normal code is very good at that. Understanding whether a change introduced a race condition, following context across the repo, deciding whether something is actually risky -> that’s where I want the agent. So the flow starts looking something like: git diff -> deterministic pipeline -> sub-agents -> reflection -> evidence -> PR OpenCodeReview also does some interesting things around this: - related files can be bundled and reviewed by isolated sub-agents - agents can explore beyond the diff when they need more context - a separate reflection stage tries to kill hallucinated findings - review effort can progressively go deeper until another pass stops finding new risk - memory is split into frozen / compressed / active context - different models can sit behind the same review pipeline And now I’m wiring that into DeepSeek Harness, where pretty much everything is a plugin. That combination is what gets interesting. You’re no longer building 'prompt -> LLM -> 🤞' You’re building an actual software factory system. Make sure you own your AI. AI in the cloud is not aligned with you; it’s aligned with the company that owns it. 163 19 Comments Like Comment Share Copy LinkedIn Facebook X Mitko Vasilev 1d Report this comment Models + Harnesses + Sandboxes + Review engines + Inference servers + Memory + Tool protocols The hard part is integrating your private R&D processes to connect them all Like Reply 28 Reactions 29 Reactions Jonathan Kuzmanko Driving Measurable AI Impact | Ex-VP BD, Israel’s Largest Insurer | PhD Candidate – AI in Decision Making Models | AI for Finance and Operations 1d Report this comment Constraining the LLM to pure semantic evaluation keeps latency and runtime token overhead predictable. Like Reply 1 Reaction 2 Reactions Nils W. 1h Report this comment The deterministic/probabilistic split matches what held up in a model evaluation I ran for legal analysis: the orchestration was plain code, and the judgment calls went to a panel rather than one model. LLM-as-a-Judge, Crew-as-a-Judge and human validation ran in parallel, and the crew caught cases a single judge waved through. One addition for the reflection stage: use a different model family as reviewer, not just a separate instance. Same-family reviewers tend to agree precisely where both are wrong. How do you verify that reflection drops hallucinated findings and not real ones? Like Reply 1 Reaction Bernard Sia 6h Report this comment I use the LLMs to build deterministic checkers. And the AI kicks in only when there's errors. Logs a plan for me to go through before next improvement. It's cheaper that way too if you don't have GBs of RAM for offline model. Like Reply 1 Reaction Mike Cecconello 6h Report this comment Any source where you took inspo for this? Like Reply 1 Reaction Luis Coimbra 12h Report this comment Mitko, letting agents explore beyond the diff is particularly valuable. I would extend that context beyond the repository too: a locally correct change can still violate a database assumption, an infrastructure constraint, or a product requirement. That is where ArchGenerator.com could complement this pipeline. It analyzes existing code, databases, and infrastructure and connects those findings to discovery, architecture, and specifications—acting as a digital squad of senior architects while teams keep their preferred coding AI. How are you bringing approved architectural decisions into the review context, so agents can evaluate both implementation quality and alignment with the intended system? Like Reply 1 Reaction Jonah Gray 9h Report this comment The split is right: deterministic code should decide what work exists and what evidence is required, while the model handles the judgment that benefits from context. The piece I’d be careful about is reflection. It needs a concrete failure signal or it can become another probabilistic layer approving its own output. What evidence does your reflection stage require before it suppresses a finding? Like Reply 1 Reaction Andrey Ilmovskiy 1d Report this comment "The less I want the LLM doing everything. Some things simply shouldn't be probabilistic." - this is the right design principle. File selection, scheduling, rule matching - deterministic. Race condition detection, cross-repo context - probabilistic. Mixing them up in either direction is where systems break. The reflection stage that kills hallucinated findings is the part most teams skip and later regret. How are you handling the case where the reflection stage and the initial review agent disagree - who wins? Like Reply 1 Reaction 2 Reactions Marcus Schack 15h Report this comment I'm experimenting with deterministic coding workflows here https://github.com/marcus-sa/decow Like Reply 1 Reaction Todor Todev 1d Report this comment I saw OpenCodeReview the other day and was wondering how I could integrate it into DSH. If you have at some point something you can share, I would be happy to copy it from you. My DS4.1 Flash is not as fast as yours :) Like Reply 1 Reaction 2 Reactions See more comments To view or add a comment, sign in