标签：#devops

Kubernetes is encouraging developers to take a closer look at KYAML, a stricter dialect of YAML designed to make Kubernetes configuration more explicit, predictable, and less prone to common YAML errors. By Craig Risi

Hello, I'm Maneshwar, and I'm building LiveReview — a blast-radius aware AI code review built for...

Disk full alerts at 2am? Learn the exact commands to find what's eating your Linux server's disk space and fix it fast. You get the alert: disk usage at 94%. Your app starts throwing errors, logs stop writing, and databases refuse to accept new rows. Finding the culprit fast matters — but on a server with millions of files, knowing where to look is half the battle. Here's a systematic approach to track down disk hogs in minutes, not hours. Start With the Big Picture: df Before you dig into directories, confirm which filesystem is actually full. Run: df -h — shows all mounted filesystems with human-readable sizes df -h / — focus on the root filesystem df -i — check inode usage (a filesystem can be 'full' even with free space if inodes are exhausted) Pay attention to the 'Use%' column. If you see 100% on /var or /home but not /, that tells you exactly which mount point to investigate. Inode exhaustion — df -i showing 100% — is easy to miss and causes the same symptoms as a full disk, so always check both. Drill Down With du Once you know which mount point is full, use du to find the largest directories. Start from the top of that mount point and work down: du -sh /* 2>/dev/null — sizes of every top-level directory, errors suppressed du -sh /var/* 2>/dev/null — drill into /var if that's the culprit du -ah /var | sort -rh | head -20 — list the 20 largest files and folders inside /var The pattern is always the same: run du -sh on the suspicious directory, find the largest subdirectory, repeat one level deeper. You'll usually hit the real culprit within three or four iterations. Common offenders are /var/log (runaway logs), /var/lib/docker (unused images and volumes), and /tmp (applications that don't clean up after themselves). Find Large Files Directly With find Sometimes a single enormous file is the problem — a core dump, a forgotten database export, or a log that rotated incorrectly. Use find to surface files above a size threshold: find / -xdev -size +500M -ls 2>/de

The agent is already in your workflow. The failed build is where it goes blind. AI coding agents have moved from novelty to daily tool. In Stack Overflow's 2025 Developer Survey, 84% of developers said they are using or planning to use AI tools in their development process, up from 76% the year before, and about one in seven professional developers now use AI agents at work every day . Among developers who have used agents at work, roughly 70% agree the agents have reduced the time they spend on specific tasks . There is one place, though, where that agent still tends to go dark: the failed CI run. The pipeline turns red, and your agent (like you) is handed a wall of log output from jobs it did not write, covering steps it did not touch. It has to reconstruct what actually broke before it can fix anything. That reconstruction is the expensive part, and it is exactly the part Latchkey is built to remove. This piece is about a clean division of labor. Latchkey's self-healing CI repairs the failures that are about your environment, not your code. For the failures that are genuinely about your code, Latchkey does not guess and patch on your behalf. Instead it hands your own coding agent a complete, structured account of the failure over the Model Context Protocol, so your agent can fix the bug with full context instead of starting from a log file. Two kinds of red build, and only one of them is yours to fix Almost every failed build is one of two things. Either the environment let you down (a flaky network, a full disk, a process killed for memory, a missing tool, configuration that drifted), or your code is actually wrong (a compile error, a failing test, a broken assertion). These two cases want opposite treatment, and conflating them is how teams end up rerunning pipelines and hoping for green. Latchkey's self-healing CI handles the first case. When a step fails on a Latchkey managed runner, Latchkey detects the failure, diagnoses the cause, and applies a fix while t

The Pipeline Became the Attack Surface For most of the last decade, we treated the CI/CD pipeline as plumbing: invisible, trusted, and mostly ignored until it broke. That assumption is no longer safe. The clearest signal came in 2025, when attackers stopped going after the software a pipeline builds and went after the pipeline itself. This week's research pass pulled together three shifts that are all landing at once: a supply-chain attack that redefined the threat model, GitHub's response in its 2026 security roadmap, a pricing change that quietly rewrites the cost math, and a persistent gap between how much teams trust AI in general and how little they trust it inside CI. Here is what the sources actually say. The tj-actions attack changed the threat model On March 14, 2025, researchers discovered that the popular tj-actions/changed-files GitHub Action had been compromised. According to Palo Alto Networks Unit 42, the action was used by over 23,000 GitHub repositories at the time ( Unit 42 ). The mechanics are worth understanding, because they explain why this matters beyond one action. Attackers injected code that dumped the CI/CD runner's memory and wrote sensitive environment variables and secrets straight into the workflow logs. They retroactively modified multiple version tags to point at a single malicious commit, so pipelines that pinned to a tag rather than a commit SHA pulled the payload ( Unit 42 ). The incident is tracked as CVE-2025-30066, described as allowing remote attackers to discover secrets by reading action logs ( GitHub Advisory Database ). The compromise did not start with tj-actions. Unit 42 traced it back through a leaked personal access token that reached reviewdog/action-setup , a dependency in the chain, with earlier steps going back to late 2024 ( Unit 42 ). In other words, the pipeline's own dependency graph was the delivery vehicle. The takeaway is not "avoid one bad action." It is that the automation running your builds is now a firs

Most "best CI/CD tools" lists are twenty logos in a table, ranked by nothing in particular, with the author's product at the top. This is not that. It is a map of the categories, what each one exists to solve, and how to tell whether you need it yet. I work at Latchkey, so I will say plainly where we sit: we are one option inside one of the six categories below, and I will tell you when we are the wrong answer. Read the rest as a map, not a pitch. A note on what is missing here: I have not invented benchmark numbers or quoted prices for tools I do not operate. Vendor pricing changes often enough that any figure I write today is wrong by the time you read it. Where a number matters, go to the vendor's own pricing page. The mistake most teams make Teams usually shop for CI/CD tools by asking "which one is best." That question has no answer, because the tools are not competing with each other. They are stacked on top of each other. A team that adopts a build accelerator to fix a slow pipeline, when the actual problem is that half their failures are flaky, has bought a faster way to fail. A team that adds pipeline observability before they have enough pipeline to observe has bought a dashboard nobody opens. The useful question is narrower: which layer is currently your constraint? Answer that, and the tool choice inside the layer is usually obvious. Here is the whole landscape in one view. Layer What it solves When it becomes your bottleneck CI platform Running the pipeline at all Never; this is where everyone starts Runners and compute Where jobs run, and how fast they start Queue time or runner cost is visible Build acceleration Doing less work per run Full rebuilds dominate your wall clock Supply chain security What the pipeline is allowed to reach You ship to production or touch customer data Observability and cost Where time and money actually go You cannot answer why last week was slow Artifacts and registries Storing what the pipeline produces You publish images

Two things are true about software delivery in 2026, and they are pulling in opposite directions. The first: AI is now writing a large share of the code that reaches your pipeline. CloudBees' 2026 State of Code Abundance Report found that AI generates or assists in writing 61% of the average enterprise codebase, and that 81% of enterprise leaders report an increase in production issues tied to AI-generated code. The same report names a confidence gap worth sitting with: 92% of leaders say they are confident in the production readiness of that code, even as the failures climb ( CloudBees, 2026 ). The second: the place best positioned to catch those failures, the CI/CD pipeline, is where teams trust AI the least. JetBrains' TeamCity team reported that 73% of organizations do not use AI in their CI/CD pipelines at all, and 78.2% do not delegate tasks to AI in CI/CD workflows, even though general AI usage in development work exceeds 90%. When asked why, 60% cited unclear use cases or value, 36% cited a lack of trust in AI-generated results, and 33% cited data privacy concerns ( JetBrains TeamCity, 2026 ). That is the trust gap. More machine-written code is arriving, more of it is breaking in production, and the pipeline that should be the safety net is the one room teams will not let automation into. This piece is about why that hesitation is rational, and what automation has to look like to deserve a different answer. Why the pipeline is different The JetBrains analysis put its finger on the reason cleanly: development workflows tolerate experimentation because feedback is immediate and cheap. CI/CD is the opposite. It demands consistent, reproducible signals, and the cost of an error is high. A coding assistant that guesses wrong wastes a few seconds of your time. A pipeline that guesses wrong can hide a real defect, ship it, or erode the one thing a pipeline exists to provide: a trustworthy answer to the question "is this build good?" So the bar for automation in CI/

The first half of 2026 reset two things at once for engineering teams: what continuous integration costs, and what it takes to keep delivery stable while AI pushes more change through your pipelines than ever. Those two stories are connected, and the connection is the part worth your time. The pricing reset On January 1, 2026, GitHub reduced prices for GitHub-hosted runners by up to 39%, with the size of the cut depending on the machine type ( GitHub Changelog ). Standard hosted-runner usage on public repositories stays free, as it was before. The DevOps publication SamExpert documented the specific per-minute moves. A Linux 2-core runner dropped about 25% (from $0.008 to $0.006 per minute). A Windows 2-core runner dropped about 38% (from $0.016 to $0.010). A Linux 64-core arm64 runner dropped about 39% (from $0.160 to $0.098) ( SamExpert ). If your CI runs mostly on hosted runners, that is real money back, and it is worth recalculating your monthly estimate against the new rates rather than assuming last year's numbers still hold. The same December 2025 announcement carried a more controversial proposal: a $0.002 per-minute charge for self-hosted runner usage in private repositories, scheduled to start March 1, 2026 ( DevClass ). GitHub framed it as ending a cross-subsidy, where revenue from hosted runners was effectively underwriting the cost of operating Actions for everyone, and said the large majority of customers would see no change to their bill. The reaction from developers who run CI on their own hardware was sharp, with some publishing the monthly figures they expected to owe for compute they already pay to operate themselves. Within about a week, GitHub posted that it was postponing the self-hosted billing change to re-evaluate its approach ( SamExpert ). Postponed, it is worth being precise here, is not the same as withdrawn. There is no new date and no guarantee the charge returns in its original form, but there is also no statement that it is gone for

The first half of 2026 rearranged three things at once for teams that live in GitHub Actions: what CI costs, how it is secured, and how much of it a machine can now do on its own. None of these landed cleanly. Prices went down for most people while a new platform charge quietly went up. A self-hosted runner fee was announced, met a wall of objections, and was pulled back within a week. And a security roadmap arrived that will change how workflows pin dependencies and scope secrets over the next two to three quarters. Here is a grounded read of what happened, with sources, and an honest account of where Latchkey fits. Hosted runners got cheaper, and a new platform charge arrived On January 1, 2026, GitHub reduced GitHub-hosted runner prices by up to 39%, with the size of the cut depending on the machine type (larger runners saw the larger relative reductions), per GitHub's own changelog ( github.blog ). In concrete terms, community reporting put the Linux 2-core rate moving from $0.008 to $0.006 per minute and the Windows 2-core rate from $0.016 to $0.010 per minute ( samexpert.com ). Alongside the cuts, GitHub introduced a $0.002 per-minute Actions cloud platform charge that applies to all Actions workflows. For GitHub-hosted runners, that charge is already bundled into the reduced meter price, so it is not a separate line item there ( github.com ). Two things stayed the same and are worth repeating, because they get lost in the noise: standard runner usage on public repositories remains free, and GitHub Enterprise Server pricing is unaffected ( github.com ). GitHub framed the net effect as small for most accounts: it stated that 96% of customers would see no change to their bill, and that of the 4% affected, 85% would see costs decrease while the remaining 15% faced a median increase of roughly $13 ( github.com ). That is a reassuring headline. It is also a reminder that the bill depends entirely on your own mix of runner sizes and minutes, which is exactly the thi

Two forces are pulling on delivery pipelines this year. Code is arriving faster than ever, and the cost of running the pipelines that ship it has been unusually unsettled. Let us look at both, honestly, and then talk about where reliability work fits. Pricing was a moving target, and it still is On December 16, 2025, GitHub announced a simpler Actions pricing model that included a new $0.002 per minute "cloud platform charge." The plan was for that charge to reach self-hosted runner usage in private repositories on March 1, 2026 ( GitHub Changelog ). The reaction was strong enough that GitHub reversed the self-hosted portion within days. As GitHub put it, they "missed the mark with this change by not including more of you in our planning," and postponed the self-hosted charge to re-evaluate the approach ( GitHub Changelog ). Postponed is not cancelled, so if you run self-hosted runners in private repos, this is worth watching rather than filing away. GitHub's own framing was that the change would touch a small slice of accounts: it reported that 96% of customers would see no change to their bill, and that of the 4% affected, most would actually see their Actions bill decrease ( GitHub Changelog ). Even so, the principle of paying a per-minute fee for software running on hardware you already own was the sticking point for many teams, and the reversal followed quickly. The other half of the announcement did take effect. On January 1, 2026, GitHub reduced the price of GitHub-hosted runners by up to 39%, depending on the machine type, while leaving free minute quotas unchanged ( GitHub Changelog ). GitHub pointed teams to its runner pricing docs and calculator for the exact per-machine rates rather than publishing a single headline number ( GitHub Changelog ). That "up to" is doing real work in the sentence: the reduction depends on which machines you actually use, so the only way to know your number is to look at your own usage mix. The practical takeaway: the ground u

This project started with a simple goal: run Kubernetes without keeping an EKS cluster online every day. In I Wanted Kubernetes Without an Always-On EKS Bill , I built an always-on k3s lab on my home server and proved that I could deploy, update, and roll back an application. The rollback worked, but it exposed the next problem. Kubernetes restored Version 2 while the saved YAML still declared Version 3. I corrected the file manually, but the recovery depended on repairing the running cluster and its saved instructions separately. In The Rollback Worked. My Next Deploy Could Break It Again , I designed a safer path. The automated build process would test and publish an exact image, then stop at a Git pull request. Git would record the reviewed version. Argo CD, running inside Kubernetes, would make the cluster follow that record. Now I needed to prove that the design worked outside a diagram. I followed one release from source code to running Pods. Then I tested two opposite failures: The cluster was wrong while Git was correct. Git contained a bad setting while the cluster followed it correctly. Those experiments showed both the value and the limit of GitOps. Automation can make the cluster match Git, but it cannot decide whether the human-approved version in Git is a good one. CI Built the Release but Did Not Deploy It The GitHub Actions workflow—my continuous integration, or CI, worker—ran the application tests and checked the Kubernetes package before building anything. Its job was to prove and publish a release, not to change the cluster. After validation, Buildx created a Linux AMD64 image with the full source commit baked into /version : docker buildx build \ --platform linux/amd64 \ --build-arg "APP_VERSION= $GITHUB_SHA " \ --tag " $image_name : $GITHUB_SHA " \ --provenance = mode = max \ --sbom = true \ --push \ application After publishing the image, CI read its registry digest. A digest is the image's content fingerprint: if the image changes, the digest

Your CircleCI pipeline is green. Every job passes. And yet your app is running against a dependency version that hasn't shipped in a month — nobody committed it, nobody bumped it, it just quietly showed up in production. If you've chased a bug like this, the culprit is almost never your code. It's your cache key. This is a five-minute read and a fifteen-minute fix. Quick Win Friday, deployed to your .circleci/config.yml . The failure mode CircleCI's dependency caching works on a simple contract: you compute a key from something that changes when your dependencies change (usually a lockfile checksum), and you save/restore a cache tied to that key. The contract breaks in three specific, extremely common ways: You checksum the wrong file. {{ checksum "package.json" }} looks reasonable until someone bumps a transitive dependency via package-lock.json without touching package.json . The checksum doesn't move. CircleCI happily hands back last week's node_modules . restore_keys does prefix matching, and people think it does exact matching. CircleCI tries your primary key first, then falls through restore_keys in order, and the first one is a prefix match against existing cache entries — not "give me the newest exact match." If your restore_keys list is too coarse (e.g. just v1-deps- ), you can restore a cache built from a completely different branch, with a completely different lockfile, and the job won't fail. It'll just quietly install nothing (cache hit, npm ci sees the modules are "there") or run against the wrong versions. There's no version escape hatch. When you inevitably need to force everyone's cache to invalidate — a corrupted cache entry, a package manager migration, a lockfile format change — there's no cheap way to do it, because the key format was never designed with a manual buster in mind. Each of these fails silently. No red X. No error in the logs. Just a build that ran with stale state, and a bug report three days later that nobody can reproduce locally

A tool claiming "up to 15x faster than cdk deploy" showed up in my feed a while back. Drop-in replacement, it said: keep your CDK app exactly as it is, just swap cdk deploy for cdkd deploy . I've learned to be skeptical of "Nx faster" claims. So I actually deployed something real to AWS with both tools and timed it. Short version: it really is that fast. What cdkd actually is cdkd deploys an existing AWS CDK app without going through CloudFormation. It calls the AWS SDK directly instead. It's built by go-to-k (Kenta Goto), an AWS DevTools Hero and CDK top contributor who also maintains cls3 (a fast S3 bucket emptier) and delstack (for cleaning up stuck CloudFormation/CDK stacks) — tools that quietly fix the annoying parts of working with AWS. cdkd feels like the biggest one yet, and I mean that as a compliment grounded in actually using it, not a throwaway one. The mechanism is straightforward. cdkd runs the exact same CDK synth step as the CDK CLI, producing the same CloudFormation template. What changes is everything after that: instead of handing the template to CloudFormation, cdkd's own engine reads the resource dependency graph ( Ref , Fn::GetAtt ), builds a DAG, and fires AWS SDK / Cloud Control API calls directly, in parallel, as soon as each resource's dependencies are satisfied. Worth saying up front: cdkd calls itself not production-ready, dev/test only. This isn't a "replace CloudFormation in prod" pitch. I actually ran both, on real AWS cdkd's own README backs up the 15x number with a VPC + Lambda + SQS + CloudFront benchmark. So I wrote that same stack as a CDK app and deployed it twice — DeployRaceCfn via cdk deploy , DeployRaceCdkd via cdkd deploy — to the same AWS account, same region (ap-northeast-1). The stack: VPC (2 AZ + NAT Gateway) with a Lambda inside it, fronted by a Function URL CloudFront, origin set to that Function URL SQS + EventSourceMapping + a consumer Lambda First attempt failed. The account had hit its VPC limit (five, the default)

A green required check is not a merge decision. It is a signal that one job graph finished without a red X. If a pre-push hook was skipped, or a snapshot fixture was regenerated without a reason, you can still ship a lie. This article walks through a merge packet: a small JSON artifact your CI publishes next to the check. The packet records hook results, fixture drift, and required-job status. A model may write the eight-line brief. It does not get a vote. Why green still lies CI dashboards collapse many facts into one glyph. You see green. You click merge. You miss three common failures. First, someone pushed with --no-verify and skipped the hook that keeps fixture hashes honest. Second, a test helper rewrote golden files because a serializer added a field. Third, a retry job went green on the second attempt and nobody recorded that the first attempt failed. You do not need a platform rewrite to catch this. You need a contract the merge button cannot ignore. Cheap code generation makes the second failure more common. When it is easy to regenerate tests, it is easy to regenerate the fixtures those tests pin. The pin becomes a moving target. Treat unexplained fixture diffs as merge blockers, the same way you treat a failed unit job. What the merge packet contains Keep the packet boring. One file. One schema. Commit it as a CI artifact, not as a comment that can be edited after the fact. { "commit" : "REPLACE_WITH_SHA" , "generated_at" : "2026-09-03T00:00:00Z" , "hooks" : { "pre_push_fixture_guard" : "passed" }, "fixtures" : { "manifest_path" : "tests/fixtures.sha256" , "changed_paths" : [], "unexplained_paths" : [] }, "required_jobs" : [ { "name" : "unit" , "conclusion" : "success" }, { "name" : "contract" , "conclusion" : "success" } ], "merge_ready" : false , "brief" : null } merge_ready is computed by a script you own. Not by a prompt. The brief is optional prose for humans who will not open the JSON. Step 1: Pin fixtures with a manifest Pick a directory you alrea

Moving a Next.js app off Vercel and onto a plain Ubuntu VPS usually starts with a painful realization: either your serverless functions are timing out on background jobs, or your client just handed you a strict "you must host this on our infrastructure" requirement. Deploying the app itself is easy. What trips people up (and what cost me hours of debugging and locking myself out of my own server) is everything around the app. Here are the 12 things that actually break when you leave the serverless ecosystem, in the order you'll hit them. 1. Next.js needs a process manager, not just npm start Running npm start in a terminal dies the moment you disconnect. You need something that keeps the process alive, restarts it on crash, and survives a reboot. PM2 is the simplest option for a single-server Node deploy. npm install -g pm2 // ecosystem.config.js module . exports = { apps : [{ name : " my-app " , script : " node_modules/.bin/next " , args : " start " , cwd : " /var/www/my-app " , instances : 1 , exec_mode : " fork " , autorestart : true , max_memory_restart : " 512M " , env : { NODE_ENV : " production " , PORT : 3000 }, }], }; cd /var/www/my-app && pm2 start ecosystem.config.js pm2 save pm2 startup systemd -u YOUR_USER --hp /home/YOUR_USER That last line is the one people forget - without it, PM2's process list doesn't survive a server reboot. 2. Nginx needs to proxy to the port, not serve the files Next.js is not a static site (unless you've explicitly exported it as one). Nginx's job is to forward requests to the Node process, not serve files from disk: upstream nextjs_upstream { server 127.0.0.1 : 3000 ; keepalive 64 ; } server { listen 80 ; server_name example.com www.example.com ; location / { proxy_pass http://nextjs_upstream ; proxy_set_header Host $host ; proxy_set_header X-Real-IP $remote_addr ; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for ; proxy_set_header X-Forwarded-Proto $scheme ; # WebSocket support - required for HMR and any realtime f

There is a category of defect that cannot appear in your acceptance criteria. Not because nobody thought of it, but because the shape of a requirement has no room for it. A requirement describes a state and a rule. A customer can apply a valid promo code at checkout. State: the code is valid. Rule: it is accepted. Both are evaluated at a single instant, because a sentence has one tense. Real systems do not have one instant. They have two, and sometimes a lot more. The gap between checking and using Take that promo code. The system validates it when the customer types it into the basket. The system commits it when the customer pays. Between those two events sits an unbounded amount of time — thirty seconds if they have their card handy, three days if they leave the tab open on a laptop lid. If the code expires in that gap, what happens? The requirement cannot tell you. It never contemplated a gap, because it was written as one sentence about one moment. And a test written by hand almost certainly cannot tell you either, because a person writing a test naturally writes it the way they would perform it: enter code, assert accepted, pay, assert charged. Three lines, one instant, no gap. This is time-of-check to time-of-use. Most developers first meet it as a security problem — access() then open() , and a symlink swapped in between. The same shape appears at business timescale, and there it is far more common and far less discussed: Stock is reserved at basket, decremented at dispatch. Someone else buys the last one. A permission is checked when the page loads, enforced when the action fires. The role changed. A price is quoted at quote time, charged at renewal. The tariff moved. A rate limit is checked at admission, consumed at execution. The window rolled over. A feature flag is read at session start, branched on at submit. Someone flipped it. A token is validated at the gateway, used by a downstream call. It expired in flight. Every one of those is a real defect clas

Plenty of test data tools are built as a UI first and an API second, if there's an API at all. You open a dashboard, configure some fields, click "generate," and download a file. That works fine for a one-off demo. It falls apart the moment test data generation needs to be part of your actual engineering workflow — running in CI, seeding a database on every branch, or producing ten thousand records instead of ten. That's the case for a test data generation API over a click-driven dashboard: the primary interface is a request you can make from code, and everything else — a UI, a CLI — is built on top of that same API. Automation and CI integration A UI is something a person operates. CI doesn't have a person sitting at it. If test data generation only exists behind a login screen and a click, it can't run as a step in your pipeline — someone has to generate the data ahead of time, commit it, and hope it doesn't drift from what the tests actually need. An API-first tool is just another HTTP call your pipeline makes: fetch fresh, schema-conformant data as part of the build, every run, with no manual step in between. Scriptability — no clicking required Generating test data through a UI means clicking through the same sequence of dropdowns and fields every time you need a new batch. That's tedious for one dataset and untenable for the dozens of shapes a real test suite needs — different entity types, different edge cases, different volumes. An API call is a script. Write it once, parametrize it, and reuse it for every collection you need, without a human repeating the same clicks. Wiring a test data generation API into pipelines and seed scripts Seed scripts are code that runs at a specific point in a workflow — before a test suite, on container startup, in a migration. They need a function call or an HTTP request they can invoke programmatically, not a browser tab. With a test data generation API, "seed the dev database with realistic orders" is a line in a setup scrip

An agent patch can pass every unit test and still write outside the workspace, call an undeclared tool, or read an env key the task never named. Gate the blast radius first. Score the prose later. This article is a method, not a field report. It proposes a fail-closed envelope around filesystem roots, tool names, environment keys, and network hosts. Side-effect violations never freeze. Only a dual-runner disagreement on a non-envelope property may freeze, and only with a hashed evidence bundle. The conclusion in one rule Treat an agent patch as a capability change. If the run touches anything outside a declared envelope, the gate fails closed. Flakes in ranking, wording, or latency do not override that rule. Cheap generation does not make side effects cheap to reverse. A green suite that never watched /tmp , os.environ , or outbound sockets is not a verification result. It is a missing observer. What this gate is not It is not a golden-file of model text. It is not a mutation score. It is not a full-suite rerun after every hunk. It answers four questions only: Did the run write or delete outside allowed roots? Did it invoke a tool name that is not on the allowlist? Did it read an environment key that is not on the allowlist? Did it open a network host that is not on the allowlist? If any answer is yes, fail. Do not freeze. Do not retry for luck. Artifact: a locked envelope and an observer log Pin the envelope as a fixture. Hash it. Refuse to run if the hash drifts without a review note. { "envelope_id" : "agent-patch-envelope-v3" , "allowed_roots" : [ "/work/repo" , "/tmp/agent-scratch" ], "allowed_tools" : [ "read_file" , "apply_patch" , "run_tests" ], "allowed_env" : [ "CI" , "RUN_ID" , "ENVELOPE_HASH" ], "allowed_hosts" : [], "network" : "deny" } sha256sum envelope.json > envelope.json.sha256 # CI must compare this digest before the agent process starts. Label the next block as a proposed harness, not a production sandbox. User-space tracing will miss kernel-leve

I sat in on Margaret-Anne Storey's DORA community session last week, and she put a name on the thing I'd been circling since April. It isn't technical debt. Her ACM Queue piece splits software health into three debts. Technical debt is the familiar one: implementation choices that make tomorrow's change harder. Intent debt is the missing rationale, the goals and constraints that say what a system is even for, which now has to be legible to agents and not just to people. Cognitive debt is the one that stopped me. It's the erosion of shared understanding, the state where nobody on the team can confidently explain how the system works or predict what a change will break. Read that again if you review pull requests for a living. I closed a thirteen-post retrospective last month admitting I couldn't answer one question: how many AI-generated pull requests a week can a review process absorb before it stops working as a control? I still don't have that number. What I have now is a name for what you accumulate while you don't have it, and a way to find yours. Approval velocity measures motion Every metric most teams watch gets better as review collapses. Merge rate climbs. Time-to-approve drops. The throughput chart looks terrific right up until the incident review, because a reviewer who has quietly become a rubber stamp is indistinguishable from a fast reviewer in every dashboard you own today. Cognitive debt doesn't announce itself as a red number. It shows up as green ones, arriving faster. I know this failure mode from the inside. Two months of green CI on conformance checks that had never once passed , on my own project. A human audit caught it. No metric I was watching came close. What you need to measure is detection. Almost nobody does. Mutation testing, pointed at the reviewers We solved this once already, for test suites. Mutation testing injects known bugs into code and checks whether the tests catch them. A suite that passes everything might be thorough or migh

A recorded expected value is a leak. An agent that can read assert f(x) == y can patch f until that line is green and leave every unlisted input broken. A metamorphic relation does not publish y . It only publishes a constraint the output must keep under a known transform. That is the gate worth automating. Fixtures still matter, but only as seeds. Flaky tests still need a freeze, but the freeze must not cover the relation itself. This article is a proposed layout, not a production case study. No runtime metrics are claimed. The commands and modules below are labeled so they can be copied into a scratch repo and executed against your own function under test. Why snapshots fail as a merge gate Golden files encode one transcript. An agent patch is a search over many transcripts. If the search can see the answer key, the cheapest passing program is a lookup table for the keys in tree. That program is green. It is also wrong on the next customer file. Property-style checks reduce that leak because they do not ship the answer. They still need a seed corpus, a replay runner that the patch cannot edit, and a quarantine file that expires. Mix those three and you get a gate that fails closed when the agent rewrites tests, when a fixture drifts, or when a flake is used to hide a broken invariant. Three relation classes worth encoding first Start with relations you can state in one line. If you cannot state the line, you do not have a gate. You have a recorder. Idempotence. f(f(x)) == f(x) for normalizers, formatters, and canonicalizers. Round-trip. parse(serialize(x)) equals x on the fields you actually guarantee, not on whitespace you do not. Oracle-free comparison. f(t(x)) relates to t(f(x)) for a transform t you control: shuffle independent rows, rename equivalent keys, NFC vs NFD unicode, scale a quantity and its unit together. These are not universal laws. They are hypotheses about your function. Write them down as code. Keep the seed inputs boring. The relation, not the