DEV Community: Indicium AI

Build without limits - SDLC Briefing, #3

Ricardo Sueiras — Mon, 26 Oct 2026 06:58:58 +0000

Hi! I am Ricardo Sueiras, leading SDLC transformation at Indicium AI. That means I get to work with customers and help them understand how to use agentic AI to build software. New tools, practices and opinions turn up every week, and Build without Limits cuts through the noise. In each edition we put together a short, curated briefing on what's worth reading, watching and worth trying. You can skim it in five minutes and dive deeper wherever something catches your eye.

Top of Mind

More Agents, Same Mythical Month is one of the more impactful posts I have read in recent months. It articulates beautifully patterns I have been seeing in the field, and that every engineer should read to understand more. The anecdotes and stories alone make this post worth reading, but the additional groups linked to have now been added to my blogroll.

Must reads this week

How to effectively debug when you no longer understand the code is a post that kept me glued to my screen (I tend to use my commute time as the perfect time to catch up on all these posts, especially long ones like this one). I have spent some time also looking at practical approaches to using agents to debug and troubleshoot, and there is a lot of good stuff in this one.

How To Use Decision Models for Evals came just in time as I managed to get some Jev tokens and am currently experimenting with decider models. A good intro that provides a lot of insights on how to get the best of these.

claude.dev is the new home for all things Claude Code for developers. A simpler layout makes it easier to find the things you care about.

LLMs are making formal software verification feasible at a much larger scale shares Anthropic's pov on the rise and rise of formal software verification in software development. It certainly follows what I have seen whilst I was working at AWS, and is well worth reading.

Watch this

There are several collections of Claude Code Skills and workflows that have gained developer attention over the last several months. You have probably heard of Matt Pocock, almost certainly read Addy Osmani's writings on agentic engineering, but perhaps are new to Lauren Tan's pstack. Rob Shocks provides an overview of these three approaches, and in coming videos will be doing a bake off to see how they compare when working on common workflows.

Tools to try out

Third-party tools links are provided as-is. They belong to their owners, follow their own licenses, and are used at your own risk.

https://github.com/Graphicle-AI/graphicle graphs are so hot right now, and so here is a new tool (written in Rust of course) that maps your repository into a code graph, remembers your project's docs, decisions and past agent sessions, and gives your coding agent cited excerpts from both. Its fast, provides options to help you manage token spend, and works natively with Claude Code.

https://github.com/The-PR-Agent/pr-agent is an agentic AI powered code review tool from the folks that brought you qodo. It provides a number of tools (/describe, /review, and /improve) that you can run within your CI workflows or in your CLI.

https://github.com/saphan-ai/proven is another agentic AI tool to help you with your code reviews. Proven takes a slightly different approach. Proven will review pull requests: proposed changes to a codebase. Every problem it reports must come with evidence you can check yourself, such as a test you can run or a data query you can repeat. If it cannot show the evidence, it does not report the problem.

https://github.com/gojko/lights-on-software-factory is a nice starting point for exploring software factories. There are a few of these kinds of repos, and one of the reasons I love open source is that the four freedoms always let me learn from what others have built.

From the field

This week it has been all about code reviews. I have been working with customers who unlock some real code review pain points, and wanted to share some of the content that I have been referencing that we have seen make an impact.

It is probably obvious, but needs stating - the larger the diff, the more findings LLMs will report. Thinking how to scope down tasks so that the PRs will be smaller, will make PR reviews easier - both cognitively for the human reviewer, but also bring back less findings. Posts like Speeding up code review with small-change provide some insights in how organisations are tackling this. Code Review After Code Gets Cheap is another post that looks (at a high level) at some of the options you should be thinking of. I am experimenting with some of the tools that I have shared above (in addition to the tools that Claude Code provides), and will report back how I get on with these.

As a side note, it can be confusing initially to know what the native review capabilities that existing within Claude Code. This is what I ended up with, and (I think) covers the different native capabilities for Code Review within Claude Code (as well as where your own or third party ones plugin).

Managed Code Review - run in GitHub, managed by Anthropic (docs dive into this here)
Local Code Review - run in your Claude Code session using /code-review
GitHub Actions Code Review - run code reviews within your GitHub/GitLab actions, as a CI process (Claude in headless mode)
Your own Review - implement your own Skills in your local sessions
3P Code Review - a number of third party Code Review services (similar to Managed Code Review) are available: Coderabbit, Quodo, etc

You can compare options here

If you enjoyed this, then remember to subscribe to the IndiciumAI blog so that you can keep up to date with future editions of this newsletter, as well as other great content that technologists at IndiciumAI will publish.

Langchain Interrupt26 - London: Why Evals and Traceability Matter More Than Your Agent Framework

Gonçalo Lourenço — Tue, 20 Oct 2026 13:25:07 +0000

By Bruno Alho and Gonçalo Lourenço

Seven of us went to LangChain's conference. We came back talking about evals.

On Tuesday, we spent the day at Interrupt, LangChain's conference on AI agents.

We work as FDEs at Indicium AI, a global, AI-native data and AI consultancy, where we help clients build and ship AI agents. So naturally we went in curious about what was new, and came out thinking mostly about what it takes to put agents in production.

There were product announcements, and we'll cover those first. But talk after talk kept circling back to the same three topics: evals, traceability and governance. Spoiler: none of them depend on which framework you pick.

What LangChain Announced

Most of the product news was about LangSmith, LangChain's platform for observing and evaluating LLM applications. Two announcements stood out to us.

Agents can now run inside LangSmith. Using Deep Agents, LangChain's newest package, you can build, run and monitor an agent in one place. Fewer moving parts between "it works on my laptop" and "it's live" is always welcome.

Bring Your Own Cloud (BYOC). Until now you had two options: self-host LangSmith, or use LangChain's cloud. BYOC adds a third, where the platform runs in your own cloud account. If you've ever sat through a data residency conversation with a client's security team, you'll know why this matters.

It was a vendor conference, so yes, there was a healthy amount of selling the LangChain stack. But the products weren't what we were discussing on the way home.

The Framework Is the Easy Choice

The conversation has moved on from "can we build an agent?" to "can we trust it in production, and prove it?". That second question looks the same whether you use LangGraph, another framework or your own code. Every team runs into three problems:

Evals: how do we know the agent does the right thing, before and after release?
Traceability: when it gets something wrong, can we see why?
Governance: can we show a client, an auditor or a regulator what the agent did, and who signed off?

Good tooling makes all three easier. Building the habit is still on us.

The agent can be built with anything. What makes it production-ready is what sits around it: a trace of every step, feeding both evals and governance.

Evals Are Your Agent's Test Suite

Nobody merges code without tests (well, nobody admits to it). Agents deserve the same treatment, with one twist: LLM outputs vary from run to run, so a single check before release isn't enough. The talks described evals at three stages:

Offline evals run before every release against a curated dataset of inputs and expected behaviour. Change a prompt, a model or a tool, and they tell you what broke.
Online evals score real production traffic continuously, using LLM-as-judge, simple heuristics and user feedback. They catch the drift and edge cases your dataset never imagined.
Human review sends the tricky cases to domain experts. Their labels go back into the offline dataset, so every failure becomes a future test.

That feedback loop is the part teams most often skip, and it's the part that makes the agent actually improve.

Offline evals gate each release, online evals watch production, and human review turns the hard cases into new entries in the dataset.

The announcement that fit this theme best was Red Teaming in LangSmith Engine. It reads your agent's traces and code to learn what the agent is for, then probes it for failures that haven't happened in production yet, like hallucinations or ignored system-prompt rules. Each confirmed issue arrives with a root cause, a suggested fix and test cases for your eval dataset. In other words, it writes the tests you forgot to. It's still in private beta and only for agents on LangSmith Deployment, but it's the right direction.

A probe only becomes an issue once the failure is confirmed, so you aren't flooded with false alarms. Each issue then splits two ways: a fix that's tested before you see it, and new test cases that go straight into your eval dataset.

Traceability: Show Your Working

Remember maths teachers asking you to show your working? Agents need the same rule. A final answer is the end of a chain of retrievals, tool calls and LLM calls. Log only the answer and a wrong one is a mystery. Trace every step and it becomes a bug with an address.

A useful trace records, for every run:

each LLM call, with its inputs, outputs, latency and cost
each tool call and what came back
each retrieval and the documents it surfaced
the decision the agent took at each branch

With that in place, you can follow a bad answer back to its cause, whether that's the retriever pulling the wrong document or a tool returning stale data. Fix it, then add the case to your eval set so it can't sneak back in.

With only the final answer logged, the bad retrieval is invisible. With every step traced, it is the first thing you see.

Governance: Keeping the Receipts

This is where evals and traceability pay off for the business. The traces you collect for debugging double as an audit trail: a record of what the agent saw, what it did and why.

The other half is keeping people in control where it counts. Human-in-the-loop checkpoints let an agent pause before a high-impact action (sending an email, changing a record, approving a payment) and wait for someone to confirm.

For clients in regulated industries, this is often what decides whether a pilot ever makes it to production.

Low-impact actions run straight away. High-impact ones wait for a person. Either way, the action ends up in the audit trail.

What We're Taking Back to Our Projects

At Indicium AI we put agents in front of clients, so these practices belong in the delivery from day one. Here's the checklist we left Interrupt with:

Start an eval dataset on day one, even a small one, and grow it with every failure you find
Run offline evals on every change to a prompt, model or tool
Score production traffic continuously, not only at launch
Trace every step of every run, not just the final answer
Add human approval before any action that's hard to undo
Agree with the client up front what "good" looks like and how you'll measure it

None of this needs a particular vendor. It needs the discipline to treat agents like any other production software.

What We'd Love to See at Interrupt 2027

We'll be back next year. Two wishes for the organisers:

More "what broke, and how we fixed it" stories. Next year, we'd love to swap some of the "what went right" stories for "what went wrong, and how we fixed it" ones. Those are the talks we learn the most from.
More room in the eval workshops. The hands-on eval workshops were the right idea, but they filled up so fast that we couldn't get into any. Bigger rooms, more sessions or a waitlist would let more people actually attend.

Final Thoughts

Interrupt confirmed something we already suspected: the agents that reach production are the ones people can test, explain and audit. Frameworks will keep coming and going. Those three habits will stay.

If we had to put what we learned in one sentence: choose your framework in an afternoon, then spend the rest of the project on evals and traces.

Working on agents yourself? We'd love to compare notes on evals or traceability in the comments.

Written by Bruno Alho, Senior FDE, and Gonçalo Lourenço, Senior FDE, at Indicium AI. Follow us on LinkedIn: Bruno Alho · Gonçalo Lourenço. All views are our own.

If you enjoyed this, subscribe to the Indicium AI blog to keep up with what our technologists publish next.

An understanding of my world: a knowledge graph over my Obsidian notes

GianPiero Bresolin — Mon, 19 Oct 2026 14:05:45 +0000

I have too many notes

In my job I take a lot of notes. I mean a lot of notes. I attend a lot of meetings, and client conversations, catch-ups with colleagues, workshops and the research I pull together for a pursuit all get written down. My vault holds more than 900 markdown files now, organized into a structure of my own.

The problem is what happens as that folder grows. There are too many notes to consume. The structure still makes sense, but it can't tell me what I actually want to know, which is usually something about people, clients and the commitments between them.

Take a question like "who owns the Northwind data contract?" The answer is in there, in a sentence about Dana Whitfield in a quarterly review note. A search will find the note, along with every other note that mentions Northwind. It won't give me the owner.

My vision

So I wanted a way of managing and storing that data that lets me query it in the right way. I want to ask a question in my own words and get the answer, along with the note it came from. That means storing my notes in a way that understands the people, clients and relationships in them.

My solution

Building it turned out to be the manageable part. In my experience the real problem is maintaining the data over time, and that problem shapes every choice in the rest of this post. The system is a consistent folder structure, markdown notes with OKF metadata, a Graphiti graph with my own ontology, a daily Cowork task that keeps it current, and an MCP server that puts it into my daily work.

I picked a structure and stuck to it

I'll show you mine as an example.

My vault has a "Clients" folder, with a folder for each client. Each one holds that client's information and its own people folder, so I can see the people who belong to that client. There's a top-level People folder as well, and folders that describe our go-to-market work and specific teams. Roughly, it looks like this (Northwind is an invented client):

Obsidian Vault/
  Clients/
    northwind/
      Northwind.md
      2026-09-14 quarterly review.md
      people/
        Dana Whitfield/
          Dana Whitfield.md
  People/
  Blog Posts/
  Strategy/

You're going to query this knowledge store in your own language. When you talk to Claude, you'll use your own references and the aliases you use for people and clients, so the structure has to make sense to you, and mine won't necessarily.

Whatever you choose, follow it consistently, because that consistency is what the rest of this system depends on.

I built on markdown

Markdown is the foundation of all of this.

People who work with LLMs regularly are comfortable with it already. For anyone who isn't, it's a very simple plain-text format, and it's one LLMs really like to work with. Any tool that reads text can read it, so the notes aren't tied to one app.

I write and read mine in an Obsidian vault. It's a good place to do that, and the wikilinks it uses to connect notes come back later in this story.

OKF FTW: I gave every note metadata

So now I have all these markdown files, which is great. What I don't have is a real sense of the state of each one. Nothing has validated it, and there isn't enough metadata around it to build up a graph from.

That's where the Open Knowledge Format comes in. OKF is published by Google Cloud (spec), and I went with it because it's lightweight. All it asks for is frontmatter: a set of keys and values at the top of the note. It's also extensible, so I can layer on new keys and values over time as I work out what I need, and that has been really helpful. Beyond that, it has a lot going for it because it comes from Google, which has the influence to help something like this gain popularity. And I like the idea of frontmatter as a metadata store. It's open-ended enough that it doesn't get in the way of how I already write.

---
type: Meeting Notes
title: "Northwind quarterly review"
description: "Migration scope, timeline pressure, and who owns the data contract."
tags: [meeting, northwind, migration]
generated: { by: claude/haiku-4-5, at: 2026-09-14T11:10:37Z }
---

Now each note carries metadata about itself: what kind of thing it is, a title, a one-line description, some tags, and a record of what produced it. That metadata could really be anything that makes sense of the document, and you can add whatever properties make sense for your organization.

Say you want to mark when a document should be considered out of date. Add a key like expires_after and put a date there. An LLM can read that key and change how it treats the note, as long as you tell it what the key means, so the metadata isn't arbitrary. A deterministic script can act on the same key, and so can anything else that reads frontmatter.

That's what OKF gives me: a lightweight structure I can tie other actions to. A markdown file can feel very unstructured, and OKF brings structure to it without making me rewrite the document to follow some convention. The document can be whatever it wants to be. The metadata carries the information that programmatic solutions need, whether that's an LLM taking a particular action or a script that runs when it sees a particular value. It opens up a whole range of possibilities for how I organize my data.

OKF's own design goals fit this well. Google's argument for it is that the context agents need should live in an open format of its own, somewhere other than a proprietary service or a pile of unstructured text. It's also deliberately minimally opinionated. type is the only field that's always required, every other field is opt-in, and custom keys are preserved. That last part is what makes the expiry example work. (OKF v0.2 does define a stale_after field for exactly that case, but the same holds for any key you invent.)

Frontmatter also changes how much of a note anything has to read. A script can pull one property, such as the type or a date, without touching the body, and the same holds for an agent. Most of the time an agent only needs to decide whether a note is relevant, and the title, description and tags are enough for that.

An agent won't stop at the frontmatter on its own, though. Left alone, it usually reads the whole file. The simplest fix is an instruction in its standing context: check the frontmatter first, and open the body only for the notes that look relevant. A skill or a tool goes further, because it can parse the frontmatter and hand the agent only those properties, so the body never reaches it unless it asks. In my vault, the sweep also rebuilds an index for each top-level folder, with one line per note built from its title and description, so an agent can scan a folder's index before it opens anything.

How I create the metadata

Metadata only helps if every note has it, so keeping the vault in shape is a job for a script. Mine runs as a sweep, in a fixed order. It waits for the vault to go quiet, checks each note, fills in missing metadata, repairs what it can mechanically, links the names it already knows, rebuilds the indexes, scans for secrets and commits. The one step that needs a model is classification, where a model reads a new note and writes its type, title, description and tags. Everything else is plain code, and I'd keep it that way, because a deterministic job like string comparison belongs somewhere that gives the same answer every time.

Keep the list of types small, too. My approved list has about thirty values, and the classifier only chooses from eight of them. Give a model an open list and it invents a plausible new type for any note that doesn't fit, and no query knows that type exists. A note that doesn't fit gets flagged for me to look at instead.

My notes are about relationships

My notes have semantic structure, but mostly they're about relationships: between the notes themselves, and between the things they describe. Obsidian is built on that idea. It uses wikilinks to link documents together, which is how you build up your own knowledge graph inside Obsidian.

The Obsidian graph view does more than look nice. It shows the relationships between ideas and people, and it also shows the ideas that sit on their own. In the screenshot above, the small dots out towards the edges are parts of my knowledge that haven't been connected with the rest of the graph yet.

It also shows where my attention goes. A dot grows as more notes link to it, so the people, entities and themes I talk about most stand out, and I can see who is really at the center of my world. That's useful for spotting gaps. An idea out on the edge may not be getting enough attention. And if there's someone who should be more prominent in my work and I can't see them in the graph, that's probably telling me there's an action I should take.

The graph serves more than one purpose, and that's one of them. What I also needed was to query my data and pull out relationships, because for consultancy work that's where the value is. Everything I deal with has relationships to everything else: companies, clients, people, organizations, protocols, standards. In a graph, the kinds of relationships are commonly described with an ontology.

I use an ontology to bring meaning

An ontology brings semantic understanding to your data. It says what kinds of things exist and how they can relate, so "Dana Whitfield is accountable for the Northwind data contract" means something a program can work with.

So what I'm doing, ever so slowly, is building up a personalized knowledge domain. It comes in layers:

flowchart TB
    NOTES["Raw notes<br/>the content"]
    OKF["OKF frontmatter<br/>metadata and processing information"]
    ONT["Ontology and graph<br/>entities and the relationships between them"]
    LLM["An LLM asking questions<br/>of my notes"]

    NOTES --> OKF --> ONT --> LLM

The raw notes are the content. The OKF keys are metadata, plus whatever post-processing I want to record. Once I ingest those layers, the things they describe show up as entities, and the relationships between them as typed edges.

This is where it becomes valuable. When the ontology is exposed to an LLM, the LLM can take my question, look at the entities and relationships it knows about, and work out where the relevant information is.

How a note becomes a fact

Here's what that looks like for the Northwind question. From the quarterly review note, extraction pulls out two entities and the relation between them (illustrative):

Dana Whitfield (Person)  --ACCOUNTABLE_FOR-->  Northwind data contract (Contract)
  fact:   "Dana Whitfield owns the Northwind data contract and signs off changes to it."
  source: Clients/northwind/2026-09-14 quarterly review.md

The relation carries a plain-language fact sentence and the path of the note it came from, so every answer the graph gives can point back to its source.

This is also where the consistency from earlier pays off. An entity's identity comes from its type and its name, with no fuzzy matching. Two notes that both say Northwind merge into one node, with no model call. A note that says Northwind Trading instead creates a second node, and it stays separate until someone maps one name to the other. So the names you use consistently in your notes become the identity of things in your graph. A wikilink like [[Dana Whitfield]] helps here too, because it gives extraction the exact spelling to use.

Why I chose Graphiti

I went with Graphiti for the graph because it's a widely used framework with a lot going for it. It lets me define my own entity and edge types in Python, and it brings the schema, typed edges and hybrid search with it.

The bigger reason was speed. Building out a graph, and the database technology underneath it, can take a long time. Graphiti let me iterate quickly and get to the point where I could focus on the parts I cared about: the ontology, the data structure and the taxonomy I wanted to define.

Graphiti needs a database underneath it, and I run FalkorDB in a single local container. It comes with a browser for looking at the graph, which is handy when you want to see what extraction actually produced. For embeddings, which the hybrid search depends on, I use a local model (nomic-embed-text) through an endpoint Graphiti already speaks. The one model the graph pipeline calls out to is Claude Haiku 4.5, and that's there for cost: it's cheap enough to run over every changed note, every day.

How I keep the graph alive

Once the ontology and taxonomy are in place, and there's somewhere to store them, the work isn't finished. My data keeps changing, so I need a daily process that brings in the new notes and notices when they describe a relationship the ontology doesn't have a name for yet.

That's where Claude Cowork comes in.

A scheduled task runs each day in Cowork and manages my data for me. It writes the OKF metadata for new notes, looks at the data, builds up a sense of the relationships in it, and proposes new relation types where nothing existing fits. It runs at 17:00 and only sends what changed since the last run to a model, so a quiet day sends nothing to a model.

Getting those names right matters. The ontology is what brings sense to the data, and the name of a relationship is how the LLM understands what that relationship means. Say Dana Whitfield reports to the head of data at Northwind, but anything that goes wrong on the contract gets escalated to someone else entirely. Those are different relationships. If the graph gives them the same name, then when I ask who's accountable for the contract, the LLM can't tell them apart, and it may well hand me the wrong person.

So a new relation name has to earn its place. Once the same name turns up in three different notes, it's promoted into the ontology automatically, and Claude Cowork can discover it.

The same task can keep the graph clean as well as growing it, and this is where the OKF metadata from the beginning comes back in. Notes go out of date. Remember the expires_after key? A scheduled task can read that date and treat an expired note differently, retire its facts from the graph, or flag it for me to review. The idea works for any property you define. Your metadata can decide what gets cleaned up, what gets removed from the graph because it's no longer relevant, and how the rest of the data is organized. That interplay between a lightweight metadata format and a task that runs every day is where a lot of the possibilities open up.

I think this applies well beyond ontologies. Any document that tells a model how things currently stand will go out of date, and nothing in the document will tell the model so. That's the kind of problem OKF metadata like an expiry date is there to solve.

Where I use it every day

The last piece is an MCP server that exposes the knowledge graph. Because it's MCP, the graph isn't only available to Cowork. Any agent that can access a local MCP server can use it. I use it with Cowork, and that's where all the pieces, and all the work that came before, start to tie together.

This is where the value actually comes alive. Without this step, it's fancy metadata on my notes. The wikilinks add something too, because they let me see my graph in Obsidian. But the real value, in my mind, is being able to integrate this into my daily work. In Cowork I can ask questions about my own notes and get answers that come from an understanding of my world, and connecting the graph through MCP opens up a whole host of possibilities beyond that.

My MCP server

The server itself is small: one Python process that talks over stdio. It needs no API key, because search runs on the local embeddings and queries go straight to FalkorDB. It gives Claude seven read-only tools, and two of them show the idea well. entity_profile returns a summary of what the graph knows about a named entity. find_relations helps Claude work out which relationship fits a question when it doesn't know the relation name, and that's how the ontology becomes something Claude can discover.

The server also carries instructions, which Claude reads when it connects. Mine tells it to check the graph before a Slack or web search when I ask about my own notes, and to name both sources when Slack and the graph disagree. That matters, because the graph only knows what my notes captured. If Claude filled a gap from the web, the answer would read as though it came from my notes, and I would repeat it with the same confidence.

What leaves my laptop

Much of my work is in regulated environments, so I'd call this out. The graph, the database and the embeddings all stay on my laptop, but every model step in the graph pipeline sends note text to Claude Haiku 4.5, the scheduled task itself runs in Cowork, and answers go to the Claude app that asked for them. Make sure that's acceptable for what's in your notes before you point this at them. The server only runs on my laptop, so a web or phone session can use it only through the Claude desktop app on my laptop, while that app is running.

Here's what Claude gets back when it profiles the contract (illustrative):

Northwind data contract (Contract)
  ACCOUNTABLE_FOR  <- Dana Whitfield
    "Dana Whitfield owns the Northwind data contract and signs off changes to it."
    source: obsidian://open?vault=Obsidian%20Vault&file=Clients/northwind/2026-09-14%20quarterly%20review

So, who owns the Northwind data contract? Dana Whitfield, according to the quarterly review on 14 September, and the answer comes back with a link to the note.

What I'm building next

I've also done a test run of Qwen 3 locally on Apple's MLX framework, using the 14B model quantized to 4-bit. The next step is to see whether a local model like that can take over the model steps. Today every model step sends note text to Claude Haiku 4.5. A local model would keep that text on the laptop, which matters for anyone whose notes come from regulated work.

Build without limits - SDLC Briefing, #2

Ricardo Sueiras — Mon, 19 Oct 2026 09:05:21 +0000

Top of Mind

How to approach reviewing code has been top of mind this week, and came up in conversations during the Applied AI Symposium that Indicium AI held in London this week. My timeline also had some interesting posts on this topic. First up was Spotify sharing how they tackle this in their post AI Changed How Spotify Builds. What We Learned (and Fixed) About Quality at Higher Velocity. Anthropic also dropped perhaps one of the more interested pieces on this topic, looking at how they approach doing review at scale in How the Claude Code team does code review, and one of the authors also pencilled another in this topic that is also worth reading, Agentic Verification. Anthropic also published a recipe in their Claude Cookbook that walks you through creating a scheduled reviewer for your repo, and it is well worth implementing this recipe. Go check it out (and other really cool recipes the folks are sharing), Building a scheduled repository reviewer.

Must reads this week

Escalate hard decisions with the advisor tool is an experimental feature within Claude Code that I will admit I did not know about it until I heard about it during a meetup I attended this week (remember folks, meetups are super valuable for learning these sorts of things!). This feature allows you to use cheaper models, and then when needed, advisor will kick in and consult stronger models when needed (for example, if its bumping into repeating errors, or before, task is completed)
Redesigning source control at Anthropic is an interesting post that looks at some of the engineering choices that Anthropic are making when it comes to how to make source control work at agentic engineering speed. Scion is their bet, and its unlikely that many will find themselves in need of implementing their own, but we are seeing folks already working on improving the scaling capabilities of git, so who knows.

Watch this

Zach Lloyd, founder and CEO of Warp did a talk at the AI Engineer conference in New York last week, talking about the software factory they built to help them manage the open sourcing of their Warp terminal (agent control plane). There is a lot of good stuff in this, including the detailed workflow and sample repo you can try for yourself. At Indicium AI we also help our customers implement software factories, and the architecture in this session had a lot of similarities to the approach we have taken, so lots of nodding from me.

Tools to try out

Third-party tools links are provided as-is. They belong to their owners, follow their own licenses, and are used at your own risk.

claude-code-templates - I was drawn to this repo because Daniel San put together a really cool Claude Code mod that lets you inspect whats inside your context window at every turn, but then got lost in all the other cool stuff Daniel has been putting together. Defo a repo to spend some time exploring.

diff-tour - this is a really neat idea, that follows a thread of similar other tools in this space. How can you make it easier to reviews to walk through your diffs during PR reviews. diff-tour attempts to solve this by creating guided walk throughs the way a senior engineer might do. Works with a number of coding agents, including Claude Code.

archify - is a tool that I am looking forward to trying out, especially in some of the code modernisation and onboarding use cases I am helping customers with. The tool uses agents to create beautiful interactive experiences that help you navigate and understand how a project or codebase works. It works with multiple coding harnesses, including Claude Code, and is one of the better tools in this space.

mixture-of-models-claude-mod - is a neat tool that allows you to provide dynamic routing of requests to your Anthropic models or cheaper, locally hosted ones. Similar to how Kiro's Auto mode works, but this one allows you to do this from within your Claude sessions. Requires a bit of fiddling, but if you like that sort of thing, give it a go.

From the field

This week, everyone has been talking about reverse engineering with agents. Whether that is using tools like rea, or one-shotting using the latest generation models, my socials are full of folks beginning to share what they are doing with it (including this cool one that looks at how gamers are using it). I am interested as I can see some practical use cases for this in code modernisation use cases where perhaps source code is not available or the confidence is low. Have you checked it out yet?

Should we Kill Plan Mode? A Case for Keeping it in Claude Code.

Alistair Heath — Mon, 12 Oct 2026 14:24:34 +0000

Plan Mode was built for the model. The case for keeping it is about the user.

Last week, Thariq Shihipar, an Engineer working on Claude Code at Anthropic posted on X suggesting that the Claude Code Team are thinking of killing Plan Mode, a specific mode in Claude which prompts the user to fully articulate the software they want to build.

// Detect dark theme var iframe = document.getElementById('tweet-2102813194196758746-946'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2102813194196758746&theme=dark" }

Soon influential voices in the AI Engineering space shared their views, agreeing with that direction.

// Detect dark theme var iframe = document.getElementById('tweet-2103197425880211644-972'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2103197425880211644&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-2102817442347032583-699'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2102817442347032583&theme=dark" }

I work as an AI Engineer at Indicium AI, a global, AI-native data and AI consultancy partnered with Anthropic, and I work with clients helping their engineering teams to adopt Claude Code. I’ve previously run Claude Code workshops with our clients and one of the first features we teach is how to use Shift+Tab to start Plan Mode, so naturally I reflected on these proposed changes and the reason we have Plan Mode at all.

It all starts with Peter Steinberger’s claim that Plan Mode is “for a different age”.

Why Did We Have Plan Mode?

If you’re an engineer, you’ve seen and probably experienced the magical moment when you type anything into Claude Code and the thing, which would have taken hours or days, is built. But that’s exactly the problem for Claude, you could put anything in that text field_. Anything_ from a small task to commissioning a whole new piece of software.

When Claude Code first came out, Plan Mode was a way for Claude to collect requirements for those bigger asks, and reply with questions about how you want something done. It signposted to the Agent that, this was a big task so spend time collecting the requirements, filling in the gaps in the user’s plan and breaking the requirements down into tasks. Plan Mode was specifically triggered like this so that the user could indicate the scale of the ask.

The argument against Plan Mode now, is that model reasoning has improved to the point where models can intuitively tell the difference between a big project and a small task. We don’t need to do that sign posting.

But if the Agent doesn’t need this signposting, who does need Plan Mode?

What If Plan mode is For Us?

When we think of Engineering Teams adopting Claude Code, it’s tempting to think that it’s as easy as throwing licenses and tokens at developers and letting them run wild with this powerful new technology. However, technology this capable demands new ways of working, of collaborating. It demands that we put structures in place to ensure code quality, transparency and engineer accountability.

Plan Mode provides an initial way of working for engineers on that journey and acts as a quality control measure for organisations.

Plan Mode as a Way of Working

In my experience running Claude Code Workshops and helping teams design ways of working, the art to teaching Claude Code is not just teaching the tool (documentation can do that), it’s about designing and driving the behaviours and workflows that encourage team productivity whilst also ensuring that constraints are in place so the LLM produces code of a consistently high standard.

Driving workflow adoption is hard. They usually have to be designed before they can be taught. Co-creating them with a team can help adoption, but getting leadership buy-in to do that work is often harder than getting approval for a workshop. A workshop is time-bound and built around a tangible tool. But with Plan Mode, a simple workflow is built right into the tool so it’s much easier to start that discussion.

Plan then Do. It’s a workflow that people intuitively understand and Plan Mode mirrors this, acting as a gateway to a broader discussion about ways of working.

Plan Mode as Quality Assurance

There’s an old adage in Data Science: “garbage in, garbage out”. It’s the same for Claude Code.

As discussed, this may no longer be true regarding the model’s ability, but it’s certainly true regarding the quality and detail of the request. This is the whole point of Spec-Driven Development and it’s why frameworks like /grill-me and SpecKit exist. This approach has arisen to make sure that the human drivers of Claude spend time thinking through their requirements in detail which then informs precisely how code is executed. Crucially, this also puts Engineers in a position to assume responsibility for their decisions.

This then leads to more conscious inputs to a change, better decisions and ultimately ownership over one’s work.

Yes, organisations should definitely consider using tools like Grill Me, SpecKit or OpenSpec, but Plan Mode is accessible to all from the moment that you install Claude and that sends a signal about how good software is built.

So What Should Plan Mode Become?

What if Plan Mode isn’t about putting the agent in Plan Mode? What if it is instead about putting the user in Plan Mode? What if we designed for this mantra?

// Detect dark theme var iframe = document.getElementById('tweet-2102813194196758746-461'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2102813194196758746&theme=dark" }

As AI becomes more capable, the question shifts from “how do we get the best out of AI?” to “how does AI get the best out of us?”.

I believe it’s when we put ourselves in Plan Mode that we get the most creativity out of people. Planning, and forethought more broadly, is how we best explore and articulate a problem and dream of a solution. Planning is how we shape our future with more than just a “vibe”. So, how do improve Plan Mode to achieve this?

Keep a Planning Tool in Claude Code dedicated to structuring the user’s planning, even if the model doesn’t need it.
Don’t collapse planning into an effort slider. Effort is how hard the model thinks. Planning is whether the human has decided.
Make Claude’s default behavior one of inquisitiveness that seeks to understand the user’s needs, desires and intentions.
Where context is provided, provoke second-order questions: blast radius, rollback, who owns the decision, what “done” looks like.
Persist decisions as a reviewable artifact for teams. This one of the benefits of /grill-me and SpecKit and it’s vital for decision traceability.

Removing Plan Mode outright risks reducing the role of human thought in defining the products shaping our future. In an age where speed is everything, having a planning tool within Claude Code makes the behaviour of pausing and planning permissible.

Alistair Heath is a Forward Deployed Engineer specialising in AI Engineering at Indicium AI. Follow me on X @alistairheath and LinkedIn. All views are my own.

Build without Limits - SDLC Briefing - Edition #1

Ricardo Sueiras — Mon, 12 Oct 2026 12:30:39 +0000

Top of Mind

State of agent skills is a report from Vercel that looks at the state of agent skills, drawing from the data they have amassed from hosting the skills.sh registry (one of a few that are out there). Essential reading.

Must reads this week

git workstree gotchas is required reading for those of us who run parallel sessions within the same repo. Some of the points raised in this post will be familiar with folk, but there were enough new ones to make this post interesting.

Linux Foundation published its research into Developer Experience that contains some nice check lists that you can review/use as you look into what is, and how to measure developer experience. Why does this matter? SDLC transformation using agentic AI is a key driver for improving developer experience, and many organisations are now beginning to spin up developer experience teams where agentic AI tooling and governance sit.

Getting started with Claude Code mods is the official launch post that walks you through what Claude Code mods are and how to build one. Beginning to see a few folk doing some cool things with this, so check this out.

Watch this

Fixing the PR Bottleneck This week I spent some time on my commute watching the latest Matt Pocock knowledge drop on how to think and approach the review bottleneck in agentic engineering. Don't want to give too much away, but I think there are some really good perspectives here.

Tools to try out

Third-party tools links are provided as-is. They belong to their owners, follow their own licenses, and are used at your own risk.

Codebase-memory-mcp is a local MCP server that turns your repo into a searchable knowledge graph of functions, calls, routes and dependencies. AI coding agents can then answer questions like "what calls this?" or "what breaks if I change this?" with one query, instead of reading through files one at a time. This is really handy if you are tackling code modernisation or supporting legacy tech stacks, something that we at Indicium AI are increasingly helping customers with.

Shipreel is a neat tool that helps you create visuals (video), turning a pull request into a short narrated walkthrough video. It uses your harness to read the diff, write a story, draw the diagrams, record the real app if the change has a UI, and then render a compact MP4, about two and a half minutes by default, with captions, crossfade cuts and an ambient music bed.

From the field

Should workers be paid for AI skills? is a super interesting post that piqued my interest given recent customer meetings that have flagged the topic of how much is the premium for AI competent engineers, and what flight risk do they present to an organisation if they train their existing engineers in AI. Are you seeing this in your organisation?

A Simple Guide to Passing the Claude Certified Developer Exam

Haider Rasool — Fri, 09 Oct 2026 09:01:11 +0000

I passed the Claude Certified Developer – Foundations (CCDV-F) exam with a score of 941. The pass mark is 720.

The exam only launched in July 2026, so there isn't much prep material out there yet. No Udemy course, no well-worn Reddit threads, no "top 50 questions" gists. So I did the obvious thing for an exam about Claude: I used Claude to prepare for it.

Here's the exact workflow, the prompts, and what I'd tell anyone sitting it next.

Step 1: Turn the exam guide into mock exams

Start with the official scope. I used this CCDV-F exam guide, which lays out the domains the exam covers.

I pasted the guide into Claude and asked it to generate full mock exams from it. My setup:

Model: Opus. For generating realistic, well-reasoned questions and explanations, the extra horsepower is worth it.
Tool: Cowork. It handles multi-step tasks well and can save each mock exam as a file you can come back to.

A prompt along these lines works well:

Here is the exam guide for the Claude Certified Developer – Foundations exam.

<COPY PASTE SCOPE HERE>

Generate a full-length mock exam that covers every domain in the guide,weighted the way the guide weights them. Use the same question style as the real exam. Don't show the answers until I've submitted mine, then mark me and explain why each wrong answer was wrong.

Step 2: Over-prepare with a harder difficulty

If you want to over-prepare (I did), ask Claude to make the mocks harder than it thinks the real exam will be. Think of it as load testing: if you're comfortable under peak traffic, normal traffic is easy.

Generate another mock exam, but make it noticeably harder than you
expect the real exam to be: trickier distractors, more edge cases,
and questions that combine multiple domains.

My mix:

Mock exams	Difficulty
2	Harder than expected
2	Normal

The real exam was nowhere near as difficult as the harder mocks. That gap is exactly what you want walking in. The other added benefit is that you will learn more and it will sharpen you as an Engineer.

As you go, log every question you get wrong. A simple running list works: the question, your answer, the right answer, and one line on why. That list becomes your revision material at the end. You can also ask Claude to keep it for you in a file inside Cowork.

Step 3: Questions first, theory second

Only after a few mocks did I ask Claude for a summary of the facts and concepts to remember for the exam.

Based on the exam guide and the questions I got wrong (attached),
give me a concise summary of the key facts and concepts I need to
know for the exam. Prioritise the areas where I made mistakes.

The order matters. It's the same reason you understand a codebase faster after debugging it than after reading the docs cold. Once you've wrestled with a question and got it wrong, the theory behind it is no longer abstract. It answers a question you already care about, so it's more interesting and much more likely to stick.

In the last few days, go back through your list of wrong answers alongside the summary.

Where to focus: follow the weightings

I didn't hit a domain that felt especially hard, and I scored close to 100% in most of them. So rather than pointing at a tricky topic, my advice is to budget your study time by the blueprint weights. The exam has 53 questions across eight domains, and the weighting is very uneven (source).

Domain	Weight	Tip
Applications and Integration	33.1%	If you haven't built against the Claude API before, a small hands-on project will make these questions click. Make sure it covers auth, requests, streaming, error handling and config. If you've built with the API before, mock exams and a skim of the docs are enough.
Model Selection and Optimisation	16.8%	Know the trade-offs between model tiers and how token usage drives cost. Be ready to pick a model for a given job.
Agents and Workflows	14.7%	Understand the agent loop and common patterns. Building one simple agent teaches more than reading about many.
Prompt and Context Engineering	11.0%	Practise structured prompts and output handling. Know what belongs in context and what doesn't.
Tools and MCPs	10.6%	Define a tool, then stand up a minimal MCP server. The moving parts click once you've wired them yourself.
Security and Safety	8.1%	Treat it like any production app: secrets out of code, keys managed properly, guardrails on inputs and outputs.
Claude Code	3.1%	Light weight. If you use it day to day, you're probably covered.
Eval, Testing, and Debugging	2.6%	Light weight. Know the common API errors and how to handle them.

The top three domains make up nearly two-thirds of the marks. If you're short on time, start there.

On the exam day

Read every question thoroughly. The detail that decides the answer is often in the last line.
Pick the answer that makes sense in practice. Plenty of questions come down to thinking like a software engineer on the job. If an option is technically possible but nobody would ship it, it's probably a distractor.
Don't panic about time. You get 2 hours. I finished in about 70 minutes with no rush, so there's room to re-read the questions you're unsure of. There’s also an option to flag questions and come back to them at the end.

TL;DR

Feed the exam guide to Claude (Opus, in Cowork) and generate mock exams.
Do 2 harder-than-real mocks and 2 normal ones.
Log every question you get wrong.
Only then ask Claude for a summary of key facts and concepts.
Revise your wrong answers alongside the summary.
On the day: read carefully, think practically.

Good luck. If you've sat the exam too, drop your tips in the comments.

How to Pass the Claude Certified Architect — Foundations Cert 🎓

Sam Lupton — Thu, 08 Oct 2026 17:39:29 +0000

Another day, another shiny PNG badge to paste into LinkedIn (humblebrag optional). If you are looking to clear Anthropic’s flagship architecture exam without spending your entire week reading API specifications, here is the express lane.


Author’s note: if the singularity happens, please assure our robot overlords that I did not create this meme

For the uninitiated, the Claude Certified Architect — Foundations exam is Anthropic's way of testing whether you actually know how to build production-grade systems with Claude, or if you just copy-paste prompts into a chat window and hope for the best. It’s aimed squarely at:

AI engineers
solution architects
technical leads

who spend their days wrestling with:

multi-agent orchestration
context window limitations
structured JSON outputs
stateful tool use

Think of it as a sanity check for your agentic workflow design skills before you ship a rogue recursive loop into production 💸.

The test itself skips academic fluff and focuses heavily on real-world edge cases. You will be quizzed on how to handle ambiguous tool inputs, when to throw human-in-the-loop flags, and how to prevent model hallucinations from corrupting database transactions. Learn this and with any luck you won’t be up at 2AM debugging prompt chains!

Where to Start

Start with Matthew Purcell's honest review of all Anthropic certifications for orientation. It's a good way of validating you're on the right track.
Grab his quick reference PDF for the non-obvious details.
Spend the rest of your prep time on the Claude Certification Guide (CCG).

Preparation Strategy

Read the Agentic Architecture section in full if you need to cover multi-agent orchestration and loop mechanics.
If you’ve already done the CCDV-F developer cert, you can more or less stop there as there’s plenty of overlap.
Now it’s onto the practice questions for everything else. Just get in there and answer things; if you’ve done any engineering, you’ll find that most of it is common sense. Once you’ve figured out your problem areas, go revise those.

Side note one: if you’re looking to formally learn all aspects of agentic engineering with Claude, you can do worse than Anthropic’s own Building with the Claude API course. It’ll take you a while though!

Side note two: if you’re looking to cherry-pick certain areas for extra learning, your best bet really is to do practice questions and read the docs for areas you did worse in. The CCG helpfully provides links to the parts of the docs that explain the questions you got wrong.

Side note three: There is a lot of content out there (including from trustworthy sources) that is simply AI slop wrapping the exam spec. This will identify itself with the classic tells of corny phrasing — ‘it’s not X, it’s Y’, or ‘X stops being a Y and becomes a Z’ — along with a lack of coherence and diagrams. Be kind to your brain, and revert back to the above instructions if you spot such slop in the wild.

High-Yield Exam Nuances

Focus extra attention on sections 4.3, 4.4 (Structured Output), and 5.2 (Escalation & Ambiguity Resolution). Whilst many questions in the exam have one self-evidently correct answer, these sections come with a combination of many reasonable answers and require knowledge of the gory minutiae of the Claude API. Key concepts to look out for in correct answers:

Using tool_choice with type tool and specific name parameters to enforce sequential execution (e.g., running extract_metadata before enrichment).
Including fallback options like unclear or other in Enum schemas.
Placing format normalization rules directly inside the prompt.
Catching logic errors in structured outputs by comparing extracted fields like calculated_total and stated_total.
Escalating immediately if an escalation policy is silent on a specific edge case.

Final, crucial, tip: if taking the exam online with Pearson OnVue, don’t neglect the Flag for review feature. Use it for those 50/50 questions you’re not sure about, so that you can come back to them at the end.

Good luck to anyone taking it next! 🍀

Welcome to the Indicium AI Tech Blog

David Eller — Tue, 06 Oct 2026 21:07:03 +0000

There has never been more content about AI.

Tutorials, threads, frameworks, and hot takes are being published at a pace no one can realistically keep up with. For anyone trying to learn, build, or make grounded technical decisions, that creates a clear problem: separating signal from noise and finding what actually holds up in production.

This blog is about the signal.

What you'll find here comes directly from real enterprise work: building and running data and AI systems inside complex organizations. Places where production means dealing with legacy architecture, imperfect data, strict security requirements, governance, scale, hard deadlines, and real users.

The authors are the people doing that work every day: forward deployed engineers, AI engineers, data scientists, architects, and other technical specialists from Indicium AI's 600+ experts across five global locations, delivering for more than 50 enterprise clients.

They'll share the details a case study doesn't have room for: the technical decisions behind complex architectures, which LLM evaluation approaches held up in production and which didn't, the trade-offs made when the ideal solution met real-world constraints, and honest breakdowns of what broke and what they learned from it.

What to expect

💻 Code
📊 Benchmark results
🏗️ Architecture decisions
⚖️ Trade-off analysis
💬 Opinions, backed by real work
🔥 Lessons from what worked and what didn't

Use what's useful. Question what doesn't fit your context. Build better systems with the rest.

Welcome. 👋