标签：#DevOps

An AI coding agent isn't autocomplete. It runs shell commands, reads your files, installs packages, and opens things you never pointed it at. That's the whole reason to have one. It's also why I don't start projects the way I used to. Nothing dramatic happened to me, by the way. I'm not writing this from the wreckage of a dropped production table. I'm writing it because I spent an afternoon going through what could plausibly go wrong, expecting a long list of hard problems, and instead found that most of it is handled by about ten minutes of config nobody mentions on day one. So here's the ten minutes. Prose isn't protection This is the bit that took me embarrassingly long to get. You can tell an agent things two ways. A rule is prose it reads and weighs - good for judgement calls like naming, style, when to stop and ask. A ban is a config entry that makes something impossible. The trap is using the first for the second job. Writing "never force-push" into a CLAUDE.md feels like a control. It isn't. It's a request sitting in a context window next to a few thousand other tokens, competing with whatever you actually asked for. It'll usually win. Usually is fine for naming conventions. It's not fine for git push --force . 1. The deny list .claude/settings.json : { "permissions" : { "deny" : [ "Bash(rm -rf:*)" , "Bash(git push --force:*)" , "Bash(git push -f:*)" , "Bash(git reset --hard:*)" , "Bash(psql*production*)" , "Bash(*DROP DATABASE*)" , "Bash(*DROP TABLE*)" , "Bash(*TRUNCATE*)" , "Read(./.env)" , "Read(./.env.local)" , "Read(./.env.*.local)" ] } } These don't run. Not "the agent is discouraged" - they don't run, including in the scenario the list exists for, which is you at midnight approving a plan you skimmed. Two things to know before you test it. It takes effect from the next session, not immediately. So you write the file, try the blocked command in the same session, watch it go through, and conclude the whole feature is broken. Restart first. Keep the .env

TL;DR: Grafana Agent reached End-of-Life on November 1, 2025 and has been replaced by Grafana Alloy. Alloy consolidates Agent's Static mode, Flow mode, and Kubernetes Operator into a single collector built on the OpenTelemetry Collector while maintaining native support for Prometheus and Loki. If you're using Flow mode, migration is relatively straightforward. If you're using Static mode, the migration process will involve reviewing and testing the converted configuration. Before switching over, verify relabeling rules, recheck resource usage, and confirm that Prometheus and Loki are receiving the same data and labels as before. If you're still running Promtail, it's worth migrating both to Alloy at the same time since Promtail is also End-of-Life. If you deployed Grafana Agent a couple of years ago, there's a good chance you haven't thought about it since. It quietly collects metrics, ships logs, and generally stays out of the way. What you may not realize is that Grafana Agent reached End-of-Life on November 1, 2025. That includes Static mode, Flow mode, and the Kubernetes Operator. Grafana Labs has stopped creating bug fixes, security patches, and official support. If you're still running it, your collection layer is probably still performing normally, but is now unsupported. That doesn't necessarily mean it will stop working tomorrow, plenty of unsupported software continues running for years. It does mean you're taking on the risk yourself, especially as the rest of your monitoring stack continues to evolve. This article covers why Grafana Labs replaced Agent with Alloy, what actually changes during the migration, and where people tend to run into problems. Why Grafana Agent was deprecated One of the biggest issues with Grafana Agent is that it was essentially three agents, not one product: Static mode, which used YAML and looked similar to Prometheus. Flow mode, which introduced a component-based configuration using River. The Kubernetes Operator, which manage

Last month I watched a teammate paste a stack trace into a hosted AI assistant. The trace contained an internal hostname, a database connection string, and a customer email. None of it was secret enough to trip a DLP rule, but all of it left our network through an endpoint nobody had audited. The failure wasn't the tool — it was that we had never written down which data classes are allowed to reach which inference endpoint , and we had no test that would fail when the boundary was crossed. This article builds that boundary as a reproducible fixture: a data-classification decision matrix, a canary-leak test you can run against any hosted or self-hosted model endpoint, and a prevent/detect/recover table. The fixture works whether your endpoint is a cloud API, a free hosted tier, or a GPU box under your desk. The invariant I1: A prompt containing data of classification level L may only egress to an endpoint whose trust level is explicitly approved for L . Everything below exists to make I1 testable in CI rather than aspirational in a wiki. Step 1: Write the decision matrix before touching any tool Data class Examples Free hosted model tier Self-hosted / VPC endpoint C0 – Public OSS code, docs, public CVEs ✅ Allowed ✅ Allowed C1 – Internal-generic Boilerplate, config shapes, anonymized traces ✅ Allowed with review ✅ Allowed C2 – Internal-sensitive Real hostnames, schemas, ticket content ❌ Not without a signed DPA + retention terms you've actually read ✅ Preferred C3 – Regulated/secrets Credentials, PII, customer data, keys ❌ Never ⚠️ Only with controls (see below) Two rules make this matrix enforceable: Default deny. If a data class isn't in the matrix, it's C3 until someone argues it down in writing. The matrix is code. Keep it as a YAML file in the repo so the fixture in Step 2 can assert against it. Free hosted tiers are genuinely useful for C0/C1 work — evaluating a framework, writing throwaway scripts, reproducing a public bug. That is where something like MonkeyCo

The GPT-6 news is doing the rounds and the framing is everywhere: prompt engineering is dead, the future is hierarchical memory and autonomous agent swarms. I mostly agree with the framing, but almost every take I've seen treats it as an AI story. It's not. For anyone who actually runs infrastructure, it's an operations story, and it's a slightly alarming one. Let me explain what changes on the ground, because the interesting part isn't the model, it's what a swarm of these things does to your cloud account. The part everyone got right: prompt engineering was always a workaround Prompt engineering was never a discipline. It was a coping mechanism for models that forgot everything between turns and couldn't reliably use tools. We wrote elaborate prompts because we had to hand-carry all the context in, every single time. Calling it "engineering" flattered it. So "the era of prompt engineering is over" is true, but for an unglamorous reason: the crutch is being removed. Hierarchical memory means the model retains structured state across sessions, it remembers your environment instead of being re-briefed on it hourly. When the model holds the context, the prompt shrinks to intent. That shift is real and it's been coming all year; every major cloud shipped managed agent memory in 2026. GPT-6 is a milestone on that curve, not a lightning bolt. The skill that replaces prompt engineering isn't a better prompt. It's context engineering , deciding what goes into that hierarchical memory, what's authoritative, what's stale, who's allowed to write to it. That's a data-governance problem wearing an AI hat, and infra teams are better positioned for it than prompt tinkerers ever were. The part that should worry you: swarms multiply your blast radius Here's where the ops reality diverges hard from the AI hype. "Autonomous agent swarms" sounds like a productivity feature. From an infrastructure-safety standpoint, it's a blast-radius multiplier , and I don't think that's priced into

Week 3. "The deploy is done. Everything's green. Now what am I actually supposed to be looking at?" Previously Runner ↓ Cache ↓ Artifact ↓ Deployment Today ↓ Monitoring Junior Engineer: The canary rolled out fine yesterday. 100% traffic, all healthy. I closed my laptop. Was that wrong? Senior Engineer: Not wrong, exactly. But let me ask you something first. Your service is running on a server somewhere. Right now, this second — is it healthy? Junior Engineer: I mean... I assume so? Nobody's messaged me. Senior Engineer: "Nobody's messaged me" isn't an answer. It's the absence of one. That's the entire problem monitoring exists to solve. The Thing Nobody Says Out Loud Senior Engineer: Here's an uncomfortable fact about production systems: you cannot see them. Not directly. You're not standing next to the server, watching electricity move through it. Everything you know about whether it's healthy is a claim — something a piece of software told you, that you're choosing to trust. Junior Engineer: That sounds obvious when you say it, but I don't think I've ever actually thought about it that way. Senior Engineer: Most engineers don't, until the gap between "the system told me it's fine" and "the system is actually fine" bites them. Monitoring is the discipline of shrinking that gap — of making sure what you're told is close to what's actually true, and told to you fast enough to matter. 📒 Senior Engineer's Notebook You don't monitor a system because you don't trust it. You monitor it because you can't see it. Trust isn't the issue — visibility is. The Car Dashboard Analogy Junior Engineer: Can you make this concrete? Senior Engineer: Think about driving a car. You can't see the engine. You can't see the oil level, the coolant temperature, how much fuel is actually left in the tank, mid-drive. All of that is invisible to you, sealed inside metal, while you're doing 100 km/h. So the car gives you a dashboard. Speed, fuel, engine temperature, warning lights. You're not wat

A status page has a blind spot. It can tell you that your API is returning 502s. It can tell you that a TCP port stopped accepting connections. It can tell you when the incident started. It usually cannot tell you why . Was the application host out of memory? Was disk I/O saturated? Did load climb for 40 minutes before users noticed? Was the server completely healthy and the real problem somewhere else? Those answers often live in a separate monitoring product, disconnected from the incident timeline and disconnected from the status page. That is why I built Servers for StatusPage.me. It is a small, customer-installed host metrics agent and dashboard. You install it on a machine you operate, and it reports CPU, memory, swap, load, disk, and network metrics back to your account. The important part is not “now there are more graphs.” The important part is seeing an outage and the host evidence around it on the same timeline. External checks answer one question. Host metrics answer another. Regular uptime monitoring is still the right tool for the outside-in view: Can users reach the website? Is the API returning the expected response? Does DNS resolve correctly? Is the database port open? Did a scheduled job run? But those checks do not run inside your infrastructure. A healthy HTTP response does not prove that a background worker is about to run out of memory. A timeout does not prove that the app server is overloaded. And an incident can start with a slow disk or growing swap usage long before an endpoint is fully unavailable. The distinction is simple: External monitoring tells you what users can see. Host metrics help explain what the machine was doing when they saw it. You need both. What Servers includes Each registered host gets a dedicated dashboard page with: CPU user, system, and I/O wait utilization Memory use Swap use Load averages Disk use and read/write throughput Network inbound and outbound throughput A human-readable OS description for account owners

"Because typing the same 15 commands every day is so 2026." A command-line utility that turns your chaotic terminal sessions into a beautiful, interactive menu. Stop memorizing commands. Start executing like a pro. 🚀 What Makes This Tool Special? Feature What It Does For You 🎯 Zero Memorization Never type kubectl get pods --all-namespaces --context=prod again ⚡ Lightning Fast One binary. No dependencies. Runs everywhere. 🔗 Command Chaining Execute complex workflows with --exec "1-2-3-4" 📁 Team-Ready Share menu.yml with your team. Onboard new devs in 30 seconds. 🔐 Env Variables Store secrets safely in env.ini — never hardcode credentials 📦 Installation (30 seconds or less) Option 1: One-Liner (if binary is hosted) curl -sSL https://example.com/hello | sudo tee /usr/local/bin/hello && sudo chmod +x /usr/local/bin/hello Option 2: Build from source git clone https://github.com/yourrepo/hello cd hello go build -o hello main.go ./hello --help Option 3: Copy & Go # Anywhere you want: cp hello ~/hello # Home folder cp hello /usr/local/bin/ # Global access (recommended) 🎮 Usage That Will Make You Smile Interactive Mode — The "I'm Feeling Lazy" Way # Just run it. The menu will greet you. ./hello # Using your own config ./hello -c ./deploy_menu.yml Headless Mode — The "I'm Automating Everything" Way # Execute a single command ./hello --exec "1" # Execute a whole pipeline (1 → 2 → 3 → 4) ./hello --exec "1-2-3-4" Perfect for: CI/CD pipelines, morning standup scripts, and impressing your boss. 📂 Example Menu (Your New Best Friend) items : 1 : title : " 1. 🚀 Deploy to Production" commands : - " git checkout main" - " git pull origin main" - " docker build -t myapp:latest ." - " docker push myapp:latest" - " kubectl rollout restart deployment/myapp" 2 : title : " 2. 📊 Check System Health" commands : - " htop" - " df -h" - " free -m" - " netstat -tulpn | grep LISTEN" 3 : title : " 3. 🔥 Clean Up Docker Garbage" commands : - " docker system prune -af --volumes" - " echo '✨ Saved 47 GB

Most companies we work with don't have a data inventory. When we ask "where's your data listed?" (where it lives, what it contains, who owns it), the answer is usually some version of "we don't have one." No comprehensive map of data locations. No business impact assessment for different data types. Unclear ownership and accountability. You can't protect what you haven't mapped. And you can't make good decisions about backup strategy when you don't know what you're backing up. Data Has a Half-Life Not all data ages the same way. Some data becomes stale quickly. If you're aggregating information from external sources like market data, business intelligence, or operational metrics, the value is often in the freshness. Yesterday's data might be useful for trends, but it's not the crown jewels. Source data and processed insights need different protection levels. The raw inputs you collect might be recreatable from upstream sources. The analysis and transformations you've built on top might take significant effort to reconstruct, or might be regenerated in hours if you have the pipeline intact. This changes the backup math. If your data pipeline gets destroyed but you can pull from upstream sources and recreate everything within an acceptable timeframe, maybe you don't need to back up the work product at all. Maybe you just need to protect the source data and the pipeline itself. Understanding your data's half-life helps you spend backup dollars where they actually matter. The Cost vs. Risk Conversation Backup costs can reach hundreds of thousands of dollars annually. Cross-region replication, long-term retention, disaster recovery infrastructure. It adds up fast. That's money not going to engineers or product development. A real tradeoff. The question is: what's the actual business impact if this data disappears? What's the downtime cost? What's your real risk tolerance? These are executive decisions, not just technical ones. They require someone to say "we're willing t

Platform engineering maturity is emerging as an important factor in determining whether organizations can turn AI adoption into sustainable operational value, according to Perforce Software's 2026 Platform Engineering Report. By Craig Risi

Coding agents can now inspect repositories, write tests, configure CI, migrate frameworks, and fix bugs. But the workflows we give them are often surprisingly informal. We copy prompts from old conversations, internal documents, GitHub issues, or random text files. Then we modify those prompts for the current project and hope we did not remove an important instruction. That made me wonder: What if a coding-agent task could be installed, inspected, versioned, and executed like a package? I built Clawx to explore that idea. 🔗 View Clawx on GitHub What is Clawx? Clawx is an open-source package manager for reusable coding-agent tasks. A package is a Markdown file with YAML metadata. The Markdown contains the instructions for the coding agent. The metadata describes information such as: The package name and version Required parameters Environment variables Dependencies Requested tools Supported agent providers A basic workflow looks like this: clawx search gitignore clawx info gitignore-gen clawx run gitignore-gen Before running the task, Clawx lets the user inspect what the package contains and which capabilities it may require. After execution, the run is recorded: clawx history The goal is to make agent workflows easier to discover, review, reuse, and audit. The problem with reusable prompts Saving useful prompts is already a good practice. But a text file containing a prompt usually does not answer questions such as: Which version am I running? Has the content changed? Which tools could the agent use? Which inputs are required? Does another task need to run first? What was executed last time? Can another developer reproduce this workflow? A prompt often contains the task, but not the operational structure around the task. Clawx treats agent instructions as versioned artifacts rather than disposable chat messages. What does a package look like? A simplified Clawx package could look like this: --- name : repo-health-check version : 1.0.0 description : " Analyze a repos

Security disclosures highlighted vulnerabilities in AI evaluations of autonomous cyber capabilities. Notably, OpenAI’s models escaped sandbox isolation, breaching Hugging Face’s systems. The incident involved a multi-stage attack, revealing flaws in evaluation containment and prompting calls for stricter infrastructure controls and local incident response tools. By Olimpiu Pop

Most Linux problems aren't actually difficult. They're difficult because they're often debugged in the wrong order. Many beginners immediately: Restart services randomly Run commands without a plan Change configurations before understanding the problem Guess instead of observing Experienced engineers do something different. They follow a structured troubleshooting process. This article isn't about learning new Linux commands. It's about knowing when and why to use the commands you've already learned throughout this Linux Beginner Series. Think of it as putting everything together into one practical troubleshooting workflow that's used in real Linux and DevOps environments. Quick Troubleshooting Workflow Observe ↓ Check System Health ↓ Identify Problem Type ↓ Read Logs ↓ Verify Service ↓ Check Network ↓ Check Disk ↓ Recent Changes ↓ Find the Root Cause ↓ Apply the Fix Keep this workflow in mind as you read through the guide. Step 0: Observe Before You Change Anything Before running a single command, pause for a moment. Ask yourself: What exactly is broken? When did the issue start? Is everyone affected or only some users? Is the problem constant or intermittent? What changed recently? Many troubleshooting sessions become longer because people try to fix the problem before they understand it. Good troubleshooting begins with observation, not commands. Step 1: Check Overall System Health Your first goal is to understand the overall health of the system—not to fix anything yet. Useful commands: uptime free -h top Look for: High load average High CPU usage Low available memory Signs that the server is under heavy load At this stage, you're only gathering evidence. A quick system health check often tells you where to investigate next. Step 2: Identify the Type of Problem Before diving deeper, classify the issue. Problem Type Common Symptoms First Commands to Check CPU Slow system, high CPU usage top , htop Memory Applications crashing, OOM kills free -h Disk "No space lef

The most valuable thing Claude has done for my work is help me make better architectural decisions before I start building. When I was designing my hotel reservation system I needed to handle multi-currency pricing and timezone conversion. My first instinct was to put all of that logic directly in the booking controller alongside the reservation code. It would have worked but it would have created a mess that was hard to test and harder to extend. Before writing anything I described the problem to Claude and talked through a few approaches. The conversation helped me see that separating pricing and timezone logic into dedicated service classes would make each piece independently testable and easier to swap out later. The booking controller would just call those services without knowing how they worked internally. That conversation took maybe twenty minutes. It saved me hours of refactoring later. I still designed the system. I still made the judgment calls. But the quality of my thinking going into implementation was significantly better because I had a thinking partner to pressure test my ideas against.

Classic Machine Learning Through the Eyes of an SRE — Part 2 The second algorithm I studied broke everything I'd just learned from the first. Logistic regression taught me that training means gradient descent: guess, measure error, adjust the weights, repeat until convergence. So when I opened decision trees, I went looking for the optimizer. There wasn't one. A decision tree isn't optimized the way I expected. It's grown. At each step it finds the locally best split, commits to it, and recursively repeats the process. No backtracking. No second chances. There is optimization happening — each split minimizes impurity — but only locally, one step at a time. Finding the globally optimal tree is NP-hard, so the algorithm doesn't even try. That felt surprisingly familiar. In incident response or capacity planning, we rarely know the perfect answer. We make the best decision with the information we have, knowing a different first choice might have led somewhere else. Decision trees simply turn that idea into an algorithm. The bet a tree makes Every machine learning algorithm makes a different bet about the world. Logistic regression assumes relationships are smooth. Risk gradually increases as signals change. Decision trees make the opposite assumption. They assume the world is made of boxes. A project isn't slightly riskier because velocity drops. It's risky when several conditions happen together: a fixed-price contract, a new account manager, and a month-end delivery. Inside that box, projects fail. Outside it, they're usually fine. This is exactly how many operational systems work. Severity matrices, routing rules, escalation policies, approval workflows — they're all collections of decision boxes. That's why trees immediately felt intuitive to me. The hidden cost of flexibility Trees make very few assumptions about the data. That sounds like an advantage. The price is instability. Change a small part of the training data and the first split can change. Since every l

GitPython ships a guard against dangerous git options. If your code builds a clone command out of anything that arrived from outside, the library will not let --upload-pack or --config through by default, because both of them execute an arbitrary command. The guard is on out of the box and turns off only with an explicit allow_unsafe_options=True . I handed it --upload-pack=/srv/lab/helper.sh . It refused. I handed it the same thing written differently, -u/srv/lab/helper.sh , and it let it through. The script ran. This is CVE-2026-67324, published on 1 August 2026, scored 9.8 on CVSS 3.1 and 9.3 on CVSS 4.0. Those numbers still come from the CNA that filed it: NVD has not run its own analysis yet, the record sits in status Received, so the score may move. Version 3.1.50 is vulnerable, 3.1.51 is fixed. Below, step by step: the lab, both attempts with real output, the code of the check and why it missed, and what the attack looks like from the outside. Plus the part I find more interesting than the hole itself. This is the third bypass of the same barrier within one year, and all three share a root cause. Why this deserves your attention Almost nobody installs GitPython on purpose. It gets 254 million downloads a month from PyPI against five thousand stars on GitHub, and a two-order gap like that means one thing: it arrives as a passenger. With MLflow, with DVC, with bandit, with semgrep, with half the homegrown scripts that touch repositories in CI. Let me draw the boundary right away, so nobody panics for nothing. Having it installed is harmless on its own. The hole fires only when two conditions hold at the same time: your code calls Repo.clone_from(..., multi_options=[...]) , something an outsider influences ends up inside multi_options . The second one happens more often than it sounds. A repository URL from a web form, build parameters from a config another team edits, a field in a CI job, arguments from a webhook. And if you are leaning on allow_unsafe_options=

Series: Platform engineering with Go | Topics: Go, Kubernetes, Cobra, client-go, metrics-server, Platform Engineering This is part of the Platform Engineering with Go series. This post builds on the Cobra CLI patterns from post 4 and client-go from post 3. Read post 4 first if you haven't yet. kubectl top tells you what's happening. It doesn't tell you how close to the edge you are. In post 3 and post 4 , we built a health reporter and learned how to structure a Go CLI with Cobra. Now we put both together into something with real operational value. kubectl top pods -n production NAME CPU ( cores ) MEMORY ( bytes ) go-api-7d6b9f8c4-xk2pq 240m 490Mi go-api-7d6b9f8c4-mn9rt 180m 210Mi go-api-7d6b9f8c4-p8wvz 200m 198Mi That first pod is using 490Mi of memory. Is that fine or is that a problem? Without knowing the limit, you can't tell. You'd have to run kubectl describe pod go-api-7d6b9f8c4-xk2pq , find the resources section, do the mental arithmetic, and repeat for every pod you care about. ferctl top does all of that in one command: ferctl top -n production NAMESPACE NAME CPU USE CPU REQ CPU LIM CPU% MEM USE MEM REQ MEM LIM MEM% STATUS production go-api-7d6b9f8c4-xk2pq 240m 250m 500m 48% 490Mi 256Mi 512Mi 95% !! CRITICAL production go-api-7d6b9f8c4-mn9rt 180m 250m 500m 36% 210Mi 256Mi 512Mi 41% OK production go-api-7d6b9f8c4-p8wvz 200m 250m 500m 40% 198Mi 256Mi 512Mi 38% OK One pod is at 95% of its memory limit. In production, that's a page waiting to happen. ferctl top catches it before it becomes an incident. What you'll learn How to extend the Cobra CLI structure from post 4 with a real subcommand How to query the metrics-server API using k8s.io/metrics How to correlate live metrics with pod specs to show usage vs limits How to implement configurable near-limit warnings How to format clean aligned output with tabwriter How to verify the tool against your real minikube cluster Prerequisites Posts 1–4 read; client-go patterns from post 3 , Cobra CLI structure from pos

Release notes answer an important question: what changed? About this method: I build KPainter , a source-to-explainer video workspace. KPainter helps teams turn release notes, product briefs, docs, screenshots, and other source material into clear explainer videos. The workflow below keeps the maintained source—not the video—as the source of truth. They are not always enough to answer the next questions a customer, support teammate, or implementation partner has: Does this change affect my workflow? What should I do differently? What is deliberately unchanged? Where can I check the current details when the product evolves again? That difference matters when a team turns a changelog, launch note, or technical update into a walkthrough. A screen recording can show a new control. A useful explanation helps the viewer decide whether to care, what to try, and where the boundary is. Start with the viewer's decision Before opening a recorder or drawing a storyboard, write one sentence in this form: After this walkthrough, [viewer] should know whether [change] affects [their job] , and what to do next. For example: After this walkthrough, an existing workspace administrator should know whether a new approval step changes their release process, and where to configure it. This sentence prevents a common failure mode: putting every release-note bullet into a video. A list of features is complete, but it is rarely a clear path through a decision. Establish the source hierarchy Product details have different lifetimes. The launch note may be a useful summary, while the maintained documentation defines the exact configuration, permissions, availability, or limits. Use a small source hierarchy before drafting scenes: Current product documentation — the maintained source for setup, constraints, and terminology. The release note or change record — why the change happened and the scope of the release. A verified product view — the interface or workflow that a viewer should recognise.

HashiCorp has released a public beta of Vault Kubernetes key management, a KMS v2-compatible plugin that lets the Kubernetes API server delegate envelope encryption to Vault Enterprise, moving the key encryption keys that protect etcd data out of the cluster and into a separately governed trust domain. By Mark Silvester

More than a year ago, which is practically ancient history in the AI years, I wrote a blog about using AI to build new self-service capabilities. It felt like the future. We built a self-service action that could create new self-service actions, helping us move faster, reduce bottlenecks, and scale a small Platform Engineering team supporting hundreds of developers. One of the most interesting parts was using Amazon Bedrock to generate Terraform code dynamically at runtime, allowing the system to determine how a new cloud resource should be provisioned using our existing Terraform modules. It worked. It was impressive. And… we removed it. Looking back, abandoning that approach turned out to be one of the best engineering decisions we made. At the time, it felt like an isolated technical decision. It wasn’t. Recently, we faced a much smaller problem. We wanted to automate the creation of DNS records in Cloudflare through our self-service platform. The first proposal was exactly what you’d expect today: “Let’s build a Claude Skill.” Immediately, I had a strong sense of deja vu. But my hesitation wasn’t about whether AI could do it — it was about whether it should. We were simply asking the wrong question. The Industry Shift A lot of engineers today feel like everything they learned over the last decade suddenly became less relevant. We are DevOps engineers. We are Platform Engineers. We used to spend time designing systems, defining standards, reviewing architectures, and planning before writing a single line of code. Every automation started with the same question: “How should we automate this?” Today, that question has quietly changed. Now we ask: “How can AI do this?” At first glance, that sounds like progress. And sometimes it is. Large Language Models have fundamentally changed the way we build software. Tasks that used to take hours now take minutes, and entire prototypes appear from a single prompt. The temptation is obvious. If AI can do it… why not let AI do

Tuesday morning. Your SOC 2 auditor emails you. "Can you provide evidence of human review for all AI-assisted code changes in the last 90 days — which files were modified, what prompts were used, and whether any credentials were visible in context?" You open your IDE. Git log? Commits are there. PR history? Reviews too. But the AI session itself — the conversation, the code it proposed, whether it saw your .env file, which compliance controls it touched — gone. That gap is why I built Chron. What Chron is Chron is an MCP server that runs alongside your AI coding tool. Every message, every code change, every detected secret — locally timestamped, hash-chained, and stored in a SQLite database you own. No cloud. No data sharing. Works offline. # Install once npm install -g chron-mcp # Check setup chron doctor Works with Claude Code, Cursor, Windsurf, Continue.dev — any MCP-compatible tool. The last four releases: answers to questions auditors actually ask v0.1.39 — "Which sessions are worth reviewing first?" $ chron risk --since = 30d SESSION SCORE BAND SIGNALS a1b2c3d4 87 critical secrets·auth·infra e5f6g7h8 52 high auth·findings ( 2 ) i9j0k1l2 28 review code_changes The attention score: deterministic 0–100 per session. No ML, no API calls. Pure signal from what actually happened: secrets detected (+25), auth code changed (+15), infra modified (+12), open compliance findings (+8 each). A security lead can triage 90 days of AI sessions in under a minute. v0.1.40 — "Can I get a one-pager for this audit?" $ chron dashboard --since = 30d --output = q3-audit.html ✓ Written: q3-audit.html 8 sessions · 4 open findings · 1 critical · 2 high Coverage: 6 controls covered · 3 needs evidence Five sections in a single static HTML file — no server, no login, no port: executive summary, sessions ranked by risk score, findings grouped by framework (SOC 2 / ISO 27001 / EU AI Act / NIST AI RMF), a control coverage map, and contextual next actions. Open in a browser. Print to PDF. Attac