DEV Community: Adam McClarin

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

I need developers to break my scoring methodology (free audit tool, 47 signals)

Adam McClarin — Thu, 28 May 2026 18:50:32 +0000

I built Canopy Guard, a free website audit tool that scores domains across SEO, AEO, GEO, and security. I published the full scoring methodology openly and I want developers to challenge it.
Here is what I want you to do:

Scan your site at thecanopyguard.com
Look at the scores
Tell me where the numbers feel wrong

The scoring is based on weighted signals. Some examples:
SEO: crawlability is weighted at 0.10 because it's a gate check. Meta description gets 0.05 for presence plus up to 0.05 for ideal length (120-160 chars). Word count is gradient scored: under 200 words = thin content penalty, 1500+ = full credit.
AEO: FAQ schema presence is 0.10 but FAQ item count is scored separately up to 0.12. Five or more FAQ items gets full credit. One item gets 0.04. The theory is that a single question-answer pair is not meaningful coverage.
GEO: chunking efficiency is 0.25. It factors in heading count, paragraph count, lists, tables, and overall content length. The idea is that well-structured pages produce cleaner retrieval chunks for RAG systems. Is this a valid signal?
Security: CSP carries the highest individual header weight at 0.08 because it has the broadest protective scope. X-Content-Type-Options carries 0.04. Is this weighting defensible?
I also added HSTS max-age as a fallback for HTTPS redirect detection after discovering that Railway's egress can't always test HTTP redirects. If HSTS max-age is 1 year+, the site is enforcing HTTPS regardless.
Full methodology documented at the site. Every weight is visible.
thecanopyguard.com
Roast the scoring. I want it to be bulletproof before a bigger launch.

I built a 12-module website audit engine that cross-references visibility with security

Adam McClarin — Tue, 26 May 2026 22:22:20 +0000

I have been developing and testing this for months. The engine is Node.js and TypeScript on Railway. The frontend is React on Vercel. The scan runs 12 modules in parallel via Promise.all and completes in 5 to 15 seconds.
I am going to walk through the architecture, the scoring methodology, and the one design decision that changed the way I think about website audits.
The problem
I audit websites for clients. Every audit required at least four tools: one for SEO basics, one for structured data validation, one for security headers, one for SSL checks. And the newest layer, how AI models discover, chunk, and cite your content, had no tooling at all.
None of these tools cross-referenced their findings. A site could pass every individual check and still have a critical gap that only surfaces when you map the data together.
The architecture
Twelve modules, each returning a standardized JSON block:

DNS Resolution (Google Public DNS API)
TLS and Certificate Validation
Security Header Scan (6 headers)
HTML Structure Parse (H1, meta, canonical, title)
JSON-LD Schema Extraction and Validation
Q&A Content Density Analysis
GEO Chunking and Citation Measurement
robots.txt AI Crawl Policy Classification
Exposed Endpoint Detection (12 paths, false positive filtering)
Internal Link Depth Sampling
Vulnerability Indicator Scan
Content Provenance Check

All twelve run via Promise.all. The response assembles into a unified schema with two branches: visibility_canopy (SEO, AEO, GEO) and security_roots (TLS, headers, endpoints, AI crawl risk).
The false positive problem
Module 9 (exposed endpoints) was generating false positives on SPA sites. A React app on Vercel returns 200 for every path because the catch-all serves index.html for client-side routing. So /.env, /.git/config, and /wp-config.php.bak all came back as "exposed."
The fix uses three-layer detection. First, the engine fetches a guaranteed-nonsense path (e.g., /canopyguard-probe-{timestamp}) to detect catch-all behavior. Then every subsequent path check compares the response body length against both the homepage and the nonsense page. If the body is within 10% of either, it is the same catch-all page and gets filtered out. There is also a content-type check: if /.env returns text/html, it is clearly the SPA serving its shell, not an actual exposed environment file.
Cross-Reference Intelligence
This is the design decision that changed the tool. Instead of just scoring each layer independently, the engine maps visibility data against security data to surface compound gaps.
Example: robots.txt policy is PERMISSIVE (allows all crawlers) and llms.txt status is MISSING (no citation guidance). An SEO tool says the robots.txt is valid. A security scanner says there is no vulnerability. But the cross-reference reveals the actual problem: AI models have full access to scrape your content with zero instructions on how to attribute it.
This layer is qualitative, not scored numerically. It only fires when two conditions from different layers combine to create a gap.
Copy-pasteable fix snippets
Every failing check in the report has a FIX button that drops the exact code to resolve it. Security headers show tabbed snippets for Nginx, Apache, Vercel, and Cloudflare. Schema markup shows complete JSON-LD templates. The llms.txt snippet generates a complete starter file.
I built this because the most common response I got to audit reports was "great, but how do I fix it?" Now the answer is right next to the finding.
The scoring methodology
Published openly on the methodology page. Every weight, every signal, every module. I published it because if you are going to define a standard for AEO and GEO scoring, it needs to be verifiable and challengeable.
What I would do differently
If I were starting over, I would add a headless browser module (Playwright) for JavaScript-rendered sites. The current HTML parser uses server-side fetch, which misses content rendered client-side. That is the biggest gap in the current scan accuracy.
I would also add competitor comparison: scan two domains side by side and diff the results.
Try it
Free, no signup: thecanopyguard.com
The code is not open source yet, but I am considering it. Would love feedback on the scoring methodology, especially the GEO layer.
Adam McClarin, CISSP
Meraki is Love Digital | Soulful Tech

I built a free audit tool that runs 12 checks in parallel against any domain. Here is the architecture.

Adam McClarin — Fri, 22 May 2026 17:53:17 +0000

I spent the past few months building Canopy Guard, a free website audit tool that combines SEO, AEO, and GEO visibility scoring with a full security posture check. One scan, one report, about 15 seconds.
This is the technical breakdown of how it works.
The problem
I audit websites for clients as part of my regular work. Every engagement started with the same routine: run the site through an SEO checker, then a separate security header scanner, then manually check for structured data, then look at robots.txt. Four tools, four tabs, four different report formats, and none of them cross-referenced their findings.
I wanted a single scan that checked everything and surfaced the gaps between visibility and security.
Architecture
The backend is a Node.js Express server written in TypeScript, deployed on Railway. The frontend is a React app on Vercel.
When a user enters a domain, the frontend POSTs to /api/scan on the Railway backend. The backend runs 12 scan modules in parallel using Promise.all:
const [dns, tls, headers, htmlStructure, schema, qa, geo,
crawlRisk, endpoints, links, vulns, bizLogic] =
await Promise.all([
checkDNS(domain),
checkTLS(domain),
checkSecurityHeaders(domain),
checkHTMLStructure(domain),
checkSchemaMarkup(domain),
checkQADensity(domain),
checkGEO(domain),
checkAICrawlRisk(domain),
checkExposedEndpoints(domain),
checkInternalLinking(domain),
checkVulnerabilities(domain),
checkBusinessLogic(domain),
]);
Each module is an async function that fetches specific data from the target domain and returns structured results.
The scan modules
DNS: Resolves the domain via Google's public DNS API (dns.google/resolve). Returns whether the domain resolves and the IP address.
TLS: Checks HTTPS reachability, HSTS header presence and max-age value, and whether HTTP redirects to HTTPS.
Security Headers: Checks for all six critical headers: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy.
HTML Structure: Fetches the full page HTML and parses it for H1 count, meta description presence and length, canonical URL match, and page title.
Schema Markup: Extracts all blocks, parses them, identifies FAQPage and Organization types, and flags structural errors like missing @context. Q&A Density: Strips HTML tags, splits into sentences, and calculates the ratio of question-pattern sentences to total sentences. This measures how "answer engine ready" the content is. GEO: Measures chunking efficiency (how well content divides into ~350-token blocks based on header/paragraph structure), citation precision (ratio of specific data points to generic text), and checks for llms.txt at the domain root. AI Crawl Risk: Fetches robots.txt, classifies the policy as PERMISSIVE/BALANCED/RESTRICTIVE/NONE, checks for AI-specific bot blocks (GPTBot, Anthropic, Google-Extended, CCBot, ByteSpider), and looks for crawl-delay directives. Exposed Endpoints: This one was interesting to build. It probes 12 common sensitive paths (/.env, /.git/config, /graphql, etc.). The tricky part: sites with catch-all redirects return 200 for every path. So the module first fetches a guaranteed-nonsense path to detect catch-all behavior. If detected, it compares each probe's response body length and content-type against the catch-all fingerprint to filter out false positives. Internal Linking: Counts unique internal links on the homepage and samples a few to estimate link depth. Vulnerabilities: Checks server headers for version disclosure and outdated software signatures. Business Logic: Checks for author/publisher attribution markup and cross-references sitemap URLs against homepage links to find orphaned pages. Scoring Each module feeds into a scoring function that normalizes results to 0-1: const seo_score = scoreSEO(htmlStructure, links); const aeo_score = scoreAEO(schema, qa); const geo_score = scoreGEO(geo); const security_posture_score = scoreSecurity( tls, headers, crawlRisk, endpoints, vulns ); The scoring weights are calibrated based on what actually impacts discoverability and security posture. For example, in SEO scoring, crawlability gets the highest weight (0.25) because nothing else matters if bots cannot reach your page. In security scoring, TLS validity (0.15) and security headers (0.25 distributed across 6 headers) carry the most weight. Cross-Reference Intelligence This is the differentiator. After scoring, the report engine maps findings across layers: geo_branch.llms_txt_status vs ai_crawl_risk.robots_policy: If llms.txt is MISSING and robots is PERMISSIVE, flag as CRITICAL. AI scrapers have access with no citation guidance. application_security.exposed_endpoints vs GEO context: If endpoints are exposed, AI RAG parsers can index internal routes from JavaScript bundles. business_logic_gaps.data_provenance_leak vs overall visibility: If content has no attribution markup, AI training sets can ingest without linking back. Lead capture When a user wants their PDF report, they enter their email. The frontend sends the lead data to the Railway backend, which writes it to a Notion database via the Notion API. Name, email, domain, all four scores, full report JSON, and a Status field (New/Reviewed/Booked/Closed). The PDF generates entirely in-browser using a print-ready HTML template opened in a new window. What I would do differently If I were starting over, I would add a headless browser module (Playwright) for JavaScript-rendered sites. The current HTML parser uses server-side fetch, which misses content rendered client-side. That is the biggest gap in the current scan accuracy. I would also add a competitor comparison feature: scan two domains side by side and diff the results. Try it Free, no signup: <a href="https://thecanopyguard.com">https://thecanopyguard.com</a> The code is not open source yet, but I am considering it. Would love feedback on the scoring methodology, especially the GEO layer. Adam McClarin, CISSP Meraki is Love Digital | Soulful TechShareContent{ "$schema": "<a href="https://json-schema.org/draft/2020-12/schema">https://json-schema.org/draft/2020-12/schema</a>", "title": "UnifiedVisibilityAndSecurityAudit", "description": "Data schema for a combined SEO/AEO/GEO optimization and cybersecurity audit report.", "type": "object", "required": [ "audit_id", "target_domain", "timestapastedPlatform at a glance The CNAPP features offered by Singularity™ Cloud Security brings hyper automation and AI into security auditing. The platform offers modules for cloud security posture management (CSPM), cloud detection and response (CDR), and cloud infrastructure entitlement management (CIEM),pasted