Notes from Claude Code Curious: Cutting Edge — featuring Ali and Ash from Anthropic, plus Tom Ashworth from Incident.io, March 24 2026.
The whole idea of Claude Code Curious was to bring people excited about AI and Agents together from all different backgrounds.
For CCC:Cutting Edge, we did the opposite: an event just for AI engineers building non-deterministic tech at scale – to find the only other people who can understand, discuss and share the kinds of challenges they are all working on.
It was an event defined by DEPTH. And it all started with our Q&A, including the rare treat of Alistair Smith from the Claude Code team in SF, ably supported by Anthropic London local, Ash Prabakar and real hands on experience from Tom Ashworth from Incident.io.
Agents at Scale — the context management problem
We kicked off leaping straight into how you build for Agents at scale.
Tom spoke about building Incident’s AI SRE product – and the extreme context management challenges:
“Any data source that we go out to, we will pre-generate a compressed summary so that we can retrieve it. If that proves fruitful, you can go and pull out more data.”
They’ve built what they call “snippets” — token-efficient representations of any object type in their system, configurable per use case.
Maybe surprisingly, he also mentioned committing documentation in the repo:
“We commit all our product documentation, with pointers back to the code that it’s related to. When you need to fix a bug, where you start is: how did the user get to that bug? And typically that is about how they use the product.”
Later in the evening, Ash also mentioned making sure the whole team is committing improvements and updates to the project’s claude.md file. Simple, but easy to forget…
Ali went bigger picture:
“Make the thing work first of all and then once you’ve done that, figure out where you can start removing bits of information that is noise to the model. They’re really good for large code bases in roughly a function of two things: the more tokens you give it, it’s going to do a better job. And the other thing is it needs to have the context.”
Harnessing full power
I’m super into harness chat. Everyone goes on and on about agents, skills, subagents, hooks etc – nobody talks about harnesses, and they are probably the most important thing in an agentic system.
So when I asked about this, Ali described a pattern that’s becoming central:
“Having a generating agent and a QA agent effectively work in parallel. You could go from having a loop running for half an hour to six hours plus. This works particularly well for one-shotting full stack apps or tools or complete projects.”
He called it the “adversarial style pattern.” A generator builds. A QA agent asks “am I done?” and pushes back. The cycle can’t end until the QA agent is satisfied. It’s the multi-agent disagreement pattern from CCC#2, but much longer timeframes.
The real shift is bottlenecks – Ash added:
“Previously the bottleneck was ‘write code’ — and definitely they can write code now. So now the bottleneck is: is it good code? And how do we verify its work?”
Tom connected this directly to his own experience:
“I can get the most out of Claude if I put a bunch of effort up front into making the product verifiable. Weirdly it’s just like test driven development, but slightly bigger.”
TDD, but slightly bigger. Sounds simple, but scale changes the stakes.
Everything on disk
Tom kept returning to one idea all evening, almost like a mantra: files on disk.
Someone asked about the “ultimate Claude Code setup.” Tom’s answer:
“Can you get it on disk and can you deploy it back from disk? If you can, you’ll find a way.”
He also (albeit apologetically) had thought about the future of BI:
“Why do we have a BI system? I think you’re dead, basically. I raced a BI tool against Claude Code and recent data earlier — absolutely wiped software that didn’t have access to any context.”
And the bit I totally love:
“Experimentation is now commoditised locally. So let it rip. Let people try stuff, make stuff easy to delete, and then when things are good, make it easily shareable.”
YES.
MCP is fine, actually
A spicy question: is MCP dying? Tom looked bemused.
“I basically thought about this as: permission boundaries are good, encapsulation and good interfaces are good. For us, where we use MCP is because it solves a problem — easy to build, easy to deploy, easy to authenticate against.”
His team built an internal MCP server for their sales team — it intermediates access to Salesforce and BigQuery with proper authentication. It also smooths rough edges non-technical users might find with errors using CLI tools.
Ali from Anthropic was characteristically relaxed about it:
“MCPs are fine and CLIs are fine and the best thing is the one that writes your product. So you should just try things.”
So: the MCP chat seems to be more rhetorical than a real problem. If it is upsetting you, maybe time to turn off Twitter and Reddit for a while…
The closing
I’m a real stickler for good audience questions. They can really make the evening, especially when you have a crowd as great as the Claude Code Curious complement.
Last question of the night: “Where are you building towards? What’s the north star?”
Ali and Ash replied in such a way that my transcript almost can’t tell where one ended and the other began – and that feels strangely fitting:
“It’s absolutely a goal of Anthropic to have very useful tools accessible by most people – not necessarily coding as the end goal. Maybe coding is a vehicle that lets us get to the next goal: we want incredible tools for everyone, to make everyone’s lives better.”
“Code has a lot of nice things which make it good for training models. If we can make it really good at that, then it can make itself better — and then we can make it really good at everything else.”
Tools have always been humans’ unfair advantage, paving the road to a better future for us all. I can’t wait to see what comes next.
Cutting Edge is our new AI-engineers only format: Smaller room, deeper conversation. Sign up here to join the next one.