DEV Community: Manos Saratsis

Run code review and releases from a conversation

Manos Saratsis — Tue, 01 Sep 2026 06:32:59 +0000

We just shipped chat as a first-class interface into Dromeas.

Instead of clicking through dashboards, you can now just ask: "review PR 247 on the payment service," "are we good to release v1.9.0?," "fix the top security finding and open a PR." Dromeas reads the diff, queries the Code Map for blast radius, runs the same quality/security/compliance agents that guard your trunk, and shows the result as a live status card — not a wall of text.

A few things worth calling out for anyone building similar agentic UX:

It's not a separate system. The chat calls the exact same MCP primitives (get_findings, code_map_search, run_finding_fix, approve_pull_request, etc.) that our IDE integrations for Claude, Cursor, and Copilot use. Start a release check in Cursor, see it finish in the chat.
Autonomy is a dial, not a toggle. Every workspace sets a default — manual, observe, assist, or auto — and you can override it per conversation. Manual shows a confirm card before anything ships; auto acts inside caps you set (file budget, severity threshold, model cost) and reports back after.
Structured over conversational-only. Long-running actions (a review, a fix, a doc run) return a live card with step, progress, and a deep link — updating in place instead of dumping another paragraph into the thread.

Video walkthrough: https://youtu.be/ypCt0d8sGis
Try it: https://dromeas.ai/chat

SonarQube Flags AI-Generated Code as a Special Case. That's the Wrong Default.

Manos Saratsis — Tue, 01 Sep 2026 06:31:56 +0000

Originally published on the Dromeas blog.

SonarQube has a feature called AI Code Assurance. When it detects that a project uses GitHub Copilot — checked via the GitHub Copilot Business org settings — it tags the project CONTAINS AI CODE and routes it through a dedicated quality gate built specifically for AI output, instead of the standard one (Sonar). More recently, they shipped a plugin that goes further: inside the GitHub Copilot CLI itself, an agent's generated code now gets run through an automatic verify-fix-reanalyze loop before it ever reaches a pull request (Sonar).

Both are sensible responses to a real problem — AI-generated code has roughly 2.74x more vulnerabilities than human-written code (Veracode 2025), so scrutinizing it more makes sense on paper. But look at the mechanism underneath both features: first you have to detect that a human didn't write this, then you route it somewhere stricter. AI-authored code is the exception you build a special lane for.

That's worth questioning, and not because the detection is badly built. It's because "detect, then route differently" only works as well as the detection does — and detection is inherently one step behind.

What AI Code Assurance actually checks — and what it misses

The detection step is worth being precise about, because its scope defines the size of the hole. SonarQube's autodetect mechanism evaluates Copilot usage patterns and code-contribution data through the GitHub Copilot Business organization API. Two consequences follow.

First, the wire it trips is GitHub Copilot-specific. A team running Claude Code, Cursor, or a local agent alongside (or instead of) Copilot doesn't necessarily trip that wire the same way. The special lane exists, but not every AI-authored line of code is guaranteed to be in it.

Second — and this is the part that makes the architecture question concrete rather than philosophical — Sonar's own docs now flag autodetect as deprecated in SonarQube Server 2026.1 LTA, with removal planned and manual project labeling as the remaining path (docs.sonarsource.com). Read that slowly: the vendor that built "detect AI code, route it to a stricter gate" is retiring the detection half of the design and asking humans to self-declare instead. Manual labeling is detection too — it's just detection delegated to the person least incentivized to do it carefully, at exactly the moment agent-written code is becoming the majority of new lines.

None of this is a knock on the feature's implementation. It's the predictable end-state of any architecture whose first step is "figure out whether a human wrote this."

The CLI plugin is the more interesting move

To be fair to Sonar, the GitHub Copilot CLI plugin (June 2026) is the smarter of the two ideas. It doesn't wait for detection at the project level — it runs an agentic loop right in the terminal: analyze the agent's output, fix what it finds, re-analyze (sonar analyze agentic) before the code reaches a PR. That's the right instinct: meet the agent where it works, and verify before merge rather than audit after.

Why "same rigor, no detection step" scales better

The alternative to a better detector is not needing one.

Every PR and every trunk commit that goes through Dromeas runs the same six-agent pipeline — quality, security, compliance, testing, docs, instrumentation — reviewed by the same multi-model council, regardless of who or what wrote it. There's no CONTAINS AI CODE badge, because there's no separate gate to route into. A junior engineer's Tuesday-afternoon commit and an autonomous agent's 2am commit get the identical bar.

That's not a philosophical stance so much as a practical one: as the share of AI-authored code climbs toward the 65% Sonar's own 2026 developer survey projects for 2027, "detect it, then scrutinize it more" is a rule that has to run correctly on a shrinking minority of code to matter, while "scrutinize everything the same way" doesn't have that failure mode at all.

There's a second-order benefit too. When there is no special lane, there is no lane-splitting argument — no "this was mostly agent-written, so the gate should have caught it" postmortem, and no quiet drift where one class of code quietly gets less review because nobody remembered to label the project. The bar is the bar.

If you're weighing the two approaches side by side, the full feature-by-feature breakdown — including AI Code Assurance and the new CLI plugin — is on the Dromeas vs SonarQube comparison page.

Claude Code's ultrareview vs Dromeas Code Review with LLM council

Manos Saratsis — Thu, 20 Aug 2026 14:51:07 +0000

Originally published at dromeas.ai

We heard about Claude Code's ultrareview and got excited — a cloud-run, multi-agent deep review sounded like exactly the kind of thing worth building a workflow around.

So we pointed it at changes in our own repo and compared it against Dromeas code review: three analyzers (quality, security, compliance) cross-checked by an LLM council. Dromeas held up well in that first pass.

That result was interesting enough that we wanted a harder, more neutral test: a large, real, independently-approved pull request from a codebase neither tool had any stake in. So we picked openclaw/openclaw — a public, actively-developed agentic coding tool — and went looking for its biggest recently-merged, genuinely-reviewed PR. That led us to openclaw#124250, 31 files changed, approved by a human reviewer, and we ran the same head-to-head again.

The PR

"Preserve ClawHub external source identity and expose only supported actions" — merged, approved by a human reviewer (not a bot self-merge), XL size: 31 files changed, +1,064/−116 lines, spanning the Control UI, macOS, iOS, and Android clients plus the backend that serves them.

The bug it fixes: ClawHub's search API returns each result's source under a nested install.reference field, but the client code expected a flat installRef. Every external search result silently fell through to a synthesized @owner/slug reference — quietly pointing installs at a different publisher's skill than the one the operator actually picked. An identity-spoofing bug in a skill-installation flow, fixed across five client surfaces.

What each tool found

ultrareview: 1 finding, nit severity — a duplicate test assertion in an Android test file, unrelated to the identity-spoofing bug the PR exists to fix.

Dromeas's LLM council: 29 candidate findings raised, 17 kept after cross-verification. Three models (Opus 5, DeepSeek V4 Pro, GPT-5.6 Terra) independently analyzed the diff, then a decider cross-checked each finding. All 12 quality findings and all 5 security findings held up; 12 compliance findings were flagged as duplicates of already-caught security issues or dropped outright, with the report explaining why for each.

None of Dromeas's 17 kept findings overlap with ultrareview's one — not because ultrareview did a bad job reading the diff, but because questions like "is this credential field masked" or "does this action get an audit trail" were never in its scope. Full breakdown, cost comparison (~$5 for the full council run vs. $5–25 typical for ultrareview), and the four findings flagged for manual triage are in the full post →

Read the full comparison

Loop Engineering: How to Actually Close the Loop When You're Coding With AI

Manos Saratsis — Mon, 10 Aug 2026 12:09:47 +0000

When we started experimenting with models coding we were looking at the right prompt, later at prompt chaining, then graphs. The higher the autonomy is we see there is the need for loops, both when coding but also when reviewing and releasing code.

Original blog here

Loop diagram with four nodes — act, observe, verify, repair — connected in a cycle
The loop. The interesting engineering lives in the bottom half.
Now multiple models are great on writing code at the act step. What requires further improvement is how the code is self healing, improving performance, take solid architecture decisions. Get real inputs to keep going, better and better each time.

That's the half of the loop Dromeas is built for. Not "write my code for me" — you already have something for that. Verify and repair. We run an amazing experiment: 16 feedback rounds with the same coding agent and a small React/TypeScript repo, building real features with and without the Dromeas MCP help. Btw this was the first time when the actual user is a machine and I have to admit that machines give more structured product feedback allowing a fun iteration until we got something useful.

Below is what actually held up. Including the parts that didn't.

What loop engineering looks like while you're coding
The loop while building a feature is four moves, and only two of them are the fun ones.

Orient. start_task({ repo_full_name, task }) in one call: where the code lives (paths, line ranges, symbols, callers), what's already known-broken in those files, and a token-budgeted read plan.
Act. Read the ranges from disk, make the change, keep the diff scoped.
Verify. Typecheck and lint first — they're free. Then verify_change with the full post-change content of every changed file. It analyses your uncommitted work; nothing needs to be committed or pushed.
Repair. get_findings({ trunk_review_id }) to read the blockers, then preview_fix for a diff or run_finding_fix to push one. Then back to step 2.
The bugs it caught that the agent didn't
This was the most consistent benefit across all 16 rounds, and it's the one worth the money. Not lint noise, not style nits — actual logic errors in code written minutes earlier.

While building a radius-select tool, a new commit() function in useRadiusSelect.ts didn't guard against a null draft. A spurious commit() with draft === null would silently wipe an already-committed selection. get_findings flagged it; the fix was one line — if (!draft) return; — and the agent's own log said it "would probably not have caught that on my own re-read."

Better one: a handlePointerUp click-vs-drag detector whose moved flag was set to true at pointer-down time. Meaning it never measured movement at all, so the comment right above it ("treat as a click if the pointer barely moved") was lying about what the code did. No linter or typechecker catches that. It takes reading code against its own comment — and two independent runs in two different rounds both caught it.

Knowing when to stop searching
Search tools have a failure mode where the agent keeps searching because searching feels like progress. Every code_finder_search and start_task response carries a value_signal, and it's honestly calibrated rather than self-flattering: tested side by side against a 22-symbol repo and a ~3,000-node repo, it rated the small repo's search value low (flat scores, most of the repo returned) and the large one medium. On low signal it returns an empty next_calls list, specifically so the agent doesn't reflexively chain another query.

On the star-map repo, getting_started reported first_move: "read_files" with the reason spelled out: "only 22 indexed symbols — reading the few source files end-to-end beats any search here." Every agent that followed it stopped after one or two orientation calls. That's real credit and context-window savings, from a tool telling you not to use it.

"What else touches this?" in one call
Search results inline the caller/callee graph and blast radius for top hits, not just a path. Searching worldToScreen came back with its file, its line range, its 3 callers (StarMapCanvas, hitTestStar, and the containing file) and a blast radius of 3 — enough to know a signature change ripples into exactly those three places, without opening any of them first. That's a manual grep chase replaced by one response.

Experiment rounds
16
same agent, same repo, with and without the MCP
Real logic bugs
2
caught in freshly written code, pre-commit
Blast radius
1 call
callers + impact inlined with search hits
Findings surfaced at bootstrap
222
60 critical, across two repos
We will cover in a different blog how loop engineering works when reviewing code or releasing products.

New Dromeas Skills
To get started with this we shipped three agent skills you can install straight into your coding tool from Workspace management → Agent instructions & skills

The honest downsides
While our early Loop engineering has been great so far, there are some downsides that you need to be aware.

It costs tokens, and on small codebases the math is worse. Orientation calls, verification payloads and findings all land in the context window. On a 22-symbol repo the agent can just read every file — and, to its credit, our own value_signal and first_move hints say exactly that. The loop earns its keep as coupling and history grow; on a toy repo it's overhead.
It makes tasks take longer. Verification is a real analysis pass, not a lint run — typically 60–120 seconds of polling per loop iteration. If you run it after every micro-edit, you'll feel it. Batch your edits, verify once per meaningful change. We're actively working on cutting that wall-clock time (quick: true already drops compliance for a materially shorter security + quality loop).
It's a loop, which means discipline. The value shows up when you actually read the findings and go back to step 2. An agent that dispatches a verification and then declares victory without reading the verdict has gained nothing. Notably, verdict: "unknown" with analyzed: false, retryable: true is not a pass — and yes, we had to write that in bold in the skill files.
Should I get started?
Actually, yes — especially if you build something robust and you have a sizeable codebase you will get real code context around dependencies, code scope and issues identified. Then your agent will self-heal your code every time it touches components with issues, always with some cost on time&token per task. Just add the new skills and get going.

Is Your Pipeline Ready for the code explosion?

Manos Saratsis — Tue, 21 Jul 2026 06:28:39 +0000

"Useful AI has arrived."

That's what Jensen Huang said at the NVIDIA GTC Taipei keynote on June 1, 2026 — pointing to a chart that should make every engineering leader stop and think.

In 2023, GitHub recorded roughly 300 million code commits. By early 2026, that number hit 1.4 billion. Not by year-end. In just the first few months.

That's not a trend line. That's a cliff edge.

The Numbers Don't Lie
The full picture from GitHub is staggering:

90 million pull requests merged
1.4 billion commits (up from 300M in 2023 — nearly 5x in three years)
20 million new repositories created every month
To put the commit growth in context: from 2023 to 2025, GitHub gained roughly 100 million commits per year — steady, unremarkable growth. Then 2026 hit and the curve went vertical. The first four months of this year alone nearly tripled the full-year totals from prior years.

This isn't an incremental improvement in developer productivity. It's a structural shift in how software gets built.

From Autocomplete to Autonomous Agents
The AI coding tools that sparked this explosion are a different breed from what came before.

GitHub Copilot in 2022 was glorified autocomplete — useful for boilerplate, impressive at demos, not much more. What Huang described at GTC Taipei is a different animal entirely. Today's AI coding assistants are agentic systems: they plan tasks, write tests, debug code, execute multi-step workflows, and submit pull requests with minimal human oversight.

GitHub has roughly 100 million developers. Nearly 1.4 billion commits in a few months means each developer is now, on average, associated with far more output than any human could produce alone. The math only works one way: AI is doing a substantial portion of the coding.

The Bottleneck Has Shifted
Here's the problem nobody is talking about loudly enough: the rest of the software delivery pipeline wasn't built for this.

Writing code is no longer the constraint. The constraint is everything that happens after. Code review. Security scanning. CI/CD throughput. Deployment pipelines. Observability. Incident response. The human oversight layers that exist to catch what AI gets wrong.

These workflows were designed for a world where developers were the bottleneck. In that world, adding more process was fine — there was always a human waiting to review the next thing. That world is gone.

When AI agents can generate code faster than any team can review, merge, test, and ship it, your pipeline becomes the ceiling on your velocity. And most pipelines today were not designed with this ceiling in mind.

More commits also means more risk surface. More PRs means more opportunities for something broken, insecure, or just plain wrong to slip through. The quality concern Huang's data raises is real: raw commit counts don't tell you whether the code is any good. If AI agents are generating vast amounts of mediocre or redundant code, the numbers could be masking a technical debt time bomb.

"Useful AI" for Shipping Software Is Required
The era Huang described — one where AI agents are first-class contributors to a codebase — demands a rethink of the entire software delivery lifecycle.

Speed without visibility is dangerous. When humans and AI agents are both committing code at scale, you need to know what's happening across the entire pipeline at all times. Not just CI status, but who (or what) authored what, why, and what downstream risks it carries.

Security is not optional, it is foundational. AI-generated code can be functionally correct and security-deficient simultaneously. Scanning, policy enforcement, and secrets detection need to run at the speed of the pipeline, not as a gate after the fact. Security has to be baked into every step, not bolted on at the end.

Humans and agents in the loop. A release doesn't belong to engineering alone. Product, design, engineering, security, privacy, and documentation all have a stake — and all need visibility and sign-off on what's shipping. In modern teams these roles increasingly converge, with individuals spanning multiple disciplines. The pipeline has to reflect that reality: every persona involved in a release, whether a specialist or a generalist, needs to be in the loop at the right moment, without becoming a bottleneck themselves.

Agentic workflows for complete and secure releases. The entire release lifecycle — PR reviews, merging, CI/CD preparation, deployment to testing and staging, release management, progressive rollout to production — can and should be automated with agents. But automation without accountability is fragile. The goal isn't to remove humans from the process; it's to have agents handle the repetitive, high-volume work while humans stay in the loop for decisions that carry real risk. Every step of the pipeline should be completable end-to-end, with agents and the right humans acting in concert, so nothing falls through the cracks between tools, teams, or time zones.

Observability that scales with code and respects end user privacy. AI is accelerating the creation of frontends, backends, databases, and entire systems at a pace that outstrips most teams' ability to instrument them properly. As that surface area grows, so does the responsibility to ensure that observability and analytics are built in from the start — and that they're designed to respect the privacy of end users, not just satisfy engineering needs. More software in production means more data being collected; the default has to be privacy-first, not privacy-as-afterthought.