DEV Community: Serdar Doğrubakar

A Valid Plot Map Is Not a Due Diligence Statement

Serdar Doğrubakar — Wed, 21 Oct 2026 10:45:20 +0000

When a supplier sends a GeoJSON or KML file, the first problem is often treated as a compliance problem. In practice, it is usually a data-quality problem first.

A plot file can open in a map viewer and still be unsuitable for the next step. It may contain a self-intersection, a ring that is not closed, an invalid geometry type, the wrong coordinate reference system, or a feature placed hundreds of kilometres from the stated origin. None of those errors tells you whether the land was deforested, whether production was legal, or whether an operator can complete its own due diligence. They do tell you that the file needs attention before those questions can be assessed reliably.

What to check before reviewing the evidence

A useful first pass separates four questions:

Is the file readable?
Is the geometry valid?
Is the location plausible for the declared source?
Is the corrected file traceable to the original?

These checks are easy to mix together. A repaired polygon is not proof of land-use history. A point inside a country is not proof of origin. A file that passes a geometry validator is not a certification.

For a practical workflow, start by keeping the supplier file unchanged. Work on a copy and record what was inspected. Check the file format, feature types, coordinate reference system and geometry validity. Then inspect the shape on a map. A narrow strip crossing a coastline, a polygon with a spike, or a feature in the wrong hemisphere is often easier to see than to infer from raw coordinates.

Repairs should be visible

Some repairs are mechanical. A geometry can sometimes be closed, normalized, or made valid. Those operations should produce a new file and a clear record of what changed. The original should remain available for comparison.

The important distinction is between a repair preview and a verified fact. A preview can show how a geometry operation would change the shape. It cannot establish that the replacement boundary is the supplier's true plot. That still requires a person with the relevant source information to review it.

The same principle applies to coordinate transformations. Reprojecting a file may make it display correctly, but it does not correct a wrong location. A transformation changes how coordinates are interpreted. It does not create missing provenance.

Keep the handoff simple

A useful handoff package can contain:

the original file
the corrected working copy
a short change log
the validation result
the map view used for the visual check
the source and date of any external reference
the person responsible for the next review

This is preparation, not a substitute for the operator's own assessment. The final decision about evidence, risk and any formal filing remains with the responsible organization.

I built EUDR Tools around this narrow preparation problem. Its Map Studio lets a user inspect GeoJSON and KML files, see geometry issues, preview selected repairs and export a working copy. The site's HS/CN scope and country-risk pages are separate lookups. They do not certify a product, verify legality or deforestation status, or submit a due diligence statement on someone else's behalf.

That boundary is deliberate. Better files make later review easier, but a clean map is only one part of a much larger evidence chain.

I made three AI models argue about my code, then judged the winner

Serdar Doğrubakar — Tue, 28 Jul 2026 07:37:51 +0000

I never fully trusted a single model's code review. Different models miss different things, and I wanted that difference working for me instead of betting everything on one. So I built a tool that runs the same review agent across several models and makes them cross-check each other. Here is how it works, and an honest note about what it is and is not yet.

One agent, many models

You already have a review agent defined for one coding CLI, a plain .claude/agents/*.md file. multi-agent runs that same agent on other model CLIs: grok, codex, claude. Each one executes it natively through its own runtime. No API keys, no re-implementation. If the CLI is installed and logged in, the agent runs there.

The point is diversity, not redundancy. When independent models converge on a finding, you get confidence. When they diverge, you get coverage you would not have had alone.

/arena: let the debate stop itself

The first command runs a deterministic tournament.

Round 1        each model audits independently
Round 2        cross-critique: KEEP / WITHDRAW / ADOPT / NEW, each citing code
Round 3, 4...  added ONLY while positions keep moving
Judge          opens the real code, confirms or rejects each disputed claim
Scoreboard     ranks the models, post-hoc

The rounds are convergence gated. My first version ran a fixed number of rounds, and half of them were theater: by round two nobody was changing position, they were just restating themselves with more tokens. Now a round is added only while someone is actually withdrawing a claim, adopting a rival's, or raising a new one. The moment the debate freezes, it ends.

Score the models, but never tell them

The arena ends with a scoreboard, and the design decision I care about most is that the models are never told they are being scored.

The moment a model knows it is in a competition, the incentives rot. It defends a weak finding because withdrawing looks like losing. It nitpicks rivals to farm points. The debate stops being about the code. So the scoring happens afterwards, from the judge's confirmed results: confirmed findings add points weighted by severity, false positives subtract, unique real catches and honest concessions count extra.

The models argue about truth. The ranking is computed behind their backs. Goodhart's law hits language models as hard as it hits people.

The honest part

I have to be straight about the current state, because it would be easy to oversell this.

It was built for and tested on Claude Code. The multi-round arena runs on top of Claude Code's Workflow system, the deterministic runtime you can watch live in /workflows. Claude is also the default judge, because it is the host model and always available.

The other CLIs, grok and codex, are supported as targets: the engine runs your agent on them and collects their findings. What is not shipped yet is native host wrappers for them, because I have not tested that path enough to trust it. The orchestration engine underneath is plain Python and host-agnostic, so those wrappers can be added later, but I would rather say "not yet" than pretend it is done.

There is also a real cost. A full adversarial run is heavy: many model turns, several rounds, minutes to tens of minutes, real token spend, and each round waits for the slowest model. For quick work you use fewer models, or the second command, a live single-model review you can talk to while it works.

Try it

It is open source under MIT. The write-up with the two commands, the exact scoring rules and the full list of limitations is on the project page: multi-agent on dogrubakar.com, and the code is on GitHub.

If you run multi-model review workflows, I would genuinely like to hear how you keep them honest.

Switch AI coding agents without losing your context

Serdar Doğrubakar — Tue, 28 Jul 2026 07:18:10 +0000

I use more than one coding agent. Claude Code, Codex, Grok, sometimes Antigravity. The problem was never which one is best. It was that every time I switched, I lost the whole conversation. I would copy a summary by hand, hunt for a session id, and start the new agent cold.

So I built a small open source tool to fix exactly that, and this is how it works, plus the part that broke while building it.

The idea: move the delta, not the transcript

The lazy way to move context between two agents is to copy the entire conversation. It is also the wrong way. A transcript is large, it repeats what the target already knows, and it buries the two sentences that actually matter.

context-bridge keeps a small knownBy matrix instead: for every pair of agents, how far into each agent's own stream the other one has already been told. A handoff sends only the missing part, in four bounded sections: Conversation, Decisions, Work, Next. The receiving agent spends one short sentence acknowledging it. That is the entire overhead.

If you have ever worked on reconciliation systems, this is the same shape: you do not resend the ledger, you send the diff since the last watermark.

What it does not do

It does not replace the agents.
It does not proxy their APIs.
It needs no API keys.

It drives the subscription CLIs you already have. One command, /bridge codex, and the agent you leave closes while the one you arrive in already knows your work.

The honest asymmetry

Not every agent accepts context the same way, and I think glossing over that would be dishonest.

Claude and Codex take the delta through their own session hooks, so it lands inside the conversation.
Grok and Antigravity get it in the opening prompt of the resumed session, because their runtimes offer no way to inject.

The knowledge is equal on every side. The session shape is not, and that difference is stated plainly rather than hidden.

The bug that reported success and carried nothing

Here is the failure that scared me most, and it was not in my code.

These agents store their sessions in undocumented internal files. Nobody owes you stability there. A point release renames one field and nothing looks broken: the binary still runs, auth still works, and the handoff reports success. Meanwhile every delta is quietly empty.

So bridge doctor got a check nobody asked for. It does not just check that an agent is installed and logged in. It opens each vendor's session files and confirms that the current version of the bridge can still parse them. That failure is invisible otherwise, until you notice that a week of handoffs carried nothing.

The lesson I keep from it: when you build on another product's internal files, "installed and logged in" tells you nothing. Test the data you depend on, not the binary that writes it.

Try it

It is a developer preview, tested and used daily, and open source. The write-up with install steps and the full list of honest limitations is on the project page: context-bridge on dogrubakar.com, and the code is on GitHub.

If you also juggle multiple agents, I would love to hear how you handle the context problem today.