DEV Community: Adam McClarin

The security rules I make every AI coding agent follow

Adam McClarin — Tue, 22 Sep 2026 03:00:21 +0000

Drafted with AI assistance, edited and checked line by line against a real build before publishing.

On the Soulful Ledger backend build, I deliberately broke the tenant scoping clause in one query, just to see what would happen. The test suite stayed green. Every test passed. That's the moment I learned a green test suite proves nothing on its own. It only proves something once you've watched it catch a real break, and then fixed the break back.

That single failure is where most of what follows came from. Not a framework borrowed from somewhere else. These are wounds, distilled into defaults, from building a real multi-tenant system with AI agents doing a lot of the typing.

Every query is parameterized, no exceptions

$1, $2 syntax, never string interpolation into SQL. Not "just this once for the admin panel." Not "just for this one internal script." The exception is always where the injection ends up living, and an AI agent generating code at speed will happily write the unsafe version if you don't tell it not to, every single time you ask.

I watched this happen on an early Soulful Ledger endpoint. An agent building a quick internal reporting query dropped a raw f-string straight into the WHERE clause, because it was faster to write and nothing in the request had mentioned parameterization. Caught it in review, not in production, which is the only place that catch is allowed to happen.

Tenant scope never comes from the client, and never from the model

If a multi-tenant boundary exists, the query enforcing it needs the scope value baked into its WHERE clause, computed server-side, before the query ever runs. Not from a request body. Not from a URL parameter. Not from anything an AI model outputs, even if the model is only echoing back a value you gave it three turns ago.

Here's the test that actually proves it: deliberately break the scoping clause, confirm the suite catches it, then restore the clause. That's the test I ran on Soulful Ledger, the one that came back green with a broken clause still in place. Twelve passing tests told me nothing until I watched one of them fail on purpose.

AI never gets raw access to the data it's protecting

If an AI needs to answer questions from a database, it doesn't get a query tool. It gets a fixed, named, reviewed set of read-only functions, built the same way a human-reviewed API endpoint would be built. The tool schema exposed to the model never includes a scope or tenant field. That value gets injected server-side, after the model has already made its choice, never accepted from the model's own output.

The agent writing the code doesn't hold the keys

An AI coding agent never carries a database owner or superuser credential across a session. It can generate the migration. It can tell you exactly what command to run. The human runs anything elevated directly, by hand. The agent works with the same restricted, least-privilege credential the running application itself uses, nothing more.

This shows up in small decisions too. When I built the security audit stack for client engagements, the exploitdb server runs stdio-only, no HTTP port, no API key sitting around to leak. Canopy Guard, the free audit tool, stays external-only and uncredentialed on purpose, a completely separate boundary from anything that touches a client's real environment. Two different products, two different trust levels, and the line between them isn't an accident.

A green test suite is not proof of anything

Every security-relevant guarantee needs a test that could actually fail, and most teams never check that it can. Twelve passing tests prove nothing by themselves. What proves something is deliberately introducing the break the test is supposed to catch, watching the right thing go red, then fixing it.

The stronger version of this is proving the negative. "This works for the right tenant" is a weak claim. "This returns nothing for the wrong tenant, even when the wrong tenant's data would rank as the best possible answer" is the claim worth building a test around. If only one file in your codebase should ever query a sensitive table, write a test that fails the moment any other file does. That's a chokepoint test, and it catches the mistake before it ships instead of after.

Where this actually leaves you

I still run the client work, the builds, the calls, same as before any of this was written down. None of it changed the pace. What changed is that I don't report something as done anymore without having actually run it and watched it behave correctly, and I don't let a large pile of adjacent, verified work stand in for testing the one thing that hasn't run yet.

This approach costs time. It's slower than trusting the first green test suite you see. It's also the only way I've found to know the AI-assisted parts of a build are actually safe, instead of just hoping they are.

I built a security audit tool. Then I pointed it at my own site.

Adam McClarin — Tue, 15 Sep 2026 14:48:29 +0000

I pointed the scanner at merakislove.com last week, my own domain, the one with my name on it, the one I send prospects to as proof I practice what I sell.

It came back with a wildcard CORS header.

For twenty-plus years I've worked across software, security, and AI. I hold a CISSP. I built the exact ZAP and ExploitDB stack that caught this, running self-hosted through Claude Code. The credentials and the tooling didn't stop the gap from existing. They're what caught it. That distinction matters more than the header itself.

What the scan found

An Access-Control-Allow-Origin: * header, open to any origin calling the site instead of the specific domains that should have access. I traced it back to Vercel's CDN default. I hadn't set it myself.

That's an easy thing to inherit and an easy thing to miss. The site still looks fine from the outside. Nothing breaks, nothing errors. It sits there, wider open than it should be, until someone runs the right scan, or someone with worse intentions finds it first.

The fix, and the part most self audits skip

Scoping the header down to the actual allowed origins took minutes. Confirming the fix held took longer, and that second part is where most self audits fall apart.

ZAP caches session results. Rerun a scan against the same URL you just tested and you can get a clean read that has nothing to do with whether your fix actually worked. I pulled fresh URLs for the before and after checks to rule that out. A scan you can't trust is worse than no scan at all. It hands you false confidence instead of an honest answer.

Why I'm writing this instead of quietly fixing it and moving on

Most of the small business sites I look at were built fast, by people juggling a dozen other priorities, with security somewhere on a list they never got back to. I get it. I run a solo studio too. I know exactly what that list looks like.

The gap on my own site is a blind spot every builder carries somewhere, the kind that only surfaces when someone looks with the right tools instead of trusting the platform defaults to cover it.

What this built

The ZAP and ExploitDB stack that caught this now backs a Review package I run through Meraki is Love. Five days, five hundred to fifteen hundred dollars depending on scope, a CISSP-informed pass across your site for exactly this kind of gap, run by someone who just found one on his own.

If you want to know what's sitting open on your own site, the review is live on merakislove.com. Ask, and I'll tell you what I find, the way I just told you what I found on mine.

A green suite that never ran is not evidence

Adam McClarin — Fri, 11 Sep 2026 16:01:10 +0000

I have spent a stretch of weeks on a live system where the dangerous part was not a crash.
It was quiet. A provenance log that had written zero bytes for months. Tests that scored green without executing. A veto that had been dropping valid setups while the board still looked calm. A calendar built for the wrong exchange.
None of that announces itself. The UI still loads. The agent still reports progress. Someone still says the suite is green.
I direct AI coding agents on work like this. Multi-week rewires. Typed contracts. Shadow paths. The agent is fast. The agent will also tell you a push landed when you have not checked the remote, or that a cost number is solid when it was inferred from a fixture. I treat the report as a claim. Then I check the claim.
The practice I now keep is small.
Every negative result needs a positive control. If the test says nothing happened, I need proof the test can detect a real break. Mutation first. Break the thing the fix is supposed to catch. Confirm the suite sees it. Restore.
Distinguish measurement from inference. An extraction bug is not a market finding. A time zone error is not a data gap. Write the correction down before it becomes folklore.
On a live rewire, keep the old path authoritative until the new path is proven in shadow. One boundary at a time. Do not cut over on confidence.
If you are using an agent on a system that already carries money, records, or a book, the skill is not the prompt. The skill is knowing what to re-run yourself.
I do this work at Meraki is Love. Studio site: merakislove.com

Building Meraki Command: One Dashboard to Run Every Project I Touch

Adam McClarin — Sat, 29 Aug 2026 15:55:13 +0000

I run more moving parts than any one person should try to hold in their head. A security audit tool. A business intelligence platform. A client automation product. A translation platform. A deck generator. An education tracker. A managed services arm. Ghostwriting and publishing work on top of all of it.

For a long time I ran that from memory, a stack of browser tabs, and whatever notebook was closest. That worked until it didn't. So I built Meraki Command.

What it actually is

Meraki Command is the internal system that sits above everything I build and everything I run for clients. It is not a single app. It is the layer that watches all the other apps.

Under the hood it pulls from a few places I already had running:

Canopy Guard, the audit tool that scores a site across SEO, AEO, GEO, and security using a MITRE ATT&CK informed methodology. Every audit that runs feeds a lead into the system automatically.

Meraki BIP, my own business intelligence platform, where I track leads, client progress, and the actual numbers behind the business. This was already internal facing. Meraki Command sits on top of it and pulls the signal forward instead of making me go dig for it.

VeloxSync, the client facing back office automation product. Different job than BIP. BIP is me watching my business. VeloxSync is what a client's team uses to run theirs.

Meraki Lingua, the multilingual content platform, and Meridian, which turns a business file into a board ready deck. Both get status pings into Command so I know when a job is stuck versus when it's just running long.

VeloxSync for Education, tracking grade band student progress for the education side of the client base.

White Glove Service, the managed implementation arm for SMBs who need someone to actually do the setup, not just hand them a tool.

And then the parts of the business that never fit neatly into software at all. Ghostwriting and publishing work for a small roster of authors. That work does not run through dashboards. It runs through deadlines and drafts. Command tracks those too, alongside everything else, because a missed manuscript deadline matters exactly as much as a missed deploy.

Why I built it instead of buying something

I looked at project management tools before I built this. Every one of them assumed my business looked like one thing. A dev shop, or an agency, or a SaaS company. Mine is all of those at once, plus a security practice, plus a writing career. Nothing off the shelf was built for a business that shape.

The other reason is the audit pipeline. Canopy Guard produces a real, structured finding for every site it touches. Exposed files, missing SPF records, weak DMARC setups. That data needs to turn into a next step without me manually copying it somewhere. Command is where that handoff happens. An audit finishes, the finding gets scored, and if it clears a threshold, it becomes a tracked opportunity instead of a PDF sitting in a folder.

How it's built

Vercel on the frontend, Railway running the backend engine, the same pairing Canopy Guard itself runs on. Resend handles the transactional layer, report delivery and the follow up flows that fire in the first 24 hours after an audit. Google Calendar is wired in with color coding by category, technical sessions, social posts, DNS work, outreach, profile updates, so a glance at the week tells me what kind of day I'm walking into before I read a single event title.

None of that is exotic. The value isn't the stack. The value is that it's one place instead of eight.

What changed after I built it

The biggest shift wasn't speed. It was that I stopped losing things. A lead from an Alignable audit doesn't sit unanswered because I forgot which tab it was in. A ghostwriting deadline doesn't quietly slip because it lived in a different mental bucket than the client dashboards did.

If you're running more than one product or more than one kind of client work, you already know the real cost isn't the work itself. It's the tax of holding all of it in your head at once. Build the thing that holds it for you.

I'm still adding to Command as the business grows. If you're building something similar, I'd like to hear how you're handling the handoff between an automated finding and an actual human follow up. That's the part I'm still tuning.

Claude Cowork and Chat now share memory. Here’s what actually changed.

Adam McClarin — Thu, 27 Aug 2026 03:11:47 +0000

What changed

Claude chat and Claude Cowork now read from and write to the same memory. Cowork picks up context from earlier chats: a project, a client, a preference you stated once. Anything Cowork learns during a task carries back into chat too.

Memory also updates live now. Claude used to summarize a conversation after it ended. Now it adds topics as the conversation happens, so a decision made mid session is already available if you switch tools before you’re done talking.

What did not change

Claude Code keeps its own memory, separate from this merge. If your workflow includes Claude Code for actual development work, don’t expect this update to touch that context. Chat and Cowork are unified. Code stands apart.

Also worth flagging for anyone running Cowork locally: the shared memory only applies when Cowork runs in the cloud. Local sessions don’t draw on it.

Why it matters for solo builders

On Canopy Guard, my security audit tool, I review findings in chat, then switch to Cowork to draft the client deliverable or the fix plan. Before this update, that switch cost me a rebrief every time. Now Cowork already has the site, the score, the finding.

If you run lean and move constantly between reasoning and building, this closes a gap you were probably absorbing without naming it.

Transparency and control

Anthropic exposed the memory itself. Settings shows stored topics, each one readable, editable, deletable. Sensitive categories, health, politics, gender identity, religion, stay off by default. You can turn them on if you want that level of personalization, and Claude flags it when a sensitive topic gets saved.

Rolled out by default on Free, Pro, and Max, across web, desktop, and mobile. Update your app if you haven’t already.

I Built a Free Audit Tool That Runs 12 Checks in Parallel Against Any Domain. Here Is the Architecture.

Adam McClarin — Mon, 17 Aug 2026 16:32:47 +0000

I had a Chrome tab open with eleven site audit tools running one after another, waiting on the slowest one to finish before I could even start reading results. That wait is what got me building CanopyGuard.

I have spent years running security and SEO audits by hand for clients, the CISSP kind of process where you go section by section, credential by credential, header by header. It works. It also does not scale past a handful of clients a month, and every existing audit tool I tried made the same mistake: it ran everything in sequence, one check waiting on the last, turning a fifteen second job into a two minute one.

So I rebuilt the whole thing around a different assumption. Nothing about checking a domain's SEO posture depends on knowing its security posture first. They are independent questions. If they are independent, they do not need to run in order.

Four categories, running at once

CanopyGuard checks a domain across four categories: SEO, AEO (answer engine optimization), GEO (generative engine optimization), and security. Across those four categories it currently evaluates 104 individual signals, and the whole scan finishes in about 30 seconds.

That speed is not a frontend trick. It comes from treating each category as its own worker that starts the moment a domain comes in, instead of a checklist processed top to bottom. Something close to this, conceptually:

> **javascript
> const [seoResults, aeoResults, geoResults, securityResults] = await Promise.all([
>   runSeoChecks(domain),
>   runAeoChecks(domain),
>   runGeoChecks(domain),
>   runSecurityChecks(domain),
]);**

Twelve worker groups fan out from there, each one owning a slice of the 104 signals, each one able to fail or time out without taking the other eleven down with it. A DNS lookup that hangs does not block the HTML parsing. A slow TLS handshake does not block the schema markup check. The scan finishes when the slowest worker finishes, not when the sum of every worker finishes.

Where the security depth comes from

The SEO, AEO, and GEO layers are what most audit tools cover. The security layer is where CISSP training actually shows up in the product instead of just my bio.

It is the same manual routine I used to run for paying clients: TLS configuration, security headers, DNS posture, exposed paths, mixed content, cookie attributes. Automated now, but the checklist itself came from real engagements, not a generic vulnerability scanner's default rule set.

This month I added a layer on top of that: every flagged security issue now maps to a technique in the MITRE ATT&CK framework. Instead of telling someone "missing HSTS header," CanopyGuard tells them which real-world attack technique that gap actually enables. A flagged issue with no context is trivia. A flagged issue tied to a named technique is a reason to fix it today.

What building it this way actually cost

Parallel execution is not free. Once four categories and twelve workers can all fail independently, you have to design for partial results from the start. If the security worker times out but the other three finish clean, the scan still has to return something useful instead of erroring out entirely. Every worker needed its own timeout, its own fallback, and its own way of reporting that a signal could not be checked without that uncertainty poisoning the rest of the report.

That is more engineering than a sequential script that just runs down a list and gives up on the first failure. It is also the only way to hit 30 seconds on 104 signals instead of asking someone to wait two minutes for a free tool they have not decided to trust yet.

Try it

CanopyGuard is free, still runs in about 30 seconds, and does not require an account. If you want to see what your own site is carrying under the surface, run it at thecanopyguard.com.

I also wrote about the growth side of this story, how it went from an idea to its first 100 downloaded reports, over at Fake Mayo , Jakob Jelling's newsletter on how founders land their first customers.

The tooling behind self-publishing an illustrated AI cookbook

Adam McClarin — Tue, 28 Jul 2026 17:52:33 +0000

The build script failed for the ninth time that afternoon, and the problem had nothing to do with my code. It was a 280 PPI image trying to pass as print-ready.

That single bug says a lot about what building The AI Cookbook actually involved: a small, repeatable production pipeline, built first, with twenty-six recipes written to run through it.

Why code instead of a word processor

The book is seventy-eight pages, twenty-six recipes, six chapters, each one following the same structure: an intro, a tools list, numbered prompts, an image placeholder. Doing that by hand in Word across seventy-eight pages means seventy-eight chances for a formatting inconsistency to slip past unnoticed until print.

I built the manuscript in Node.js instead, using the docx library to generate the Word file from structured content. Every recipe lives as a JavaScript object: title, tools, intro, prompts, image reference. A build script assembles them into the final document. Fix a formatting rule once, and it holds everywhere, not just in the one paragraph someone happened to catch.

One real bug from that process: standalone empty paragraphs inserted as page breaks were rendering as square glyphs on Word mobile. The fix was moving the break onto the pageBreakBefore property of the next heading instead. Small change, and it only surfaced because someone actually opened the file on a phone.

The image pipeline

Every illustration started in Gemini, then went through a manual check for watermarks and resolution before it got anywhere near the manuscript. Four images came back under 300 PPI, the print minimum, and needed a second pass before they qualified.

Getting each image to the same portrait ratio without cropping the part that mattered took a small Python script using PIL, padding each image with a warm wood-tone background matching the book's kitchen aesthetic, rather than stretching or cropping to force the fit.

Video, almost as an afterthought

The promotional side needed a short Instagram Reel and a YouTube Shorts version, both built with ffmpeg. Ken Burns style zoom on each still image, crossfade transitions between them, rendered straight from the command line.

Why it mattered

Twenty-six recipes staying genuinely consistent across seventy-eight pages needed automation. Hand-editing that many repeated structures invites the kind of mistake nobody catches until print.

If you want the actual prompt templates, all twenty-six of them organized by the kind of problem they solve, the book's up on Gumroad: https://merakislove.gumroad.com/l/cookbook

I turned 26 AI prompts into a cookbook, and gave away the system prompts too

Adam McClarin — Sat, 11 Jul 2026 03:56:53 +0000

I spent the last few weeks doing something a little unusual: writing a cookbook. Not a real one. A prompt cookbook, twenty six tested, reusable prompts for ChatGPT, Claude, and Gemini, organized the same way you'd organize a recipe book, by what you're actually trying to make.

Here's the part that might actually be useful to you as a builder, not just a reader.

The problem I kept running into

Every time I wanted a model to do something specific and repeatable, a Socratic tutor for studying, a structured research synthesizer, a system prompt builder for my own agents, I'd rewrite the same prompt from scratch, slightly worse than the last time. No version control on my own thinking. No single source of truth.

So I built one. Not a prompt library buried in a Notion doc nobody opens. Something structured enough to hand directly to a model as its own instructions.

What that actually looks like

Each recipe follows the same shape: a role, a tool recommendation, and a prompt formula with the variables marked out in brackets.

You are a Socratic tutor teaching [subject or topic] to a [grade level] student.
Never give the direct answer. Instead, ask one guiding question at a time that
leads the student toward the answer themselves. Wait for their response before
asking the next question. If they get stuck twice in a row, offer a small hint
framed as another question, not a statement.

That's one of twenty six. Others cover research synthesis, system prompt design for persistent agents, debugging assumptions with explicit step by step reasoning, and a handful of less technical ones, meal planning, budget review, client onboarding, because the same discipline applies whether you're prompting for code review or a bedtime story.

The part I think is actually novel

Along with the book itself, I built three ready made skill files, one for ChatGPT custom instructions, one formatted as an actual Claude Skill with proper frontmatter, one for a Gemini Gem. Drop one in, and that model already has all twenty six recipes as reference material. Ask it in plain language for what you need, and it pulls the right formula instead of you re-deriving it every time.

If you've built internal tooling around reusable prompt libraries before, I'd genuinely like to hear how you structured it. This was my first pass at treating prompts like something closer to a dependency than a one-off message.

The full thing, book plus all three skill files, is here if you want to see the whole set: https://merakislove.gumroad.com/l/cookbook

Curious what other builders are doing for prompt reuse across models. Drop it in the comments.

I Will Adopt New AI Tools When They Fit My Work. Fable 5 Was Shut Down Before I Could Test It

Adam McClarin — Mon, 15 Jun 2026 14:32:53 +0000

When a model gets pulled by the White House after four days, adopting it was never the real option anyway. My stack stays stable while others chase hype.

I watched Fable 5 launch on June 9. It died on June 13.

The numbers were real. The hype was loud. Everyone on social was talking about a new frontier capability with cyber safeguards that the rest of the industry was years away from. On Thursday night, Amazon reported critical vulnerabilities to the White House. By Friday evening, the model was gone.

But I was not reshuffling my stack to adopt it anyway.

Here is what actually happened: Fable 5 lasted four days in public hands. That is not long enough to validate integration, test against your actual workloads, or even understand whether it solves a real problem in your production system. It is long enough to decide you need it.

That is the trap. A model launches with impressive benchmark numbers. Your team sees it. Everyone online is talking about the capability. You start running the mental calculation of refactoring your prompts, updating your integrations, retraining your context windows. Then the government shuts it down.

I run a production stack. Claude for reasoning and building. Gemini for deep research. Together.ai for fine-tuned inference on Ei-Core. VeloxSync runs on this. The Canopy Guard runs on this. Nail Check runs on this. Each tool has earned its place through real work, not visibility. That stack does not change because something had four days of hype.

*What the Shutdown Actually Means
*
The government alleged that researchers were able to jailbreak portions of Mythos through relatively simple methods, and the administration considered this a national security threat serious enough to mandate export controls. Anthropic's position was that the vulnerability was straightforward to address and similar issues exist in other models. That argument did not matter. The government decided the model posed a risk to national security. Within hours, it was offline.

This is not a story about Anthropic or government overreach. It is a story about adoption.

When you decide to shift your entire workflow for a new tool, you are making a bet on stability. You are betting that the tool will be available, that it will continue to work the way it works today, and that the investment you make in integrating it will pay dividends. Fable 5 proved in the harshest possible way that new models, no matter how powerful, carry risk. They can be pulled overnight. They can be subject to sudden government action. They can cease to exist before your first integration is finished.

*The Discipline to Wait
*
I will watch what happens next. If Anthropic retools the model and returns it to service with government approval, if the security questions are resolved and the product becomes available again, then I will evaluate whether it actually solves a problem my production system does not currently handle. But I will know why I am adopting it. Not because it launched. Not because everyone else did. Because the work demands it.

The bandwidth to keep tools sharp is real. The temptation to chase every new capability is real. The difference between a working stack and a broken one is the discipline to say no until the work asks you to say yes.

And sometimes, the work never asks. Sometimes the tool disappears. And you keep running.

Adam McClarin · Meraki Is Love | AI Engineer and Full-Stack Developer · adammcclarin.com

I Will Adopt New AI Tools When They Fit My Work. Fable 5 Is Not That Moment.

Adam McClarin — Thu, 11 Jun 2026 15:25:34 +0000

I watched Fable 5 launch on June 9. The numbers are real. The hype is loud. Everyone on social is reshuffling their AI stack, and I get the appeal. A new frontier capability with cyber safeguards that the rest of the industry is still years away from? That moves people.
But I am not switching anything. Not yet. Maybe not ever, depending on what VeloxSync and the bigger scope projects actually need.
Here is the thing about adopting new tools: the adoption is not the hard part. Integration is. When you run a production stack like mine, you do not pivot because something has a headline. You pivot because the work demands it and because you can measure the delta.
Right now, my stack works. Claude for reasoning and building. Gemini for deep research. Together.ai for fine-tuned inference on Ei-Core. A handful of platforms that have earned their place through real projects, not visibility. VeloxSync runs on this. The Canopy Guard audit tool runs on this. Nail Check runs on this. Each tool has a job. Each job is done.
Fable 5's cyber capability is gated anyway. The public version has safeguards. The version that actually finds zero-days and writes autonomous exploits, Mythos 5, requires verification I do not yet have. So what am I adopting? A model with the same reasoning ability as Sonnet with guardrails in front? Claude already does that. The thing that would make Fable 5 worth restructuring my workflow around, Mythos access, is not available to me and may not be for months.
That is the actual picture people miss. They see the headline, they see the capability numbers, and they assume they need it now. But adoption without a real reason to adopt is technical debt. It is a new integration surface. It is refactoring prompts that already work. It is retraining context windows. It is slower.
I will watch it. If VeloxSync reaches a point where the cyber reasoning matters more than Claude's reasoning does, if the education build requires a model that can hold multiple constraint sets at once better than it does now, if a major project lands that makes Mythos access necessary, then I will move. But I will know why I am moving. Not because everyone else did.
The bandwidth to keep tools sharp is real. The temptation to chase every new capability is real. The difference between a working stack and a broken one is the discipline to say no until the work asks you to say yes.

80% of Anthropic's Production Code Is Now Written by Claude. Here Is What That Actually Means for Engineers.

Adam McClarin — Sat, 06 Jun 2026 14:42:36 +0000

Last week I shipped a full SaaS module without writing most of the code myself.
Not a prototype. Not a one-off script. A production feature for VeloxSync: 10 database tables, 30-plus API endpoints, 12 frontend pages, Stripe billing integration, and 112 state academic standards mapped to AI-powered grade-band models. One extended Claude Code session, one engineer (me) directing and reviewing.
That used to take weeks.
This week, Anthropic published internal production data that explains why, and where this is heading. If you are building software professionally right now, the numbers in this report are worth looking at directly.

What the data actually says
This is not a benchmark report. Anthropic is publishing numbers from inside their own development process.

80%+ of code merged to Anthropic's production codebase was authored by Claude as of May 2026
8x increase in code merged per engineer per day compared to 2024
Task horizon doubling every ~4 months: In March 2024, Claude reliably handled tasks that take humans about four minutes. By April 2026, that benchmark was 12-hour tasks.
76% success rate on fully open-ended tasks in May 2026 (up 50 percentage points in six months)
52x speedup on a code optimization benchmark by Claude Mythos Preview, vs. roughly 4x from a skilled human engineer in four to eight hours on the same task
800+ fixes shipped by Claude in April 2026 in a single sweep; the engineer overseeing the work estimated a human would have taken four years

These numbers are from the company's own production environment, not a controlled lab setting.

The distinction you need to hold onto
The report draws a line that I think is more useful than the usual "AI will take developer jobs" framing.
The doing: Writing the code, running the experiment, generating the output.
The directing: Deciding which problems matter. Choosing the approach. Judging whether a result is trustworthy. Knowing when to stop.
The doing is already nearly free in human time.
The directing is still human.
Anthropic's internal analysis found that Claude can match or outperform skilled humans at executing a well-specified experiment. The remaining gap is in goal-setting: which experiments are worth running, when to trust an output, when to abandon a direction entirely.

A real example from the report
A routine upgrade started crashing tens of thousands of training jobs inside Anthropic. An engineer pointed Claude at the live incident with some text context and cluster access, minimal guidance beyond that.
Working through running jobs and testing one environment setting at a time, Claude isolated a single obscure debugging flag that was triggering the crash, reproduced it reliably, and confirmed a fix.
Time: about two hours.
Equivalent human work: two to three days.
The engineer still had to recognize this was the right kind of problem to hand off, set up the context correctly, and validate the fix. That judgment is not automated.

The code quality question you are probably wondering about
The report is honest here. Claude-written code was worse than human-written code at Anthropic in late 2025 in terms of readability and maintainability. Anthropic says it is roughly at parity today and expects it to be better within the year.
They also deployed an automated Claude reviewer that runs on every proposed change to their codebase before merge. When they ran it retrospectively on past changes, it would have caught roughly a third of the bugs behind past production incidents on claude.ai. Written by engineers who are, as the report notes, among the best in the world at building these systems.
That is the current state of the tooling. Not theoretical.

What this means for your work right now
The report identifies "research taste" as the remaining human comparative advantage: the ability to decide which problems are worth working on at all.
For engineers, this translates directly.
Do you understand your system well enough to know which Claude Code session is worth running and which one will produce plausible-looking garbage? Can you review an AI-generated PR and spot the part that will fail under load? Can you translate a client's stated problem into the actual architecture they need?
That judgment does not come from knowing which tools to use. It comes from having shipped things that broke and understanding why.
The report also maps three possible futures: capabilities plateau at current levels and diffuse widely; AI development becomes substantially automated while humans retain research direction; or AI achieves full recursive self-improvement. Anthropic says they believe the second scenario is the most likely near-term outcome.
In that world, an engineer directing ten Claude Code sessions with good judgment is worth more than an engineer writing 10,000 lines by hand. The question is how fast you develop the clarity to operate at that level.

A practical read
The full report is long and worth reading in full if you build AI-adjacent systems professionally: anthropic.com/institute/recursive-self-improvement
If you want to see how I apply this at the solo studio level across VeloxSync and other active builds, I document a lot of it at veloxsync.app and in the Soulful Tech newsletter.

Adam McClarin is a full-stack AI developer and founder of Meraki is Love (Soulful Tech). CISSP, Azure AI Engineer, 20 years across software, security, and AI.

The AI Stack Behind PTSD Care for Veterans (How It Actually Works)

Adam McClarin — Fri, 05 Jun 2026 14:19:56 +0000

I was at a VA clinic and watched something I had not expected to see: a veteran completing a clinical interview with an AI avatar. Not a video call. Not a chatbot. A purpose-built, research-backed system doing what standard clinical instruments had consistently failed to do: getting veterans to open up about trauma symptoms.
I build AI for a living. That afternoon, I got to watch it work.
Here is a technical breakdown of the major AI systems being deployed in veteran PTSD care, and what is actually under the hood.

USC's Ellie: Embodied conversational AI for clinical interviews Ellie is a virtual avatar built to conduct clinical mental health interviews. The system uses multimodal input including facial expression analysis, voice tone detection, and body language cues to guide a structured interview in real time. The clinical insight here is not that the AI is better than a human clinician. It is that many veterans are more willing to disclose sensitive information to a non-human interviewer. The social risk calculus changes. Studies have consistently shown higher disclosure rates with Ellie compared to standard self-report instruments. From a build perspective: this is a combination of natural language processing for response handling, computer vision for behavioral cue analysis, and rule-based clinical logic governing the interview structure. The avatar rendering runs on a separate graphics layer alongside the conversation model in real time.
MACPI: ML-based PTSD detection from voice data MACPI (Mining Audio Cues from PTSD Interviews) was developed by researchers at NYU Langone Health and MITRE. The system trains machine learning models on speech samples to detect PTSD-associated acoustic patterns. The features it analyzes: fundamental frequency variation (pitch), voice quality measures, temporal patterns in speech (pauses, rhythm, rate), and spectral characteristics. The model achieves up to 90 percent accuracy in screening. This matters because it removes self-report as the primary diagnostic mechanism. A veteran does not need to consciously disclose. The model operates on acoustic data, not stated content. The architecture is a supervised classification pipeline. Feature extraction from audio using signal processing libraries (likely Librosa or similar), dimensionality reduction, and a classifier trained on labeled clinical interview data.
REACH VET: Predictive risk modeling at VA scale REACH VET runs inside the VA's healthcare infrastructure. It is a predictive modeling system that processes structured clinical data including medication records, diagnoses, appointment history, and behavioral health notes to assign risk scores for hospitalization and suicide. The VA system covers millions of veterans. Running REACH VET at that scale requires a batch-processing pipeline capable of scoring records across a distributed data store. When a veteran's risk score crosses a defined threshold, a clinical alert is triggered and outreach is initiated. From an engineering standpoint: this is a supervised learning problem (binary classification, high-risk vs. baseline) applied to longitudinal healthcare records. The challenge is not the model architecture. It is data quality, feature engineering across heterogeneous clinical data sources, and ensuring the trigger mechanism integrates cleanly with clinical workflows.
Tiatros and CBT delivery at scale The Tiatros Post Traumatic Growth platform analyzes written narratives submitted by veterans and maps them to CBT module sequences. This is applied NLP: topic modeling, sentiment analysis, and semantic similarity matching to clinical CBT taxonomies. The output is a personalized module sequence rather than a linear program. A veteran who writes about sleep disruption gets different next-step content than one writing primarily about hypervigilance. This is the pattern-matching problem between unstructured patient input and structured therapeutic content that large language models are now well-positioned to solve. Systems that predate LLMs used traditional NLP pipelines. New platforms building in this space are starting to use transformer-based classification and retrieval-augmented generation to handle the mapping. What this space still needs The systems above are working. The gaps are in interoperability, data privacy at the edge, and explainability. Clinical teams want to understand why a model flagged a particular veteran for outreach. Black-box scores are hard to act on in a clinical setting. If you are building in health AI or veteran care specifically, those are the problems worth focusing on. Model accuracy is largely there. The infrastructure around trust, transparency, and clinical workflow integration is where the real engineering work remains. I build at Meraki is Love. If you are working on adjacent problems, reach out. https://calendly.com/hello-merakislove/new-meeting

Adam McClarin · Meraki Is Love | AI Engineer and Full-Stack Developer · adammcclarin.com