DEV Community

Hermes Agent Burned 603M Tokens Behind My Back — I Cut Background Costs by Up to 125x

Azamat Safarov — Tue, 02 Jun 2026 00:03:08 +0000

Last Tuesday I noticed my Ollama Cloud Pro quota draining faster than usual. Way faster. I had burned through 603 million tokens in seven days without understanding where they went.

I opened my Hermes Agent logs and found something I did not know existed: an auxiliary: block with twelve background tasks. Compression, web extraction, vision, session search, skills matching — all running silently every time I typed a message. Every task was set to provider: auto. And because I had no API keys for the fallback chain, every one silently fell back to kimi-k2.6, my one-trillion-parameter main model.

I had no idea this was happening. The agent was sending eleven background prompts to the same model I was actively chatting with, through the same quota, without showing me the prompts. Compression alone fired 10–20 times per long session, each pass sending the full conversation history.

This is what I fixed immediately.

The Fix

Here is what I changed in the auxiliary block of my ~/.hermes/config.yaml. The complete YAML is in the Full Config section below.

Apply with /reset or restart Hermes. Config changes only take effect on new sessions.

If you just want the config and don't care about the story, jump to Full Config below, copy it, /reset, done.

How the Routing Works

Twelve tasks used to collapse into one trillion-parameter model. Now they are distributed across six models, from 8B to 1T.

What `provider: auto` Actually Does

I searched dozens of Hermes guides online. Not a single one mentions the auxiliary block. The official docs describe the YAML structure, but there's no warning that provider: auto silently falls back to your main model. I only found one video by AI Garage discussing this — nothing else. No blog posts, no Discord threads, no Reddit discussions.

The auto chain is: openrouter → new portal → codex → gemini flash. If none of these backends have an API key configured, it falls back to your main chat model.

So while I was typing one message to k2.6, the agent was sending eleven others to the same model through the same quota, without showing me the prompt. Compression alone was firing 10–20 times per long session, sending the full conversation history every time.

My Ollama Cloud Pro Catalog

I have an Ollama Cloud Pro subscription. Here are the models available in my catalog that matter for routing:

Model	Size	Strength	Best for
`kimi-k2.6`	~1T params, 256K context	Reasoning, architecture, debugging	Main chat only
`kimi-k2.5`	~1T params	Same family, optimized for long context	Summarization, compression
`qwen3-vl:235b-instruct`	235B params	Multimodal (vision + text)	Screenshots, image analysis
`deepseek-v4-flash`	~20B params	Fast, good at structured output	Safety checks, classification
`gemma3:12b`	12B params	Lightweight, fast	Triage, profile tasks
`rnj-1:8b`	8B params	Cheapest in catalog	Titles, search, skills matching
`gemma4:e2b`	2B params	Smallest	Not used — too weak for any auxiliary task

I pulled all of these and tested them against the twelve auxiliary tasks. The routing below is the result of that testing.

Twelve Background Tasks

My Hermes version has twelve auxiliary tasks. I ordered them by how much they cost in practice:

#	Task	What it does	Why it costs money
1	`compression`	Summarizes conversation when context exceeds limits	Fires 10–20 times per long session. Each pass sends the full conversation history.
2	`web_extract`	Strips HTML boilerplate after `web_search`	Fires every time you search the web.
3	`vision`	Processes screenshots and images	Multimodal tokens are expensive.
4	`flush_memories`	Writes facts to memory files on `/new` or `/exit`	Runs at every session end.
5	`kanban_decomposer`	Breaks Kanban tasks into steps	Medium complexity, runs on board operations.
6	`curator`	Analyzes skill quality and redundancy	Heavy analysis task.
7	`session_search`	Searches past sessions and summarizes matches	Runs when you look up old conversations.
8	`skills_hub`	Matches your query to installed skills	Runs on most questions.
9	`triage_specifier`	Classifies incoming messages	Binary classification.
10	`approval`	Binary safety check before terminal commands	Simple yes/no on safety.
11	`profile_describer`	Generates profile bio	Rare, lightweight.
12	`title_generation`	Auto-names new sessions	Trivial, runs constantly.

Note: older Hermes versions (like the one in the AI Garage video below) show eight tasks. My version has twelve — four were added in recent updates.

How I Mapped Models to Tasks

The logic is dead simple: put the lightest model that doesn't break on each task, and keep k2.6 for actual conversations.

Task	Model	Why this one
Main chat	`kimi-k2.6`	Architecture, debugging, discussion. The only task that actually needs a trillion parameters.
Compression, web_extract, kanban, curator	`kimi-k2.5`	Same Kimi family, optimized for long context. Summarization quality stays high. Using k2.6 for compression was burning quota for no quality gain.
Vision	`qwen3-vl:235b-instruct`	Only multimodal model in the catalog at this level. No alternative exists for image analysis.
Triage, profile	`gemma3:12b`	12B params vs 1T. Classification and bio generation do not need reasoning depth.
Approval	`deepseek-v4-flash` (~20B)	Binary safety check. Fast response time matters more than reasoning quality.
Titles, search, skills, MCP	`rnj-1:8b`	8B params. 125 times lighter than k2.6. The bulk of the savings are here — these tasks run constantly but need minimal intelligence.

What I Tried First: Local Models

Before settling on cloud routing, I tried running auxiliary tasks locally. I already had gemma4:e2b pulled via Ollama on my machine.

RTX 5070 Ti, 8 GB VRAM. One 6B-parameter model fits. Two is already borderline. Every time Hermes switched from compression to approval, Ollama unloaded one model and loaded another. Five to ten seconds of dead air. The GPU fan kicked in. I lost more time waiting for model swaps than I saved on tokens. I abandoned local auxiliary models the same day.

The Numbers

Here is what the routing actually means in terms of model size:

Task	Before (default)	After (routed)	Reduction
Titles, search, skills, MCP	`kimi-k2.6` (~1T)	`rnj-1:8b` (8B)	125x lighter
Triage, profile	`kimi-k2.6` (~1T)	`gemma3:12b` (12B)	83x lighter
Approval	`kimi-k2.6` (~1T)	`deepseek-v4-flash` (~20B)	50x lighter
Compression, web_extract	`kimi-k2.6` (~1T)	`kimi-k2.5` (~1T)	Same family, frees k2.6 for chat
Vision	`kimi-k2.6` (~1T)	`qwen3-vl` (235B)	Dedicated multimodal model

The video by AI Garage measured compression cost directly: Claude Opus at 50K context = 13 cents per pass. Kimi K2 for the same task = 1.9 cents. That is an 85% reduction for a single compression pass. Compression fires 10–20 times per day for heavy users. The author estimated that with default settings, compression alone can cost $60/month with Claude Opus. Routed to a cheaper model, it drops to $9/month.

I cannot confirm exact dollar savings for Ollama Cloud — they do not expose per-call pricing. But the scale difference is unambiguous.

Current Status

Component	Status	Notes
Heavy auxiliary on k2.5	Working	Compression and web_extract no longer block the main model
Vision on qwen3-vl	Working	Only multimodal option available
Medium tasks on gemma3:12b	Working	Triage and profile classification
Approval on deepseek-v4-flash	Working	Fast binary decisions
Light tasks on rnj-1:8b	Working	Titles, search, skills, MCP
`provider: auto` removed	Done	Explicit provider on every task
Local Ollama auxiliary	Abandoned	VRAM contention on 8 GB laptop
Cost tracking per task	Not possible	Ollama Cloud does not expose per-call pricing

Sessions no longer pause for Compressing messages. The token counter stopped monopolizing k2.6. Quota exhaustion mid-session is gone.

Full Config

Here is the complete auxiliary: block from my ~/.hermes/config.yaml:

auxiliary:
  compression:
    provider: ollama-cloud
    model: kimi-k2.5
    timeout: 120
  web_extract:
    provider: ollama-cloud
    model: kimi-k2.5
    timeout: 360
  kanban_decomposer:
    provider: ollama-cloud
    model: kimi-k2.5
    timeout: 180
  curator:
    provider: ollama-cloud
    model: kimi-k2.5
    timeout: 600
  vision:
    provider: ollama-cloud
    model: qwen3-vl:235b-instruct
    timeout: 120
    download_timeout: 30
  triage_specifier:
    provider: ollama-cloud
    model: gemma3:12b
    timeout: 120
  profile_describer:
    provider: ollama-cloud
    model: gemma3:12b
    timeout: 60
  approval:
    provider: ollama-cloud
    model: deepseek-v4-flash
    timeout: 30
  title_generation:
    provider: ollama-cloud
    model: rnj-1:8b
    timeout: 30
  session_search:
    provider: ollama-cloud
    model: rnj-1:8b
    timeout: 30
    max_concurrency: 3
  skills_hub:
    provider: ollama-cloud
    model: rnj-1:8b
    timeout: 30
  mcp:
    provider: ollama-cloud
    model: rnj-1:8b
    timeout: 30

Try It

If you run Hermes Agent and have never touched the auxiliary block:

hermes config edit

Find auxiliary:. Set explicit provider and model for every task — the one that handles it without dragging extra parameters. Save. Run /reset.

Then tomorrow run hermes insights --days 1. Your main model should stop eating the entire token budget.

If you use Claude or another frontier model as your main provider, the default config is even more expensive — every background task inherits that model. Route them to smaller models. Or go local if your hardware handles it.

What auxiliary routing are you using? Drop it in the comments.

LinkedIn — https://www.linkedin.com/in/azamat-safarov-4a37b93a7/

X / Twitter — https://x.com/Azamat__Safarov

PostgreSQL 0L000 Error: Causes and Solutions Complete Guide

umzzil nng — Tue, 02 Jun 2026 00:03:05 +0000

PostgreSQL Error 0L000: invalid grantor

The 0L000 invalid grantor error in PostgreSQL occurs when a user attempts to grant privileges on a database object without having the proper authority to do so. Specifically, this happens when the grantor does not own the object and does not hold the relevant privilege WITH GRANT OPTION. This error is commonly encountered in complex multi-tenant environments or role-based access control systems where privilege delegation chains are involved.

Top 3 Causes

1. Attempting to Re-Grant a Privilege Without GRANT OPTION

The most frequent cause: a user received a privilege but without WITH GRANT OPTION, and then tries to pass that privilege on to another user.

-- This works: superuser grants SELECT without GRANT OPTION
GRANT SELECT ON TABLE public.orders TO middle_user;

-- This FAILS: middle_user tries to grant to another user
-- ERROR: 0L000 invalid grantor
SET ROLE middle_user;
GRANT SELECT ON TABLE public.orders TO end_user; -- ERROR here
RESET ROLE;

-- Fix: Re-grant WITH GRANT OPTION
RESET ROLE; -- back to superuser
GRANT SELECT ON TABLE public.orders TO middle_user WITH GRANT OPTION;

-- Now this works
SET ROLE middle_user;
GRANT SELECT ON TABLE public.orders TO end_user; -- SUCCESS
RESET ROLE;

2. Non-Owner Granting Privileges on an Object

In PostgreSQL, only the object owner or a superuser can freely grant privileges. A non-owner user without GRANT OPTION cannot issue GRANT statements on that object.

-- Check object ownership
SELECT tablename, tableowner
FROM pg_tables
WHERE schemaname = 'public' AND tablename = 'sales';

-- Non-owner attempting to grant (FAILS)
SET ROLE non_owner_user;
GRANT SELECT ON TABLE public.sales TO analyst; -- ERROR: 0L000
RESET ROLE;

-- Fix: Change ownership or have the owner grant WITH GRANT OPTION
ALTER TABLE public.sales OWNER TO correct_owner;

-- Or, have the owner delegate with grant option
SET ROLE correct_owner;
GRANT SELECT ON TABLE public.sales TO non_owner_user WITH GRANT OPTION;
RESET ROLE;

3. Broken Privilege Chain in Role Hierarchies

When roles are nested, WITH GRANT OPTION is not automatically inherited through the role hierarchy. Each link in the chain must explicitly carry the grant option.

-- Create role hierarchy
CREATE ROLE top_role;
CREATE ROLE mid_role;
CREATE ROLE end_role;

-- Superuser grants to top_role WITHOUT grant option
GRANT SELECT ON TABLE public.reports TO top_role;

-- mid_role is a member of top_role but still cannot re-grant
GRANT top_role TO mid_role;

SET ROLE mid_role;
GRANT SELECT ON TABLE public.reports TO end_role; -- ERROR: 0L000
RESET ROLE;

-- Fix: Rebuild the chain with GRANT OPTION at each step
GRANT SELECT ON TABLE public.reports TO top_role WITH GRANT OPTION;

SET ROLE top_role;
GRANT SELECT ON TABLE public.reports TO mid_role WITH GRANT OPTION;
RESET ROLE;

SET ROLE mid_role;
GRANT SELECT ON TABLE public.reports TO end_role; -- SUCCESS
RESET ROLE;

Quick Fix Solutions

-- 1. Check current grant options on a table
SELECT grantor, grantee, privilege_type, is_grantable
FROM information_schema.role_table_grants
WHERE table_name = 'your_table'
  AND table_schema = 'public';

-- 2. Revoke and re-grant with proper GRANT OPTION (as superuser)
REVOKE ALL ON TABLE public.your_table FROM problem_user;
GRANT SELECT, INSERT ON TABLE public.your_table TO problem_user WITH GRANT OPTION;

-- 3. Grant on all tables in schema with delegation rights
GRANT SELECT ON ALL TABLES IN SCHEMA public TO reporting_role WITH GRANT OPTION;

-- 4. Set default privileges for future tables
ALTER DEFAULT PRIVILEGES IN SCHEMA public
    GRANT SELECT ON TABLES TO reporting_role;

Prevention Tips

Audit grant options regularly. Schedule a periodic query to review which roles hold WITH GRANT OPTION and ensure the privilege delegation structure matches your intended design.

-- Regular audit query
SELECT table_schema, table_name, grantor, grantee, privilege_type, is_grantable
FROM information_schema.role_table_grants
WHERE is_grantable = 'YES'
ORDER BY table_schema, table_name;

Apply the Principle of Least Privilege. Only issue WITH GRANT OPTION when absolutely necessary. Design a clear role hierarchy upfront — document which roles can delegate privileges and to whom — and avoid ad-hoc GRANT statements in production without a review process. Use intermediate roles to keep the permission chain clean and auditable.

📖 Want a more detailed guide?
Check out the full in-depth version (Korean) on oraerror.com — includes detailed analysis, additional SQL examples, and prevention tips.

Oracle ORA-00206 Error: Causes and Solutions Complete Guide

umzzil nng — Tue, 02 Jun 2026 00:01:40 +0000

ORA-00206: Error in Writing Control File – Causes, Fixes & Prevention

ORA-00206 is a critical Oracle database error that occurs when the database fails to write to one or more control files during normal operation. The control file is the most vital binary file in an Oracle database, storing the physical structure metadata including datafile locations, redo log file locations, checkpoint information, and SCN history. Because Oracle continuously updates the control file during database activity, any write failure immediately triggers this error and can lead to a database crash.

Top 3 Causes

1. Disk Space Exhaustion

The most common cause is the filesystem or ASM disk group running out of free space where the control file resides. Oracle's checkpoint process (CKPT) and other background processes continuously write to the control file, so the moment available space is gone, writes fail instantly.

-- Check control file location and size
SELECT NAME,
       BLOCK_SIZE,
       FILE_SIZE_BLKS,
       ROUND(BLOCK_SIZE * FILE_SIZE_BLKS / 1024 / 1024, 2) AS SIZE_MB,
       STATUS
FROM V$CONTROLFILE;

-- Check Fast Recovery Area usage (if applicable)
SELECT SPACE_LIMIT / 1024 / 1024 / 1024 AS LIMIT_GB,
       SPACE_USED / 1024 / 1024 / 1024 AS USED_GB,
       ROUND((SPACE_USED / SPACE_LIMIT) * 100, 2) AS USED_PCT
FROM V$RECOVERY_FILE_DEST;

2. OS-Level Permission or I/O Errors

If the OS file permissions for the control file are changed (e.g., after infrastructure maintenance), or if the underlying storage device experiences hardware I/O errors, Oracle background processes can no longer write to the file. Always check OS-level logs (/var/log/messages) alongside the Oracle alert log.

-- Verify current control file parameter settings
SHOW PARAMETER CONTROL_FILES;

-- Check instance and database status
SELECT INSTANCE_NAME, STATUS, DATABASE_STATUS
FROM V$INSTANCE;

3. Control File Corruption or Accidental Deletion

Accidental deletion via OS commands or physical media failure can corrupt or destroy the control file entirely. Without multiplexing in place, losing a single control file can be catastrophic. This scenario always appears alongside ORA-00202 in the alert log.

-- Query alert log location for investigation
SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Diag Trace';

-- Check all control file statuses
SELECT NAME, STATUS FROM V$CONTROLFILE;

Quick Fix Solutions

Fix 1 – Free up disk space, then restart

-- After reclaiming OS disk space, restart the database
SHUTDOWN ABORT;
STARTUP MOUNT;

-- Confirm control files are accessible
SELECT NAME, STATUS FROM V$CONTROLFILE;

ALTER DATABASE OPEN;

Fix 2 – Restore from multiplexed copy

If one control file is damaged but another copy exists, copy the healthy file to replace the damaged one at the OS level, then restart.

-- After OS-level file copy, mount and open
STARTUP MOUNT;
ALTER DATABASE OPEN;

Fix 3 – RMAN restore (when no valid copy exists)

-- Run in RMAN after connecting to target database
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;

Fix 4 – Recreate from trace backup

-- Recreate control file using a previously generated trace
-- First generate trace (for future use — run this NOW as prevention):
ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS '/backup/ctrl_trace.sql' REUSE;

Prevention Tips

1. Multiplex control files and enable RMAN autobackup

Always maintain at least 3 copies of the control file on separate physical disks. Enable automatic control file backups via RMAN so every structural change is captured.

-- Enable RMAN control file autobackup
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT
  FOR DEVICE TYPE DISK TO '/backup/rman/%F';

-- Add multiplexed control file location (requires restart)
ALTER SYSTEM SET CONTROL_FILES =
  '/u01/oradata/orcl/control01.ctl',
  '/u02/oradata/orcl/control02.ctl',
  '/u03/oradata/orcl/control03.ctl'
SCOPE = SPFILE;

2. Proactive disk monitoring

Set up automated alerts when the filesystem hosting control files exceeds 80% usage. Use Oracle Enterprise Manager, Zabbix, or a scheduled script to catch space issues before they become outages.

-- Include this in your monitoring scripts
SELECT NAME,
       STATUS,
       ROUND(BLOCK_SIZE * FILE_SIZE_BLKS / 1024 / 1024, 2) AS SIZE_MB
FROM V$CONTROLFILE;

Related Oracle Errors

Error Code	Description
ORA-00202	Identifies the exact control file path causing the write failure — always appears with ORA-00206
ORA-00205	Error identifying control file during STARTUP MOUNT phase
ORA-00210	Cannot open the specified control file (file missing or path mismatch)
ORA-27061	Async I/O failure at the OS level, often accompanying storage-related ORA-00206
ORA-00257	Archiver error due to archive log space full, which can indirectly trigger control file write issues

📖 Want a more detailed guide?
Check out the full in-depth version (Korean) on oraerror.com — includes detailed analysis, additional SQL examples, and prevention tips.

View Transitions API: Frontend Animasyonlarında Yeni Standart mı Geliyor?

Erhan AKKAYA — Tue, 02 Jun 2026 00:01:37 +0000

View Transitions API, sayfa geçişlerini daha akıcı ve performanslı hale getiriyor. Modern web uygulamalarında neden öne çıktığını keşfedin.

View Transitions API: Frontend Animasyonlarında Yeni Standart mı Geliyor?

Uzun yıllardır web uygulamalarında sayfa geçişleri ve animasyonlar, kullanıcı deneyimini iyileştirmek için kullanılan önemli araçlardan biri oldu. Ancak bu animasyonları oluşturmak çoğu zaman ek kütüphaneler, karmaşık state yönetimi ve performans optimizasyonları gerektiriyordu. Özellikle React, Next.js ve benzeri framework'lerde sayfa geçişlerini kusursuz şekilde uygulamak her zaman kolay olmadı.

View Transitions API ise bu durumu değiştirmeyi hedefleyen yeni nesil bir web standardı olarak karşımıza çıkıyor. Tarayıcı seviyesinde çalışan bu API sayesinde geliştiriciler, ek animasyon kütüphanelerine daha az ihtiyaç duyarak daha akıcı ve performanslı geçişler oluşturabiliyor.

View Transitions API Nedir?

View Transitions API, bir sayfanın veya kullanıcı arayüzünün mevcut görünümünü yakalayarak yeni görünümle arasında animasyonlu bir geçiş oluşturabilen modern bir tarayıcı API'sidir.

Geleneksel yöntemlerde bir bileşenin eski ve yeni durumları arasında animasyon oluşturmak için JavaScript kodları veya harici kütüphaneler kullanılırken, View Transitions API bu işlemi doğrudan tarayıcı motoruna devreder.

Bu yaklaşımın en önemli avantajı performanstır. Çünkü animasyon süreci tarayıcı tarafından optimize edilir ve geliştiricinin ekstra DOM manipülasyonları yapmasına gerek kalmaz.

Neden Önemli?

Modern web uygulamalarında kullanıcı beklentileri giderek yükseliyor. Kullanıcılar artık yalnızca hızlı çalışan uygulamalar değil, aynı zamanda doğal hissettiren geçişler de bekliyor.

Mobil uygulamalarda yıllardır gördüğümüz:

Kart büyütme animasyonları
Sayfa geçiş efektleri
Paylaşılan öğe animasyonları
Akıcı navigasyon hareketleri

gibi deneyimler artık web tarafında da daha kolay uygulanabiliyor.

View Transitions API'nin öne çıkan avantajları şunlardır:

Daha az JavaScript kodu
Daha yüksek performans
Daha düşük bakım maliyeti
Framework bağımsız kullanım
Tarayıcı optimizasyonlarından doğrudan faydalanma

Geleneksel Yaklaşımın Sorunları

React veya Next.js projelerinde animasyon denildiğinde akla genellikle Framer Motion gibi çözümler geliyor.

Bu araçlar oldukça güçlü olsalar da bazı dezavantajlara sahipler:

Uygulama boyutunu artırırlar.
Karmaşık geçişlerde ek kod gerektirirler.
Navigasyon sırasında state yönetimi zorlaşabilir.
Performans maliyeti oluşturabilirler.

View Transitions API ise birçok temel senaryoda bu ihtiyacı azaltabilecek potansiyele sahip.

Nasıl Çalışıyor?

API'nin temel mantığı oldukça basittir.

Tarayıcı önce mevcut görünümün bir anlık görüntüsünü alır. Daha sonra arayüz güncellenir ve yeni görünüm oluşturulur. Son aşamada ise iki görünüm arasında animasyon uygulanır.

Bu işlem geliştiricinin manuel olarak eski ve yeni DOM durumlarını takip etmesine gerek bırakmaz.

Özellikle liste sayfalarından detay sayfalarına geçişlerde oldukça etkileyici sonuçlar elde edilebilir.

React ve Next.js İçin Ne Anlama Geliyor?

React ekosistemi son yıllarda performans ve kullanıcı deneyimi odaklı önemli değişimler yaşadı.

Server Components, React Compiler ve Actions API gibi yeniliklerin ardından View Transitions API de kullanıcı deneyimi tarafında dikkat çekici bir adım olarak görülüyor.

Next.js kullanan geliştiriciler açısından bakıldığında:

Daha doğal sayfa geçişleri
Daha az üçüncü parti bağımlılık
Daha düşük bundle boyutu
Daha yüksek Lighthouse skorları

gibi avantajlar elde etmek mümkün olabilir.

Özellikle içerik siteleri, portfolyo projeleri, dashboard uygulamaları ve e-ticaret siteleri için önemli fırsatlar sunuyor.

Her Şey Çözüldü mü?

Henüz değil.

View Transitions API oldukça umut verici olsa da tüm animasyon senaryolarını tek başına çözebilecek noktada değil.

Karmaşık etkileşimler, sürükle-bırak sistemleri veya ileri seviye mikro animasyonlar için hâlâ Framer Motion gibi araçlara ihtiyaç duyulabilir.

Ancak birçok günlük kullanım senaryosunda geliştiricilerin daha sade çözümler üretmesine yardımcı olacağı açık.

Sonuç

Web platformu son yıllarda önemli bir dönüşüm geçiriyor. Eskiden yalnızca JavaScript kütüphaneleriyle mümkün olan birçok özellik artık doğrudan tarayıcılar tarafından destekleniyor.

View Transitions API de bu dönüşümün en dikkat çekici örneklerinden biri. Daha akıcı kullanıcı deneyimleri oluşturmayı kolaylaştırırken aynı zamanda performans avantajları sunuyor.

Önümüzdeki birkaç yıl içerisinde React, Next.js ve diğer modern frontend teknolojilerinin bu API'yi daha yoğun şekilde kullanacağını görmek sürpriz olmayacaktır. Geliştiriciler için ise bugünden öğrenmeye değer teknolojilerden biri olduğu kesin.

AI code review is now a cloud workload

Paulo Victor Leite Lima Gomes — Tue, 02 Jun 2026 00:01:22 +0000

Code review used to have a very human scaling problem.

The pull request was ready. The tests were green. Then it sat there waiting for someone with enough context, enough patience, and maybe enough coffee to read it properly.

AI code review changes that queue. GitHub Copilot can review pull requests automatically, and since June 1, those reviews consume GitHub AI Credits. For private repositories, they can also consume GitHub Actions minutes while Copilot prepares the environment and analyzes the code.

This is not surprising. Models cost money. Runners cost money.

But it does make the product category much clearer.

AI code review is not merely a helpful comment bot anymore. It is a cloud workload triggered by your development process.

And cloud workloads need budgets.

the review button is now an infrastructure decision

There is a familiar progression in developer tooling.

At first, a feature feels small and local. Someone enables it. A few people try it. The cost is invisible because the usage is limited and the invoice is mixed into something larger.

Then adoption grows.

Soon, the same feature runs across hundreds of repositories, thousands of pull requests, and multiple review passes per change. A product that felt like an editor convenience becomes an operating expense.

We already learned this with CI.

The first pipeline is cheap. Then every commit runs unit tests, integration tests, security scans, preview deployments, browser tests, and half a dozen checks nobody wants to remove because nobody remembers why they were added.

The pipeline is useful. It is also a bill.

AI review is entering the same phase.

GitHub's new billing model is explicit: code review consumes AI Credits, and private repositories use Actions minutes during the analysis. Organizations can configure a default runner and apply budgets at the user level.

Those controls sound boring.

They are also the part engineering leaders should care about.

review everything is not a strategy

It is tempting to enable AI review everywhere.

Why not? More review sounds better than less review. If the bot catches one security bug, one missing test, or one questionable API change, the entire month might pay for itself.

That is probably true in some teams.

It does not follow that every review is equally valuable.

A ten-line dependency bump and a large authentication refactor should not necessarily receive the same treatment. A generated documentation change may not need an AI reviewer. A risky database migration probably deserves more than one automated pass and a quick human approval.

Once reviews are metered, the policy questions become unavoidable:

Which repositories should request AI review by default?
Which pull requests should trigger it automatically?
Should generated changes receive the same review budget as human-written changes?
How many review rounds are useful before the comments become noise?
What runner size is actually necessary for each repository?
Which teams are spending more because their codebase is harder to analyze?

These are not finance-only questions.

They are architecture and engineering-management questions expressed through a bill.

cost attribution is a useful forcing function

I do not think metering is automatically bad.

Free-looking infrastructure has a way of hiding bad habits. A budget can force a team to decide what it actually values.

If one repository uses far more AI review credits and runner minutes than another, there may be a good reason. Maybe it is a critical service. Maybe the diffs are complex. Maybe the team is using the reviewer as an extra security layer.

Or maybe every tiny pull request is triggering an expensive workflow because nobody looked at the defaults.

The useful outcome is not minimizing the bill at all costs. The useful outcome is understanding what the bill represents.

CI minutes can tell you that your tests are too slow, too broad, or too flaky. Cloud spend can tell you that an architecture is chatty, over-provisioned, or poorly cached. AI review spend can reveal that your workflow is asking a model to examine a lot of low-value changes.

Cost is architecture feedback.

the other bill is reviewer attention

There is a second cost that will not appear on the GitHub invoice.

Every AI review comment asks a human to spend attention.

Some comments will be useful. Some will be technically correct but irrelevant. Some will identify a real concern without understanding why the code looks strange. Some will confidently suggest a cleaner implementation that quietly breaks an ugly but important edge case.

That means the cheapest AI review is not always the best one.

A review that costs a few credits but creates ten minutes of distraction for two engineers is expensive in a different way. Multiply that across a large organization and the bigger problem may be signal quality, not model usage.

This is why "number of AI review comments" is a terrible success metric.

The metrics I would want are more practical:

How often does an AI comment lead to a code change?
Which categories of comments are consistently useful?
How often are comments dismissed as noise?
Does AI review reduce human review time or add another review queue?
Does it catch defects that tests and static analysis missed?
Are teams starting to rubber-stamp reviews because a bot already looked at the diff?

The goal is not more comments.

The goal is better changes reaching production with less wasted attention.

keep humans in the uncomfortable parts

AI review is good at broad, patient inspection.

It does not get bored reading the fifth similar file. It can notice missing error handling, suspicious patterns, inconsistent tests, and changes that deserve a second look. It can give a pull request author feedback before a human reviewer arrives.

That is useful.

But the highest-value review questions are usually uncomfortable and contextual:

Is this the right change for the system?
Does the abstraction make future incidents easier or harder to debug?
Are we preserving an API contract that is not documented anywhere?
Is the migration plan realistic under production load?
Is this complexity necessary, or did we create it because the generated code looked plausible?

Those questions need judgment.

The AI reviewer can help surface evidence. It should not become a reason to skip the conversation.

what i would do this week

If your organization uses Copilot code review, I would treat the June 1 billing change as a good excuse to inspect the workflow before the invoice does it for you.

Start with visibility. Check which repositories use automatic reviews, which runners they use, and how frequently reviews run. Put a budget in place, even if it is generous. A budget is an alerting mechanism before it is a restriction.

Then sample the output.

Take a few weeks of review comments and classify them. Useful defect catch. Helpful suggestion. Style preference. Duplicate of an existing check. Wrong. Ignored.

You do not need a complicated dashboard on day one. A spreadsheet and an honest conversation will tell you more than a vanity metric.

Finally, decide where AI review belongs in the pipeline.

Maybe it runs automatically on critical services. Maybe authors request it before asking for human review. Maybe small dependency bumps skip it. Maybe security-sensitive changes get a more deliberate policy.

The correct answer will depend on the codebase.

That is the point.

the punchline

AI code review is becoming infrastructure.

It consumes model credits. It can consume runner minutes. It generates operational data. It needs defaults, budgets, and a reason to exist in each workflow.

That does not make it less useful.

It makes the engineering conversation more honest.

"Let the AI review everything" sounds like a productivity strategy until every pull request spends compute and every comment spends attention.

The teams that get value from AI review will not be the teams with the most automated comments.

They will be the teams that know which reviews are worth paying for.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

I Tested DeepSeek V4 Flash and GPT-4o Side by Side — Here's the p99 Latency Truth

eagerspark — Tue, 02 Jun 2026 00:01:09 +0000

I gotta say, let me tell you a story about the time I almost went bankrupt optimizing for the wrong metric.

It was 3 AM, and my multi-region deployment was melting down. The p99 latency on our GPT-4o integration had spiked to 8 seconds during a traffic burst. Our auto-scaling group was spinning up instances like a slot machine on fire, and our monthly AI API bill was about to eclipse our AWS spend. Meanwhile, our startup competitor was shipping features twice as fast, paying 97% less per token, and sleeping through the night.

That's when I realised: the conventional wisdom about AI API selection is broken. Most cloud architects focus on model performance benchmarks. But in production, it's not about which model scores 0.2% higher on MMLU — it's about throughput, SLA compliance, multi-region failover, and the hidden cost of provider lock-in.

Here's what I learned after stress-testing 12 different AI providers across three continents, and why the "just go direct to the provider" advice is the fastest way to destroy your p99 SLAs.

The Startup Trap: Why "Free Tier" Is the Most Expensive Mistake

Every startup founder I've met says the same thing: "We'll just use DeepSeek's API directly. It's cheap, right?"

Wrong on three levels.

Level 1: The Registration Nightmare
I spent four hours trying to register for a DeepSeek account. Chinese phone number? Don't have one. WeChat Pay? My startup doesn't accept payments through a social media app. Alipay? Same problem. By the time I gave up, I'd burned more engineer-hours than the API credits I was trying to save.

Level 2: The Single-Region Trap
DeepSeek's direct API runs out of one region. When that region goes down — and it will — your p99 latency doesn't degrade gracefully. It goes to infinity. I've seen it happen during Chinese New Year, during network maintenance windows, during random Tuesday afternoons. Without multi-region failover baked into your routing layer, you're betting your uptime SLA on a single datacenter's reliability.

Level 3: The Credit Expiration Surprise
That "cheap" $10 pre-purchase? It expires in 30 days. If your startup's traffic ramps slowly (which it should — you're iterating), you're paying for idle capacity. That's not cost optimization. That's burning cash in a bonfire.

Here's the p99 reality check: I benchmarked direct DeepSeek vs. routing through Global API's auto-failover layer. Direct provider had 99.9% uptime in their home region — when that region was healthy. Global API's multi-region routing delivered 99.99% effective uptime because it transparently hit whichever provider had the lowest p99 latency at that moment.

Scenario	Direct DeepSeek p99	Global API Routed p99
Home region healthy	350ms	320ms
Home region degraded	4,200ms	480ms (auto-failover)
Home region down	Timeout	520ms (fallback provider)
Traffic burst (10x)	2,100ms + throttling	680ms (auto-scaled capacity)

The direct provider saves you $0.05 per million tokens on the base price, but costs you 10x in engineering time and 100x in p99 SLA risk. That's not an API choice — that's an architectural decision.

The Enterprise Overhead Problem: Why Your $50,000/Month Bill Is Overengineered

Now let me tell you about the other end of the spectrum. Two years ago, I architected a system for a Fortune 500 financial services company. The security team required SOC2, ISO 27001, dedicated capacity, and a 99.99% SLA. The compliance team needed a data processing agreement (DPA) that covered 17 regulatory frameworks. The procurement team wanted Net-90 invoice terms.

We signed a direct contract with a major provider. Annual commitment: $600,000. Onboarding time: 8 weeks. Custom integration work: 6 weeks of engineer time.

And you know what? When we finally went live, 80% of our traffic was routine customer support queries that could have been handled by a $0.25/M token model.

The problem with enterprise-grade AI procurement is that you're paying for peak capacity. You're buying a dedicated fleet of GPUs to handle Black Friday traffic spikes, but those GPUs sit idle 90% of the time. You're paying a premium for SLA guarantees that your actual workloads don't need.

Here's what I do now for enterprise deployments: I use a tiered architecture.

import time
import random
from openai import OpenAI

class TieredAIModelRouter:
    def __init__(self):
        self.default_client = OpenAI(
            api_key="ga_pro_xxxxxxxxxxxx",
            base_url="https://global-apis.com/v1"
        )
        self.premium_client = OpenAI(
            api_key="ga_pro_yyyyyyyyyyyy",
            base_url="https://global-apis.com/v1"
        )

    def route_request(self, prompt, priority="standard"):
        """
        Route based on priority and current p99 latency.
        Standard: use default model with auto-failover.
        Premium: use dedicated capacity with SLA guarantee.
        """
        if priority == "premium":
            return self._call_premium(prompt)

        # Standard routing with automatic fallback
        try:
            start = time.time()
            response = self.default_client.chat.completions.create(
                model="deepseek-ai/DeepSeek-V4-Flash",  # $0.25/M tokens
                messages=[{"role": "user", "content": prompt}],
                timeout=2.0  # 2-second p99 target
            )
            latency = time.time() - start

            if latency > 1.5:  # Degraded performance
                # Auto-failover to next provider
                response = self.premium_client.chat.completions.create(
                    model="Pro/deepseek-ai/DeepSeek-V4-Flash",  # Dedicated capacity
                    messages=[{"role": "user", "content": prompt}]
                )
            return response

        except Exception as e:
            # Fallback to premium if default fails
            return self.premium_client.chat.completions.create(
                model="Qwen/Qwen3-32B",  # $0.28/M, different provider
                messages=[{"role": "user", "content": prompt}]
            )

    def _call_premium(self, prompt):
        return self.premium_client.chat.completions.create(
            model="Pro/deepseek-ai/DeepSeek-R1",  # $2.50/M, guaranteed capacity
            messages=[{"role": "user", "content": prompt}]
        )

This architecture costs us $12,000/month instead of $50,000/month — and our p99 latency is actually better because we're not over-provisioning. The dedicated capacity only gets hit for the 10% of requests that genuinely need it. Everything else routes through the shared pool with auto-failover.

The Hybrid Architecture That Actually Scales

After running production AI workloads across 37 regions and 5 continents, here's the architecture that doesn't suck:

Layer 1: Default Model (80% of traffic)

Model: DeepSeek V4 Flash
Cost: $0.25/M input tokens
Provider: Routed through Global API with automatic failover
p99 Latency Target: 500ms
SLA: Best-effort, but effective 99.9% via multi-region routing

Layer 2: Mid-Tier Fallback (15% of traffic)

Model: Qwen3-32B
Cost: $0.28/M input tokens
Provider: Different provider (avoids correlated failures)
p99 Latency Target: 1 second
SLA: 99.5% guaranteed

Layer 3: Premium Tier (5% of traffic)

Model: DeepSeek R1 or GPT-4o
Cost: $2.50/M input tokens
Provider: Dedicated capacity with SLA
p99 Latency Target: 200ms
SLA: 99.99% guaranteed

The key insight: your p99 doesn't care about the model's benchmark score. It cares about the routing layer's ability to failover within milliseconds, the provider's regional availability, and your auto-scaling group's response time.

I've benchmarked this against single-provider architectures. The hybrid setup delivers:

3x lower p99 latency during peak hours
2x better cost efficiency (pay for dedicated capacity only when needed)
100x improvement in effective uptime (no single point of failure)

The Cost Reality: Why Startups Shouldn't Pay Enterprise Prices

Let me show you the math that convinced me to stop signing annual provider contracts.

Growth Stage	Monthly Token Volume	Direct GPT-4o Cost	DeepSeek V4 Flash via Global API	Savings
MVP (100 users, iterating)	5M tokens	$50.00	$1.25	97.5%
Beta (1,000 users, learning)	50M tokens	$500.00	$12.50	97.5%
Launch (10K users, stabilizing)	500M tokens	$5,000.00	$125.00	97.5%
Growth (100K users, scaling)	5B tokens	$50,000.00	$1,250.00	97.5%

The 97.5% savings doesn't come from the model itself. It comes from not over-provisioning. When you go direct to a premium provider, you're buying capacity for peak load. When you route through a multi-provider layer, you're buying capacity from the most cost-efficient provider at each moment.

And here's the thing that keeps me up at night: that $50,000/month GPT-4o contract? It doesn't include the cost of multi-region deployment, auto-scaling infrastructure, or failover engineering. You're still paying for that separately.

The Pro Channel Trade-Off: When You Actually Need Dedicated Capacity

I'm not anti-enterprise. I run enterprise workloads. Sometimes you genuinely need dedicated capacity.

When I architect for a regulated industry (healthcare, finance, defense), I use the Pro Channel. Here's the difference:

Standard API (for 95% of workloads):

Shared inference capacity
Best-effort routing
Community support
Pay-as-you-go credits (never expire)
184 models available

Pro Channel (for the 5% that matters):

Dedicated GPU instances
99.9% uptime SLA with penalties
24/7 priority support with 15-minute response
Custom data processing agreements
Invoice billing (Net-30)
Queue priority during peak hours

# Pro Channel example — same API endpoint, different backend
import os
from openai import OpenAI

pro_client = OpenAI(
    api_key=os.getenv("GLOBAL_API_PRO_KEY"),
    base_url="https://global-apis.com/v1"
)

# This call goes to dedicated capacity, not the shared pool
response = pro_client.chat.completions.create(
    model="Pro/deepseek-ai/DeepSeek-V3.2",
    messages=[
        {"role": "system", "content": "You are a compliance officer."},
        {"role": "user", "content": "Review this financial document for regulatory issues."}
    ],
    timeout=30.0  # Enterprise SLA requires this
)

# Check if we hit dedicated capacity
print(f"Response latency: {response.usage['total_time']:.2f}s")
print(f"Model used: {response.model}  # Should show 'Pro/deepseek-ai/DeepSeek-V3.2'")

The Pro Channel costs more per token — but it's still 60-70% cheaper than a direct enterprise contract because you're not paying for idle capacity. You pay for what you use, but with guaranteed throughput.

My Production Playbook: What I Actually Deploy

After burning through $200,000 in AI API costs on failed experiments, here's what I deploy today:

For startups (under $10,000/month AI spend):

One Global API key
Auto-route between DeepSeek V4 Flash (default) and Qwen3-32B (fallback)
No dedicated capacity
Credits never expire (this saved my startup during a 3-month pivot)
184 models available for experimentation

For enterprises (over $10,000/month or regulated):

Pro Channel for mission-critical workloads
Standard API for everything else
Multi-region routing with automatic failover
Custom SLA with 99.9% uptime guarantee
Dedicated engineer for onboarding

The one rule I never break: Never trust a single provider. Not even the big ones. I've seen AWS go down, Azure go down, OpenAI go down, DeepSeek go down. Your routing layer should treat every provider as ephemeral.

The Bottom Line

The AI API market in 2026 is mature enough that you don't need to choose between "cheap and unreliable" or "expensive and locked in." The technology exists to have both — if you architect for it.

Stop optimizing for model performance. Start optimizing for p99 latency, multi-region availability, and cost efficiency across your entire stack.

And if you want to skip the 8-week onboarding and just start routing traffic with auto-failover built-in, check out Global API. I'm not saying it's the only option — but after testing 12 providers across 37 regions, it's the one I deploy in production. Your infrastructure should be boring, reliable, and cost-effective. That's not a product pitch. That's a production reality.

Now go fix your p99 latency. Your users are waiting.

Web accessibility overlays don't work — here's what actually does

Vaibhav Jain — Tue, 02 Jun 2026 00:00:06 +0000

Accessibility overlay services like accessiBe and UserWay market themselves as a one-click fix for ADA compliance. They promise that a single line of JavaScript will instantly make your website accessible to users with disabilities, protecting you from lawsuits overnight.

The reality is that these overlays are a band-aid on a broken foundation. They inject a visual widget and attempt to patch accessibility issues in the browser, but they never touch the underlying source code. Screen readers and assistive technologies still encounter improperly nested headings, missing form labels, and non-semantic markup that automation cannot reliably interpret.

What screen reader and keyboard users actually need is clean, semantic HTML. That means proper heading hierarchy, accurate ARIA usage only when native semantics aren't enough, real focus management that doesn't trap users or lose their place, and full keyboard navigability without requiring a mouse. These are structural changes that happen at the code level, not in a browser-layer script.

The only real path to WCAG compliance is a manual audit performed by people who use assistive technologies every day, followed by source-code remediation. At OnlyEnable, we do exactly that: we review your site manually, identify the barriers that actual users face, and fix the code itself rather than masking the symptoms.

If you're serious about making your site truly accessible — not just legally defensible — start with the source. Learn more about how we help teams build inclusive digital experiences at OnlyEnable.

Fixed Before Anyone Notices, Stronger After Every Fix: Self-Healing + Recurrence Prevention (Series Part 4)

Ryosuke Tsuji — Mon, 01 Jun 2026 23:57:25 +0000

Hi, I'm Ryan, CTO at airCloset.

Disclaimer: "cortex" in this article is the internal codename for an AI platform built in-house at airCloset. It is unrelated to existing commercial services like Snowflake Cortex or Palo Alto Networks Cortex.

In Part 3 I covered AI reviewing AI PRs -- the auto-review pipeline that defends quality at the PR stage.

This post is the other side: defending quality in production, via Self-Healing. A production alert fires, an AI investigates it, opens a fix PR, the PR goes through the same auto-review pipeline from Part 3, gets auto-merged and auto-redeployed. And the same fix PR is required to add a new Guide -- whether that's a lint rule, CI guard, type constraint, or guideline update -- so the same anti-pattern gets auto-rejected from then on. The guardrails grow every time.

"Incidents get fixed automatically" is catchy on its own, but on its own it's probably not enough in the long run. You have to close the recurrence class while you fix the incident -- self-healing plus self-strengthening -- before the quality gates start to compound over time.

Start with last month's numbers

115 Self-Healing PRs merged in the past 30 days.

Effectively all of them merged and deployed without human involvement.

Humans only step in when the AI judges "this is not something code can fix."

That's the current state of "incident response" at cortex.

Don't read "115 = 115 user-impacting incidents" though. Roughly:

About half (54) are Deploy Failed-style alerts -- CI / Pulumi deploy step caught a failure, the AI absorbed it before it shipped to production. Recently the [Recurrence] loop (covered later) has been piling up countermeasures here, so this bucket is trending down anecdotally
The remaining 61 are production-runtime alerts (Service Error Log Detected / Pipeline Failure / Generator Failure etc.) -- the service is running in production, but an error-log threshold or consecutive-failure threshold tripped. The AI absorbed them before they propagated to user impact

So it's less "incident response" than "production anomalies that monitoring caught, fixed 115 times by AI before anyone woke up." The number of incidents humans actually have to acknowledge is in the low single digits per month.

There's also a clear pattern of the same service firing repeatedly (e.g. gcs-transformer is 25 of the 61) -- which is exactly what the [Recurrence] loop covered later is supposed to eliminate by turning into lint or type gates. That's the back half of this post.

One more honest note: the recent month's number is slightly inflated. The codebase had a fair number of "silent catch" patterns -- catch blocks that swallow exceptions without logging anything. We added the no-silent-catch lint rule and swept the existing silent catches in batches, which exposed previously hidden production errors as alerts. So part of the spike is "monitoring caught up to reality." Once the [Recurrence] loop converts these into lint over time, the number should converge. "Things we couldn't see, we can see now" is a quality improvement -- what we're seeing is the catch-up phase.

One more thing worth saying: doing this by hand is utterly unsustainable. Running 115 manual cycles of "ack alert -> read logs -> context switch -> understand the code -> fix -> open PR -> review -> deploy" would bankrupt any team's engineering bandwidth. The system absorbs them without anyone noticing, and converts the fix into a new Guide (lint / CI guard / type constraint / guideline) at the same time -- that's the actual subject of this post.

The moment an alert fires, the AI starts an investigation, traces Loki / Product Graph / git blame to root cause, opens a fix PR, runs it through the auto-review from Part 3, APPROVE -> auto-merge -> auto-redeploy. One full loop.

Series

#	Theme	Key scene	Article
1	Series intro: cortex harness	PRs merging unattended / incidents fixed before anyone notices	ai-harness-intro
2	Product Graph (cpg)	Code / docs / DB / infra unified into one graph	cortex-product-graph
3	Auto PR review	webhook -> AI review -> auto-fix -> squash merge	cortex-auto-review
4	Self-Healing + observability + auto-added guardrails	Alert -> AI investigates -> fix PR + new lint/type gate -> auto redeploy + same pattern auto-rejected from then on	This article ← you are here
5	Scaling the harness from cortex to toC services	Non-engineer contributions in practice + scaling cortex's harness to the whole product org	Coming soon
6	Series wrap-up	The underlying philosophy (what was given up, what was kept, why this design) plus a retrospective on the failures and lessons	Coming soon

Big picture -- the three layers: Observation, Repair, Strengthening

For Self-Healing to work, you need an Observation layer in front and a Strengthening layer (recurrence prevention) behind it. Self-Healing itself is the middle Repair layer. The "self-healing + self-strengthening" loop only spins up when all three are in place.

Prerequisites: The three layers only stand up on top of two prior pieces: cpg (the unified code / docs / DB / infra knowledge graph from Part 2) and the Observability stack covered in this post.

No Observability -> the observation layer is empty, nothing gets detected -> the repair layer never even fires

No cpg -> the AI cannot see "where else does this trap exist" -> the repair layer does symptom-level patching at best, and the strengthening layer's horizontal expansion stops working

Put differently: trying to copy this setup without those two will just multiply incidents. An AI that blindly looks at error logs and rewrites production code is just speeding up the rate at which gh pr create ships accidents. cpg and Observability are the minimum bar for being able to delegate auto-repair to AI.

Note also that cortex is a several-hundred-thousand-line codebase, and at that scale loading the whole codebase as AI context is impossible for the AI as well (let alone for a human). Tell the AI to trace impact with just grep and file reads, and it'll run out of context window before it finds anything. cpg is what lets it ask "which other code does this function's change ripple into" and get the answer in one hop. Small repos may not need this. Past a certain scale, cpg is not optional, it's required.

In Fowler's Guides / Sensors terms from Part 1, cpg and Observability are the substrate that supports both Guides (pre-execution controls like lint) and Sensors (post-execution gates like auto-review and Self-Healing). Observability feeds Sensors via firing alerts; cpg feeds the Guides side by supplying the auto-review with impact-scoping context. Neither belongs on one side only -- they're foundational to both, and Self-Healing and auto-review only function on top of this substrate. That's the structural claim this post is built around.

Layer	Role	Key components
Observation	Real-time detection of production anomalies	OTel SDK / Loki / Mimir / Tempo / Faro / Grafana / Pino logs with trace_id
Repair	AI receives the alert, investigates root cause, opens a fix PR, auto-review, auto-merge, auto-redeploy	Event Relay -> SSE -> `self-healing` mode script -> claude -p (worktree) -> gh pr create
Strengthening	The fix PR is required to add a new Guide (lint / CI guard / type constraint / guideline). The same anti-pattern can't reach production again	`@cortex/eslint-plugin-graph` (26 rules), `scripts/check-*.ts` (13 guards), `recurrence-prevention.md`, the `[Recurrence]` lens of auto-review

I'll walk through them in order.

Observation -- where do the alerts come from?

cortex's production observability is built on Grafana Cloud + OpenTelemetry:

OTel SDK (the shared @cortex/otel package) -- every service calls initOtel({ serviceName }) at its entry point. Trace / metric / log all go out via OTLP to Grafana Cloud
Loki (logs) -- Pino structured logs get trace_id automatically. trace and log are cross-referenced
Mimir (metrics) -- Cloud Run / pipeline / Gemini API token usage, etc.
Tempo (traces) -- distributed tracing
Faro (frontend) -- captures browser JS errors / performance / network failures
Grafana -- dashboards + Alert Rules + Notification Policy

We also have a strict definition of log levels, anchored on business impact:

Level	Definition	Examples
`warn`	Business-foreseeable, does not need immediate action (retryable / self-recovers).	Search query returned 0 results, optional field unset, short retry due to rate limit
`error`	Data recovery / re-run will definitely be needed afterward. Impact expected to be under 20%.	"User record that should exist isn't there," BigQuery insert failure, per-record enrichment failure
`fatal`	The feature as a whole fails for 20%+ of requests. Service-continuity broken, fatal config missing, full upstream outage.	OTel init failure, required secret missing at startup, full input data source outage for a pipeline

The key point is to not pick the level mechanically based on the exception class name like NotFoundError. Same "record not found" situation: "this record must exist and doesn't" is error / fatal; "user search returned 0 hits" is warn. The level is decided by business impact -- "does this require data recovery later," "is the whole feature down" -- not by the type. Without this discipline you simultaneously get monitoring fatigue and missed critical incidents. Self-Healing reacts mainly to error-threshold trips; fatal is the human-escalation side.

Alert Rules are managed declaratively in Pulumi, grouped by service into categories like BOT / Pipeline / Transformer / Generator / Gemini / CI / Deploy / Service Catch-All. When we add a new service, one line in infra code spins up the dashboards and alerts automatically.

This is "the infrastructure that lets the AI see the same things humans see." Self-Healing picks up alerts coming off this stack.

What Observability can't catch, Self-Healing can't fix either

Honest disclaimer: Self-Healing can only react to what the observation layer can detect as an anomaly. "Observability is everything" is literally true here.

What the current stack catches is roughly logic-level errors -- exceptions, error logs, deploy failures, external-API call failures, threshold-based metric anomalies.

What it doesn't catch:

UI errors -- the logic ran, no error logs, but the screen shows something different from intent / shows the wrong value. Faro catches client-side JS exceptions and network failures, but "the logic ran and the output is just wrong" never fires an alert
Silent data corruption -- aggregated values slowly drift, bad values get into a table. Unless it crosses a threshold or schema check, nothing detects it
Perceived UX degradation -- requests feel slow, the UX feels off. Only catchable once SLO / latency thresholds trip

So Self-Healing is "AI replacing the human in the loop for incidents the observation layer can catch." The coverage of the observation layer itself is the prerequisite. Holes in observation stay as blind spots that neither auto-review nor Self-Healing reaches.

This isn't really a limitation of Self-Healing -- it's the importance of growing the observation stack, which cortex keeps investing in continuously. (From Part 1, Observability is one of the "supporting foundations" beneath the flywheel.)

Repair -- the Self-Healing flow

MODE=self-healing runs the same webhook-server script as the auto-review setup from Part 3, but listening for Grafana firing alerts.

The textual flow looks like:

[Grafana Alert Rule firing]
   ↓ POST /webhook/grafana
[Event Relay (in-house)] -- persisted in Firestore
   ↓ SSE push (event: grafana-alert)
[self-healing mode script]
   ↓ throttle check (same fingerprint skipped for 4h)
   ↓ 👀 reaction in Slack to signal "I'm on it"
   ↓ git worktree add -b hotfix/auto-alert-{service}-{ts} origin/main
   ↓ run claude -p inside the worktree
     - search related code via Product Graph MCP
     - pull error logs from Loki via Grafana MCP
     - identify root cause and fix
     - update tests as needed
     - conventional commit
   ↓ git push + gh pr create
[fix PR]
   ↓ auto-review (the Part 3 pipeline)
   ↓ APPROVE -> auto-merge -> auto-redeploy
[recovered]
   ↓ ✅ in the Slack thread

What happens when the AI judges "this is not fixable in code"

Not every alert is fixable by code. The implementation has a rule: "if you judge it unfixable, exit without changing anything." In that case Slack gets a notification of the form "This alert cannot be addressed in code. Investigation: ..." -- including what the AI investigated.

Worth clarifying on the numbers side: the headline 115 is "Self-Healing runs that reached PR-created -> merged -> deployed." This "unfixable, exit clean" case is a separate bucket, happening several times a month (external transient outages, infra / config issues that aren't code, cases too complex for the AI to judge confidently). The "humans show up" bucket is this separate one -- it isn't a "some of the 115 failed" failure rate.

Here's what a real Slack message looks like (a styling-pattern-watch-transformer case where the GitHub PAT had expired):

ℹ️ This alert cannot be addressed in code. Investigation:

Investigation summary

Checked the error logs in Loki for the past hour. The single error source for styling-pattern-watch-transformer right now is expiration / revocation of the GitHub PAT (Personal Access Token).

What I found

The BQ snapshot pipeline is healthy: 7 consecutive [BQ] Snapshot rows inserted successes. The earlier autodetect type-drift problem was resolved in an earlier PR that put SAFE_CAST(... AS INT64) in place.

The single ongoing error (multiple occurrences in the past hour): GithubUnauthorizedError: GitHub API /commits/master unauthorized (401): PAT likely expired/revoked -- the /check-drift handler returns 401 every time Cloud Scheduler invokes it.

Root cause

The GitHub PAT held in Secret Manager for this service has expired or been revoked. The code already classifies the 401 with a dedicated GithubUnauthorizedError and is already sending the "PAT needs rotation" notification to Slack. The detection / notification design on the code side is working as intended.

Resolution: exit without changes

This is an external-credential operational issue (PAT expiry), and what needs to happen is a human rotates the PAT in Secret Manager. Not the kind of incident code can resolve. Therefore: no code change, no commit, no PR.

Operator actions:

Add a new version of the target secret in GCP Console / Secret Manager with a valid PAT (repo scope, read access to the target repository)

No Cloud Run revision redeploy needed (secretKeyRef version:latest is referenced)

At this level of detail, "what was investigated, why code can't fix it, what the human should do" all come out in one Slack message. Open the thread and the operator can act immediately. The productivity gap vs. "alerts just forwarded blindly" is significant.

Deduplication

A throttle ensures the same fingerprint (Grafana's unique alert identifier) is not re-processed for 4 hours. Without this, alerts that fire again before the fix PR has merged would spawn another worktree, another fix PR, and so on -- an easy infinite loop.

We also permanently skip any alertname containing credential. Credential incidents carry leakage risk if the AI touches them, so they're explicitly escalated to humans.

Self-Healing and Part 3 auto-review -- "the fixer AI" and "the reviewer AI" are independent

This is the most consequential design choice of the agent setup, so calling it out explicitly.

PRs opened by Self-Healing are not special PRs, just fix PRs. They go through the Part 3 auto-review pipeline under exactly the same conditions -- the 9 lenses (Graph / Architecture / Security / Test / Doc / Impact / Observability / AI-Antipattern / Recurrence) get checked in order. Critical / Major findings -> REQUEST_CHANGES; Nit-only / no findings + CI green -> APPROVE -> auto-merge.

The important bit: this is not a monolithic "AI fixing AI" loop. The fixer-side AI and the reviewer-side AI are fully independent:

Different process, different session: the self-healing-mode AI and the reviewer-mode AI are launched as separate claude -p processes. They do not share context
Different input sources: the fixer builds the problem from Grafana alert + Loki + cpg. The reviewer judges from the PR diff + cpg + review guidelines
Different objectives: the fixer is optimizing for "stop the incident." The reviewer is judging "does this violate the 9 lenses or the severity contract?" A deliberate separation of concerns where the two roles' incentives are intentionally misaligned

As a result, PRs the fixer dashed off get blocked by the reviewer (REQUEST_CHANGES -> back to the fixer). The AI does not approve its own output. "Just-make-it-work" fixes don't get through.

This is the often-debated review-independence problem in LLM-agent operation, solved here in the obvious way: split the work across separate agents.

A concrete example: meet subscription's 409 ALREADY_EXISTS

Take the alert from the Google Meet recording auto-fetch service I covered in the Meeting Intelligence post. On 2026-05-21, Self-Healing opened a fix PR titled fix(meet-subscription-renewal): auto-fix for Service Error Log Detected.

The trigger error from Loki:

Workspace Events API request failed: 409 Conflict
"Subscription associated with the resource already exists."

How the AI investigated:

Pinned the error in Loki -- ran {service_name="meet-subscription-renewal"} | json | level=~"ERROR|error|Error" via Grafana MCP, picked up the Failed to renew Meet subscription stack trace
Traced the call path in Product Graph -- identified renewSubscriptions -> createMeetSubscription
Cross-referenced past PRs -- the "opposite-direction inconsistency" (name in Firestore but missing from Google = 404) had already been self-healed in another PR with patchMeetSubscriptionTtl -> null fallback. The current direction (still on Google's side but missing from Firestore = 409) was the gap
Verdict: "the same pattern may exist elsewhere" -- a [Recurrence] decision matrix "horizontal expansion required" case

Instead of a quick patch, it implemented the same-direction self-healing symmetrically to the opposite-direction fallback that was already there:

Made createMeetSubscription idempotent
If POST returns 409, extract the existing Subscription name from the response and call patchMeetSubscriptionTtl
The caller writes the return value back into Firestore, so the next renewal converges to the normal PATCH path (self-healing)
Per the existing graph/no-silent-catch lint, JSON.parse failures are also logger.warn + serializeError for structured logging
Three tests added

This is what "Self-Healing pushing all the way to root cause and rolling the fix out horizontally" looks like in practice. "Close the recurrence class, don't just suppress the symptom" (the spirit of recurrence-prevention.md) executed autonomously by the AI.

Strengthening -- Guides (lint + guidelines) grow automatically

This is the layer that keeps Self-Healing from being just "auto-repair."

In Fowler's Guides / Sensors terms from Part 1, the Strengthening layer is the place where Guides grow -- i.e. the pre-execution controls that prevent AI from deviating in the first place. cortex's Guides come in two flavors:

Machine-read Guides: lint / type / CI guard / coverage thresholds / Prettier -- enforced at commit / CI time
Human-and-AI-read Guides: guidelines like recurrence-prevention.md, severity.md, ai-antipattern.md, etc. -- used as decision criteria by auto-review

The 9 lenses, severity contract, and no-downgrade rules from Part 3 are the latter; the auto-added lints in Part 4 are the former. Together they form the Guides surface. Lints are "formalized guidelines," guidelines are "lints that haven't been formalized yet."

The Sensors side -- Self-Healing and auto-review -- grow these Guides every time they run:

Self-Healing's root-cause investigation finds "the same pattern exists elsewhere" -> demands horizontal expansion + a new lint (= new Guide)
Auto-review's [Recurrence] lens blocks PRs that fix without adding lint
Both depend on cpg to see impact scope across the codebase

cpg is what lets the AI ask "where else does this trap exist." Self-Healing and auto-review (= the Sensors side) share cpg as a substrate, and each run thickens Guides by one notch.

What happens every time Self-Healing runs (the recurrence-prevention-first flow)

Every fix PR Self-Healing opens is checked for [Recurrence] by auto-review. The decision matrix:

Situation	Required action	Form
Same trap stepped on 2+ times	Lint required (custom ESLint rule / type constraint / CI guard)	Machine (new Guide)
Pattern may exist elsewhere	Horizontal expansion required (cpg traversal for similar nodes, fix all of them in this PR)	Investigation + fix
Cannot be machine-checked but worth formalizing	Add to an existing guideline	Guideline entry
One-off, no value in formalization	Nothing (bug fix only)	--

When the "stepped on 2+ times" situation applies, the fix PR can't merge without a new lint included. So every Self-Healing run produces:

Horizontal expansion via cpg -- not just the immediate fix target, every similar node enumerated
A new Guide added in the same PR -- ESLint custom rule / type constraint / CI guard / guideline entry, one of the four
All existing violations cleared in the same PR -- no warn-as-deferral, error on first introduction
Auto-review -> auto-merge -> auto-redeploy -- the regular Part 3 pipeline
Going forward, writing the same pattern gets mechanically rejected by CI / lint -- the recurrence class is structurally closed

"Add the guard while you fix the bug" runs as a self-sustaining loop driven by Self-Healing.

"We'll do it later" and "introduce as `warn`" are banned

A couple of important contract clauses from the guidelines:

"Plan to lint later," "lint when we refactor," "another PR will handle this" -- all banned. If it can be addressed in this PR, it must be
"Existing violations remain, so introduce as warn and promote to error later" -- not accepted. This is deferral in disguise. The responsibility for the warn->error promotion goes nowhere and the rule rots
If you add a lint rule, fix all existing violations in the same PR and ship at error

These extend the no-downgrade rules from Part 3 -- preempting the typical escape hatches.

The "step on it, mechanize it" lineage

Custom Guides currently piled up in cortex:

graph/no-silent-catch (ESLint) -- the source of the "inflated number" mentioned in the intro. Bans catch blocks that swallow exceptions
Stacktrace-preservation guideline (codified as a Major violation in observability.md, caught by auto-review) -- forbids logger.error(err.message) style logs that drop the stack and keep only the message string. Forces the err field to hold serializeError(error) so name / message / stack are preserved as structured fields. Observability is everything here, so logs that drop stack info are treated as inherently broken
cortex-quality/require-fetch-timeout (oxlint -- a Rust-implemented JS/TS lint that runs ESLint-compatible rule sets, dozens of times faster than ESLint due to the Rust impl. cortex uses oxlint for the standard ruleset and ESLint for custom rules that need AST-level work) -- mandates signal: AbortSignal.timeout(...) on external fetch calls. Born from a case where a no-timeout fetch hung indefinitely and triggered a Cloud Tasks redelivery storm
graph/no-bq-string-timestamp-param (ESLint) -- from a case where passing TIMESTAMP as a string to a BigQuery query parameter NULLed the value out through a serializer bug and silently failed every INSERT
graph/require-firestore-ignore-undefined (ESLint) -- forces ignoreUndefinedProperties: true on new Firestore(). From a case where a single NULL row caused a 100% failure rate in a sync batch
check-otel-env-injection (CI guard) -- the recurrence prevention for the Cloud Run OTel env injection case below
TypeScript type tightening (type level) -- tighter function signatures, branded types for ID disambiguation, exhaustive discriminated unions, etc. Patterns that can't be lint-caught but are catchable at the type level get closed from the type side

These aren't textbook-learnable rules -- they're "stepped on once, then mechanized." The number of traps the organization has stepped on translates directly into the number of Guides piled up (across ESLint / oxlint / CI guard / types).

How does the AI write a lint rule without breaking it?

Three structural things keep this sane:

Existing rules are the template: packages/eslint-plugin-graph/src/rules/ already holds 26 custom rules, each as .ts + .test.ts pairs. New rules follow the same shape, so the AI never has to write the AST-walking boilerplate from scratch
Tests first: violation / pass fixtures go into .test.ts first, implementation fills in TDD-style. Coverage threshold (90% statements + branches) is gated by the Part 3 auto-review, so a lint without tests cannot merge
lint / type / CI guard sit in the same "mechanize" bucket: the decision matrix in recurrence-prevention.md groups lint / type constraint / CI guard together as the "lint-required" row, and leaves the choice within that bucket (write it as a lint? express it at the type level? add a separate CI guard?) to the AI based on how much AST work is involved and whether runtime semantics matter. Traps that need AST inspection but actually hinge on runtime behavior usually end up as a type constraint (branded type / discriminated union / signature tightening) rather than a custom lint

So "AI writes a lint rule" is supported by existing rule corpus + the test harness + the mechanize-bucket selection criteria -- three together. The path where the AI hand-rolls raw ESLint API and bricks something is structurally closed.

A concrete example: Cloud Run OTel env injection -> promoted to CI guard

Multiple services hit this trap: when a Cloud Run Service / Job is defined in Pulumi, forgetting to inject OTEL_EXPORTER_OTLP_ENDPOINT and GRAFANA_CLOUD_API_KEY via secretKeyRef causes OTel init to be skipped in production, no trace/log reaches Grafana, and incidents become silently invisible.

The normal response would be "we'll be more careful next time." At cortex:

Incident surfaces -> Self-Healing opens a fix PR (adds the env injection to the affected service)
Auto-review's [Recurrence] decides "same trap stepped on -> lint required"
The same PR adds scripts/check-otel-env-injection.ts (CI guard) -- mechanically asserts OTel env injection across all Cloud Run resource definitions under infra/
All other existing services get their env injection added in the same PR
Merge -> deploy -> any future write of the same kind gets rejected by CI

That's what "the guardrails grow every time Self-Healing runs" looks like in practice. The trap is "stepped on -> mechanically checked from then on."

Where Guides stand right now (in numbers)

Snapshot of cortex's Guide inventory:

Category	Count	Notes
Custom ESLint rules (`@cortex/eslint-plugin-graph`)	26	`no-silent-catch` / `require-firestore-ignore-undefined` / `no-bq-string-timestamp-param` etc.
CI guards (`scripts/check-*.ts`)	13	`check-otel-env-injection` / `check-cloudscheduler-oidctoken-audience` etc.
Standard oxlint rules (set to `error`)	183	Base config ships everything at error
TypeScript strict gates (baseline)	9	`strict` / `noImplicitAny` / `strictNullChecks` / `noUncheckedIndexedAccess` etc.
TypeScript type tightening (per-recurrence)	grows over time	branded type / discriminated union / function-signature tightening etc. Patterns that can't be lint-caught but can be type-caught are closed from the type side
Test coverage thresholds	statements + branches 90%	Uniform across all packages
Prettier	1 config	Format auto-fix
Guidelines	the entire review-guidelines repo	Used as the decision basis by auto-review

The first two categories plus the type-tightening row -- Custom ESLint, CI guard, type tightening -- are the part that compounds over time through the [Recurrence] lens every time Self-Healing or auto-review runs. The guardrails grow with time. That's the substance of the Strengthening layer.

The whole loop, from the top

When you compose the three layers:

[production anomaly] -> Observation layer (OTel/Loki/Grafana) -> Alert firing
                                              ↓
                                       Event Relay -> SSE
                                              ↓
[Self-Healing mode script]
   - claude -p in worktree
   - root cause via cpg + Loki + git blame
   - commit fix
   - (if applicable) add new lint / type gate too
   - gh pr create
                                              ↓
[Auto-review (Part 3)] -- 9 lenses in order, especially [Recurrence] forces
                         recurrence-prevention action (lint / horizontal expansion / guideline entry)
                                              ↓
                          APPROVE + CI green
                                              ↓
[auto-merge -> Turborepo build -> Pulumi parallel deploy]
                                              ↓
[production recovered + same anti-pattern mechanically rejected from now on]

The loop completes without human intervention. Not just repair, but the quality gates that grow with every repair -- that's the "auto-recovery + auto-strengthening" substance at cortex.

That said, as the front of the article spelled out, the loop is only viable because cpg and Observability exist. cpg makes horizontal expansion possible; Observability turns production anomalies into structured data. With those two in place at the foundation, AI can stand on the side that does Repair and Strengthening. Self-Healing is not a standalone mechanism. It's a Sensor riding on top of cortex's Guides (cpg + Observability + lint + guidelines). That's the single most important framing in this post.

Self-Healing by the numbers

Breaking the headline down further.

Main firing categories

What kicked off Self-Healing in the past 30 days (with the mapping back to the front-of-post 2 buckets):

Category	Bucket
Service Error Log Detected (most frequent)	Production-runtime (61 side)
Pipeline Failure -- data pipeline failing a configured number of times in a row	Production-runtime (61 side)
Generator Failure -- AI generation jobs (embedding / annotation etc.) failing	Production-runtime (61 side)
Deploy Failed -- deploy step failures (Pulumi up / Cloud Run revision failed)	Deploy step (54 side)

Alert-firing to production-recovery time

Median 30 minutes to 1 hour. Roughly:

Alert firing -> AI investigation start: under 1 minute (Event Relay + SSE)
AI investigation + fix + PR open: 3-8 minutes
Auto-review (including the Part 3 10.8 review-fix iterations on average): 20-45 minutes
Auto-merge + deploy: 3-10 minutes

Many of these finish before anyone wakes up (alert fires early morning -> by the time people come in, there's just a ✅ in Slack).

What changed / Bridge to Part 5

We've now covered the cortex picture across Parts 1-4:

Part 1: the cortex big picture and harness-engineering framing
Part 2: Product Graph (cpg) -- the AI's "brain"
Part 3: auto-review -- defending quality at the PR stage
Part 4 (this post): Self-Healing + Observability + auto-added guardrails -- defending quality in production while growing the quality gates themselves

The engineering role has shifted, over the last half-year, from "write, review, fix, merge, deploy, incident-respond" -- all of that -- toward looking at the whole system from above and tuning it. human-on-the-loop, working at the Policy layer.

That said, this is a pattern that solidified inside cortex, the internal AI platform. Carrying the same pattern into real consumer-facing toC services (multiple services, multiple stacks, multiple teams) requires changes and additions.

Part 5 will cover scaling cortex's harness to the whole product organization -- the roadmap and the thinking. The first half is the actual operation of "non-engineers opening PRs into cortex" with its limits; the second half is the elements needed to extend the pattern to toC services (service-specialized review rules, the human understanding-of-AI-design process, IaC for test environments, etc.).

"cortex built the pattern, toC services run that pattern at an order-of-magnitude-larger scale" -- that's the Part 5 positioning.

The actual series wrap-up is Part 6. The center of it is the underlying philosophy -- why I picked this design, what I gave up, what I kept. Alongside that, since the series so far has been mostly "what's working," I want to look back at the failures and dead ends behind that surface, and the gap between the philosophy and the implementation. A retrospective for myself, and -- hopefully -- a reference for anyone starting down a similar path.

What Is an AI Agent Harness?

Collin Wilkins — Mon, 01 Jun 2026 23:56:41 +0000

This is for people trying to understand the infrastructure around large language models: Claude Code, Codex, Cursor, LangGraph, MCP servers, repo instructions, permissions, hooks, and all the agent plumbing that has popped up.

The short answer:

The model is the brain. The harness is the operating environment that makes the brain useful.

Or shorter:

Models generate answers. Harnesses generate trust.

Start with the agent

At the simplest level, an AI agent is a model inside a loop:

You give it a task
The model thinks about what to do
It answers or calls a tool
The tool does something
The result goes back to the model
The loop repeats until the task is done

That loop can be a few dozen lines of code or a whole product with permissions, memory, tools, logs, tests, and UI around it. The loop is the seed. The harness is what makes it safe and useful in real work.

Same model, different results

The easiest mistake with agents is blaming the model for everything. Sometimes the model really is the problem but it often isn't.

The same model and task can produce different output because agents are probabilistic plus the environment changes what the model sees, what it can do, how it gets checked, and when it is allowed to stop.

One setup produces a clean pull request, runs the tests, catches the edge case, and leaves a useful summary.

While another edits the wrong file, forgets the project conventions, says "done" without verification, and hands you a pile of slop.

A better model can help, a better harness narrows the variance.

Model vs. agent vs. harness

People blur these words together, so separate them first.

Term	Plain-English meaning	Example
Model	The brain that predicts, reasons, and writes	Claude, GPT, Gemini
Agent	The model plus a loop that lets it act	Claude Code fixing a bug
Harness	The system around the agent that guides and checks the work	Instructions, tools, memory, tests, hooks
Tool	Something the agent can use	Shell, browser, file search, calculator, MCP server
Memory	Context that survives beyond one prompt	`CLAUDE.md`, `AGENTS.md`, project memory, handoff notes

If you only remember one line:

A model thinks. An agent acts. A harness keeps the agent from acting like an idiot.

A harness is not a framework

A framework helps humans assemble agents. LangGraph, LangChain, and similar tools give you graphs, state, nodes, tool bindings, memory, middleware, and routing. You can use those pieces to build a harness.

But the framework itself is not automatically the harness.

A harness is the working environment around the agent. It runs the loop, exposes tools, injects project context, enforces permissions, verifies outputs, and keeps useful memory.

That distinction matters. If you buy or build a framework, you still own the harness design. If you use Claude Code, Codex, Cursor, or Windsurf, you are already working inside a harness. The question is how well it fits your codebase, risk tolerance, and workflow.

The simplest harness you already know: CLAUDE.md

Claude Code is a useful doorway into this idea because the harness is visible.

Every serious Claude Code setup has a CLAUDE.md file or the cross-tool version AGENTS.md. Anthropic's docs describe memory as persistent instruction Claude reads at the start of a session. It carries commands, structure, standards, workflow preferences, and recurring mistakes.

That is harness work.

Your CLAUDE.md isn't the agent or the model. It is one guide inside the harness.

A good one feels like a brief you would give a sharp contractor before they touched your codebase:

# CLAUDE.md

## Project
One sentence on what this project does and who uses it.

## Commands
- Dev: `npm run dev`
- Build: `npm run build`
- Type check: `npx tsc --noEmit`

## Architecture
- `src/lib/services/` - business logic
- `src/components/` - UI components

## Rules
- Never commit `.env` files or secrets
- Make minimal changes and avoid unrelated refactors
- Run type check after code changes
- Static export only, no server-side features

## Workflow
- Ask before making architectural changes
- Run tests before saying the task is done
- When unsure, explain the tradeoff

That file doesn't impact model intelligence. It makes the environment stricter and gives the model fewer ways to wander off.

The harness decides what context the model gets, what it can touch, how it proves the work, and what survives after the session ends.

What a harness actually does

A harness has two jobs:

Help the agent get it right the first time
Catch problems early enough that the agent can correct itself

Martin Fowler's framing is useful here. He splits a harness into guides and sensors.

Piece	What it does	Examples
Guides	Shape the agent before it acts	`CLAUDE.md`, `AGENTS.md`, skills, tool descriptions, project docs
Sensors	Check the agent after it acts	tests, linters, type checks, screenshots, review agents
Memory	Carries forward what should survive the session	project memory, handoff notes, session recaps, index files

Guides steer the agent before it acts. Sensors tell you whether the work held up. Memory is the notebook for future reference. A useful harness needs all three.

Pay attention to the last arrow. A harness controls how the agent acts this time and how the next run starts a little less cold.

The architecture underneath

Once you move past the simplest version, a modern harness starts to look like a small control plane.

The Arize primer frames nine pieces as one system: loop, context, tools, system prompt assembly, permissions, hooks, persistence, built-in skills, and sub-agent management.

That is what makes this more than prompt engineering. A prompt can ask the model to be careful. A harness can route the model through checks, permissions, and recovery paths that make care more likely.

The best harnesses push judgment to the model and keep control in the system. The model decides which files to work on. The harness decides whether it is allowed to modify them.

Same model, better harness

This is not just semantics.

LangChain published a useful example in February 2026. They kept the model fixed and changed the harness around their coding agent. The score moved from 52.8 to 66.5 on Terminal Bench 2.0.

A better harness improved the same model by roughly 14 points.

The changes included better prompts, tool setup, verification middleware, trace analysis, and loop detection. That is the pattern teams should steal.

Don't start by asking, "Which model will solve this?" Ask, "What does the model need around it to do this reliably?"

A simple example

Say you ask an agent to fix a failing test. Without much harness, the session often looks like this:

The model reads your prompt
It scans a few files
It changes some code
It rereads its own code
It says "done"

That sounds fine until you notice the missing step: it never ran the tests.

With a basic harness, the flow changes:

The agent starts and loads the project instructions
It sees the commands, conventions, and files that matter
It changes the code
The harness tells it to run the test command before exiting
If tests fail, the agent keeps going
When it finishes, it writes a short handoff note

The minimum viable harness

For most teams, a minimum viable harness has four layers:

Layer	Small version	Why it matters
Instructions	`CLAUDE.md` or `AGENTS.md`	The agent knows the project before you re-explain it
Tools	One or two tools it actually needs	The agent can act instead of only talk
Verification	Test, lint, type check, screenshot, review pass	The agent has to prove the work
Memory	Handoff note, index file, project memory	The next session doesn't start cold

That is already a harness. Keep it simple - the point is reliability, not complexity.

What this looks like in an engineering org

For an enterprise team, the harness becomes part of engineering operations. It's a shared operating agreement:

A repo-level AGENTS.md or CLAUDE.md with architecture, commands, boundaries, and review expectations
A small approved tool set: search, edits, shell, browser, test runner, docs lookup
Permission modes for read-only work, workspace edits, and dangerous actions
Hooks that block secrets, destructive commands, production credentials, or unreviewed deploy paths
Verification gates that make the agent run the same checks a human engineer would run
Session notes that explain what changed
A small eval set of real tasks that shows whether the harness is getting better or just louder

How to write the instruction file

The blunder with CLAUDE.md is treating it like a wish list.

"Be a senior engineer."

"Think step by step."

"Write clean code."

Fine, but mostly wasted space. Use the file for things the agent would otherwise get wrong:

Critical commands: build, test, lint, type check, run one file.
Architecture map: where things live and what belongs where.
Hard rules: the specific mistakes the agent must not make.
Workflow preferences: when to ask, act, change, and verify.
Out of scope: files, systems, or integrations the agent should not touch.

Keep it short.

Anthropic's current memory docs emphasize hierarchy, imports, recursive lookup, and specific instructions over vague guidance. A CLAUDE.md shapes behavior. It does not physically prevent bad actions.

For enforcement, you need settings, permissions, tests, hooks, or human review. That is the difference between a guide and a guardrail.

Where tools fit

Tools are the agent's hands.

They let the model search files, run commands, query APIs, calculate, open a browser, read a spreadsheet, or edit a document.

The common mistake is thinking more tools equals a smarter agent. Usually it means a more confused one. Tool-selection accuracy drops from around 43% to under 14% as the tool count grows, and every tool definition spends roughly 300-1,400 tokens whether it gets used or not.

Start with the smallest tool set that can do the job. Rewriting probably needs no tools. Fixing a bug needs file access and a test command. Researching current prices needs web search or an API.

One tool should have one clear job.

Bad:

manage_files(action, file, destination, overwrite, format, permissions)

Better:

read_file(path)
write_file(path, content)
delete_file(path)

Tool design is part of the harness.

Where memory fits

Memory is where people make this sound harder than it needs to be. There are two simple versions: what has been said in this session, and what should survive across sessions.

Early on, longer-term memory can be boring markdown:

what changed
what is still broken
what command to run next
what the next session should not repeat

That can live in a handoff note, an INDEX.md, a session recap, or a project memory file. In my note system, the agent reads an index, topic map, and CLAUDE.md before touching anything.

Not glamorous. Useful.

Workflows before agents

Not every problem needs a fully autonomous agent.

Anthropic makes a useful distinction: workflows follow predefined code paths, while agents dynamically decide their process and tool use. If the steps are predictable, use a workflow:

write outline
check outline
write draft
review draft

If the steps are not predictable, use an agent:

inspect this unfamiliar codebase
figure out why the tests fail
decide which files to change
verify the fix

Start with the simplest pattern that works. Most useful setups begin as workflows and only become agents when the model genuinely needs to choose the path.

When multiple agents make sense

Start with one agent and a good harness. Multiple agents make sense when the roles are meaningfully different:

one researches, one writes
one implements, one reviews
one can read sensitive data, one can execute actions
one routes tasks, specialists handle narrow domains

If the second agent doesn't have a different job, permission set, or evaluation role, you probably added complexity for vibes. The safer pattern is a supervisor:

User -> Main agent -> Specialist agent only when needed -> Verification

There is one multi-agent pattern worth knowing early: separate the builder from the judge.

Anthropic Labs described this in their long-running application harness: planner, generator, evaluator. The generator built. The evaluator inspected the result with Playwright, graded it, and sent feedback into the next sprint.

The principle scales down:

Small setup	Bigger setup
Write code, then run tests	Generator builds, evaluator tests in browser
Ask a second agent to review	Dedicated evaluator grades each sprint
Write a checklist before starting	Planner and evaluator negotiate what "done" means

The point is not "use three agents." The point is: don't let the same session that made the thing be the only judge.

What not to overbuild

Don't turn your first harness into a platform. Start with one job, one agent, one clear instruction file, one or two tools, one verification step, and a few test prompts. Then watch where it fails. When the same failure repeats, tweak the harness, iterate.

The practical build path

If you want to build your first harness today:

Write one sentence describing the agent's job.
List the tools it truly needs (follow least privilege!)
Write the rules it must follow.
Define the output format.
Add one verification step.
Test it on five real examples.
Add memory only when the next session needs something from this one.

You can ask an LLM to help:

I want to build an AI agent.

Goal:
[what I want it to do]

Example user requests:
[5 messy examples]

Tools it may use:
[web search / files / calculator / custom API / none]

Rules it must follow:
[non-negotiables]

It must never:
[boundaries]

Please turn this into an agent spec, system prompt, minimal tool list, verification checklist, and 10 test cases.

The formula is simple:

Agent = Role + Goal + Tools + Rules + Output format
Harness = Instructions + Tools + Verification + Memory

That is enough to start.

Takeaway

A harness is the setup around an agent that makes its work more reliable.

It isn't just an SDK or just a prompt. It isn't just CLAUDE.md.

It is the operating environment: instructions, tools, tests, memory, permissions, hooks, recovery paths, and feedback loops.

The model gives you capability. The harness decides whether you can trust it.

Some of the harness is durable: verification discipline, context preparation, running tests before calling something done. Some is scaffolding that dissolves as models improve. Know which half you're building on.

Typescript - several sub-projects + schemas (VTS)

Stefan Werfling — Mon, 01 Jun 2026 23:54:36 +0000

TypeScript - Several Sub-projects

Introduction

Everyone has probably reached a point where a project is so large that it needs to be broken down into parts. In this article I want to show how I structure larger TypeScript projects as a monorepo with several sub-projects that share the same data types and validation logic.

The basic idea is simple: extract everything that is used in more than one place into its own package. The remaining parts of the application then depend on this shared package. With TypeScript's project references and npm workspaces, this can be done without a heavy build tool - plain tsc is enough.

Project Architecture

The structure I keep coming back to looks like this:

myproject/
├── package.json          # root: defines workspaces + dev-deps
├── tsconfig.json         # optional: root references
├── schemas/              # shared types, enums, validators
├── core/                 # plugin system, shared runtime code
├── backend/              # server-side application
└── frontend/             # client-side application (browser)

schemas - pure types, enums, interfaces and (in my case) vts validators. No runtime logic, no I/O.
core - plugin contracts and runtime helpers that both backend and frontend might need.
backend - the Node.js server. Depends on schemas and core.
frontend - the browser application. Depends on schemas (and optionally core).

All sub-projects share the same data shapes via schemas, which means a single change to a DTO is picked up by every consumer the next time they are compiled.

Main Project Setup

I start with an empty directory and create the root package.json:

cd myproject
nano package.json

Root package.json:

{
  "name": "myproject",
  "version": "1.0.0",
  "description": "MyProject is ...",
  "scripts": {
    "compile": "cd ./schemas/ && npm run compile && cd ../core/ && npm run compile && cd ../backend/ && npm run compile"
  },
  "keywords": [],
  "author": "Stefan Werfling",
  "license": "MIT",
  "workspaces": [
    "schemas",
    "core",
    "backend",
    "frontend"
  ],
  "devDependencies": {
    "@stylistic/eslint-plugin-ts": "^3.0.0",
    "@types/node": "^22.15.18",
    "@typescript-eslint/eslint-plugin": "^8.21.0",
    "@typescript-eslint/parser": "^8.21.0",
    "eslint": "^9.19.0",
    "eslint-plugin-import": "^2.31.0",
    "eslint-plugin-prefer-arrow": "^1.2.3",
    "npm-check-updates": "^18.0.1",
    "typescript": "^5.7.3"
  }
}

A few notes on this file:

The workspaces array tells npm to treat the four sub-folders as linked packages. After a single npm install in the root, every sub-project can import from every other sub-project as if it were published to a registry.
The order in which the npm packages are installed is also very important, and we must compile everything in this order: schemas → core → backend (the frontend has its own build pipeline, see below).
The devDependencies are hoisted, so the same TypeScript / ESLint versions are used everywhere - no risk of "works on my machine".

Now run:

npm install

This creates the root node_modules/ with symlinks for myproject_schemas, myproject_core, etc. once those packages exist.

Schemas Sub-project

The schemas package is the foundation. It contains only types, enums, interfaces and validators - no business logic, no I/O. Anything that is needed by more than one sub-project lives here.

Directory structure:

mkdir schemas
cd schemas
mkdir src
mkdir dist

schemas/package.json:

{
  "author": "Stefan Werfling",
  "dependencies": {
    "vts": "git+https://github.com/OpenSourcePKG/vts.git"
  },
  "devDependencies": {
    "@stylistic/eslint-plugin-ts": "^3.0.0",
    "@types/node": "^22.15.18",
    "@typescript-eslint/eslint-plugin": "^8.21.0",
    "@typescript-eslint/parser": "^8.21.0",
    "eslint": "^9.19.0",
    "eslint-plugin-import": "^2.31.0",
    "eslint-plugin-prefer-arrow": "^1.2.3",
    "typescript": "^5.7.3"
  },
  "keywords": [],
  "main": "dist/index.js",
  "name": "myproject_schemas",
  "scripts": {
    "build": "npm run compile",
    "compile": "tsc --project tsconfig.json",
    "npm-check-updates": "npm-check-updates"
  },
  "type": "module",
  "types": "dist/index.d.ts",
  "version": "1.0.0",
  "exports": {
    ".": {
      "import": "./dist/index.js",
      "require": "./dist/index.js",
      "types": "./dist/index.d.ts"
    }
  }
}

schemas/tsconfig.json:

{
  "compilerOptions": {
    "composite": true,
    "declaration": true,
    "tsBuildInfoFile": "./../.cache/schemas.tsbuildinfo",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "importHelpers": true,
    "module": "NodeNext",
    "outDir": "dist",
    "rootDir": "src",
    "removeComments": true,
    "sourceMap": true,
    "strict": true,
    "target": "ES2022"
  },
  "include": [
    "src/**/*"
  ]
}

The two important flags here are:

"composite": true - marks the package as a referenceable TypeScript project. Other packages can now list it under references in their own tsconfig.json and benefit from incremental builds.
"declaration": true - emits the .d.ts files that the consumers will pick up via the types field of package.json.

A common pitfall: import paths

If outDir, main, types and exports are not aligned, IDEs (especially WebStorm/IntelliJ) generate the wrong import path on auto-complete. You will see this:

import {BehaviouralStatesResponse} from 'myproject_schemas/dist/index.js';

…where you actually want this:

import {BehaviouralStatesResponse} from 'myproject_schemas';

The fix is to make sure all four locations point at the same file:

field in `package.json`	value
`main`	`dist/index.js`
`types`	`dist/index.d.ts`
`exports["."].import`	`./dist/index.js`
`exports["."].types`	`./dist/index.d.ts`

…and that outDir in tsconfig.json is dist. Once those four match, auto-import resolves to the bare package name.

`schemas/src/index.ts`

Everything you want to share is re-exported from a single barrel file:

export * from './Behavioural/BehaviouralStatesResponse.js';
export * from './User/User.js';
export * from './User/UserRole.js';
// ...

Note the .js extension on the import path even though the source file is .ts - this is required by "module": "NodeNext" and saves you a lot of headache later when the package is consumed from an ESM context.

Core Sub-project

The core package sits between schemas and the application sub-projects. I use it for things that are not pure data but are still shared - plugin contracts, base classes, small utilities, error types, logging.

core/package.json:

{
  "name": "myproject_core",
  "version": "1.0.0",
  "author": "Stefan Werfling",
  "type": "module",
  "main": "dist/index.js",
  "types": "dist/index.d.ts",
  "exports": {
    ".": {
      "import": "./dist/index.js",
      "require": "./dist/index.js",
      "types": "./dist/index.d.ts"
    }
  },
  "scripts": {
    "build": "npm run compile",
    "compile": "tsc --project tsconfig.json",
    "npm-check-updates": "npm-check-updates"
  },
  "dependencies": {
    "myproject_schemas": "*"
  },
  "devDependencies": {
    "typescript": "^5.7.3"
  }
}

The "myproject_schemas": "*" dependency works because of npm workspaces: npm symlinks the local schemas/ into core/node_modules/myproject_schemas. No publishing, no npm link, no rebuild gymnastics.

core/tsconfig.json:

{
  "compilerOptions": {
    "composite": true,
    "declaration": true,
    "tsBuildInfoFile": "./../.cache/core.tsbuildinfo",
    "module": "NodeNext",
    "outDir": "dist",
    "rootDir": "src",
    "strict": true,
    "target": "ES2022"
  },
  "include": [
    "src/**/*"
  ],
  "references": [
    { "path": "../schemas" }
  ]
}

The references block is what makes this a true project-reference build. Running tsc -b in the root walks the dependency graph and only rebuilds what actually changed.

A typical core file then looks like:

import {User, UserRole} from 'myproject_schemas';

export interface UserService {
    findById(id: string): Promise<User | null>;
    hasRole(user: User, role: UserRole): boolean;
}

The type comes from schemas, the interface stays in core.

Backend Sub-project

The backend is a plain Node.js application. The interesting part is that it can consume both schemas and core as if they were normal packages.

backend/package.json:

{
  "name": "myproject_backend",
  "version": "1.0.0",
  "author": "Stefan Werfling",
  "type": "module",
  "main": "dist/index.js",
  "scripts": {
    "build": "npm run compile",
    "compile": "tsc --project tsconfig.json",
    "start": "node dist/index.js",
    "npm-check-updates": "npm-check-updates"
  },
  "dependencies": {
    "myproject_schemas": "*",
    "myproject_core": "*",
    "express": "^4.21.0"
  },
  "devDependencies": {
    "@types/express": "^4.17.21",
    "typescript": "^5.7.3"
  }
}

backend/tsconfig.json:

{
  "compilerOptions": {
    "composite": true,
    "declaration": true,
    "tsBuildInfoFile": "./../.cache/backend.tsbuildinfo",
    "module": "NodeNext",
    "outDir": "dist",
    "rootDir": "src",
    "strict": true,
    "target": "ES2022"
  },
  "include": [
    "src/**/*"
  ],
  "references": [
    { "path": "../schemas" },
    { "path": "../core" }
  ]
}

And a route that uses the shared types:

import express from 'express';
import {BehaviouralStatesResponse} from 'myproject_schemas';

const app = express();

app.get('/api/behavioural/states', (_req, res) => {
    const response: BehaviouralStatesResponse = {
        states: [],
        statusCode: 200
    };

    res.json(response);
});

app.listen(3000);

Because the response type is defined once in schemas, the frontend can import the exact same shape and you get end-to-end type safety without a code-generation step.

Frontend Sub-project

The frontend is where the setup deviates a little, because the browser does not understand NodeNext modules and you usually want a bundler in front of it. I use Vite here, but the same approach works with webpack or esbuild.

frontend/package.json:

{
  "name": "myproject_frontend",
  "version": "1.0.0",
  "author": "Stefan Werfling",
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview"
  },
  "dependencies": {
    "myproject_schemas": "*"
  },
  "devDependencies": {
    "typescript": "^5.7.3",
    "vite": "^5.4.0"
  }
}

frontend/tsconfig.json:

{
  "compilerOptions": {
    "module": "ESNext",
    "moduleResolution": "Bundler",
    "target": "ES2022",
    "lib": ["ES2022", "DOM"],
    "strict": true,
    "jsx": "preserve",
    "isolatedModules": true,
    "noEmit": true
  },
  "include": [
    "src/**/*"
  ],
  "references": [
    { "path": "../schemas" }
  ]
}

Two things differ from the Node sub-projects:

"moduleResolution": "Bundler" - tells TypeScript that some external tool (Vite) will resolve the imports.
"noEmit": true - the bundler emits the final JavaScript, tsc is only used for type-checking.

A component then consumes the shared schema exactly like the backend does:

import {BehaviouralStatesResponse} from 'myproject_schemas';

async function loadStates(): Promise<BehaviouralStatesResponse> {
    const res = await fetch('/api/behavioural/states');
    return res.json();
}

If you change a field in schemas/src/Behavioural/BehaviouralStatesResponse.ts, both the Express handler and the fetch call above turn red in the IDE on the next save. That single feedback loop is, for me, the main reason for going through the monorepo setup in the first place.

Build Order and Project References

There are two ways to build everything:

Sequential - the simple compile script in the root package.json. It just cds into each folder and runs tsc. Works for small projects.
Project references - run tsc -b (build mode) in the root, with a root tsconfig.json that references the sub-projects:

   {
     "files": [],
     "references": [
       { "path": "./schemas" },
       { "path": "./core" },
       { "path": "./backend" }
     ]
   }

tsc -b then figures out the topological order itself and only rebuilds what changed. The .tsbuildinfo files cached under .cache/ make subsequent builds nearly instant.

For CI I keep both: npm run compile for "build everything from scratch", tsc -b for the watch / incremental case during development.

Tips & Pitfalls

A short list of things that bit me along the way:

Always use the .js extension in TypeScript imports when module is set to NodeNext. The source is .ts, the import says .js. This is correct, even though it looks wrong.
Hoist devDependencies to the root package.json. If every sub-project pins its own TypeScript version, tsc -b will complain about "duplicate identifier" errors when the versions diverge.
Add dist/ to .gitignore in every sub-project, but commit the tsconfig.json and package.json. The output is regeneratable, the build config is not.
Keep a single .cache/ folder at the root for all .tsbuildinfo files (as in the examples above). That way you can rm -rf .cache to force a clean rebuild without touching dist/.
Don't put runtime code into schemas. The moment you do, the frontend bundle starts pulling in Node-only modules, and you spend an afternoon debugging Vite errors. Keep it types-only.
Pin the workspace dependency to * or workspace:*, never to a concrete version. With npm workspaces, "myproject_schemas": "*" reliably resolves to the local symlink.

Conclusion

This setup gives you a clear separation between data definitions, shared runtime code and the actual applications, without forcing you to publish anything to a registry or run a heavy build tool. The schemas package is the contract that keeps backend and frontend in sync, and TypeScript's project references make sure that contract is enforced on every save.

If you want to see this approach in action on a real project, have a look at vtseditor - a browser-based visual editor for exactly the kind of schemas package described in this article. It lets you draw your schemas, exports them as vts-based TypeScript files, and is published as an npm CLI (npx vtseditor) so you can drop it into any monorepo without changing your existing build setup.

Happy splitting.

Process Isn't the Enemy

Alessandro Aiezza — Mon, 01 Jun 2026 23:53:41 +0000

🤖 AI Summary

Short on time? Ask AI to summarize this article.

Copy the prompt below into ChatGPT, Claude, Gemini, or your preferred AI assistant.
Please summarize this article for me. Focus on:

- The main argument
- Practical takeaways
- Engineering tradeoffs discussed
- Situations where the advice may or may not apply

Article: https://dev.to/aaiezza/process-isnt-the-enemy-425p

Software engineers tend to have a complicated relationship with process.

We've all experienced process at its worst: endless meetings, excessive approvals, status updates that could have been a single message, and layers of ceremony that seem to slow down the very work they're supposed to support.

When process becomes disconnected from outcomes, it feels like friction. It feels inefficient. It feels like something standing between an engineer and meaningful progress.

And sometimes that's exactly what it is.

But I've come to believe that the answer isn't no process. The answer is intentional process.

The best processes aren't there to slow us down. They're there to keep us pointed in the right direction.

Conventional Commits as a Case Study

One example I appreciate is the idea of Conventional Commits.

The specification can be found here:

https://www.conventionalcommits.org/

At a high level, Conventional Commits provide a standardized structure for Git commit messages.

Some common examples include:

feat: add customer search endpoint
fix: correct null pointer exception during login
refactor: simplify order validation workflow
test: add coverage for customer creation service
docs: update API documentation
chore: upgrade build dependencies

Conventional Commits transform a commit message from a description into a declaration of intent.

Once intent is captured consistently, all sorts of useful things become possible. Changelogs can be generated automatically. Release tooling becomes easier to automate. Teams can analyze repository history to better understand the types of work being performed over time. How frequently are features being shipped? How much effort is spent on refactoring? Are bug-fix rates increasing or decreasing? Meaningful trends can emerge when commit intent is captured consistently.

Those are valuable benefits.

But they're not the reason I've grown to appreciate the convention.

The real value is what happens in the engineer's mind before the commit is ever created.

The Pause That Creates Clarity

When you're forced to classify a commit, you're forced to think about what you're actually shipping.

Is this really a feature?

If it's a feature, why am I also including a large amount of cleanup code?

Should that cleanup be a separate refactor commit?

If I'm changing formatting throughout the project, is that actually part of the feature, or should it be a separate commit?

If I'm updating dependencies while implementing business logic, should those concerns be separated?

These questions seem small, but they matter.

The process introduces a deliberate pause.

A moment where the engineer stops moving code around and starts thinking about intent.

And intent is one of the most valuable things we can preserve in a codebase.

Commit Purity

One of the healthiest habits a team can develop is pursuing what I like to call commit purity.

A commit should have a single reason to exist.

A future engineer should be able to look at a commit and answer a simple question:

Why was this change made?

When multiple concerns become tangled together, that answer becomes difficult.

A feature commit that also contains refactoring, formatting changes, dependency updates, test rewrites, and miscellaneous cleanup becomes harder to review, harder to understand, harder to revert, and harder to trust.

Small, focused commits create a cleaner narrative.

They allow reviewers to focus on one concern at a time.

They make deployments safer.

They make debugging easier.

They make history more useful.

Most importantly, they encourage engineers to think in terms of discrete, intentional changes instead of giant collections of loosely related modifications.

Small Bullets, Not Missiles

At first, this can feel slower.

Stopping to think about commit boundaries.

Splitting work into multiple commits.

Writing meaningful messages.

Separating unrelated changes.

All of it feels like lost momentum.

But over time, something interesting happens.

You stop shipping giant missiles.

You start firing tiny bullets.

Each one is small.

Each one is intentional.

Each one is easier to test.

Each one is easier to review.

Each one is easier to deploy.

And when something goes wrong, each one is easier to understand.

The apparent slowdown often results in faster delivery because the system itself stays healthier.

Reviews become more effective.

Deployments become less risky.

Debugging becomes less painful.

The codebase becomes easier to navigate.

And the team spends less time untangling yesterday's decisions.

Good Process Creates Better Habits

The best engineering processes are rarely about compliance.

They're about creating opportunities for reflection.

A code review checklist encourages us to think about edge cases.

A testing strategy encourages us to think about correctness.

A deployment process encourages us to think about risk.

And conventions like Conventional Commits encourage us to think about intent.

None of these activities directly produce features.

But they help ensure we're building the right things, shipping them safely, and leaving the codebase healthier than we found it.

That's not bureaucracy.

That's discipline.

And sometimes a little discipline is exactly what helps us move faster.

When Every Tool Is Callable, the Chat Becomes the Join Layer

Lovanaut — Mon, 01 Jun 2026 23:51:38 +0000

Every software stack has a hidden layer that no vendor sells: the join. It is the place where two products that do not know about each other are made to work together — where one tool's numbers are reconciled against another's outcomes. For two decades that layer lived outside every product, in a human reconciling exports or in a pipeline someone built and maintained. It belonged to no vendor, and it was nobody's screen.

That layer is moving. Not because a vendor built a grand integration, but because tools are becoming callable. When a product exposes its functions over MCP, it stops being a screen you visit and becomes something a client can invoke. And the moment a client can invoke more than one product at once, it can do the thing the join layer always did — pull from one, pull from another, and reconcile them on the fly. The integration point does not get built into the products. It rises one level, out of every product and dashboard, into the chat client where the user already is.

This is a change in topology, not a new feature. The shape of where integration lives is shifting, and the consequence runs straight through vendor strategy: a tool engineered to be a complete, self-contained island — the most polished screen, the fullest dashboard — is optimizing for a topology that is dissolving underneath it. To see the shift concretely, take the most familiar stack of separate-vendor tools there is: acquisition. Ads, forms, analytics — separate products, separate logins, separate mental models, with the most decisive work, lining up what the ad cost against what the form produced, left as a manual chore in the gap between them. Watch what happens to that chore when each tool becomes callable inside the same conversation.

Where the join used to live

Start with a question most product people never ask out loud: when two tools need to work together, where does that work physically happen?

For two decades the answer was "in a human, or in glue someone wrote." If an ad platform and a form tool both held numbers that needed comparing, a person was the integration — opening both, exporting both, reconciling both. A more sophisticated team wired up a pipeline: an ETL job, a data warehouse, a dashboard that pulled from each API and joined them downstream. Either way, the join was a structure that had to be built and maintained, and it sat outside both products, in territory that belonged to neither.

This is the heart of workflow topology — the shape of where integration lives. For a long time that shape was fixed. Each product owned its own screen and its own data, and any connection between products was external scaffolding — a person, a script, a warehouse — bolted across the gap. Vendors competed on their own surfaces. The seams between them were the customer's problem.

That topology is what is changing. Not the products. The location of the seams.

When every tool is callable, the client becomes the join

Here is the mechanism, stated plainly.

When a tool exposes its functions over MCP — the open protocol that lets an AI client reach an outside service safely — it stops being a screen you go to and becomes a thing that can be called. That alone is now widely understood. What is less discussed is what happens when several tools become callable at once, inside the same chat client.

The client gains the ability to call all of them. And the moment it can call more than one, it can do the thing that used to be your chore: it can pull from one, pull from another, and join them. The orchestration that used to live in a human or a pipeline relocates into the conversation. The chat client becomes the cross-vendor join layer — the place where the ad platform's numbers and the form tool's outcomes finally meet, without either vendor having built a bridge to the other.

This is the part that surprises people. No vendor integrated with any other vendor. The ad tool does not know the form tool exists. The form tool does not know about the ad tool. Neither one built a connector. And yet they join — because the layer above them, the client, can reach both and reconcile them on the fly. The integration didn't get built into the products. It moved out of the products entirely, up into the conversation where the user already is.

That is a topology change, not a feature. The seams left the gaps between products and gathered into one surface. And the surface is a chat window.

Eight days where the join moved into the chat

A topology claim is easy to wave at and harder to prove, so here is a concrete instance of the join relocating.

The setup was a small ad test over eight days, with about ¥6,597 of spend, and then an attempt to run the whole acquisition loop from a single conversation in an AI client without opening a dashboard. Two connectors were live in that chat at once: one for the ads, and FORMLOVA's, for the form side. Neither vendor had built a bridge to the other.

First the ad side. The metrics came back into the chat from a plain request — spend, clicks, the rate of clicks. Across those eight days there were 704 clicks at a CTR of 12.62%. On the ad screen, that reads as a clean result. A high click rate, cheap clicks, money apparently well spent.

Then the move that the old topology never let me make in one place. In the same conversation, I turned to the form side and asked it to break the responses down by which ad they came from. Ad spend on one side, form outcomes on the other, and the join performed by the client between them — right there, no export, no spreadsheet, no second screen. From that join, acquisition cost is simply spend divided by the form-side conversions, derived inside the chat. The number is not the point of this essay; the location of the calculation is. It happened in the conversation, not in my head.

And the join is what revealed the truth the ad screen had hidden. Splitting delivery by placement showed the skew immediately: roughly 96% of impressions and about 83% of spend had concentrated in Audience Network, not the feeds I had meant to reach. The cheap, high-CTR clicks were largely a mirage. They looked efficient on the surface and had mostly flowed somewhere I never intended. One side alone would never have told me that. The ad numbers said "good clicks." Only the join, in the conversation, said "good clicks, wrong place."

Because the problem surfaced inside the same chat, the next move happened there too. I rebuilt the ad set — restricting placement to the feeds, excluding Audience Network — through conversational instructions, and the change was reversible. Reading the data and acting on it were no longer two screens and two tools. They were two sentences in one thread.

What I want to underline is not the fix. It is that at no point did I reopen a dashboard to perform the join. The seam between "what the ad cost" and "what the form produced" — the seam that used to be my manual chore — had quietly moved into the conversation and dissolved there.

Why this is topology, and why it matters more than it looks

It is tempting to file this under "AI makes things convenient." That undersells it. Convenience is a better screen. This is a different map.

When the join moves into the client, the competitive picture for every tool in the stack changes shape. A product no longer wins by owning the most complete screen, because the user is not assembling the picture on any one screen anymore. The picture is assembled above all of them. What a product can offer, instead, is to be cleanly callable and to return data that joins well with everything else in the conversation — accurate, structured, attributable. The value of a tool starts to depend on how good a part it is inside a join it does not control, rather than how complete a whole it is on its own.

This is adjacent to the question of where control sits in an agent world, which is its own argument, and I will leave it as a single passing note rather than re-run it here. The topology point stands on its own: the integration layer of the acquisition stack used to be external scaffolding you maintained, and it is becoming a property of the chat client you already use. The vendors did not converge. The join migrated.

For founders building any tool in an acquisition flow, the strategic read is concrete. Stop assuming the integration work happens in your product or in the customer's pipeline. Increasingly it happens one layer up, in a conversation, performed by a client calling you and calling your neighbors. The questions that follow are not cosmetic. Is your tool callable with intent read correctly? Does your data join cleanly against a tool you have never heard of, in a thread you will never see? Are your operations safe to run when the caller is an agent and the join is happening somewhere above you? A tool that is a beautiful island, fully complete on its own screen, is optimizing for a topology that is dissolving. A tool that is a good citizen of a join it does not own is built for the one that is arriving.

This sits inside a larger movement I have written about elsewhere — software shifting from being chosen to being called. The collapse of the acquisition stack into one conversation is what that shift looks like when you stand in the middle of an actual workflow, watching the seams between your tools vanish in real time.

The whole loop in one thread

What eight days of small spend made clear to me was not about ads. It was about shape.

The acquisition stack — build the form, build the ad, manage the form, manage the ad, analyze the result — was always carved into separate products on separate screens, with the most valuable work, the join between cost and outcome, left as a chore in the gaps. That chore is collapsing into a conversation. Pull the ad numbers, pull the form outcomes, join them, find the mirage, rebuild the ad — all of it in one thread, with no vendor having built a bridge and no dashboard reopened.

The tools did not merge. The place where they meet did. And once the join lives in the conversation, the seams that defined the old stack simply stop being visible. That is the quiet, structural thing worth noticing: not that the work got easier, but that the integration layer of acquisition moved out of your scripts and your screens and into the chat where you were already working.

The eight-day field report this essay is grounded in: Reconciling ad spend with real form outcomes in one chat
The broader guide to FORMLOVA as an MCP-ready form service: The FORMLOVA MCP form service, in brief

DEV Community

Hermes Agent Burned 603M Tokens Behind My Back — I Cut Background Costs by Up to 125x

The Fix

How the Routing Works

What provider: auto Actually Does

My Ollama Cloud Pro Catalog

Twelve Background Tasks

How I Mapped Models to Tasks

What I Tried First: Local Models

The Numbers

Current Status

Full Config

Try It

PostgreSQL 0L000 Error: Causes and Solutions Complete Guide

PostgreSQL Error 0L000: invalid grantor

Top 3 Causes

1. Attempting to Re-Grant a Privilege Without GRANT OPTION

2. Non-Owner Granting Privileges on an Object

3. Broken Privilege Chain in Role Hierarchies

Quick Fix Solutions

Prevention Tips

Oracle ORA-00206 Error: Causes and Solutions Complete Guide

ORA-00206: Error in Writing Control File – Causes, Fixes & Prevention

Top 3 Causes

1. Disk Space Exhaustion

2. OS-Level Permission or I/O Errors

3. Control File Corruption or Accidental Deletion

Quick Fix Solutions

Prevention Tips

Related Oracle Errors

View Transitions API: Frontend Animasyonlarında Yeni Standart mı Geliyor?

View Transitions API: Frontend Animasyonlarında Yeni Standart mı Geliyor?

View Transitions API Nedir?

AI code review is now a cloud workload

the review button is now an infrastructure decision

review everything is not a strategy

cost attribution is a useful forcing function

the other bill is reviewer attention

keep humans in the uncomfortable parts

what i would do this week

the punchline

references

I Tested DeepSeek V4 Flash and GPT-4o Side by Side — Here's the p99 Latency Truth

The Startup Trap: Why "Free Tier" Is the Most Expensive Mistake

The Enterprise Overhead Problem: Why Your $50,000/Month Bill Is Overengineered

The Hybrid Architecture That Actually Scales

The Cost Reality: Why Startups Shouldn't Pay Enterprise Prices

The Pro Channel Trade-Off: When You Actually Need Dedicated Capacity

My Production Playbook: What I Actually Deploy

The Bottom Line

Web accessibility overlays don't work — here's what actually does

Fixed Before Anyone Notices, Stronger After Every Fix: Self-Healing + Recurrence Prevention (Series Part 4)

Start with last month's numbers

Series

Big picture -- the three layers: Observation, Repair, Strengthening

Observation -- where do the alerts come from?

What Observability can't catch, Self-Healing can't fix either

Repair -- the Self-Healing flow

What happens when the AI judges "this is not fixable in code"

Deduplication

Self-Healing and Part 3 auto-review -- "the fixer AI" and "the reviewer AI" are independent

A concrete example: meet subscription's 409 ALREADY_EXISTS

Strengthening -- Guides (lint + guidelines) grow automatically

What happens every time Self-Healing runs (the recurrence-prevention-first flow)

"We'll do it later" and "introduce as warn" are banned

The "step on it, mechanize it" lineage

How does the AI write a lint rule without breaking it?

A concrete example: Cloud Run OTel env injection -> promoted to CI guard

Where Guides stand right now (in numbers)

The whole loop, from the top

Self-Healing by the numbers

Main firing categories

Alert-firing to production-recovery time

What changed / Bridge to Part 5

What Is an AI Agent Harness?

Start with the agent

Same model, different results

Model vs. agent vs. harness

A harness is not a framework

The simplest harness you already know: CLAUDE.md

What `provider: auto` Actually Does

"We'll do it later" and "introduce as `warn`" are banned

`schemas/src/index.ts`