Albert Sikkema - Building Production AI Systems

Fully Automated LLM Builds: Where It Actually Stops

2026-04-17T00:00:00+00:00

A lot of moving parts that have to mesh. Photo by Kiwihug on Unsplash.

For the last year or so I have been automating my software build workflow, handing more and more of the actual development work over to LLMs and watching where it breaks. The builds mostly run themselves now with good quality code, good enough that I can hand off that work and check back an hour later on the progress (or react to the Telegram message telling me a PR is waiting).

This is the point I was aiming for when I started iterating on automated LLM-driven development a year ago. There were quite a few steps in between with different levels of automation, tools, start all over again, improve etcetera.

What I Found to Be Bottlenecks

Three things I suspected but could only experience and prove by running the loop:

You cannot skip the human review. Left alone long enough the agent will drift. Possibly not in the first couple of PRs. But somewhere between 5 and 10 it will make a decision that looks locally correct and is globally wrong, and every PR after that builds on the drift. No amount of prompt engineering fixes this (and I tried a lot of methods). I wrote about the same pattern with meta-tests last November and it is still true, just with a bigger blast radius now that the loop is tighter.

Work item size matters. Too small and you burn tokens spinning up six agents to change a button color. Too large and the model cannot hold the whole thing in its usable context and produces something that seems plausible or it does not get anywhere at all (one word of advice: set up a max number of turns, some processes can go on for hours spinning in a logical loop without progress). The trap is assuming “size” maps to the human version of the word. It does not. Eight hours of copy-paste work is boring, not complex, and the LLM will do it in seconds. A 15-minute architectural decision can be too much for the model because it needs judgment the model does not have. The right granularity for an agent queue is not a human time estimate, it is “how much context and judgment does this require,” and you have to learn that shape by running the loop and watching where it breaks. Getting the backlog granularity right is now a separate skill. And automating that part is the challenge: I start to reach the conclusion that with the current models this is not possible. And perhaps we can even say that with LLMs as we know it, this will highly likely never be possible (not until we get different kinds of intelligence). So there is the human role again.

Reviewing LLM code all day is boring. This one is mostly about me, but I do not think I am alone. When you do not write the code yourself, the mental connection is gone. I have to search for everything. When I wrote (parts of) the codebase myself, I knew my way (that data model contains this, we have a helper function for that, etc). You are reading prose somebody else wrote in a codebase you do not know by heart, with the added complication that the entity (in the broadest sense) that wrote the code does not learn from your feedback across sessions (you can use memories to persist, but that is not learning). After a few hours your attention drops and you start approving things you would not have approved in the morning. And the idea that the future holds endless PR reviews every day for the rest of my life is not really motivating, especially since code will be produced so fast that the pipeline will always be full and waiting for you.

The Review-Triage-Fix Loop

The first two problems I can partly engineer around. The third one I can only manage.

What I experimented with, and works better than anything else I tried, is a review loop with three stages before a human sees it:

A very critical review, with explicit checklists, run by a strong model. Not “looks fine” but “hunt for everything.” Complete, pedantic, slightly paranoid. Use multiple agents all focused on certain angles to look at the codebase.
A triage pass over the findings. What actually needs to be fixed now? What goes on the backlog? What is wrong but not wrong enough to matter?
A fix pass on the must-fix items and fix them automatically.

One run of the loop: plan, build, review, triage, fix, all green. 51 minutes, 407 turns, 111k tokens, one PR out the other end.

Then and only then the human looks. By this point the easy stuff is handled, the backlog has captured the medium stuff, and the human is adding judgment.

This works. The reviews get caught early, the agent stays on track, and I can intervene at the point where my time is worth the most. But two things crack under load.

Cost

Each loop eats a lot of tokens. A critical review is not a two-line “LGTM” prompt, it is pages of context, guidelines, and targeted checks. The triage step needs the full review output. The fix step needs the triage output plus the original code plus the repo context. Do this on every PR and the bill adds up.

And having the human only intervene at the PR stage means a lot of work has been done before. If the PR is turned down or changes (possibly big ones) need to be made, this adds to the costs.

Opus 4.6 runs $5 per million input tokens and $25 per million output tokens. That is one of the most expensive models that are currently available. It is even more expensive at scale with this approach: every feature goes through several expensive passes before a human is even involved. Caching helps, batching helps, but the floor is still non-trivial. And it is of course the most fun to have several processes run at once (let’s say I can burn through my Claude Code token limits in no time). And then the extra usage starts, most of the time I am at 1 euro per hour. Not sustainable for the long run unless you are deeply funded and have money to burn (literally almost). So needless to say that I turned that off for most projects I work on.

The obvious question is whether you can drop to a cheaper model for some of the stages. I have tried, and the answer is no for most work. What works for me is Opus on planning and review, Sonnet on building. Results are better with Sonnet on everything, but token usage is a factor. I have never found a use for Haiku in this loop, and anything smaller than Sonnet on the build stage just breaks. The reviews from a weaker model miss the subtle stuff or flag perfectly fine code as breaking issues. A mediocre review is worse than no review because it gives you false confidence, the human at that point has to be able to trust the review done automatically. That is not the place to save tokens. Every time I have tried to save tokens by running a cheaper model somewhere in the chain, the quality drop caused rework, and the rework cost more tokens than I saved. The cheap option is, in the end, the expensive option. Given the hourly rate of the developer and the costs of tokens you can do a nice calculation of what it costs: in the end the human is more expensive. So making it easy for the human is key: less time spent per feature is cheaper. But rework costs extra time.

Fatigue

The other problem is me (or developers in general). I can absorb code and automated reviews in a PR for a while, but only a while. Staring at well-structured PR summaries and deciding “yes, agree, ship it” over and over is draining in a way that writing code is not. You are in evaluation mode all day and never in creation mode, and evaluation mode runs on a smaller battery.

The obvious fix is to take the human out of every review, but that runs straight back into lesson one. Automated reviews alone miss things an experienced developer would catch in thirty seconds. A well-rested, motivated, experienced developer is still a better reviewer than any model I have tried, even with careful prompts and all the checklists in the world.

An interesting sub-observation: the automated review is probably better than a significant fraction of what developers do in practice. I would guesstimate 40%, with no hard numbers to back that up, based on the PR reviews I have seen from myself and colleagues over the years. Tired reviewer on a Friday afternoon versus an LLM run on a critical-review prompt? LLM wins, most of the time.

The Ceiling

So what is blocking the next step, where I can trust the loop without babysitting it every few PRs?

Two things, and they are linked.

Tokens. Cost and availability. I need to run more review passes, with more context, on more PRs, and I cannot unless the per-token cost drops or the rate limits go up. Right now a busy day maxes out my limits before I am done, which is its own kind of bottleneck. Combine that with recent changes in Anthropic weighing tokens used between 14 and 22h (that is in my timezone) and it means having this run after 2 in the afternoon makes it even more expensive. And a few times per week connections fail, so lots of problems there.

Smarter models. Specifically, smarter models that I can run locally. Not because I want to self-host for the sake of it, but because local inference is how the per-token cost drops. The current local options are getting genuinely good. Qwen3 Coder Next scores 44.3 on SWE-Bench Pro, above DeepSeek-V3.2 and GLM-4.7. Qwen 3.5 hits 76.4 on SWE-bench Verified, level with Gemini 3 Pro. Gemma 4 is a real step up from Gemma 3.

But Opus 4.6 still wins on the hard stuff: multi-file reasoning, long-horizon planning, the kind of review where you need to hold a whole architecture in your head. And the critical review stage is exactly that kind of work. For me to move the review loop onto local hardware, the local models need to at least match what Opus 4.6 does today, not approximately match it. We need something closer to Opus 4.6+++, running on a box in my office, before this flips.

That will happen. Local models are improving fast. But it is not this year.

And Then There Is Electricity

AI data center demand is pushing electricity prices up across Europe. Goldman expects a 10 to 15% boost to European power demand over the coming 10 to 15 years, mostly from data centers. The IEA puts global data center consumption on track to approach 1,050 TWh by 2026, which would rank data centers between Japan and Russia if they were a country.

On top of that, the situation in the Middle East has pushed physical crude oil prices near $150 a barrel, with shipping through the Strait of Hormuz still severely restricted. Energy, in other words, is getting more expensive while AI is driving demand higher, and both lines are bending up. Thankfully we have wind and sun.

So even the local-hardware dream has a cost floor (not forgetting the rising costs of RAM and GPUs). Running Opus-class models on your own machine still takes a lot of watts and decent hardware.

Where This Leaves Me

The review-triage-fix catches more than manual review alone. It produces better PRs than pure automation. It lets me spend my attention on the decisions that need attention.

But it is not the end state. The end state, where I can let the builds run themselves, is gated by two things I cannot fix on my laptop: cheaper strong-model inference, and a local model that reaches Opus 4.6 plus. Until those arrive I am more or less at a standstill when it comes to further improvement.

Which is fine if you look back at what is now possible that was not possible only three years ago when all this started for me. I have run worse loops. And in the meantime I have learned a lot about where the human adds value in this stack, which is probably the most useful thing you can learn right now.

If you are running a similar loop and have found something that works better, I would really like to hear about it.

Automating builds, tuning review loops, or stuck on the same ceiling? Get in touch to compare notes.

Resources

Models and pricing

Claude API pricing - Official Anthropic pricing for Opus 4.6 and other models
Anthropic API pricing deep dive - Caching and batching cost breakdown
Qwen3-Coder-Next on Hugging Face - Open-weight coding model
Qwen 3.5 benchmarks - SWE-bench and real-world results
Gemma 4 on Ollama - Local deployment
Can anyone beat Claude Opus? - Open vs commercial comparison

Energy and infrastructure

IEA: Energy demand from AI - Global data center projections
Goldman Sachs on AI electricity demand - European power demand forecast
IEA Oil Market Report April 2026 - Current supply disruptions
Middle East crisis and global oil demand

Human in the Loop - Why human review still matters
When LLMs Actually Deliver - The tooling that makes LLMs useful
gtk: Filtering CLI Noise to Save Tokens - Related token-cost work

When LLMs Actually Deliver

2026-04-16T00:00:00+00:00

Many signals, one panel. Photo by Frantisek Duris on Unsplash.

I have a love/hate relationship with LLMs (mostly love, but every now and then I get frustrated).

One moment they nail a complex refactor across six files. The next they confidently introduce a bug that any starting developer would (probably) catch, or hallucinate an API that has never existed. The swing between brilliant and stupid can happen within two turns of the same conversation. Every time you start to trust, even a little, that trust is crushed to bits.

But every now and then something happens that makes you stop and think: this changes things. (especially if you suddenly realise how complex and time-consuming some tasks were before)

One Sentence, Thirty Seconds

This morning I opened Claude Code and typed one sentence:

Please check the logs for production of over the last 24 hours. Then check the PRs made to see if the uploaded changes in the last 3 days have made a difference.

Thirty seconds later I had:

A full breakdown of all log events with error rates per hour
Error classification by type, with counts and affected tenants
A correlation table showing how each merged PR impacted specific error categories
A before/after comparison: ‘clarifyinput’ errors dropped from 29 to 2, OpenAI errors from 43 to zero
An explanation of why icon errors went up (improved logging granularity, not a regression)
Three concrete action items with root causes identified

Really helpful: the LLM didn’t just count errors – it ‘understood’ that PR #458 changed the logging format from a generic “fetching” message to per-icon “loading” messages, and correctly concluded that the apparent spike in icon errors was an artifact of better observability, not a regression. That kind of contextual reasoning across log data and code changes used to take me an hour of cross-referencing. On a bad day, longer.

Before this, checking whether a deploy improved things looked something like:

Open the logging dashboard, set the time range, filter by severity
Stare at graphs, try to spot patterns
Open GitHub, find PRs merged in the relevant window
For each PR, read the diff and figure out which error messages it should have affected
Go back to the logging dashboard, write queries for those specific error messages
Compare before/after time windows
Write it all up in your head or in a document
Repeat for each PR

If you had proper dashboards and saved queries this was maybe an hour. Without them, half a day. And you had to know what to look for in advance – if a PR had an unexpected side effect, you might miss it entirely.

Apart from the time it took, also the mental drain to check the logs: it takes time and energy but does not create a solution. It is not even about getting to know the scope or the cause of the problem, the energy is consumed by using tools itself, forcing you to spend mental energy on using the tools to actually see if there IS a problem. And now that energy can be put towards seeing the problem and moving on to what we get paid for: thinking about how to solve the problem.

All I had to do is decide if I agree with its conclusions (about 60% of the time I do), and decide how to tackle the issues.

The Playbook Is Everything

The LLM did not do this on its own, left to its own with this instruction it would not have access to the logs and the repo so it could not do anything at all. Even when it has API access to the logs and would have connected to the repo, results would be not as good as this. The model would have fumbled with authentication, guessed at query syntax, missed fields, and produced a surface-level summary that looks impressive but tells you nothing you didn’t already know. And it would not remember next time how it should query to get to a certain result.

What made this work is that I built the tools and the playbook first. (Logbench is one of several tools I built for this; another is gtk, which filters CLI output to save tokens.)

Logbench is a small MCP server I wrote in Go. It connects to our Axiom log platform and exposes a handful of tools: query_apl for running raw queries, explore_dataset and error_breakdown for guided analysis, get_dataset_schema so the LLM knows what fields exist. Nothing fancy. But each tool has a clear contract: here is what you pass in, here is what you get back. (why not the official Axiom MCP server? We are on a separate version (eu) and the official server does not work with that. I did take inspiration from their code though.) Besides I added some extra steps to find certain information that is unique to this implementation.

The key is the prompted workflows. Logbench doesn’t just expose raw query access. It includes structured playbooks: “when investigating errors, first get the schema, then run an error breakdown, then drill into the top categories.” The LLM follows the playbook instead of improvising.

So the LLM is not being creative here. It is following a recipe for how to query the logs for certain often needed results. And then the starting prompt turns into a logical order:

Get the dataset schema (know your fields)
Run aggregate queries (get the big picture)
Break down errors by message (find the categories)
Get recent PRs from GitHub (know what changed)
Run time-windowed queries per error category (measure impact)
Cross-reference and synthesize (connect the dots)

Each step is a tool call with predictable input and output. The LLM’s job is to orchestrate the steps, handle errors (like when a field name is wrong – it recovered and tried bracket notation), and synthesize the results into something a human can act on. (This is the same orchestration principle I described in automating Claude Code workflows, but applied to log analysis instead of code.)

The IFs

This only works:

IF you give them the right tools. Not raw access to everything, but curated tools with clear interfaces.

IF you give them a playbook. Not “figure it out” but “here are the steps, follow them.”

IF the tools handle the hard parts. Authentication, query syntax, field validation, error formatting – all of that lives in the MCP server, not in the prompt.

Without those guardrails the same model will confidently query a field that doesn’t exist, and present wrong conclusions with the same authoritative tone. (I wrote about building these kinds of guardrails in more detail previously.) Because that is what I observed starting out during development, before the playbooks and extensive query examples were in place.

The Pattern

Sometimes LLMs are truly brilliant and come up with solutions that are elegant and useful. Most of the time they do not. Apart from those moments of brilliance, every time I have seen an LLM deliver useful results this was because of:

Structured tools with clear inputs and outputs
Guided workflows that tell the model what steps to follow
Domain knowledge baked into the tools
The LLM as orchestrator and synthesizer, not as domain expert

That is a fundamentally different use case than “write me a function” or “refactor this class.” It is closer to having a junior analyst who can follow a checklist very fast and write a surprisingly good summary. You still need to build the checklist and the tools.

Love/Hate, But Mostly Love Today

I will go back to being mad and amazed at hallucinated facts and stupid ideas and authoritative tone tomorrow. The love/hate cycle continues. But moments like today are a reminder that the frustrating parts are worth pushing through, because when it clicks – when the tools are right and the playbook is clear – the result is something that was not possible two years ago.

Not because the AI is intelligent in itself, but because the system around it is. (which with some philosophical reflection is not far from how we humans function). Have a nice day!

Logbench is not public – it is custom built for internal use. Interested in building something similar? Get in touch.

gtk: Filtering CLI Noise to Save LLM Tokens

2026-04-09T00:00:00+00:00

Filtering out what you don't need. Photo by Eiliv Aceron on Unsplash.

A few weeks ago I ran into rtk (Rust Token Killer), a CLI proxy that filters command output before it reaches your AI coding agent. The idea is brilliant: most of what git log or cargo test spits out is noise the model doesn’t need. Strip it, and you save tokens. (and limit the total context you build up over the run of several back and forths)

I liked the concept but not the scope. rtk is written in Rust and supports a lot of features I’ll never use. And for a lot of my workflow it is important to have a full response on git diff and PR: rtk does not do that and I found no easy way to alter this. So I did what any reasonable developer would do: I took the principle and rewrote it in Go with only the parts I care about.

The result is gtk (Go Token Kit): a quick-and-dirty single static binary with no dependencies and 87 filters across the tools I actually use. It is not public (it is not polished enough for that, and rtk already exists), but the principles behind it are worth sharing.

Does it save as much as rtk suggests? I don’t know because I do not measure the total tokens saved. And every now and then you have to rerun the command to get the output without gtk intervention, so that is an extra call which makes a lot of what you saved before not useful anymore. So overall I think that I do not save as much as rtk claims, my guesstimate is at 10-15%: still more than enough to justify using it.

Why This Is Worth Caring About

In a typical Claude Code session, CLI output is the largest source of (wasted) tokens. Run go test ./... with 100 passing tests: hundreds of lines of noise. Multiply that by dozens of commands per session. And all you actually need for that step is: did the tests pass? Nothing more. One analysis found that AI coding agents spend 60-80% of their token budget on orientation (finding things, reading output), not on actual problem-solving.

Tokens aren’t free, every token gets consumed by the LLM and costs money, and since the context is passed on every interaction, this adds up. Also tokens eat into your context window, which means shorter useful conversations before the model starts forgetting earlier context. They slow down responses (more input to process) and irrelevant context actively degrades LLM performance.

gtk (and rtk) cuts that down. A git log -20 that would produce 2,000 tokens comes out as ~120 tokens (hash, subject, date, author). A test run with 100 passing tests becomes a single summary line. The savings add up fast.

[gtk: 2054 -> 118 tokens, 94% saved]

That hint prints to stderr after every filtered command. It’s a nice reminder that the thing is actually working. And gives an idea about what is passed to the LLM instead of the full output of the previous step.

How It Works

gtk operates in three stages:

Argument injection. Before running the command, gtk can modify arguments to get more parseable output. It injects -json into go test, --pretty=format:... into git log, --reporter=json into vitest. It checks whether you already specified these flags, so it never overrides your intent.

Execution. Runs the real command, captures stdout and stderr, preserves the original exit code. If go test fails with exit code 1, gtk returns exit code 1.

Filtering. Applies one of 87 registered filters to compress the output. If no filter matches, output passes through unchanged. If a filter errors, you get the raw output as fallback. It never blocks you.

The filter strategies vary by what makes sense for each command:

Strategy	What it does	Example
Elimination	Strips passing tests, compilation progress, hint lines	`cargo test` only shows failures
Compression	One line per item instead of multi-line blocks	`git log` becomes hash + subject + date
Deduplication	Replaces timestamps and UUIDs with placeholders, counts occurrences	Repeated log lines collapse
Structured parsing	Parses JSON output into summaries	`go test -json` becomes “100 passed in 2 packages”
Truncation	Caps long lines and large result sets	Lines cut to 80-120 chars
Masking	Replaces sensitive values with `****`	Env vars containing “secret”, “token”, “password”

The Part That Makes It Actually Work

If the AI has to remember to prefix every command with gtk, it probably will (sometimes). Inconsistency is the norm with LLMs.

So to make sure this always runs, we need to make sure that Claude does not have to remember it: Claude just runs git log -10 normally. A PreToolUse hook is called: it intercepts the command and rewrites it to gtk git log -10 transparently. You can compare it to a proxy in a way (or middleware): it intercepts the command, does some things to it, runs the altered command and then returns the cleaned output.

The hook checks if the command starts with a known prefix and prepends the gtk binary path. Commands with pipes or chains are left alone, since those already have their own filtering. (and also more pragmatic: are too difficult to reliably recreate with gtk)

var gtkPrefixes = []string{
    "git ", "cargo ", "go test", "go build", "gh ",
    "docker ", "kubectl ", "npm ", "pytest ", "curl ",
    // ... 24 prefixes total
}

func tryGtkRewrite(command string) string {
    if strings.ContainsAny(command, "|") { return "" }
    if strings.Contains(command, "&&")   { return "" }

    for _, prefix := range gtkPrefixes {
        if strings.HasPrefix(command, prefix) {
            return gtkBin + " " + command
        }
    }
    return ""
}

This is the same hook I wrote about in Securing YOLO Mode, except now it does three jobs instead of one:

Security patterns – blocks dangerous rm, fork bombs, force pushes to main, reverse shells, credential exfiltration
Deny list – project-specific glob patterns from settings.json converted to regex at runtime
GTK rewrite – the token optimization layer

One binary, three layers. In container mode (CLAUDE_CONTAINER_MODE=1), local-only threats like rm -rf are skipped since the container is disposable, but network and escape checks stay active.

Why Go Instead of Rust

The original I took inspiration from is written in Rust. It works well. But I like Go, had little time and thought this should work just as well: Go compiles to a static binary just like Rust and is more than fast enough. Cross-compilation is trivial (GOOS=linux GOARCH=amd64 go build). And adding a new filter is just writing a function and registering it in a map. Easy does it.

I also dropped everything I don’t use. rtk supports Gradle, Maven, Swift, .NET, Terraform, and others, and integrates with Cursor, Gemini CLI, Aider, and other agents. I don’t work with any of those tools, and I only use Claude Code. My version covers git, go, cargo, docker, kubectl, npm, pnpm, pytest, eslint, tsc, prettier, vitest, curl, and a few more. That’s it.

Bypass When Needed

Sometimes filtered output hides what you need. The escape hatch is gtk proxy:

gtk proxy git log -10   # full unfiltered output

You need this when:

Filtered output doesn’t explain a failure
You want to see passing tests, not just failures
You need full diff content, not just stats
A warning or log line might be relevant to the issue

Claude is aware of the option to bypass and is instructed to use gtk proxy whenever the output is not clear (for instance a failing test is only labeled as failed, without the details). When confronted with that, Claude can rerun the command with gtk proxy to get the full original output.

In practice I see Claude using this a few times a day. The filters are conservative enough that failures and errors always come through, but since this happens regularly, the savings are not as great as one would expect at first.

What It Doesn’t Do

gtk is not a general-purpose output compressor. It doesn’t try to summarize arbitrary text or use any AI to decide what’s relevant. Each filter is hand-written for a specific command and knows exactly what matters for that command. There’s no magic, no heuristics beyond “does this line match a known noise pattern.”

It also doesn’t help with non-CLI token costs. If you’re burning tokens on large file reads or massive prompts, gtk won’t touch those. It only filters shell command output. It only works on bash commands.

The End Result?

Inconclusive. I think I save tokens, but not as much as I hoped: it is not a day and night difference. It is hard to properly measure. Does the LLM result improve? Hard to say. Do I get more meaningful conversations? Hard to say. Does Claude’s regular use of gtk proxy negate the savings? Not completely, but it happens often enough to have an impact.

The only way to say for sure requires a lot more data and a lot more proper testing. Not something I am going to do. For now I will keep it running in my setup: it does no harm and I think I see a benefit in token usage, but I cannot prove it.

If the concept interests you, just use rtk. It is well-maintained, supports more tools than my version, and integrates with most AI coding agents out of the box. I built my own because I wanted to customize the filters for my specific workflow, but for most people rtk will do everything you need.

Building your own Claude Code tooling? Get in touch to compare notes.

Resources

rtk (Rust Token Killer) – the original Rust project that inspired gtk
rtk website – documentation and install instructions for rtk
Claude Code Hooks Reference – how PreToolUse hooks work
Securing YOLO Mode – my earlier post on using hooks for security

Security by Design: Using Project CodeGuard as AI Guardrails

2026-04-07T00:00:00+00:00

Security by design, the natural way. Photo by Viktor Smoliak on Unsplash.

In the previous two posts I shared 18 best practice files that keep AI-generated code production-ready, covering architecture, error handling, security, privacy, accessibility, and more. Those are my own distillations, written from experience and grounded in standard and literature. This post adds another layer: security by design (or better ‘early implementation’)

The rules come from Project CodeGuard, an open-source, model-agnostic security framework maintained by CoSAI (Coalition for Secure AI) and originally developed by Cisco. The framework provides over a hundred security rules derived from OWASP cheat sheets and CWE guidance, formatted specifically so AI coding agents can use them during code generation and review.

I’m not going to walk through every rule, there are 109 of them and that would be a very boring read. Instead, I’ll show how I’ve wired them into my Claude Code setup so they activate at the right moments, and how you could do something similar regardless of your tooling.

What is Project CodeGuard?

Project CodeGuard ships two sets of rules:

Core rules (22 files) cover broad security domains: input validation, authentication, authorization, session management, cryptography, file handling, logging, container security, supply chain, privacy, and more. These are language-tagged, each file lists which programming languages it applies to in its YAML frontmatter.

OWASP rules (86 files) are more granular. They map closely to individual OWASP Cheat Sheets: SQL injection prevention, CSRF, XSS, content security policy, JWT handling, OAuth2, Docker security, Kubernetes security, GraphQL, REST assessment, and dozens more.

The format is straightforward. Each rule is a markdown file with YAML frontmatter listing the applicable languages and a description. The body contains the actual guidance: principles, do/don’t patterns, code examples in multiple languages, and implementation checklists. Here’s a taste of the authorization rule:

---
description: Authorization and access control (RBAC/ABAC/ReBAC, IDOR, mass assignment, transaction auth)
languages: [c, go, java, javascript, php, python, ruby, typescript, yaml]
alwaysApply: false
---

## Authorization & Access Control

### Core Principles
1. Deny by Default
2. Principle of Least Privilege
3. Validate Permissions on Every Request
4. Prefer ABAC/ReBAC over RBAC

The rules don’t guarantee secure code. They steer the model toward safer patterns and away from common mistakes. Think of them as a knowledgeable colleague looking over the model’s shoulder, one who has memorized every OWASP cheat sheet.

How I Use Them

I’ve built a fairly extensive Claude Code setup with custom commands, agents, skills, and helper scripts, more than what most people will have. The examples below show how I’ve wired the rules into that setup. Your setup will look different, and that’s fine. The underlying pattern is what matters: load the right rules at the right moment, not all of them all the time.

The rules sit in memories/security_rules/ with two subdirectories: core/ and owasp/. They’re not loaded into every conversation, that would burn tokens on rules about Kubernetes security when you’re writing a Python CLI tool. Instead, they’re pulled in selectively by the parts of my setup that need them.

Planning Phase Risk Analysis

Before writing a plan, my setup spawns a quality risk analyzer agent. It takes the feature description, figures out which security areas apply (does this feature handle user input? sessions? file uploads?), reads the relevant CodeGuard rules, then surfaces risks and recommendations that get baked into the plan itself.

The result is that security considerations don’t popup at review. They’re in the plan from the start, with specific rules referenced. The developer (or the model) knows what to watch for during implementation. (Which does fit the security-by-design paradigm nicely)

Security-Aware PR Reviews

My PR review workflow spawns multiple agents in parallel, code quality, test coverage, best practices, and security. The security agent is where CodeGuard rules come alive.

The agent’s instructions include a mapping table: if the diff touches user input, load the input validation rules, etcetera. The agent reads the relevant 3-5 rule files, then applies them against the actual changed code.

| If code handles...  | Read these rules                                          |
|----------------------|----------------------------------------------------------|
| User input           | input-validation-injection, injection-prevention          |
| Authentication       | authentication, password-storage, credential-stuffing     |
| Authorization        | authorization-access-control, insecure-direct-object-ref  |
| File operations      | file-handling-and-uploads, file-upload                    |
| Docker/K8s           | devops-ci-cd-containers, docker-security, kubernetes      |

This is the same table that appears in the agent definition, the code audit command, and the quality risk analyzer. This makes sure that there is consistency in mapping across all those steps.

Full Security Audits

My code audit command runs a full security analysis across 18 areas, split into three phases: critical controls (data isolation, injection, authentication, XSS, file uploads, secrets), security configuration (rate limiting, CSRF, RBAC, database, logging, third-party integrations), and implementation patterns (secure coding, error handling, API security, frontend, dependencies, performance).

Phase 0 of this audit is “framework discovery”, it detects the tech stack, then loads the relevant CodeGuard rules filtered by language. The audit then cross-references findings against both my own best practice files and the CodeGuard rules, giving two independent perspectives on the same code.

How You Could Use Them

You don’t need my specific setup to benefit from these rules. Here’s the general pattern:

Step 1: Get the rules. Clone the Project CodeGuard rules repository. The rules are in core/ and owasp/ directories.

Step 2: Put them where your agent can find them. For Claude Code, that means somewhere in your project directory or a path your configuration references. I use memories/security_rules/ but any path works.

Step 3: Don’t load everything. The rules total a lot of tokens. You benefit costwise from selective loading based on what the code actually does.

Step 4: Build a mapping. Create a simple lookup: “if the code handles X, load rules Y and Z.” This is the most important part. Without it, you either load nothing (useless) or everything (expensive and noisy).

Step 5: Wire it into your review/audit workflow. Whether that’s a custom command, a hook, a skill, or just a prompt, the rules need to be loaded at the point where security matters. That’s in planning and review.

The rules also come with a SKILLS.md template that you can drop directly into coding agents that support skills (Claude Code, Cursor, Copilot). The template defines when to activate the skill and how to apply the rules based on what the code does. I do not use it as a skill. Why? Because that would imply that I need to think about it, and the whole point is that I do not need to remember using it, but that it is part of everything I do. So it should be there in the background, just out of sight but always there and steering the plans and reviews.

Why External Rules and Not Just “Be Secure”

Simply prompting “Write secure code” is not gonna work for you. It is too simple, too broad and does not comply with the idea of security by design.

The model has extensive security knowledge in its training data. The art of getting this to work is activating the right knowledge at the right time. When you load a CodeGuard rule about SQL injection prevention, you’re not teaching the model something new, it has a lot of data about injection prevention: you’re simply telling it “this is relevant right now, apply it.” The rule contains specific patterns (use parameterized queries, never concatenate user input into SQL, use least-privilege database users) that the model knows but might not prioritize without the prompt.

This is the same principle behind the best practice files from the previous posts: bring specific knowledge to the front of the model’s attention when it matters. The good thing is that CodeGuard rules are maintained, OWASP-backed, and cover a broader surface than I could write.

Keep in mind that this does not make your code secure: it still is up to you to decide if it is secure in your context. But in my experience this does help a lot! (My automated code reviews have never been so sharp and to the point as now I started applying these principles.)

Try It Yourself

The CodeGuard rules are available from the Project CodeGuard rules repository. The best practice files from the previous posts are in my public repository. Grab what’s relevant to your stack and wire them into your workflow.

Have questions or want to share your approach? Get in touch.

References

Project CodeGuard (old Cisco repo), the framework
CoSAI / Project CodeGuard (OASIS), the CoSAI-maintained repository
OWASP Cheat Sheet Series, the source material for many CodeGuard rules
OWASP Top 10
CoSAI (Coalition for Secure AI), the broader initiative behind CodeGuard, with more AI security projects worth exploring
Announcing a New Framework for Securing AI-Generated Code (Cisco Blog)

Evidence-Based Best Practices as AI Guardrails (Part 2)

2026-04-01T00:00:00+00:00

Layers of protection, carved deep. Photo by Madhu Shesharam on Pexels.

This is part two of an originally three part now turned into two-part series on using evidence-based best practice files to keep AI-generated code production-ready and improve the general quality. Part 1 covered the foundations: architecture, error handling, testing, API design, data integrity, and structured logging – with detailed examples of how each file works. I originally planned 3 parts, but I do not like dragging it out, and I get bored easily, so better to get it done: here is the rest!

This post covers the remaining twelve files. Rather than repeating the deep-dive format, I’ll give you the core idea behind each: the problem it solves, the principle it encodes, and why Claude gets it wrong without it. The files themselves contain the full rules, code examples, and trade-offs – grab them from the public repository and read what’s relevant to your stack.

What This Post Covers

Security and Privacy

Authorization – the difference between “logged in” and “allowed”
Defense-in-Depth Validation – why one validation layer is never enough
Container Security – a secret “deleted” in layer 5 still exists in layer 3
Privacy by Design – the safest data is data you never collected

Operations and Reliability

Resilience Patterns – designing for the certainty that dependencies will fail
Zero-Downtime Deployment – old and new code run simultaneously, plan for it
Observability – turning 2-hour investigations into 5-minute ones
Background Job Patterns – not all work belongs in the request cycle

User-Facing Quality

Accessibility – build interfaces that work for everyone
SEO – make your structure machine-readable

External Boundaries

Robots and Scraping Protection – control what automated agents can access
LLM Integration Patterns – route cheap before expensive

Security and Privacy

1. Authorization

Authentication and authorization are two different things. Claude is quite loose in using the terminology: It builds login flows, JWT validation, and session management, then considers security “done.” But knowing who a user is tells you nothing about what they’re allowed to do. (BTW important to realise: this is not necessarily Claude’s ‘fault’, probably has more to do with the training data and the ambiguity in there.)

The file encodes default-deny authorization: every request is unauthorized unless explicitly permitted. Object-level checks (not just “can users access orders” but “can this user access this specific order”), centralized RBAC, and re-authentication for destructive operations. Without it, Claude writes GET /api/orders/:id that returns any order to any authenticated user. IDOR (Insecure Direct Object Reference – where a user accesses resources by manipulating an identifier like an ID in the URL, without the server checking whether they’re allowed to) sits at #1 in the OWASP Top 10 as a part of A01:2021 Broken Access Control. And Claude in my experience is notoriously bad and inconsistent when it comes to IDOR.

2. Defense-in-Depth Validation

Most of the time Claude adds one layer of input validation (if at all) – usually a schema check at the handler – and moves on. That catches missing fields and wrong types. It does nothing against path traversal, injection patterns, or context-specific attacks. Not a problem, I do not expect to create perfect software all in one go. But I am supposed to spot that and deliver a secure product. Defense in depth is a step in getting there.

The file defines four independent validation layers: structural constraints, format and character restrictions, explicit security pattern checks (path traversal, null bytes, injection), and downstream sanitization (parameterized queries, shell escaping, HTML encoding). The key principle: each layer assumes the others might fail. Remove any single layer and the system is still protected (perhaps not as good as with the layer you removed, but you get the point: adding multiple layers protects you from yours or Claude’s stupidity).

3. Container Security

Claude is actually quite good at writing docker container definitions. It does not use full Ubuntu base images, running as root, secrets passed as build arguments visible in docker history forever. It does not build a functional container with the attack surface of a full server. But it is smart to keep it aligned with your (or in this case my) vision on security and building layers.

The file mandates minimal base images (distroless or slim), multi-stage builds, non-root execution, read-only filesystems, dropped capabilities, and never baking secrets into layers. A Go app in distroless is small with no shell to exploit. The same app in Ubuntu is 500MB with everything that gives a bad actor points to interact with.

4. Privacy by Design

Sometimes I think Claude has no concept or was never trained on the basic concepts of privacy. Ask it to build a user profile page and it’ll collect date of birth, phone number, and address “in case we need them later.” That “in case” creates legal liability under GDPR that compounds over time. Plenty of examples (also here in the Netherlands) with very private data that becomes available on the dark web or is ransomed. Not something you want to run into. So the starting point: do not collect it unless absolutely necessary (and most of it is absolutely NOT necessary).

The file encodes data minimization (collect only what’s functionally necessary), consent management (explicit, informed, granular, revocable), right to erasure (covering all copies: database, backups, caches, third-party systems), data portability, and cookie compliance under the ePrivacy Directive. Privacy becomes a first-class architectural concern, not a compliance checkbox. You want to start with privacy awareness in the start phase of your product, but keep the right to erasure and data portability for a later stage.

Operations and Reliability

5. Resilience Patterns

Sometimes you get lucky and Claude remembers to build in some resilience. Most of the time you will find out when testing, or even better in production. And with luck the first time a dependency slows down in production, the entire system cascades into failure. Better to build this in from the start and explicitly design for it.

The file defines timeouts on every outbound call (with specific defaults per type), deadline propagation, retries with exponential backoff and jitter (only for idempotent operations, only for transient errors), circuit breakers (closed/open/half-open), graceful degradation (hard vs soft dependencies), and backpressure. The composition order matters: backpressure -> circuit breaker -> timeout -> retry -> degradation. As I said in the previous post: Claude knows much more about this than I will ever do, but you need to call it to the center of attention (not unlike how you focus a human’s attention I find).

6. Zero-Downtime Deployment

Deployments and data migrations with Claude can often go awesome, and sometimes you are in deep trouble. So it is good, for your own sanity and job security, to protect the data at all costs. How far you will take this is up to you. You decide what is acceptable (no data loss is priority one and zero downtime (or near zero) is a good second one.) If need be, make sure to run both versions of your database at once. Or just go for it. It is a thrill (if you like that kind of thrill). Rule number one: make sure you always can go back! Rule number two: backup. Rule number three: make sure you can roll back. Rule number four: backup. (And rule 5 and following: make sure your backups can be deployed. Best to do that before deploying.)

The file mandates expand-contract migrations in four phases (expand, backfill, deploy new code, contract), health-check-gated rollouts with separate /health and /ready endpoints, graceful shutdown on SIGTERM, and tested rollback scripts. Every change must be safe for both old and new versions to read and write at the same time. Make this as complex as you want or the situation warrants.

7. Observability

Simply following a data flow through your code using correlation IDs is really handy. It really helps with debugging, monitoring and logging. Claude sometimes adds logger.info("request processed") and considers observability done and is very sure of that. No correlation IDs, no metrics, no structured context. When something breaks, you’re searching unstructured logs with no way to connect a failed request to its downstream calls. And the good thing about doing this properly (or at least add some improvements that help observability): Claude will help you debug better because it can easily work with this.

The file covers the three pillars: structured logs (what happened), metrics (how much), and distributed traces (the journey of a request). Every request gets a correlation ID propagated through all downstream calls. The Four Golden Signals (latency, traffic, errors, saturation), RED method for services, USE method for resources. Alerts with severity-appropriate thresholds and enough context to start investigating immediately.

8. Background Job Patterns

I suspect that it has to do with the training data, but Claude will almost never propose to put a process in a background process, unless you explicitly ask it to. Mentioning it in these files does increase the likelihood that it will be used in the places that matter (it is funny when you worked with claude for a while and start adding these files, it seems to become a lot better at making code that makes sense.)

The file defines three patterns with clear selection criteria: fire-and-forget (return 202, spawn background work, no status tracking), tracked jobs (return a job ID, persist status to a database, client polls for completion), and queue-based processing (decouple producer and consumer with a message queue, bounded retries, dead letter queues). Cross-cutting concerns are covered: isolation between request and worker threads, correlation IDs for background logging, timeouts on every job, and graceful shutdown behavior. Start simple, scale up when you need it. Background processes are not the answer to all problems, but they have their uses.

User-Facing Quality

9. Accessibility

Claude generates

instead of

Evidence-Based Best Practices as AI Guardrails (Part 1)

2026-03-31T00:00:00+00:00

Guardrails keep you on the road, even when the terrain gets rough. Photo by Brice Cooper on Unsplash.

Claude Code writes working code. It passes tests, it runs, it does what you asked. Then it logs passwords in plaintext, skips input validation, serves pages that screen readers can’t parse, and deploys in a way that takes your site down for thirty seconds.

Tell it once, it listens. Next conversation, same mistakes.

I’ve spent over 2,000 hours iterating on my Claude Code setup. The single most impactful thing I did wasn’t clever prompting or complex hooks, it was writing down what I know about building production software in a way the model can actually use.

Not opinions. Evidence-based practices, grounded in standards: RFC 9457 for error responses, WCAG 2.2 for accessibility, OWASP Top 10 for security, DAMA-DMBOK for data quality. Each practice traces to a concrete requirement, each requirement traces to a specification, and each specification traces to a library choice. When the model writes code, it doesn’t just know what to do, it knows why, and with what.

The Problem with Instructions

You’ve probably tried the obvious approach: tell the LLM what to do.

“Always use parameterized queries.” “Handle errors properly.” “Make it accessible.”

This works once, maybe twice but inevitably it drifts. The model is smart enough, but the instructions are vague, context-dependent, and easily outweighed by other things in the prompt. “Handle errors properly” means nothing without defining what “properly” looks like in your stack, with your patterns, for your use case. And you need to keep repeating this, every prompt. Or it will revert to its old ways.

I went through the same cycle most people go through. First, I wrote instructions in the prompt, then claude.md. Then I moved them to rules. Then I added hooks to enforce them. Each step helped, but the model kept finding new ways to cut corners I hadn’t explicitly forbidden. Then skills came into swing.

I also tried existing frameworks (when I started they did not really exist yet). BMAD, spec-driven development, HumanLayer (which I genuinely liked for its “thoughts” directory approach to project memory). But in practice, I found most of them too dogmatic. They impose a rigid process that doesn’t bend to the messy reality of actual projects, where sometimes you need to spike something quickly, sometimes you need deep planning, and the model needs to know the difference. What works is pragmatism: take the good ideas from each, discard the ceremony, and build something that adapts to how you actually work.

I am not explaining my full system in this series: it would take way more to explain that, maybe I will do that later. (I am now building a semi-automated system, that takes these best practices and so far is actually able to write better code than I can, maintaining a level of quality and coherence) But it remains a work in progress.

The System: Requirements, Specifications, Best Practices

What I ended up building is a connected system of three layers:

Requirements define what must be true. Each has an ID, a description, and a project phase (start, mvp, production). For example:

REQ-API-001: Error responses must follow RFC 9457 (Problem Details for HTTP APIs) with a consistent structure: type, title, status, detail, and optional instance and extension fields. (Phase: mvp)

Specifications define how to implement each requirement. They trace back to requirement IDs:

Error format: RFC 9457 Problem Details. Content-Type: application/problem+json. Structure: { "type", "title", "status", "detail", "instance" }. Use type as a stable URI for each error category. Add extension fields as needed. Never expose stack traces in production. (Traces to: REQ-API-001)

Best practices provide the deep knowledge, the why, the trade-offs, the common mistakes, the patterns. They are what this series shares.

The traceability matters. When the model writes an error handler, it doesn’t just know “use RFC 9457”, it knows the requirement demands it, the specification defines the exact format, and the best practice file explains why generic errors are useless at 2 AM and how to add context that actually helps diagnose problems. And not to forget: the extensive training data knows more about this standard than I will ever do: you just have to ‘trigger’ it to come forward from that vast amount of data.

This is part one of a two-part series. The files discussed here (and the rest) are available in a public repository that I’ll keep updating as I add more.

“Doesn’t This Cost a Lot of Tokens?”

Yes. It does.

Loading best practice files, requirements, and specifications into context costs tokens. There’s no way around that. But the cost is manageable if you’re smart about when you load what.

I don’t dump all 18 files into every conversation. The full files are loaded during the steps that actually use them: planning and review. When the model is designing an approach or reviewing code against standards, it needs the deep knowledge. When it’s implementing a well-defined task from an approved plan, the plan itself already encodes the relevant practices, the model doesn’t need to re-read the source material. And every now and then you find a little gem, where Claude Code starts correcting you based on your own best practices. One of mine says to leave no dead code in the repo. It corrected me that my commented-out code was not in accordance with the best practices.

The alternative, not spending the tokens, is worse. Without this context, the model drifts. It makes its own architectural decisions, picks its own error format, skips validation it doesn’t know you care about. Then you spend tokens correcting it. And correcting the corrections. And explaining why the correction matters. And next conversation, you start over.

In the end it is simple math: pay upfront to load the model with your standards at the right moments, or you pay afterwards and repeatedly to fix the output when it inevitably diverges from what you need. The upfront cost is predictable and targeted. The correction cost is unpredictable and compounds. (both in time and in money)

So yes, be selective: nothing more and nothing less than what is needed at that point. A frontend task doesn’t need the container security file. A database migration doesn’t need the accessibility rules. Load what’s relevant to the phase of work you’re in.

What This Post Covers

In this first post: the foundational practices every project needs regardless of what you’re building.

Layered Architecture, how to structure code so Claude doesn’t write spaghetti
Error Handling, turning “something went wrong” into actionable diagnostics
Testing Strategy, tests that catch real bugs, not just verify mock wiring
API Design, consistent, predictable interfaces that follow standards
Data Integrity, because corrupt data is worse than downtime
Structured Logging, logs that are actually useful at 3 AM

For each practice, I’ll show the problem it solves, a taste of the key rules, and how it connects back to the requirements and standards it’s built on. Most of this is no rocket science, and you might not agree with some choices, which is fine. Define your own.

1. Layered Architecture

The problem: Without explicit guidance, Claude tends to put everything in one place. Business logic in the API handler. Database queries mixed with validation. HTTP status codes decided deep inside a service function. It works, until you need to test it, replace a dependency, or understand what the code does.

The principle: Separate code into distinct layers with strict downward dependency, handler, service, repository, model. Each layer has one job and never reaches past its neighbour.

Handler / API Layer      -- owns the transport protocol
    |
Service / Business Logic -- owns the rules
    |
Repository / Data Access -- owns the queries
    |
Domain Model             -- owns the data shape

Key rules from the file:

The handler validates input shape and formats responses. It does not contain business rules.
The service layer orchestrates business logic and defines transaction boundaries. It does not know about HTTP status codes or request objects.
The repository layer executes queries and maps results. It does not decide what data to return based on business rules.
Dependencies go down only. A service never imports from a handler. A repository never calls a service.

Why it matters for AI-generated code: When the model understands this separation, it stops making the most common architectural mistake: putting everything in the handler. It writes services you can test without spinning up an HTTP server. It writes repositories you can swap without rewriting business logic.

Traces to: REQ-QUAL-005 (testable code), REQ-QUAL-006 (maintainable tests). Built on the principle that each module should be describable in one sentence.

2. Error Handling

The problem: Claude’s default error handling is either too aggressive (catch everything, return a generic message) or too lazy (let exceptions propagate without context). Both are bad. The first hides bugs. The second makes debugging impossible.

The principle: Errors are not exceptional, they’re a normal part of program execution. Handle them explicitly at every layer, propagate them with context, translate them at boundaries, and never swallow them silently.

Key rules from the file:

Never swallow errors. catch (e) { log(e) } is not handling, it’s ignoring with a paper trail. The system continues in a corrupt state.
Add context when propagating. Each layer adds what it was doing. The final message reads like a stack of explanations: "create order: charge payment: POST /payments: connection refused".
Translate at boundaries. A repository throws a database error. The service translates it to a domain error. The handler translates it to an HTTP response. Each layer speaks its own language.
Distinguish error types. Retriable (5xx, timeout) vs terminal (4xx, auth) vs corruption. Different types require different responses: retry, report to user, or alert on-call.

The standard: Error responses follow RFC 9457 (Problem Details for HTTP APIs), a machine-parseable format with type, title, status, detail, and instance fields. This replaces the ad-hoc { "error": "something went wrong" } that Claude defaults to.

{
  "type": "https://api.example.com/errors/insufficient-funds",
  "title": "Insufficient Funds",
  "status": 422,
  "detail": "Account abc-123 has EUR 10.00, but the transaction requires EUR 25.00.",
  "instance": "/orders/order-456"
}

Traces to: REQ-API-001 (RFC 9457 error format), REQ-API-002 (appropriate status codes), REQ-OBS-002 (errors logged with sufficient context).

3. Testing Strategy

The problem: Left to its own devices, Claude writes tests that test nothing. It mocks everything, asserts that mocked functions were called with the right arguments, and calls it a day. The tests pass. The code is broken. Nobody notices until production.

The principle: Test behaviour, not implementation. The test pyramid (unit -> integration -> E2E) defines how many tests of each type to write, but the core rule is simpler: if everything is mocked, the test proves nothing.

Key rules from the file:

Every feature tests five things: happy path, validation errors, auth errors, downstream failures, and edge cases.
Mock at system boundaries, not internally. Mock the payment gateway, not the service that calls it. Your test should exercise the actual code path.
Name tests as specifications: test_create_user_with_duplicate_email_returns_409 tells you exactly what broke without reading the test body.
Tests must be independent and parallelisable. No shared state, no ordering dependencies, no “run test A before test B.”
Coverage target: 80% overall, 70% minimum per module. Not as a vanity metric, but as a signal that error paths are tested.

Why it matters for AI-generated code: When the model has this file, it stops writing tests that just verify mock wiring. It writes tests with real assertions against real behavior. And when you ask it to add error handling, it also adds the test that verifies the error handling works. This ties into the broader human-in-the-loop review approach: the AI writes, you verify.

Traces to: REQ-QUAL-005 (test happy and error paths), REQ-QUAL-006 (useful, maintainable tests), REQ-QUAL-003 (coverage thresholds), REQ-QUAL-007 (test framework bootstrap from day one).

4. API Design

The problem: Claude builds APIs that work for the happy path but fall apart at the edges. No pagination. Inconsistent error formats. Stack traces in production error responses. Rate limiting that returns no headers so clients can’t self-throttle.

The principle: An API is a contract. It should be consistent, predictable, and follow established standards so that clients (and future developers) can rely on its behavior without reading the implementation.

Key rules from the file:

Standard HTTP status codes. Not just 200 and 500, use the full vocabulary: 201 (created), 204 (no content), 400 (bad request), 401 (unauthorized), 403 (forbidden), 404 (not found), 409 (conflict), 422 (unprocessable), 429 (rate limited).
RFC 9457 for all errors. Same format, every time, machine-parseable. The type field is a stable URI that clients can switch on.
Cursor-based pagination for large datasets. Offset pagination breaks under concurrent writes. Include items, hasMore, and nextCursor in every list response.
Rate limiting with standard headers. RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset on every response. 429 with Retry-After when exceeded. Clients shouldn’t have to guess.
Never expose internals. No stack traces, no SQL errors, no file paths in production responses. Log them server-side, return a clean error to the client.

Traces to: REQ-API-001 through REQ-API-004, REQ-SEC-009 (rate limiting), REQ-DOC-001 (OpenAPI documentation). The specification further mandates generating OpenAPI docs from code annotations and validating them in CI.

5. Data Integrity

The problem: Claude writes code that works perfectly, until two requests arrive at the same time, or a payment fails after inventory was already deducted, or a migration drops a column while the old code is still running. Concurrency and partial failure are invisible in code reviews. They only surface in production.

The principle: Data corruption is worse than downtime. A crashed server restarts in minutes. Corrupt data requires investigation, manual fixes, and sometimes can’t be recovered at all.

Key rules from the file:

Transactions for multi-step mutations. Create order, deduct inventory, charge payment, all in one transaction. If payment fails, everything rolls back.
Database constraints as the last line of defence. NOT NULL, UNIQUE, FOREIGN KEY, CHECK constraints. Application validation can have bugs. The database doesn’t lie.
Idempotency by design. Every operation that might be retried (webhooks, queue messages, API calls) must produce the same result when executed twice.
Race condition prevention. Optimistic locking (version column) for low-contention reads. Pessimistic locking (SELECT ... FOR UPDATE) for critical sections. INSERT ... ON CONFLICT instead of check-then-insert.
Expand-contract migrations. Never drop or rename a column in the same migration that adds its replacement. Add the new column, backfill, deploy code that uses it, then remove the old one.

The framework: Data quality is evaluated across eight dimensions from DAMA-DMBOK: accuracy, completeness, consistency, integrity, reasonability, timeliness, uniqueness, and validity. These give you a vocabulary for discussing data issues.

Traces to: REQ-DATA-001 (versioned migrations), REQ-DEPLOY-002 (expand-contract pattern), REQ-DEPLOY-003 (tested rollback scripts).

6. Structured Logging

The problem: Claude’s default logging is console.log("user created") or logger.info(f"Processing order {order_id}"). String interpolation, no structure, no context. Useless in production where you need to filter, aggregate, and correlate across services.

The principle: Logs are structured data, not formatted strings. Every log entry should be a set of key-value pairs that machines can parse and humans can read.

Key rules from the file:

Structured fields, not string interpolation. logger.info("order_created", user_id=user.id, order_id=order.id, total=order.total), not logger.info(f"Created order {order.id} for user {user.id}").
Consistent field names across the codebase. user_id, request_id, session_id, error_type, duration_ms, operation. Pick names once and stick with them.
Never log secrets. Not passwords, not tokens, not API keys. Log their presence: api_key_present=true, not the value.
Log at system boundaries. Request received, request completed, outbound call started, outbound call finished, job started, job completed. Not inside tight loops.
Severity levels mean something. DEBUG for developer-only detail, INFO for expected events, WARN for unexpected-but-handled situations, ERROR for failures requiring investigation. Don’t log everything as INFO.
Correlation IDs. Generate a request ID at the entry point, propagate it through all downstream calls. Every log line includes it. When something breaks, you can trace the entire request path.

Traces to: REQ-OBS-001 (structured JSON logs with request context), REQ-OBS-002 (errors logged with diagnostic context), REQ-OBS-003 (correlation IDs propagated through downstream calls).

The Connection Between Layers

These six practices don’t exist in isolation. They reinforce each other:

Layered architecture creates the boundaries where error handling translates errors between layers.
Error handling defines the error format that API design exposes to clients.
Testing strategy verifies all of the above, and is made possible by the clean separation that layered architecture provides.
Data integrity protects the database layer that sits at the bottom of the architecture.
Structured logging observes what happens across all layers, with the correlation IDs that API design generates at the entry point.

And all of them trace back to requirements with IDs, specifications with implementation details, and a tech stack where every library choice is justified. The model doesn’t just follow rules, it understands a system.

Try It Yourself

The full files for all six practices discussed here, plus twelve more covering security, resilience, accessibility, deployment, and more, are available in the public repository.

You can use them as-is by dropping them into a best_practices/ directory that your Claude Code setup references, or adapt them to your own stack and standards. The format is simple: a principle, a “why” section, core rules with code examples, and common mistakes. The model picks them up without any special configuration, they just need to be part of the context.

Coming up next:

Part 2: Security, Privacy, Operations, Accessibility, SEO, and Integration Patterns – the remaining 12 files covering authorization, validation, containers, privacy, resilience, deployment, observability, background jobs, accessibility, SEO, robots/scraping, and LLM integration.

Have questions or want to share how you keep AI-generated code in line? Get in touch.

Standards and References

Bijna de helft van alle bushaltes in Nederland is ontoegankelijk, dus bouwde ik een tool om er wat aan te doen

2026-02-24T00:00:00+00:00

Een bushalte een paar kilometer van mijn huis. Geen verhoogd perron, geen geleidelijnen — ontoegankelijk voor veel reizigers.

This post is in Dutch — a first for this blog. It covers a topic specific to the Netherlands: I built an open-source tool that maps all 20,277 inaccessible bus stops in the country and lets citizens email the responsible authority with a legally grounded request for improvements. Apologies to my English-speaking readers; normal service will resume next post.

Vandaag publiceerde de NOS dat voor veel mensen als een verrassing kwam: ongeveer de helft van de Nederlandse bushaltes is niet of nauwelijks toegankelijk voor mensen met een beperking. Zes op de tien haltes missen goede voorzieningen voor blinden en slechtzienden. Bijna de helft is slecht ingericht voor rolstoelgebruikers. In sommige gemeenten ligt het percentage ontoegankelijke haltes boven de 90%.

Afgelopen jaren ben ik intensief bezig geweest met toegankelijkheid, onder andere als developer van de Beter Bereikbaar Applicatie - BBA, en dit bevestigt alle verhalen die ik hoorde. De data is openbaar beschikbaar, maar dat meer dan de helft van de bushaltes in Nederland slecht bereikbaar zijn is hoger dan ik zelf had verwacht. Dus heb ik de mooie kaarten bekeken, en toen dacht ik: wat nu? De gemiddelde persoon zal het getalletje zien, en of zijn schouders ophalen of het voor kennis geving aannemen. Wat moet je er immers mee? Dus toen dacht ik: wat kan ik er mee? Zou het niet mooi zijn als je een kaart zou hebben waar je deze data op ziet en die je in staat stelt om dit onder de aandacht te brengen bij de desbetreffende instantie (vaak een gemeente, soms een provincie en heel soms een waterschap) Dus bouwde ik er iets voor.

De onzichtbare data

Het Centraal Haltebestand — beheerd door DOVA, het samenwerkingsverband van OV-autoriteiten — bevat gedetailleerde informatie over elke bushalte in Nederland. Van elke halte is bekend hoe hoog de stoeprand is, hoe breed het perron, of er geleidelijnen liggen, of de halte obstakels heeft. Al die data is openbaar.

Maar “openbaar” is niet hetzelfde als “zichtbaar”. De data zit in de Halteviewer, een tool voor professionals. Je moet weten dat die bestaat, je moet weten hoe je erin zoekt. Voor een gemeenteraadslid of burger die willen weten hoeveel haltes in hun gemeente niet op orde zijn, is dat een doodlopende weg.

20.277 haltes die niet voldoen

Ik schreef een datapipeline die alle haltedata ophaalt en toetst aan de CROW-normen voor toegankelijkheid. Een halte voldoet niet als de stoeprand lager is dan 18 centimeter, het perron smaller dan 1,50 meter, er geen geleidelijnen liggen, of er geen obstakelvrije looproute is.

De cijfers:

	Aantal
Actieve bushaltes in Nederland	42.068
Voldoet niet aan CROW-normen	20.277 (48%)
Verantwoordelijke wegbeheerders	384

Die 384 wegbeheerders — dat zijn 345 gemeenten, 12 provincies, 5 waterschappen, 7 kantoren van Rijkswaterstaat, en nog een handvol private partijen. Allemaal afzonderlijk verantwoordelijk voor hun eigen haltes.

De wegbeheerders met de meeste ontoegankelijke haltes:

Rotterdam: 416
Provincie Overijssel: 397
Amsterdam: 393
Provincie Gelderland: 367
Provincie Drenthe: 268

De tool: Toegankelijke Bushaltes

Niet met de bus? is een interactieve kaart die alle 20.277 ontoegankelijke haltes toont, gegroepeerd per wegbeheerder. In de zijbalk klik je op je gemeente (of provincie, waterschap, etc.) en je ziet direct welke haltes niet voldoen. Je kunt inzoomen, haltes aanklikken, en zien welke haltes niet voldoen aan de eisen. En het belangrijkste: je kunt met één klik een e-mail genereren naar de verantwoordelijke wegbeheerder.

De interactieve kaart op nietmetdebus.nl toont alle ontoegankelijke bushaltes per wegbeheerder.

De e-mail: goed onderbouwd, klaar om te versturen

De gegenereerde e-mail is geen vaag verzoekje. Hij bevat:

Het exacte aantal ontoegankelijke haltes van die wegbeheerder
Een verwijzing naar het VN-verdrag inzake de rechten van personen met een handicap (artikelen 9 en 20) — dat Nederland in 2016 heeft geratificeerd
Een verwijzing naar de Wet gelijke behandeling op grond van handicap of chronische ziekte (Wgbh/cz, artikelen 2 en 3)
Een verwijzing naar het Bestuursakkoord Toegankelijkheid OV 2022-2032 — waarin overheden zelf hebben afgesproken om alle haltes toegankelijk te maken

Je hoeft geen jurist te zijn. Je hoeft geen expert te zijn in OV-wetgeving. Je klikt, je past de mail aan naar hoe jij het wilt, en je verstuurt hem. Dat is het.

Waarom dit ertoe doet

Peter Waalboer, belangenbehartiger voor mensen met een beperking, zei het treffend in het NOS-artikel: “Het openbaar vervoer is een publieke voorziening. Die moet voor iedereen toegankelijk zijn — daar is geen discussie over mogelijk.”

Helemaal waar, maar de realiteit is weerbarstig: gemeenten hebben beperkte budgetten en bushaltes aanpassen kost geld — een enkele halte kan al duizenden euro’s kosten. Er bestaan subsidies van OV-autoriteiten, en het Bestuursakkoord zet ambities neer, maar naleving is vrijwillig. Zonder druk van inwoners verschuift “toegankelijkheid” makkelijk naar de onderkant van de prioriteitenlijst.

Wat er ontbreekt is niet wetgeving of goede bedoelingen — het is zichtbaarheid. Als een raadslid niet weet dat 60% van de haltes in haar gemeente niet voldoet, gaat ze er niet naar vragen. Als een dorpsgenoot niet weet dat zijn halte ongeschikt is voor zijn buurvrouw in een rolstoel, mist hij het signaal. Data die onzichtbaar is, leidt niet tot actie.

Deze tool maakt die data zichtbaar en actionable. In een paar klikken kun je zien wat er aan de hand is en de verantwoordelijke partij aanspreken — met een juridisch onderbouwd verzoek.

Open source, voor iedereen

De tool is volledig open source. De broncode staat op GitHub. Technisch is het bewust simpel gehouden: een datapipeline in Node.js die de DOVA- en Allmanak-data ophaalt, en een statische frontend met vanilla HTML, CSS en JavaScript — met een Leaflet-kaart en marker clustering. Geen frameworks en geen build-stappen. De data is verversbaar door de pipeline opnieuw te draaien.

De timing: gemeenteraadsverkiezingen op 18 maart

Op 18 maart 2026 zijn de gemeenteraadsverkiezingen. Dat maakt dit hét moment om actie te ondernemen. Kandidaat-raadsleden en zittende politici zijn nu extra ontvankelijk voor signalen van inwoners. Stuur die e-mail nu — vóór de verkiezingen. Vraag aan je lokale partijen wat zij gaan doen aan de ontoegankelijke haltes in jouw gemeente. Toegankelijkheid hoort in elk verkiezingsprogramma, niet als voetnoot maar als prioriteit.

Wat kun jij doen?

Ga naar nietmetdebus.nl en zoek je eigen gemeente op
Bekijk welke haltes niet voldoen — misschien is het die halte bij jou om de hoek
Genereer een e-mail en stuur die naar je wegbeheerder — liefst vóór 18 maart
Deel de tool met je gemeenteraad, je lokale belangenorganisatie, je buren
Stel het aan de orde bij verkiezingsdebatten en inspraakavonden in je gemeente
Heb je suggesties of wil je bijdragen? Open een issue op GitHub

Toegankelijkheid is geen gunst. Het is een recht. En soms begint verandering met een simpele e-mail.

Let the AI Pick React

2026-02-13T00:00:00+00:00

Photo by Denys Nevozhai on Unsplash

There is a self-reinforcing cycle forming in frontend development, and it is making people nervous.

React has the most code in LLM training data. LLMs therefore generate better React code than anything else. More React code gets written — by both humans and AI — feeding future training data. Repeat. The flywheel spins, and React’s dominance compounds with every prompt.

The evidence is hard to miss: give an LLM a vague prompt like “build me a web app” and you will almost invariably get React + Tailwind + shadcn/ui. Tools like v0, Lovable, and Bolt.new all default to this stack. v0 technically supports Vue and Svelte, but by Vercel’s own admission it “really works best using React, Tailwind and shadcn/ui.”

The usual reaction to this is concern. It is called the problem with the default AI stack. Others warn about stifled innovation, outdated patterns being perpetuated at scale, and a knowledge barrier for newcomers who never discover alternatives because the AI never suggests them.

I see it differently.

The Fragmentation Problem Nobody Talks About

Frontend development has been drowning in choice for a long time. React, Next, Vue, Svelte, Solid, Angular, Qwik, Astro, Lit, Preact, Marko, Alpine, Htmx — and many more, and that is just frameworks. Each comes with its own ecosystem of state management libraries, routing solutions, meta-frameworks, and component libraries. Every combination produces a slightly different mental model, a different set of conventions, a different way to do the same thing.

This fragmentation has real costs. Teams spend weeks evaluating frameworks. Developers switching jobs need ramp-up time to learn the local flavour. Hiring becomes framework-specific. Knowledge sharing across projects is harder than it should be. The industry has been paying a quiet tax on all this optionality, and for what? For 95% of use cases, any of these frameworks would do the job just fine.

What AI is doing — accidentally, through the cold logic of training data statistics — is pushing the community toward standardisation. And standardisation, when the standard is good enough, is not a loss. It is a relief.

Good Enough Wins

React is not the best framework. I will say that plainly. If I had to write code by hand — really sit down and build components line by line — I would pick Svelte. It is cleaner, less verbose, and gives me a better overview of what is happening. The developer experience is genuinely superior when you are the one typing.

But I am not the one typing.

I wrote about this shift in my post on vibe coding, product quality and democratisation: the value equation has changed. When AI generates 80-90% of the code, my personal preference for a framework’s syntax becomes almost irrelevant. What matters is whether the AI can produce correct, functional code — and right now, it produces better React code than anything else. That is not ideology. It is a measurable quality gap rooted in training data volume.

React is not the best. But it is good enough for the vast majority of what gets built. And “good enough + excellent AI support” beats “technically superior + mediocre AI support” in every practical scenario I can think of.

I learned this first-hand when I was using a new Svelte version with GitHub Copilot — a long time ago it seems — when the training data had not included that version yet. Not a fun experience, having to reinstruct the LLM every time.

The Time Argument

Every hour I do not spend fighting an AI tool’s weaker output in a less-supported framework is an hour I can spend on what actually matters: the product, the user experience, the business logic, the security model.

The cost savings are real. When Lovable or Claude Code can scaffold a working application in half an hour using React, the overhead of choosing a different framework — debugging AI-generated code that is slightly off, filling in gaps where training data is thin, manually correcting patterns the model has not seen enough of — becomes a luxury most projects cannot justify.

This is the argument that makes the monoculture concerns less relevant for most teams: time saved is money saved. And time is the final currency.

When I Would Not Do This

I am not saying React is the answer to everything. There are clear cases where another approach is justified:

Security-critical applications. When a project demands the highest level of security assurance, I want to understand every line of code. AI-generated code — in any framework — adds a layer of uncertainty that might be unacceptable. In those cases, the framework choice should serve the security model, not the AI tooling.

Performance as a hard requirement. If a client needs the absolute smallest bundle size or the fastest possible rendering, Svelte or Solid or plain Javascript will outperform React. When performance is a specification, not a nice-to-have, the technical choice should win over the AI convenience.

Simplicity as a constraint. Some projects need to be small, understandable, and maintainable by non-specialists. A simple static site does not need React’s complexity. The right tool here might be vanilla Javascript, Alpine, or something deliberately minimal.

These are the 5% cases. They exist, they matter, and they require deliberate technical choices. But they are the exception, not the rule.

What About Innovation?

The strongest counterargument is that a React monoculture stifles innovation. If future LLMs are trained mostly on React, the reasoning goes, new frameworks will never gain enough traction to compete.

Here is how I see it: we have not actually seen real innovation in frontend frameworks for a long time. Frontend is complicated — genuinely, deeply complicated. And so far, none of the alternatives have found a definitive answer. They are variations. Svelte’s compile step, Solid’s fine-grained reactivity, Astro’s island architecture — these are smart ideas, well-built tools, and genuine improvements in specific areas. But they are also steps back in others. They are not the next paradigm shift. They are refinements.

Meanwhile, the industry runs on a multi-year cycle that keeps repackaging older ideas under new names. Server-side rendering is back. Signals — called observables in Knockout.js back in 2010 — are back. The pendulum swings, and we call it progress.

A lot of developers see their framework of choice as real innovation. I understand that attachment — I feel it with Svelte. But in the grander scheme, these are variations on the same fundamental approach to building UIs. If something truly new comes along — something that genuinely changes how we think about frontend development — it will break through regardless of what LLMs default to. That kind of innovation does not need training data momentum. It needs to be undeniably better.

Until that happens, we are better off accepting what we have and building with it.

The Accidental Standard

React did not plan this advantage. No committee decided it should be the AI default. It happened because React was the most popular framework when the training data was collected — a decade of documentation, tutorials, Stack Overflow answers, and open-source projects.

But planned or not, it gives developers a common language. It gives teams a safe default. It gives non-developers building their first app through vibe coding a foundation that actually works. And it gives the rest of us more time to spend on what we are actually building instead of debating what to build it with.

React apparently is not that bad.

Resources

The Problem with the Default AI Stack — Maximilian Schwarzmüller
GitHub Copilot vs ChatGPT vs Claude for Frontend Development — 200ok Solutions
Best Vibe Coding Tools — TechRadar
Is React Still the Best Choice in 2025? — The Alpha Spot
Svelte 5 and the Future of Frameworks: A Chat with Rich Harris — Smashing Magazine
DHH on AI, Vibe Coding, and the Future of Programming — The New Stack

Vibe Coding: Product Quality and Democratisation

2026-02-05T00:00:00+00:00

I read a few articles the last few weeks about the state of SaaS products and the changes in making and selling software because of the emergence of LLM use among a greater customer base. Some are calling it the SaaSpocalypse: customers can now build their own tools, so why would they keep paying for yours? (SaaS: Software as a Service)

And combine that with increases in searches for “vibe coding”: a jump of 6,700% in 2025. By late 2025, 84% of developers were using or planning to use AI coding tools.

So that seems to be quite a threat for a lot of software businesses. Bad times are coming. Or are they? There are multiple facets to the story, let’s look at two of them: product quality and social implications.

Product Quality

Most of the vibe-coded applications I have seen are quite bad. A few weeks ago I tried to contribute to an open-source project that was clearly vibe-coded. It was a great idea, I started with enthusiasm, but ran away within an hour.

The code looked fine at first glance: clean-ish syntax, impressive number of files. But the moment I tried to understand what it actually did, I hit a wall. Fragile abstractions, bad architecture and bugs, so many small bugs.

Now I believe that bad code is not a problem per se, just as ‘good’ code is not a goal in and of itself, just for the sake of writing good code (however you want to define that). (The lack of a proper definition is what keeps me from pursuing good code among other things.) I am much more pragmatic: does the code solve a problem? Yes? Then it is good code; it fulfills its purpose. However, take into account that the purpose is not just to solve the problem then and there, but also in the future. And the cost it takes to maintain the solution for the problem has by definition to be lower than the (perceived) costs the problem causes. Costs can be money, time, assets, reputation, failing to comply etc. If the costs are low enough (and good software drives down the total cost, by reducing maintenance time etc) it is a good solution.

So the main reason to write good code is to drive down the cost of the solution to below the cost of the problem. That also means that good code is not a fixed outcome or definition, it depends on the situation. That also means that for personal use a badly coded vibed app can be perfect: who cares that it is bad? It solves my problem! (Good for you, power to the people etc.)

And that touches on what for me is one enormously important aspect: democratisation of software. No-code and low-code platforms took the first steps here, making it possible to build without writing code at all. Now AI-assisted coding takes it further: you can create actual software, not just what fits within a platform’s constraints. Suddenly you do not need a masters degree to do complicated things with your computer: you can do all sorts of stuff!

I really am wondering what this will mean in terms of social improvement, equality and human rights. The keys to writing software were always in the hands of white, middle-aged, rich men with a predisposition for details and light autism, who kept their trades securely guarded and often were and are not able to properly communicate with their customers. If that is no longer the case, what will happen?

The best "diverse" stock photo I could find. Note how everyone is still conventionally attractive. We have a way to go. Photo by Vitaly Gariev on Unsplash.

Of course there is still a barrier: LLM costs. Right now, using these tools at scale costs real money, and that creates its own form of gatekeeping. But I expect this to come down significantly in the coming years through economies of scale, efficiency gains in model architectures, reduced energy consumption, and the rise of smaller models that perform nearly as well as the large ones.

But getting back to product quality: if writing the software is no longer the hard part (no more writing ‘print’ in javascript after working with python for weeks and making some changes in a javascript project), what will change?

The Bottleneck Shift

Something strange happens when you can generate code instantly: you lose the thinking time that was hidden in the coding process.

Before AI tools, writing code forced a pace. You’d sit with a problem for days, turning it over in your mind while your fingers typed. The friction of implementation gave you space to contemplate, to look at the problem from different angles, to notice that your initial understanding was wrong.

Now? You describe what you want and get code in seconds.

The bottleneck shifts: building becomes trivial, but understanding the problem correctly becomes the new hard part, and you have less time to figure it out.

Research on vibe coding calls this the “flow-debt tradeoff”: the speed you gain now, you pay back later in technical debt. The AI doesn’t maintain a unified architectural vision across prompts, nobody documents why the code is the way it is, and the problems only surface during maintenance and scaling. The productivity gains are real, but they’re borrowed time.

This is where personal use and business use diverge, because for your own tools “it works” is enough (who cares if it’s messy, it solves your problem), but the moment software becomes a product, something others depend on and that needs to work next year, the equation changes completely. Building was always only about 10% of the work anyway, while the other 90% (compliance, security, support, maintenance, edge cases) doesn’t go away just because building got easier.

So yes, the SaaS products that were basically CRUD apps with a subscription are in trouble, but that’s not an AI problem, that’s a product problem. You were always one motivated developer away from obsolescence; AI just made that developer faster.

That said, vibe coding does have a legitimate place in professional software development. In our workflow we now use it as a scratch pad: instead of going through an entire UI design process, business research, endless meetings and iteration cycles, we vibe-code the idea first and test it with the customer. Does it answer the problem? Great, now we know what to build properly. This saves so much time that would otherwise go into design documents and alignment meetings.

The challenge is managing expectations. You have to make clear to the customer that this is just a draft to explore the idea, and the real thing will cost time and money to build. That can be difficult to grasp: “But you already built it? Why does it take so much time and cost so much?” The answer is everything we discussed above: the 90% that isn’t building.

Democratisation

Back to the social angle: what happens when software creation is widely accessible? Will we see tools built by and for communities that Silicon Valley never understood? Will existing power dynamics be rearranged? Hopefully yes to both.

The complaint that vibe-coded apps are “bad” misses the point entirely: if someone who couldn’t build software before can now solve their own problem, messy code and all, that’s a win. The quality bar for personal tools is “does it work for me?” and nothing more. The trouble comes when personal tools try to become products, when someone thinks “this works for me, I should sell it.” That’s when understanding your own problem (relatively easy) becomes understanding someone else’s problem (hard), and maybe it’s even harder now because building no longer forces you to slow down and think.

So is the time of building and selling SaaS products over? Some think so, but the narrative that “customers will just build their own” underestimates what it takes to maintain and be accountable for software others depend on. Meanwhile, go vibe-code something for yourself, seriously. That’s the democratisation promise and it’s real, just have fun building!

Thinking about vibe coding, democratisation, or the future of software products? I’d love to hear your perspective. Get in touch to share your thoughts.

Resources

Securing YOLO Mode: How I Stop Claude Code from Nuking My System

2026-02-01T00:00:00+00:00

I always run Claude Code in YOLO mode. I have cly aliased to claude --dangerously-skip-permissions in my .zshrc because I want Claude to just get things done without asking me to approve every file write.

This works great for productivity, but it also means Claude has free rein to do whatever it wants. Format my hard disk? Sure. Leak my .env secrets to some random API? Why not. Force push to main? Go for it.

Obviously, I’d prefer to avoid those outcomes. The main thing here is: I don’t let Claude run unsupervised for hours on my system, and I add plenty of other guardrails too. If you do want to experiment with that, please do it on a Raspberry Pi or a VPS, with nothing special on it. But that’s not the subject here.

This post is about hooks: one specific defense layer I researched (again) while updating my claude workflow. Hooks let you intercept and block dangerous operations before they execute, even in YOLO mode. This post documents what I learned. Maybe it helps you too.

Hooks are also fun to use for alerts. This afternoon I added audio phrases from Command & Conquer and Red Alert to some of my hooks. Adding those sounds brought back a lot of fun memories of hours of playing. “Well done, Commander!”

Well done, Commander! Your hooks are ready. (Source: Wallpaper Cave, uploaded by kallie)

From here on, this has nothing to do with Red Alert or Command & Conquer. But it is about defending your computer and software, so there is some sort of match there :-)

Reader warning: This is a long and boring post. Only read if you’re interested in securing your Claude Code setup with hooks, blocking dangerous commands, preventing path traversal attacks, or protecting sensitive files. Use it as a reference, but never trust it blindly. Don’t say I didn’t warn you!

Why Hooks Matter for Security
The Hook Lifecycle
Blocking Dangerous Commands
Input Validation Best Practices
Path Traversal Prevention
Protecting Sensitive Files
Complete Real-World Implementation
PermissionRequest Hooks
Known CVEs and Vulnerabilities
Exit Code Reference
Comprehensive Security Checklist
Defense in Depth
Final Thoughts
Sources and Further Reading

Why Hooks Matter for Security

Hooks are user-defined shell commands or LLM prompts that execute automatically at specific points in Claude Code’s lifecycle. They execute with your full user permissions, meaning they can read, modify, or delete any file your account can access.

This is both the opportunity and the risk. Without proper controls, Claude Code could:

Execute destructive shell commands like rm -rf
Access sensitive files containing credentials
Modify system configurations
Expose secrets in logs or outputs

Hooks let you build guardrails that operate deterministically: unlike CLAUDE.md instructions that are “parsed by LLM, weighed against other context, maybe followed,” hooks execute regardless of what Claude thinks it should do.

The Hook Lifecycle

Understanding when hooks fire is essential for effective security. Here are the most relevant events for security purposes (Claude Code has additional events like Notification, SubagentStart, SubagentStop, and PreCompact):

Event	When it fires
`SessionStart`	When a session begins or resumes
`UserPromptSubmit`	When you submit a prompt, before Claude processes it
`PreToolUse`	Before a tool call executes: can block it
`PermissionRequest`	When a permission dialog appears
`PostToolUse`	After a tool call succeeds
`PostToolUseFailure`	After a tool call fails
`Stop`	When Claude finishes responding
`SessionEnd`	When a session terminates

For security, PreToolUse is your primary defense: it runs before dangerous operations execute and can block them entirely.

Blocking Dangerous Commands

The most common security use case is blocking destructive shell commands. The examples below show the concepts step by step. If you want to skip ahead to a complete, production-ready implementation, jump to Complete Real-World Implementation.

Here’s a practical implementation:

Basic Configuration

Add this to your .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/block-dangerous.sh"
          }
        ]
      }
    ]
  }
}

The Blocking Script

#!/bin/bash
# .claude/hooks/block-dangerous.sh

COMMAND=$(jq -r '.tool_input.command' < /dev/stdin)

# Block rm -rf variants (handles -rf, -fr, -r -f, etc.)
if echo "$COMMAND" | grep -qE 'rm\s+(-[a-zA-Z]*r[a-zA-Z]*f|-rf|-fr)\b'; then
  echo "Blocked: rm -rf commands are not allowed" >&2
  exit 2
fi

# Block force pushes to main/master
if echo "$COMMAND" | grep -qE 'git\s+push.*--force.*(main|master)'; then
  echo "Blocked: Force push to main/master not allowed" >&2
  exit 2
fi

# Block sudo rm
if echo "$COMMAND" | grep -qE 'sudo\s+rm'; then
  echo "Blocked: sudo rm commands require manual approval" >&2
  exit 2
fi

# Block chmod 777
if echo "$COMMAND" | grep -qE 'chmod\s+777'; then
  echo "Blocked: chmod 777 is a security risk" >&2
  exit 2
fi

exit 0  # Allow the command

Exit code 2 tells Claude Code to block the operation and feed the error message back to Claude, who can then explain the issue and suggest alternatives.

Configurable Safety Levels

For more flexibility, consider implementing configurable safety levels:

critical: Block only catastrophic operations (rm -rf ~, fork bombs, dd to disk)
high: Add risky operations (force push main, secrets exposure, git reset –hard)
strict: Add cautionary items (any force push, sudo rm, docker prune)

Input Validation Best Practices

Hook input arrives via JSON on stdin. Never trust it blindly. Here are essential validation patterns:

Always Quote Variables

# Bad - breaks with spaces or special characters
FILE_PATH=$TOOL_INPUT

# Good - handles all path types
FILE_PATH="$TOOL_INPUT"

Validate Before Processing

#!/bin/bash
INPUT=$(cat)

# Extract with fallbacks
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')

# Check if value exists
if [ -z "$FILE_PATH" ]; then
  exit 0  # No file path to validate
fi

# Validate the path looks reasonable (don't check existence - file might be new)
# Add your validation logic here

Check Tool Availability

if ! command -v prettier &> /dev/null; then
  exit 0  # Tool not available, skip gracefully
fi

Path Traversal Prevention

Path traversal attacks like ../../etc/passwd are a significant risk. Here’s how to prevent them:

Simple Detection

#!/bin/bash
INPUT=$(cat)
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')

# Block obvious path traversal
if echo "$FILE_PATH" | grep -q '\.\.'; then
  echo '{"decision":"block","reason":"Path traversal detected"}'
  exit 0
fi

# Ensure path is within project (CVE-2025-54794: use trailing separator)
PROJECT_DIR="$CLAUDE_PROJECT_DIR"
RESOLVED_PATH=$(realpath -m "$FILE_PATH" 2>/dev/null)

# Add trailing slash to prevent /project matching /project_malicious
if [[ ! "$RESOLVED_PATH" == "$PROJECT_DIR" && ! "$RESOLVED_PATH" == "$PROJECT_DIR/"* ]]; then
  echo '{"decision":"block","reason":"Path is outside project directory"}'
  exit 0
fi

exit 0

Python Implementation

For more robust validation, use Python:

#!/usr/bin/env python3
import json
import sys
import os
from pathlib import Path

input_data = json.load(sys.stdin)
file_path = input_data.get('tool_input', {}).get('file_path', '')

if not file_path:
    sys.exit(0)

project_dir = Path(os.environ.get('CLAUDE_PROJECT_DIR', os.getcwd())).resolve()
target_path = (project_dir / file_path).resolve()

# CVE-2025-54794: Must check with trailing separator to prevent
# /project matching /project_malicious
project_str = str(project_dir)
target_str = str(target_path)

if not (target_str == project_str or target_str.startswith(project_str + os.sep)):
    print(json.dumps({
        "decision": "block",
        "reason": "Path is outside project directory"
    }))
    sys.exit(0)

sys.exit(0)

Protecting Sensitive Files

Create a blocklist for files that should never be accessed:

#!/bin/bash
INPUT=$(cat)
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')

# Sensitive file patterns
SENSITIVE_PATTERNS=(
  "\.env$"
  "\.env\."
  "\.pem$"
  "\.key$"
  "\.p12$"
  "credentials\.json"
  "secrets\.yaml"
  "\.git/config$"
  "id_rsa"
  "id_ed25519"
)

for pattern in "${SENSITIVE_PATTERNS[@]}"; do
  if echo "$FILE_PATH" | grep -qE "$pattern"; then
    echo "Blocked: Access to sensitive file not allowed" >&2
    exit 2
  fi
done

exit 0

Complete Real-World Implementation

The snippets above are useful for understanding individual concepts, but here’s the actual Python hook I use. It combines all the security checks into a single, comprehensive PreToolUse hook:

#!/usr/bin/env python3
"""
PreToolUse security hook that blocks dangerous operations.

Checks for:
- Dangerous rm commands
- Fork bombs
- Dangerous git commands (push to main/master, force push)
- Disk write attacks (dd to /dev/)
- Sensitive file access (.env, .pem, .key, credentials, etc.)
- Path traversal attacks
- Project directory escape

Set CLAUDE_HOOKS_DEBUG=1 to enable debug logging.
"""

from __future__ import annotations

import json
import os
import re
import sys
from pathlib import Path

# Debug mode for troubleshooting
DEBUG = os.environ.get('CLAUDE_HOOKS_DEBUG', '').lower() in ('1', 'true')

# Pre-compiled regex patterns for performance
DANGEROUS_RM_PATTERNS = [
    re.compile(r'\brm\s+.*-[a-z]*r[a-z]*f'),  # rm -rf, rm -fr, rm -Rf, etc.
    re.compile(r'\brm\s+.*-[a-z]*f[a-z]*r'),  # rm -fr variations
    re.compile(r'\brm\s+--recursive\s+--force'),
    re.compile(r'\brm\s+--force\s+--recursive'),
    re.compile(r'\brm\s+-r\s+.*-f'),
    re.compile(r'\brm\s+-f\s+.*-r'),
]

DANGEROUS_RM_PATH_PATTERNS = [
    re.compile(r'\s/$'),          # Root directory
    re.compile(r'\s/\*'),         # Root with wildcard
    re.compile(r'\s~/?'),         # Home directory
    re.compile(r'\s\$HOME'),      # Home environment variable
    re.compile(r'\s\.\./?'),      # Parent directory references
    re.compile(r'\s\.$'),         # Current directory
]

RM_RECURSIVE_PATTERN = re.compile(r'\brm\s+.*-[a-z]*r')

FORK_BOMB_PATTERNS = [
    re.compile(r':\(\)\s*\{\s*:\|:&\s*\}\s*;:'),  # Classic bash fork bomb
    re.compile(r'\.\/\w+\s*&\s*\.\/\w+'),  # Self-replicating pattern
    re.compile(r'while\s+true.*fork', re.IGNORECASE),
    re.compile(r'fork\s*\(\s*\)\s*while', re.IGNORECASE),
]

DANGEROUS_GIT_PATTERNS = [
    # Block ALL pushes to main/master (including regular push)
    re.compile(r'git\s+push\s+.*\b(main|master)\b'),
    re.compile(r'git\s+push\s+origin\s+(main|master)'),
    # Block force push without explicit branch (might be on main)
    re.compile(r'git\s+push\s+.*--force'),
    re.compile(r'git\s+push\s+.*-f\b'),
    # Other dangerous commands
    re.compile(r'git\s+reset\s+--hard\s+origin/'),
    re.compile(r'git\s+clean\s+-fd'),  # Force delete untracked files
]

DANGEROUS_DISK_PATTERNS = [
    re.compile(r'\bdd\s+.*of=/dev/'),  # dd to device
    re.compile(r'\bmkfs\.'),  # Format filesystem
    re.compile(r'>\s*/dev/sd'),  # Write to disk device
]

ENV_ACCESS_PATTERNS = [
    re.compile(r'\bcat\s+[^\|]*\.env\b(?!\.sample|\.example|\.template)'),
    re.compile(r'\bless\s+[^\|]*\.env\b(?!\.sample|\.example|\.template)'),
    re.compile(r'\bhead\s+[^\|]*\.env\b(?!\.sample|\.example|\.template)'),
    re.compile(r'\btail\s+[^\|]*\.env\b(?!\.sample|\.example|\.template)'),
    re.compile(r'>\s*[^\s]*\.env\b(?!\.sample|\.example|\.template)'),
    re.compile(r'\bcp\s+[^\|]*\.env\b(?!\.sample|\.example|\.template)'),
    re.compile(r'\bmv\s+[^\|]*\.env\b(?!\.sample|\.example|\.template)'),
    re.compile(r'\bsource\s+[^\|]*\.env\b(?!\.sample|\.example|\.template)'),
    re.compile(r'\.\s+[^\|]*\.env\b(?!\.sample|\.example|\.template)'),
]

SENSITIVE_FILE_PATTERNS = [
    (re.compile(r'\.pem$'), 'PEM certificate/key file'),
    (re.compile(r'\.key$'), 'Key file'),
    (re.compile(r'\.p12$'), 'PKCS12 certificate'),
    (re.compile(r'\.pfx$'), 'PFX certificate'),
    (re.compile(r'credentials\.(json|yaml|yml|xml|ini|conf)$'), 'Credentials file'),
    (re.compile(r'secrets?\.(json|yaml|yml|xml|ini|conf)$'), 'Secrets file'),
    (re.compile(r'\.kube/config'), 'Kubernetes config'),
    (re.compile(r'\.aws/credentials'), 'AWS credentials'),
    (re.compile(r'\.ssh/'), 'SSH directory'),
    (re.compile(r'\.gnupg/'), 'GPG directory'),
    (re.compile(r'\.netrc'), 'Netrc file'),
    (re.compile(r'\.npmrc'), 'NPM config with tokens'),
    (re.compile(r'\.pypirc'), 'PyPI config with tokens'),
]

SENSITIVE_FILES = {
    '.env', '.env.local', '.env.production', '.env.development',
    'id_rsa', 'id_ed25519', 'id_ecdsa', 'id_dsa',
}

ALLOWED_ENV_FILES = {'.env.sample', '.env.example', '.env.template'}


def debug_log(message: str) -> None:
    """Log debug message if debug mode is enabled."""
    if DEBUG:
        print(f"[DEBUG] {message}", file=sys.stderr)


def is_dangerous_rm_command(command: str) -> bool:
    """Detect dangerous rm commands."""
    normalized = ' '.join(command.lower().split())

    for pattern in DANGEROUS_RM_PATTERNS:
        if pattern.search(normalized):
            return True

    if RM_RECURSIVE_PATTERN.search(normalized):
        for pattern in DANGEROUS_RM_PATH_PATTERNS:
            if pattern.search(normalized):
                return True
    return False


def is_fork_bomb(command: str) -> bool:
    """Detect fork bomb patterns."""
    for pattern in FORK_BOMB_PATTERNS:
        if pattern.search(command):
            return True
    return False


def is_dangerous_git_command(command: str) -> bool:
    """Detect dangerous git commands."""
    normalized = ' '.join(command.lower().split())
    for pattern in DANGEROUS_GIT_PATTERNS:
        if pattern.search(normalized):
            return True
    return False


def is_dangerous_disk_write(command: str) -> bool:
    """Detect dangerous disk write operations."""
    normalized = ' '.join(command.lower().split())
    for pattern in DANGEROUS_DISK_PATTERNS:
        if pattern.search(normalized):
            return True
    return False


def is_sensitive_file(file_path: str) -> tuple[bool, str | None]:
    """Check if file path points to sensitive files."""
    if not file_path:
        return False, None

    path_lower = file_path.lower()
    basename = os.path.basename(path_lower)

    if basename in ALLOWED_ENV_FILES:
        return False, None

    if basename in SENSITIVE_FILES:
        return True, f"Access to {basename} files is prohibited"

    for pattern, description in SENSITIVE_FILE_PATTERNS:
        if pattern.search(path_lower):
            return True, f"Access to {description} is prohibited"

    return False, None


def is_path_escape(file_path: str, project_dir: str) -> tuple[bool, str | None]:
    """Check if path escapes the project directory."""
    if not file_path or not project_dir:
        return False, None

    try:
        abs_path = Path(file_path).resolve()
        abs_project = Path(project_dir).resolve()

        # CVE-2025-54794: Must check with trailing separator to prevent
        # /project matching /project_malicious
        project_str = str(abs_project)
        path_str = str(abs_path)

        if not (path_str == project_str or path_str.startswith(project_str + os.sep)):
            return True, "Path is outside project directory"

        if '..' in file_path:
            return True, "Path traversal attempt detected"

    except (ValueError, OSError):
        return True, "Invalid path"

    return False, None


def check_bash_command(command: str) -> str | None:
    """Check bash command for dangerous patterns."""
    if is_dangerous_rm_command(command):
        return "Dangerous rm command detected"
    if is_fork_bomb(command):
        return "Fork bomb detected"
    if is_dangerous_git_command(command):
        return "Dangerous git command detected (push to main/master or force push)"
    if is_dangerous_disk_write(command):
        return "Dangerous disk write operation detected"

    for pattern in ENV_ACCESS_PATTERNS:
        if pattern.search(command):
            return "Access to .env files is prohibited"

    return None


def check_file_operation(tool_name: str, tool_input: dict, project_dir: str) -> str | None:
    """Check file operations for security issues."""
    file_path = tool_input.get('file_path', '')

    if tool_name == 'Grep':
        file_path = tool_input.get('path', '') or file_path
    if tool_name == 'Glob':
        file_path = tool_input.get('path', '') or file_path

    if not file_path:
        return None

    is_sensitive, reason = is_sensitive_file(file_path)
    if is_sensitive:
        return reason

    if os.path.isabs(file_path) or '..' in file_path:
        is_escape, reason = is_path_escape(file_path, project_dir)
        if is_escape:
            return reason

    return None


def main() -> None:
    try:
        input_data = json.load(sys.stdin)
        tool_name = input_data.get('tool_name', '')
        tool_input = input_data.get('tool_input', {})
        project_dir = os.environ.get('CLAUDE_PROJECT_DIR', os.getcwd())

        debug_log(f"Checking tool: {tool_name}")

        if tool_name == 'Bash':
            command = tool_input.get('command', '')
            error = check_bash_command(command)
            if error:
                print(f"BLOCKED: {error}", file=sys.stderr)
                sys.exit(2)

        if tool_name in ['Read', 'Edit', 'MultiEdit', 'Write', 'Glob', 'Grep']:
            error = check_file_operation(tool_name, tool_input, project_dir)
            if error:
                print(f"BLOCKED: {error}", file=sys.stderr)
                sys.exit(2)

        sys.exit(0)

    except json.JSONDecodeError:
        sys.exit(0)  # Fail open on parse errors
    except Exception:
        sys.exit(0)  # Fail open on unexpected errors


if __name__ == '__main__':
    main()

Save this as .claude/hooks/pre_tool_use.py and configure it in your settings:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/pre_tool_use.py\""
          }
        ]
      }
    ]
  }
}

Key design decisions in this implementation:

Pre-compiled regex patterns for better performance on repeated checks
Fail-open on errors (sys.exit(0)) so parsing failures don’t break your workflow
Debug mode via CLAUDE_HOOKS_DEBUG=1 for troubleshooting
CVE-2025-54794 fix with proper path prefix checking using os.sep
Allows safe variants like .env.sample and .env.example
Covers multiple tools including Bash, Read, Edit, Write, Glob, and Grep

PermissionRequest Hooks

The PermissionRequest hook (v2.0.45+) triggers when Claude Code displays a permission dialog, allowing automatic approve/deny decisions:

{
  "hooks": {
    "PermissionRequest": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/permission-handler.sh"
          }
        ]
      }
    ]
  }
}

Auto-Approve Safe Operations

#!/bin/bash
INPUT=$(cat)
TOOL_NAME=$(echo "$INPUT" | jq -r '.tool_name // empty')
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

# Auto-approve read-only tools
if [[ "$TOOL_NAME" =~ ^(Read|Glob|Grep)$ ]]; then
  echo '{"hookSpecificOutput":{"hookEventName":"PermissionRequest","decision":{"behavior":"allow"}}}'
  exit 0
fi

# Auto-approve safe npm commands
if [[ "$TOOL_NAME" == "Bash" ]] && [[ "$COMMAND" =~ ^npm\ (test|run\ lint|run\ build) ]]; then
  echo '{"hookSpecificOutput":{"hookEventName":"PermissionRequest","decision":{"behavior":"allow"}}}'
  exit 0
fi

# Deny dangerous patterns
if echo "$COMMAND" | grep -qE 'rm\s+-rf'; then
  echo '{"hookSpecificOutput":{"hookEventName":"PermissionRequest","decision":{"behavior":"deny","message":"Destructive command blocked"}}}'
  exit 0
fi

# Default: show permission prompt
exit 0

Note: PermissionRequest hooks do not fire in non-interactive mode (-p). Use PreToolUse hooks for automated permission decisions.

Known CVEs and Vulnerabilities

Several vulnerabilities have been discovered in Claude Code over time. If you’re running a recent version (2.1.12 at time of writing), these are all patched. They’re listed here to illustrate the types of attacks that hooks can help defend against:

CVE	Issue
CVE-2025-54794	Path restriction bypass via matching directory prefixes
CVE-2025-54795	Command injection via improper input sanitization
CVE-2025-52882	WebSocket authentication bypass allowing remote code execution
CVE-2025-66032	8 different command execution bypasses (led to blocklist → allowlist redesign)

Check Anthropic’s releases for the latest patched versions.

General Mitigation

Never execute development tools in untrusted directories
Use strong sandboxing and isolation
Treat Claude Code output as unverified
Keep prompts precise and exclude sensitive data

Exit Code Reference

Understanding exit codes is essential:

Exit Code	Meaning	Effect
0	Success	Allow operation; JSON on stdout is processed
2	Blocking error	Block operation; stderr shown to Claude
Other	Non-blocking error	Continue; stderr shown to user only

Choose one approach per hook, either exit codes alone or exit 0 with JSON output. Don’t mix them; Claude Code ignores JSON when you exit 2.

Comprehensive Security Checklist

Before deploying hooks in production:

Testing Your Hooks

Before deploying, test your hooks with sample input:

# Test dangerous command blocking
echo '{"tool_name":"Bash","tool_input":{"command":"rm -rf /"}}' | python3 .claude/hooks/pre_tool_use.py
echo $?  # Should be 2 (blocked)

# Test safe command
echo '{"tool_name":"Bash","tool_input":{"command":"ls -la"}}' | python3 .claude/hooks/pre_tool_use.py
echo $?  # Should be 0 (allowed)

# Test sensitive file blocking
echo '{"tool_name":"Read","tool_input":{"file_path":".env"}}' | python3 .claude/hooks/pre_tool_use.py
echo $?  # Should be 2 (blocked)

Defense in Depth

Implement security at multiple layers:

UserPromptSubmit - Validate prompts before Claude processes them
PreToolUse - Block dangerous operations before execution
PermissionRequest - Auto-approve safe operations, deny dangerous ones
PostToolUse - Validate results and provide feedback
Deny lists - Add explicit permission denials in settings

{
  "permissions": {
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(terraform destroy:*)",
      "Bash(docker system prune:*)"
    ]
  }
}

Final Thoughts

Claude Code hooks provide powerful security controls, but they require careful implementation. The key principles:

Hooks execute deterministically - Unlike CLAUDE.md rules, hooks cannot be bypassed
Validate everything - Never trust input data
Exit code 2 blocks - Use it for security violations
Defense in depth - Implement multiple security layers
Stay updated - Patch promptly when vulnerabilities are discovered

Security isn’t about preventing all possible risks: it’s about reducing attack surface while maintaining productivity. Well-designed hooks let you work confidently with AI assistance while protecting your systems from accidental or malicious damage.

Sources and Further Reading

Official Documentation

Hooks Reference - Claude Code Docs - The official reference documentation
Automate Workflows with Hooks Guide - Quickstart guide with examples
Claude Code Best Practices - Anthropic’s official best practices
Agent SDK Hooks - Hooks in the Agent SDK

Security Resources

CVE Details and Security Advisories

Tutorials and Guides

GitHub Repositories

claude-code-hooks-mastery - Comprehensive hooks examples and patterns
claude-code-bash-guardian - Automated security layer for Bash hooks
awesome-claude-code - Curated list of skills, hooks, and plugins
claude-code-hooks - Collection of useful hooks
claude-code-damage-control - Safety hooks
everything-claude-code - Complete configuration collection
claude-code-security-review - AI-powered security review GitHub Action

Community Resources

Working with Claude Code in production? I’d love to hear about your security patterns and hook implementations. Get in touch to share your experiences.

Albert Sikkema - Building Production AI Systems

Fully Automated LLM Builds: Where It Actually Stops

What I Found to Be Bottlenecks

The Review-Triage-Fix Loop

Cost

Fatigue

The Ceiling

And Then There Is Electricity

Where This Leaves Me

Resources

Models and pricing

Energy and infrastructure

Related posts

When LLMs Actually Deliver

One Sentence, Thirty Seconds

The Playbook Is Everything

The IFs

The Pattern

Love/Hate, But Mostly Love Today

gtk: Filtering CLI Noise to Save LLM Tokens

Why This Is Worth Caring About

How It Works

The Part That Makes It Actually Work

Why Go Instead of Rust

Bypass When Needed

What It Doesn’t Do

The End Result?

Resources

Security by Design: Using Project CodeGuard as AI Guardrails

What is Project CodeGuard?

How I Use Them

Planning Phase Risk Analysis

Security-Aware PR Reviews

Full Security Audits

How You Could Use Them

Why External Rules and Not Just “Be Secure”

Try It Yourself

References

Evidence-Based Best Practices as AI Guardrails (Part 2)

What This Post Covers

Security and Privacy

1. Authorization

2. Defense-in-Depth Validation

3. Container Security

4. Privacy by Design

Operations and Reliability

5. Resilience Patterns

6. Zero-Downtime Deployment

7. Observability

8. Background Job Patterns

User-Facing Quality

9. Accessibility

10. SEO

External Boundaries

11. Robots and Scraping Protection

12. LLM Integration Patterns

The Full Picture

Try It Yourself

Standards and References

Evidence-Based Best Practices as AI Guardrails (Part 1)

The Problem with Instructions

The System: Requirements, Specifications, Best Practices

“Doesn’t This Cost a Lot of Tokens?”

What This Post Covers

1. Layered Architecture

2. Error Handling

3. Testing Strategy

4. API Design

5. Data Integrity

6. Structured Logging

The Connection Between Layers

Try It Yourself

Standards and References

Bijna de helft van alle bushaltes in Nederland is ontoegankelijk, dus bouwde ik een tool om er wat aan te doen

De onzichtbare data

20.277 haltes die niet voldoen

De tool: Toegankelijke Bushaltes

De e-mail: goed onderbouwd, klaar om te versturen

Waarom dit ertoe doet

Open source, voor iedereen