This record spanned 1975 to 2026 and included 165 billing encounters over 51 years.

With a chart this large, the challenge is whether it can maintain the relationships between conditions across decades of patient history, distinguish current clinical relevance from historical noise, and still produce something coherent enough to move through a single coding cycle.

For this test, we carried the record all the way through to submission. In a live patient environment, a longitudinal record like this would continue accumulating new encounters and documentation rather than truly reaching an end state.

This record comes from our working corpus of more than one million records, which includes de-identified Stanford Medicine data alongside longitudinal records generated by Synthea from MITRE. Every record was de-identified before entering our pipeline. No PHI is present, and no identifiers were retained. Every number in this case study came directly from the end-to-end production run; none of the results were estimated.

The patient record was for a 68-year-old female with 26 active diagnoses, 50 procedures, 15 immunizations, three active medications, seven source documents, and 165 billing encounters.

The first question was whether the system could keep relationships intact across decades of history. A chart with 165 encounters naturally contains repeated diagnoses, changing terminology, incomplete documentation, historical conditions, and information that may have been clinically relevant decades apart.

The clearest example involved diabetes and its downstream complications.

AICD-10 recommended E11.22, type 2 diabetes with diabetic chronic kidney disease, at 90% confidence, connected to N18.1, stage 1 chronic kidney disease, at 95%.

It also recommended E11.40, type 2 diabetes with diabetic neuropathy, at 95%, connected to G63.0, diabetic polyneuropathy, also at 95%.

The system then surfaced N08, glomerular disorders in diseases classified elsewhere, at 80% confidence. The system had to maintain enough context across the longitudinal record to determine that these conditions were related rather than simply separate diagnoses that happened to exist in the same chart.

Across the final recommendation set, the engine produced 100 evidence citations for 39 recommendations, or roughly 2.5 evidence references per recommendation. That was the densest evidence trail we had measured in the corpus.

This chart also gave us a useful example of information the system could derive rather than simply copy. The patient’s extracted vitals were 167 centimeters and 93.7 kilograms, producing a BMI of approximately 33.6.

From those measurements, the system recommended Z68.33, BMI 33.0–33.9, at 95% confidence, alongside E66.9 for obesity. Nobody manually entered the BMI category for the test. The system used information it had already extracted from the chart and carried that information forward into the coding workflow.

The record also contained years of behavioral and social context. AICD-10 surfaced F41.0 for panic disorder at 90% confidence, F43.9 for reaction to severe stress at 80%, Z60.2 for problems related to living alone at 95%, and Z56.89 for other employment problems at 80%.

On a record this large, filtering bad information was just as important as finding good information. In this case, four recommendations were rejected.

R73.03, prediabetes, came through at 60% confidence, but it conflicted with the stronger confirmed diabetes chain already established elsewhere in the record. I48.91, atrial fibrillation, came through at 30%. R09.1, pleurisy, came through at 20%. M25.70, osteophyte, came through at 10%. All four were rejected.

That was important for this particular test because the longer the chart becomes, the easier it is for old or weak signals to start accumulating. By the end of the coding review, 35 recommendations were accepted, and four were rejected.

The documentation side of the workflow was substantially larger than in our earlier tests. The record started with 22 open documentation gaps, including three high-severity and two medium-severity gaps. For this test, all 22 were carried through resolution.

Each gap ultimately resulted in a provider-signed note, growing the document set from seven source documents to twenty-nine. The final record contained 27 notes, one lab, and one EHR export.

In a live longitudinal workflow, this would likely happen over multiple patient interactions rather than in one closed testing cycle.

The final state was 100% documentation completeness, 98% coding confidence, low audit risk, zero open gaps, zero open alerts, and submitted status.

Overall, this case gave us a much clearer benchmark for how AICD-10 handles long-term patient history and whether its reconciliation logic remains consistent as the amount of underlying documentation increases.

One hundred sixty-five encounters, fifty-one years, one clean billable cycle was originally published in DevSecOps & AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

With clean demo records and hand-picked examples with one obvious diagnosis and one obvious code, AICD-10 has been on track 1:1 with the timelines of the real in-field process. I wanted something with multiple touchpoints that could show whether the system was really doing any sort of a marginal improvement when contract-matched against the status quo.

For the purpose of this test, we mark the patient journey as coming fully to a close. In a real-world example, it would likely remain open in a paused state for future patient interactions.

This record comes from our working corpus of more than one million records, which includes de-identified Stanford Medicine data alongside longitudinal records generated by Synthea from MITRE. Every record was de-identified before entering our pipeline. No PHI is present, and no identifiers were retained. Every number in this case study was measured from the actual end-to-end run. None of the results were estimated.

The record used was a 57-year-old patient with 29 active diagnoses, 50 procedures, 15 immunizations, five active medications, and six source documents containing different pieces of the patient history.

The chart started at 0% documentation completeness, with seven open documentation gaps, and eventually closed at 100% documentation completeness and 98% coding confidence.

In total, the system generated 31 code recommendations with 44 evidence citations.

As you can surmise, the chart came in with a lot of information, but that did not mean it was complete.

The first thing AICD-10 did was import the CCDA and structure what was already available in the record. Demographics, vitals, medications, smoking status, language, height, weight, BMI, diagnoses, procedures, and the rest of the available chart information were brought into the workflow automatically.

This is something we had previously run into with imported records, where information could technically exist in the source document but not make it far enough into the derived workflow to count toward documentation completeness or downstream scoring.

Once the chart was structured, there was plenty of clinical information available, but the chart still started at 0% documentation completeness.

One of the clearest examples in this chart was type 2 diabetes.

A basic coding pass could have stopped at E11.9, type 2 diabetes without complications. The patient clearly had diabetes, so the generic code would have been easy to justify if you were simply looking for the first supported answer.

In reality, the complication evidence was spread across different parts of the record. AICD-10 pulled those pieces together and recommended E11.22 for type 2 diabetes with diabetic chronic kidney disease and E11.40 for type 2 diabetes with diabetic neuropathy. Both came through at 100% confidence.

The record also supported N18.1 for stage 1 chronic kidney disease and E88.81 for metabolic syndrome.

A human coder can obviously reconcile information across a patient record and use those relationships to determine how specific the coding can actually be. The question we are trying to answer is whether software can make that reconciliation consistent across every chart, especially when supporting information is spread across multiple documents and multiple points in the patient’s history. In this case, it did.

It also surfaced information that would be easy to pass over when working through a large queue.

The chart had several social and contextual factors supported in the record. The system surfaced education and literacy problems, unemployment, other employment problems, social exclusion and rejection, the death of a family member, and confirmed adult physical abuse.

Some came through at very high confidence, while others were more borderline. Every recommendation also had evidence tied back to the underlying chart.

Importantly, it did not try to force every recommendation through. This is something I have been watching closely as we test AICD-10. If an AI coding system gets rewarded simply because it finds more codes, you can very quickly create the wrong incentive.

In this chart, four recommendations were ultimately rejected because the evidence was not strong enough to support them.

Z55.1, schooling unavailable and unattainable, came through at 60% confidence. Z62.822, parent-foster child conflict, was also at 60%. R53.81, other malaise, came through at 50%, and CPT 99173, visual acuity screening, came through at 60%. All four were rejected.

There was also a recommendation for F41.0, panic disorder, that stayed proposed rather than being moved forward.

There was evidence in the record pointing toward it, but the evidence density was not strong enough for the system to treat it the same way it treated the higher-confidence recommendations.

The chart started with seven open documentation gaps, including two considered high severity.

In this workflow, those seven gaps remained attached to the patient journey until they were resolved. Each one eventually resulted in a provider-signed note, and as the documentation cycle continued, the number of source documents grew from six to thirteen. For this test, we closed all seven.

In a real patient journey, that process would not necessarily happen all at once. The chart may remain paused while the practice waits for a provider response, follow-up appointment, additional documentation, or the next patient interaction.

We also did not want the reviewer to be able to click past unfinished work. The final submission process has six gates, all enforced server-side.

Documentation completeness has to be at 100%. The documentation cycle has to be closed. Coding confidence has to meet the required threshold. Audit risk cannot be high. There cannot be any open documentation gaps, and there cannot be any open alerts. The reviewer cannot override those conditions from the review screen.

You can tell someone a chart is 72% complete or that there are two unresolved high-severity gaps, but if there is still a button underneath that allows the chart to be submitted anyway, the system is not really enforcing anything. In this case, the chart stayed open until all of those conditions were met.

The chart started with six source documents and finished with thirteen. It started at 0% documentation completeness and finished at 100%. The coding workflow generated 31 recommendations. Twenty-six were accepted, four were rejected, and one remained proposed. The final coding confidence was 98%.

To accomplish this, the system had to structure the source record correctly, reconcile information across multiple documents, recognize when the chart supported more specific combination coding, surface less obvious information that could have been missed, identify where documentation was incomplete, keep those gaps open until they were resolved, reject recommendations that were not supported strongly enough, and prevent the chart from closing until the remaining work was actually finished.

Overall, this case gave us a much clearer view of how AICD-10 behaves across a complete patient journey and how the workflow holds up under more complex, longitudinal documentation.

Twenty-nine active diagnoses, seven open gaps, and a chart that closed at 98% coding confidence was originally published in DevSecOps & AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Security tooling has a strange problem.

We have more scanners than ever, but less unified understanding.

One tool scans containers. Another scans infrastructure-as-code. Another searches repositories for secrets. Another walks HTTP endpoints. Another checks Kubernetes manifests.

One produces SARIF. Another produces JSON. Another produces XML. Another invents its own severity model.

Each tool is useful. Together, they often create noise instead of clarity.

This is where the idea behind Chagu becomes interesting.

The Problem Is Not a Lack of Tools

Modern engineering teams already have tools: Trivy for containers and dependencies, Opengrep for code patterns, Gitleaks for secrets, Checkov for infrastructure-as-code, Nuclei for vulnerability templates, CodeQL for semantic analysis, ZAP for dynamic testing, plus Kubernetes scanners, CI/CD signals, observability data, and internal detectors.

The problem is not that we need one more scanner.

The problem is that every scanner speaks a different language. Each has different inputs, outputs, severity labels, evidence formats, confidence models, and remediation styles.

So teams build glue code again and again. Then the AI layer receives messy evidence and is expected to magically reason over it.

That is the wrong abstraction.

The Chagu Common Protocol

Chagu should not try to replace security tools. Chagu should unite them.

The idea is simple:

Third-party tool
      ↓
Chagu adapter
      ↓
Normalized finding
      ↓
Reasoning and correlation
      ↓
Policy
      ↓
Action

Instead of asking an LLM to understand every scanner, CLI, and output format directly, Chagu defines a common protocol. Every tool gets an adapter. Every adapter emits the same normalized structure.

The reasoning layer does not need to know whether a finding came from Trivy, Nuclei, Opengrep, Gitleaks, CodeQL, or an internal scanner. It only needs to understand the Chagu finding contract.

Today, the ecosystem often looks like this:

Nuclei   → JSON A
Trivy    → JSON B
Opengrep  → JSON C
Gitleaks → JSON D
CodeQL   → SARIF
ZAP      → XML

Chagu turns that into:

Nuclei   → Chagu Finding
Trivy    → Chagu Finding
Opengrep  → Chagu Finding
Gitleaks → Chagu Finding
CodeQL   → Chagu Finding
ZAP      → Chagu Finding

The important part is not the scanner. The important part is the contract.

A normalized finding could look like this:

{
  "finding_id": "finding-123",
  "asset": "payments-api",
  "asset_type": "repository",
  "category": "secret_exposure",
  "severity": "critical",
  "confidence": 0.97,
  "evidence": {
    "file": "src/config.py",
    "line": 42
  },
  "source": {
    "tool": "gitleaks",
    "rule_id": "generic-api-key",
    "raw_evidence_ref": "evidence://scan-991/result-17"
  },
  "remediation": {
    "type": "code_change",
    "suggested_action": "Remove the hardcoded secret and rotate the credential"
  }
}

The normalized fields provide consistency. The source reference preserves the original scanner output.

That matters. Normalization should remove format chaos without destroying provenance.

The Real Value Is Correlation

Converting six formats into one is useful, but it is not enough to justify a new system.

The stronger reason is that normalized findings can be correlated across tools.

Imagine that Gitleaks reports an exposed AWS key. Checkov reports publicly accessible storage. Cloud telemetry shows an unusual access pattern. The service catalog says the affected asset belongs to the Payments team and runs in production.

No individual tool can see the complete situation.

Chagu can:

A production payment service contains an exposed cloud credential associated with public storage and anomalous runtime access. Rotate the credential immediately, review access, and notify the owning team.

That is not a fifth scanner result. It is a conclusion created by connecting four pieces of evidence.

This is where Chagu becomes more than a translation layer. It becomes a shared reasoning surface above the security ecosystem.

LLMs Should Reason, Not Crawl

This is the part worth being precise about, because it is easy to get backwards.

The temptation is to hand an LLM everything — raw scanner output, log dumps, inconsistent JSON, half-parsed YAML — and ask it to “figure out what matters.”

That is not reasoning. It is asking a language model to do the work of a parser, badly, with no guarantee of consistency between two runs.

An LLM crawling heterogeneous output has to rediscover structure every time. What is the severity field called here? Does “critical” from Nuclei mean the same thing as “critical” from Checkov? Is this a duplicate of something another scanner reported differently?

None of that is reasoning about risk. It is ad hoc parsing wearing a reasoning costume.

Worse, it can fail silently. The result may sound like a credible triage decision while actually reflecting how the input happened to be formatted that day.

The Chagu Common Protocol draws a hard line above that layer. Adapters absorb the format chaos once, at the edge. The reasoning layer receives the same shape, the same semantics, and the same provenance model every time.

Now the LLM can reason about the questions that matter: Is this real? Is it exploitable? Is it a duplicate? What other evidence supports it? Who owns it? What should happen next?

The Protocol Solves Format. The Log Solves Memory.

Normalization alone is not sufficient.

A finding contract tells the reasoning layer what a piece of evidence means. It does not tell the system what Chagu concluded, which context produced that conclusion, whether the risk was accepted, or what happened after an action was requested.

Without durable history, the system re-litigates the same finding on every scan. “Is this a duplicate?” and “Did we already accept this risk?” become new guesses instead of lookups.

That is the job of the Semantic Write-Ahead Log.

The log is not one hop between normalization and reasoning. It is a parallel backbone to which every stage appends:

Normalized finding ───────→ FINDING_RECEIVED
Reasoning verdict ────────→ VERDICT_RECORDED
Policy decision ──────────→ ACTION_DECIDED
Execution result ─────────→ ACTION_COMPLETED
Human correction ─────────→ VERDICT_OVERRIDDEN

This gives Chagu durability and meaning. But what about truth?

An append-only log cannot guarantee that every recorded claim is true. A scanner can be wrong. A model can be wrong. Two verdicts can conflict. What the log guarantees is that the system never loses what was claimed, why it was claimed, or what happened next.

Current truth is resolved above the log as an authoritative projection. Verified evidence can outrank inference. A successful action can supersede a planned one. A human decision can override a model verdict. Newer evidence can invalidate an older conclusion without erasing it.

So Truth does not mean pretending the latest event is infallible. It means having an explicit, reproducible way to determine what the system currently accepts as true — and being able to trace that state back through every supporting or conflicting event.

The protocol gives evidence structure. The Semantic WAL gives the system memory. The truth projection tells the reasoning layer which version of reality is currently authoritative.

Reasoning Recommends. Policy Authorizes.

The reasoning layer may conclude that an exposed production credential should be rotated immediately.

It should not independently decide whether it is allowed to rotate that credential.

That belongs to a deterministic policy layer.

Policy can consider the environment, asset criticality, confidence, supporting evidence, organizational rules, maintenance windows, and whether human approval is required.

The LLM recommends what should happen. Policy determines what may happen. The action layer executes the permitted decision and records the result.

That boundary is what makes reasoning near production systems useful without making it reckless.

One Reasoning Layer, Many Specialized Tools

Chagu does not need to compete with Trivy, Semgrep, Nuclei, Gitleaks, CodeQL, or whatever scanner appears next.

Specialized tools should remain specialized. Their job is to produce reliable evidence.

Chagu’s job is to give that evidence a shared language, connect it across domains, remember what the system concluded, resolve what it currently accepts as true, and turn judgment into controlled engineering action.

The future of security automation is not one scanner that does everything.

It is many specialized tools operating through one coherent reasoning system.

Chagu Common Protocol: Uniting Security Tools Under One Reasoning Layer was originally published in DevSecOps & AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Writing Playwright tests is not hard.
Writing good Playwright tests consistently is.

Most teams don’t struggle with syntax — they struggle with how to write stable tests quickly.

The common problem

You’ll often see code like this:

await page.click('Login');

It works, but it’s not reliable.

Selectors like this are:

• unclear
• fragile
• easy to break

Now multiply this across hundreds of tests.

Why this slows teams down

Every time someone writes a test, they have to think:

• Which selector should I use?
• Is this stable?
• Will this break later?

This decision-making takes time.
And different people write tests differently.

So you end up with:

• inconsistent code
• unstable tests
• more maintenance later

What better snippets change

Now imagine instead you write:

await page.getByRole('button', { name: 'Login' }).click();

This is:

• clearer
• more stable
• aligned with Playwright best practices

Good snippets remove the thinking part.

You don’t have to figure out the best approach every time — it’s already there.

Real impact in teams

With better snippets:

• new testers ramp up faster
• code becomes consistent
• fewer flaky selectors
• less debugging later

Over time, this saves a lot of effort.

Why I built Smart Test Snippet Generator

While working on automation, I noticed the same issue:
people were writing tests differently, and often not using the best patterns.

So I built Smart Test Snippet Generator.

It helps generate:

• clean Playwright actions
• better selectors (like role-based ones)
• ready-to-use test code

Instead of starting from scratch, you get a solid base instantly.

Small change, big effect

Snippets might feel like a small thing, but they directly affect:

• code quality
• test stability
• team productivity

When everyone follows better patterns by default, the overall quality improves automatically.

Final thought

Good automation is not just about writing tests — it’s about writing them the right way, consistently.

Better snippets make that easier.

How Better Snippets Help QA Teams Write Stable Tests Faster was originally published in DevSecOps & AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Six months of running a multi-agent stack taught me more about engineering judgment than six years of writing code ever did.

I used to measure a good day by lines of code shipped.

Now I measure it by how well I directed the agents who wrote those lines.

That shift happened slowly, then all at once. And it changed something fundamental about what I think “being an engineer” actually means.

The moment I noticed something had changed

It was a Wednesday in November. I was building an IAM (Identity and Access Management) module for a cloud ops platform. A task that, six months earlier, would have meant me: open terminal, write boilerplate, test, push, repeat.

Instead, I spent about 40 minutes writing a prompt. Describing the context. The constraints. The edge cases I already knew about. The output format I needed.

Then I handed it to Claude Code and went to make tea.

When I came back, 80% of the module was done. Solid, readable, mostly correct. The remaining 20% took me another hour of back-and-forth, not writing, but directing. Asking for a different approach here, catching a security assumption there, nudging the agent toward what I actually wanted.

Total time: under two hours. The same task used to take me a full day.

I sat back and thought: when exactly did I stop being a coder?

What “managing agents” actually looks like in practice

This isn’t a theoretical shift. Let me show you what my actual stack looks like on a Tuesday.

I use six tools in a typical session. Each one has a job:

Claude Code handles the heavy reasoning. Architecture decisions, complex refactors, anything where I need the model to hold a lot of context and think carefully. This is the expensive seat at the table, so I protect it.

Gemini Flash (via Google AI Pro, which in India came bundled almost free) gets the bulk reads. Long files, large context reviews, any task where I need a model to scan 10,000 lines and tell me what’s relevant. Gemini’s context window here is the point, not its reasoning depth.

Codex does the review and testing work. It’s genuinely good at edge cases, catching what breaks, suggesting test coverage I wouldn’t have thought of. Also free for a year in India (longer than I expected, honestly, because I kept waiting for the catch).

Excalidraw MCP (Model Context Protocol, the open standard that lets AI tools connect to external services, think of it like USB-C for AI integrations) handles all my diagrams. I describe a system architecture in plain English. The diagram appears. I stopped hand-drawing flows entirely.

Google Stitch takes the UI components. Anything visual, any frontend scaffold, that goes to Stitch, not Claude. Stitch MCP integrates directly inside Claude Code, so I don’t even context-switch.

Slack MCP and ClickUp MCP close the loop. When a session ends, Slack gets a summary. ClickUp gets the tasks. Nothing falls through the gaps.

The whole stack cost me roughly the price of my Claude Pro subscription. Everything else was either free or came with plans I already had.

The thing nobody tells you about running agents

You don’t get better at coding. You get better at thinking.

Here’s what I mean. When I was writing code myself, I could be vague with myself. I’d start typing and figure it out as I went. The code would evolve. The thinking would happen in the doing.

Agents don’t work like that.

If your prompt is vague, the output is vague. If you haven’t thought through the edge cases before you ask, you’ll get something that looks right but breaks in the third scenario. If you don’t specify the constraints upfront, the agent will make assumptions, and those assumptions will be invisible until they cause a problem.

I’ve shipped broken things because I was lazy with my instructions. Three times in the last four months (which I only know because I keep a log of what broke and why).

What that forced on me: I now think harder before I type anything. What am I actually trying to build? What are the non-obvious constraints? What would success look like, specifically? What do I not want it to do?

That’s not a prompting skill. That’s an engineering judgment skill. The agents just made it visible.

The routing problem nobody talks about

Once you have multiple agents, you have a new problem: which agent gets which task?

This is genuinely harder than it sounds. I spent about three weeks figuring out my routing logic, and I still adjust it. The rough mental model I use now:

If the task needs deep reasoning or will have downstream consequences: Claude. If the task is mostly reading, scanning, or summarising large inputs: Gemini. If the task is code review, testing, or edge case thinking: Codex. If the task is visual: Stitch or Excalidraw. If the task is communication or follow-up: Slack and ClickUp MCPs.

The key word is “mostly.” Real tasks bleed across categories. A refactor needs reasoning (Claude) but also test coverage (Codex). A new feature needs architecture (Claude) but also a UI component (Stitch). Learning to decompose a task into its sub-tasks, then route each sub-task correctly, that’s the new engineering skill.

I think of it the same way a senior engineering manager thinks about their team. You don’t give your best architect grunt work. You don’t ask your junior to make the hardest call. You match the task to the capability. The only difference is your team is now partly made of AI agents.

What this means for anyone building today

I want to be direct here, because I see a lot of vague takes on this topic.

The engineers who will matter in the next three years aren’t the ones who can write the most code. They’re the ones who can:

• Define problems precisely enough for an agent to act on them
• Catch when an agent’s reasoning has gone sideways
• Route the right task to the right tool without wasting compute
• Know which 20% of an agent’s output needs a human eye

None of those skills come from learning a new framework. They come from building real things with agents, making mistakes, and paying attention.

I’ve been at this for about six months. I’m still learning the edges of it.

But the shape of what good engineering looks like has changed for me. Permanently.

A note for the leaders reading this

If you manage a team, this matters to you too.

The gap Dario Amodei mentioned last week about SaaS companies potentially going bankrupt if they don’t adopt AI, it’s not a software adoption problem. It’s a mental model problem. Most teams are using AI to do old tasks faster. The ones moving ahead are using AI to do tasks that weren’t possible before, and redesigning their workflows from scratch around what agents can actually do.

There’s a difference between plugging a faster engine into an old car and building a new vehicle entirely.

Your team’s job description is changing. The question is whether you’re ahead of that change or catching up to it.

The honest version of where I am

I’m not going to pretend this transition is smooth. Some days, the agents save me four hours. Some days, I spend two hours debugging a prompt that a half-hour of manual coding would have solved.

The calculus still clearly favours the agents. But the romanticized version, where AI just handles everything, and you focus purely on strategy, that’s not where we are yet.

What we have is a messy, powerful middle ground. Agents that are genuinely good at specific things, that break in specific ways, that reward clear thinking and punish lazy instructions.

I find it more interesting than writing code, honestly.

And some days, I miss just having a problem and a terminal and nothing in between.

If you’re building with a multi-agent stack and want to compare notes, I’m usually in the comments. What’s in your routing logic?

I am Sachin Sharma, building AI-powered cloud operations platforms and writing about agentic AI, DevSecOps, and leadership at the intersection of technology and people. Follow me on Medium and DevSecOps & AI Today. You can find me on LinkedIn at linkedin.com/in/rksachin5.

How I stopped writing code and started managing AI agents was originally published in DevSecOps & AI on Medium, where people are continuing the conversation by highlighting and responding to this story.