Forem: Sasha Podlesniuk

Claude Code: Using Hooks for Guaranteed Context Injection

Sasha Podlesniuk — Mon, 02 Feb 2026 09:08:53 +0000

When configuring Claude Code, most teams use CLAUDE.md or skills files to define coding standards. These work well for general guidance, but they share a limitation: the model decides when to read them.

This post explores Claude Code hooks—a mechanism that guarantees your critical rules are injected into context before every file operation.

The Context Loading Problem

Vercel's engineering team ran into this with their AI agent evaluations. In their research comparing skills vs embedded documentation, they found that skills-based retrieval was skipped in 56% of eval cases. The agent simply didn't invoke them.

Passive context (like CLAUDE.md) performed better because it's always present. But even passive context has limits—it's read once at session start, and the model still decides how much attention to give it during each task.

For rules that must be followed every time—security practices, architectural constraints—we need something stronger.

Claude Code Hooks: Guaranteed Execution

Hooks are shell commands that execute automatically at specific points in Claude Code's lifecycle. The key difference: hooks run on every matching tool call, regardless of what the model thinks is relevant.

Mechanism	When It Loads	Reliability
CLAUDE.md	Session start	Read once, attention varies
Skills	When model invokes	May be skipped by the model
Hooks	Every matching tool call	Guaranteed execution

The PreToolUse hook fires before Claude executes any tool—including Read, Edit and Write. This lets you inject rules directly into context at the moment they matter most.

User: "Add a new endpoint"
    ↓
Claude prepares Read tool call
    ↓
PreToolUse hook fires ← Guaranteed, every time
    ↓
Your rules injected into context
    ↓
Claude writes code with rules present

Implementation: Package-Aware Rule Injection

Consider a monorepo where different packages have different coding standards. The API package requires Zod validation and parameterized SQL. The UI package mandates React Query over raw useEffect fetching.

Project Structure

project/
├── .claude/
│   ├── settings.json
│   └── hooks/
│       └── inject-rules.py
└── packages/
    ├── api/
    │   └── RULES.md
    └── ui/
        └── RULES.md

Package Rules

packages/api/RULES.md

# API Package Rules

## Required Patterns
- All endpoints must have input validation using Zod schemas
- Wrap async handlers with error middleware
- Use `logger.info/error` instead of console.log
- All database queries must use parameterized statements

## Naming Conventions
- Controllers: `*.controller.ts`
- Routes: `*.routes.ts`
- Validators: `*.schema.ts`

packages/ui/RULES.md

# UI Package Rules

## Required Patterns
- Use React Query for data fetching (no useEffect + fetch)
- Components must be functional with TypeScript props interface
- Always handle loading and error states

## Naming Conventions
- Components: PascalCase directories with index.tsx
- Hooks: `use*.ts`
- Styles: `*.module.css`

Hook Implementation

The hook reads the file path from stdin, detects the package, and injects the corresponding rules.

.claude/hooks/inject-rules.py

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

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

PACKAGE_RULES = {
    "/packages/api/": "packages/api/RULES.md",
    "/packages/ui/": "packages/ui/RULES.md",
}

for pkg_path, rules_path in PACKAGE_RULES.items():
    if pkg_path in file_path:
        package = pkg_path.strip("/").split("/")[-1]
        rules = Path(rules_path).read_text()
        print(json.dumps({
            "hookSpecificOutput": {
                "hookEventName": "PreToolUse",
                "additionalContext": f"[{package}] rules:\n{rules}"
            }
        }))
        break

Configuration

.claude/settings.json

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Read|Edit|Write",
        "hooks": [{
          "type": "command",
          "command": "python3 .claude/hooks/inject-rules.py"
        }]
      }
    ]
  }
}

The matcher uses regex—Read|Edit|Write captures both file editing and creation.

Results

With this configuration, requesting a new API endpoint produces code that follows all injected rules:

Request: "Add a createUser endpoint to packages/api/users.controller.ts"

Output:

import { z } from 'zod';
import { logger } from '../shared/logger';
import { asyncHandler } from '../middleware/errorHandler';

const createUserSchema = z.object({
  name: z.string().min(1).max(100),
  email: z.string().email(),
});

export const createUser = asyncHandler(async (req, res) => {
  const { name, email } = createUserSchema.parse(req.body);
  logger.info('Creating user', { email });
  const result = await db.query(
    'INSERT INTO users (name, email) VALUES ($1, $2) RETURNING *',
    [name, email]
  );
  res.status(201).json(result.rows[0]);
});

Rule	Applied
Zod schema validation	✓
asyncHandler wrapper	✓
logger instead of console.log	✓
Parameterized SQL query	✓

While the same outcome can be achieved with skills, a growing skills library or codebase increases contextual noise and raises the risk that the model overlooks the correct skill.

Advanced Patterns

Compress Rules for Context Efficiency

Every hook injection adds to the context window. As context length increases, LLM performance can drop—a phenomenon called lost in the middle. Compression isn't just about cost; it's about effectiveness.

Borrowing techniques from prompt compression research, here's how to minimize your rules footprint:

Technique 1: Remove Filler Words

Strip articles (a, the), hedging words (should, please, always), and redundant phrases.

Before	After
"All endpoints must have input validation"	"endpoints: validate input"
"You should always use parameterized queries"	"use parameterized queries"
"Please make sure to wrap handlers"	"wrap handlers"

Technique 2: Use Symbols and Shorthand

Replace words with universally understood symbols—similar to how minified JS uses short variable names.

Pattern	Meaning
`→`	leads to, use, becomes
`!=`	not, avoid, don't use
`✓`	required, do this
`✗`	forbidden, never
`*`	wildcard (any)
`$1, $2`	parameters

Technique 3: Code-Like Syntax

LLMs parse structured formats efficiently. Use patterns they recognize from code:

# BEFORE
## API Package Rules

### Required Patterns
- All endpoints must have input validation using Zod schemas
- Always wrap async handlers with error middleware
- Use `logger.info/error` instead of console.log for all logging
- All database queries must use parameterized statements to prevent SQL injection

### Naming Conventions
- Controllers should be named: `*.controller.ts`
- Routes should be named: `*.routes.ts`
- Validators should be named: `*.schema.ts`

# AFTER
[api] validate:zod | wrap:asyncHandler | log:logger.* !=console.* | sql:parameterized($1,$2)
naming: *.controller.ts, *.routes.ts, *.schema.ts

Technique 4: Relevance Filtering

Not every rule applies to every file. Filter dynamically in your hook:

# Only inject SQL rules for database-related files
if "repository" in file_path or "query" in file_path:
    rules += "\nsql: parameterized queries only"

The compressed format remains fully interpretable by Claude while using a fraction of the context space.

Preserve Through Compaction

Use PreCompact to ensure critical rules survive context compaction:

{
  "PreCompact": [{
    "hooks": [{ "type": "command", "command": "python3 .claude/hooks/inject-critical-rules.py" }]
  }]
}

Debugging

Run claude --debug to see hook execution:

[DEBUG] Executing hooks for PreToolUse:Write
[DEBUG] Hook command completed with status 0: {"hookSpecificOutput":...}

Try It Yourself

Create .claude/settings.json with the PreToolUse configuration
Add .claude/hooks/inject-rules.py with your package detection logic
Create RULES.md files in each package directory
Restart Claude Code to load the new hooks
Edit a file and observe the injected context with claude --debug

From Prompts to Invariants: Re-architecting Systems with ArchUnit and LLMs

Sasha Podlesniuk — Thu, 18 Dec 2025 13:40:56 +0000

Architectural drift is a slow tax on every codebase.

Layers blur. Boundaries erode. Patterns decay. Over time, what started as intentional design becomes accidental structure.

AI coding agents and autonomous loops promise a way out: give the agent a task, let it iterate, and stop when it “looks done”. This works well for local refactors and mechanical changes.

But architectural change is different.

Architecture is not a one-off transformation.

It is a target state defined by invariants.

What if we could run an autonomous loop, but instead of relying on natural language prompts to guide it, we defined the desired architectural outcome as executable constraints?

That is where ArchUnit becomes the control mechanism for autonomous architectural change.

Reframing Autonomous Loops

In the Ralph Wiggum autonomous loop technique — a lightweight pattern for running LLM agents in self-correcting cycles — an agent repeatedly iterates on a task with minimal human intervention. The loop typically looks like this:

Give the agent a task description
Let it modify the code
Evaluate the result (tests, output, heuristics)
Repeat until a stop condition is met

The weak point is step 3.

For architectural tasks, “did it work?” is rarely a binary answer. The agent must infer intent from prompts and guess whether the desired architectural state has been reached.

We can keep the loop, but replace the stop condition.

Instead of asking:

Does this look architecturally correct?

we ask:

Do the architectural tests pass?

When the stop condition is defined by ArchUnit tests, the loop becomes deterministic.

Architecture as the Loop Condition

In this model, ArchUnit tests define the desired architectural change , not just static restrictions.

The loop looks like this:

Write an ArchUnit test that expresses the target architecture
Run the test suite (it fails)
Ask the agent to make the tests pass
Repeat until all architectural tests are green

This is an autonomous loop, but one that converges on explicit invariants rather than emergent behavior.

The agent is not discovering architecture.

It is satisfying constraints.

Why This Is Different from “Using ArchUnit for Rules”

This is not just about enforcing rules after the fact.

The key shift is using ArchUnit tests as the primary driver of change :

The test describes where the system should go
Failures show what still violates the target state
Passing tests mean the architectural migration is complete

In other words, the ArchUnit test is the prompt, the feedback mechanism, and the stop condition.

Example 1: Driving a Shift from Unit Tests to Integration Tests

Suppose you want to move from unit tests with mocked repositories to integration tests.

Instead of telling an agent:

“Refactor tests to stop mocking repositories”

You encode the desired end state:

@Test
void repositoriesShouldNotBeMockedInTests() {
    JavaClasses importedClasses = new ClassFileImporter()
            .importPackages("com.example.demo");

    fields()
        .that().areAnnotatedWith(org.mockito.Mock.class)
        .should().haveRawType(not(resideInAPackage("..repository..")))
        .because("repositories should not be mocked - use integration tests instead")
        .allowEmptyShould(true)
        .check(importedClasses);
}

This test initially fails.

Now the autonomous loop is trivial:

Run tests
See the failure
Ask the agent to fix the violations
Repeat

The loop ends naturally when no repository mocks remain.

Example 2: Migrating Stripe Usage with a Test-Driven Loop

Consider a system that uses Stripe’s static API configuration:

Stripe.apiKey = "sk_test_123";
Charge charge = Charge.create(params);

You want to migrate to explicit client usage:

StripeClient client = new StripeClient("sk_test_123");
client.v1().charges().create(params);

Instead of instructing the agent to “refactor Stripe usage”, you define the invariant:

@Test
void stripeStaticApiCallsMustNotBeUsed() {
    JavaClasses importedClasses = new ClassFileImporter()
            .importPackages("com.example.demo");

    DescribedPredicate<JavaCall<?>> isStripeStaticCall =
        DescribedPredicate.describe(
            "static method in com.stripe.model (excluding builder())",
            call ->
                call.getTarget().getOwner().getPackage().getName().startsWith("com.stripe.model")
                && call.getTarget().resolveMember()
                    .map(member -> member.getModifiers().contains(STATIC))
                    .orElse(false)
                && !call.getTarget().getName().equals("builder")
        );

    noClasses()
        .should().callCodeUnitWhere(isStripeStaticCall)
        .because("Stripe static API calls should not be used - inject StripeClient instead")
        .check(importedClasses);
}

This test now defines the migration target.

The autonomous loop runs until every static Stripe call is eliminated.

What the Agent Actually Does

From the agent’s perspective, this is ideal:

Failures point directly to violating code
because(...) explains the expected fix
The search space narrows with every iteration

There is no need for the agent to understand Stripe, testing philosophy, or architectural intent in abstract terms.

It only needs to make the build green.

Benefits of Test-Driven Autonomous Architecture

Using ArchUnit as the loop condition gives you:

Deterministic stopping criteria
Predictable convergence
Clear auditability for human reviewers
Architecture that stays enforced after the migration

Most importantly, the architecture does not live in prompts or documentation.

It lives in executable tests.

Closing Thought

Autonomous loops are powerful, but architecture requires precision.

By defining the desired architectural change as ArchUnit tests, we can keep the loop while removing ambiguity. The agent iterates, the tests judge, and the system converges on a clearly defined target state.

This approach is not without trade-offs. Architectural invariants can be over-constrained, hard to express, or temporarily at odds with incremental change. Poorly designed tests can block valid evolution just as easily as they can prevent drift. The discipline shifts from writing better prompts to designing better constraints — and those constraints still require human judgment.

This is not replacing human architectural thinking.

It is making architectural intent explicit, reviewable, and enforceable — so machines can apply it reliably, and humans can reason about it clearly.

Making Coding Agent Verification Fast, Accurate, and Lightweight with Architectural Tests

Sasha Podlesniuk — Mon, 08 Dec 2025 14:59:58 +0000

When you build software with the help of an LLM, your workflow naturally splits into two complementary phases: guiding and checking.

Guiding is all about context-setting. You feed the model prompts, examples, architectural rules, and any tribal knowledge your team has accumulated over the years. You’re essentially teaching the LLM how things should be done.

Checking is where you verify the model’s output through human review, automated guardrails, or even an additional “verification prompt” that asks the LLM to critique its own work.

Today, let’s zoom in on this second phase and explore how it can help balance an entire AI-assisted development workflow by using architectural unit tests.

Architectural unit tests help ensure that a project is built in a consistent, sensible way. Instead of testing what the code does, they check that the code is put in the right folders, depends on the right things, and follows the patterns the team agreed on.

A Typical Setup: Layers, Rules, and the Chaos Between Them

Imagine a fairly standard architecture inside your org:

Controllers, Events, Background Jobs: Your main entry points.
Application & Domain layers: Where all your business logic lives.
Infra / Repositories / Persistence : The nuts and bolts behind the scenes.
A forest of internal rules : Dependency directions, DTO requirements, guidance on connecting controllers, and dozens of conventions born from real-world constraints.

This is the system your LLM must navigate, consistently, predictably, and without going rogue.

Naturally, the first instinct is:

Let’s just write all this down.

So you add everything into a markdown file. If you’re using Claude Code, maybe it’s CLAUDE.md. Eventually you introduce something like skills to structure that guidance better.

And you know what?

It does work… at first.

But as your rulebook grows, the cracks start to show.

When Guidance Starts Fighting Itself

Anyone who has used LLMs for code generation knows this moment well: the instruction you thought was perfectly clear gets ignored or worse, overwritten by another instruction you forgot you wrote.

Some real examples from my setup:

I had a long description explaining that our application must use CQRS (commands and queries) instead of Service classes. For example, instead of:

public class SomeController {
  private final UserService userService;

  public ResponseEntity<User> getUser(String userId) {
    return userService.get(userId);
  }
}

Should be:

public class SomeController {

  private final Mediator mediator;

  public ResponseEntity<User> getUser(String userId) {
    return mediator.send(new GetUserById(userId));
  }
}

I added another block clarifying that all controller responses must use DTOs , never domain objects, for instance:

public class SomeController {
  private final Mediator mediator;

  public ResponseEntity<UserDto> getUser(String userId) {
    return mediator.send(new GetUserById(userId)).map(UserDto::fromUser);
  }
}

Later, after issues popped up, I added rules forbidding cross-package communication within the application layer (no handler-to-handler commands):

public class GetUserByIdHandler implements Handler < > {
  private final Mediator mediator; // NOT ALLOWED

  public User handle() {
    mediator.send(new AnotherCommand()); // NOT ALLOWED
  }
}

Each addition fixed something… but also increased the cognitive load on both me and LLM.

To make things more complex, in a typical mixed codebase, where old implementation still coexist with a new one (Service classes live together with CQRS), the model often sees both patterns and becomes unsure which one to follow.

Soon you’re in a loop of:

I’ll add one more rule; that should fix it.

Until the rulebook becomes a labyrinth.

Guidance Alone Isn’t Enough

At some point, scaling guidance becomes expensive both in tokens and in mental overhead. What you really need is a fast, deterministic way to verify output and give the LLM immediate feedback.

Ideally something:

Predictable (clear pass/fail)
Cheap (no giant prompt blocks)
Quick to run (so feedback can be automated)

And this is where an unexpected hero enters.

Using Architectural Tests as LLM Feedback Signals

Architectural testing tools like ArchUnit were originally designed to keep software engineers from violating architectural constraints.

Turns out, they are excellent at correcting LLMs, too.

Instead of endlessly describing rules in prose, you can:

Encode the rule as an architectural test.
Have the LLM generate code.
Run the tests.
Feed the failures back to the LLM.

Now the model isn’t guessing what you meant; it is responding to a precise, machine enforced contract.

This shifts the system from:

LLM tries to remember everything

LLM generates a proposal → tests verify correctness → LLM fixes only what failed.

Suddenly, your guidance becomes lighter, your rulebook becomes smaller, and your architecture becomes much easier for the model to follow.

What Exactly Can We Enforce? A Practical Tour of Rules

Now let’s look at the kinds of architectural rules we can enforce and how they help us keep an LLM on the rails.

For the examples below, we’ll use a Spring Boot project paired with ArchUnit tests.

We’ll tackle the same challenges described in the earlier section.

1. Eliminating Service Packages (to Push CQRS)

One of the recurring issues was the LLM drifting back toward a traditional Service Layer approach often by creating a brand new service package out of thin air.

A simple rule shuts that down immediately:

@Test
@DisplayName("Classes should not reside in 'service' packages")
void noClassesInServicePackages() {
  noClasses()
    .should().resideInAPackage("..service..")
    .because("use 'application' package with mediator instead of 'service'")
    .check(importedClasses);
}

This is small but incredibly effective.

If the LLM tries to “helpfully” reintroduce Service classes, this test fails instantly steering it back toward the CQRS pattern.

This was reinforced with one more constraint:

private static final String[] ALLOWED_ROOT_PACKAGES = {
  "..application..",
  "..controller..",
  "..config..",
};

@Test
@DisplayName("Classes must reside in allowed root-level packages only")
void classesResideInAllowedPackagesOnly() {
  classes()
    .should().resideInAnyPackage(ALLOWED_ROOT_PACKAGES)
    .because("enforces standard package structure: application, controller, config")
    .check(importedClasses);
}

This guards the root package from accumulating unexpected folders like utils, common, manager, or anything else the LLM might creatively invent.

2. Restricting the Controller Layer

Controllers should depend on only two kinds of things:

DTOs: Plain transport objects with no DI annotations.
Controller classes: Annotated with @RestController and extending your internal ApiController abstraction (which provides the mediator for sending commands/queries).

Anything else — domain objects, application handlers, repository types — is forbidden.

You can enforce that with a rule like:

@Test
@DisplayName("Controller package should only contain DTOs and RestControllers")
void controllerPackageOnlyContainsDtosAndRestControllers() {
  noClasses()
    .that().resideInAPackage("..controller..")
    .and().areNotAnnotatedWith("org.springframework.web.bind.annotation.RestController")
    .should().notBeAnnotatedWith("org.springframework.stereotype.Service")
    .orShould().notBeAnnotatedWith("org.springframework.stereotype.Component")
    .orShould().notBeAnnotatedWith("org.springframework.stereotype.Repository")
    .because("non-controller classes must be plain DTOs without DI annotations")
    .check(importedClasses);
}

@Test
@DisplayName("RestControllers must extend ApiController")
void restControllersMustExtendApiController() {
  classes()
    .that().areAnnotatedWith("org.springframework.web.bind.annotation.RestController")
    .should().beAssignableTo("com.example.ApiController")
    .because("controllers must extend ApiController to access the mediator")
    .check(importedClasses);
}

This single constraint prevents the LLM from “accidentally” injecting half your system into the controller layer.

3. Enforcing CQRS in the Application Layer

All public classes in the application package should follow CQRS patterns:

Commands / Queries
CommandHandlers / QueryHandlers

Everything else should remain package-private.

A rule might look like this:

@Test
@DisplayName("Public classes in application layer must implement CQRS interfaces")
void applicationLayerPublicClassesMustImplementCqrs() {
  classes()
    .that().resideInAPackage("..application..")
    .and().arePublic()
    .and().areNotInterfaces()
    .should().beAssignableTo("com.example.Command")
    .orShould().beAssignableTo("com.example.Command.Handler")
    .because("public classes must be Commands or Handlers - catches accidental UserService or OrderManager")
    .check(importedClasses);
}

This automatically catches cases where an LLM introduces a UserService or OrderManager, especially if it makes it public to expose it to controllers.

4. Preventing Application → Application Communication

Another common violation: the LLM tries to send commands or queries between application packages, e.g., user handlers calling invoice handlers.

That breaks the vertical-slice structure.

ArchUnit allows us to forbid this and immediately suggest a fix:

@Test
@DisplayName("Application layer should not import Pipeline")
void applicationLayerShouldNotImportPipeline() {
  noClasses()
    .that().resideInAPackage("..application..")
    .should().dependOnClassesThat().haveFullyQualifiedName("com.example.Mediator")
    .because("Application handlers should not call other handlers via Mediator. FIX: consider using domain events")
    .check(importedClasses);
}

This turns a subtle architecture rule into a crisp, enforceable contract.

5. Ensuring Controllers Return DTOs Only

A bonus check validates that controller return types never leak domain entities or events:

@Test
@DisplayName("Controller methods should not return domain entities or events")
void controllerMethodsShouldOnlyReturnDtos() {
  ArchCondition < JavaMethod > notReturnDomainOrEvents = new ArchCondition < > ("not return domain or event types") {
    @Override
    public void check(JavaMethod method, ConditionEvents events) {
      method.getReturnType().getAllInvolvedRawTypes().stream()
        .filter(type -> type.getPackageName().contains(".domain.") ||
          type.getPackageName().contains(".events."))
        .forEach(type -> events.add(SimpleConditionEvent.violated(
          method,
          String.format("%s returns forbidden type %s", method.getFullName(), type.getName())
        )));
    }
  };
  methods()
    .that().areDeclaredInClassesThat().areAnnotatedWith("org.springframework.web.bind.annotation.RestController")
    .and().arePublic()
    .should(notReturnDomainOrEvents)
    .because("controllers must return DTOs only - prevents leaking domain internals")
    .check(importedClasses);
}

This rule alone helps maintain API stability and prevents accidental exposure of internals.

And of course, this is only the beginning. You can add many more invariant checks such as naming conventions, allowed dependency flows, type usage rules, and other architectural guarantees that help keep the system consistent and easier for the LLM to navigate.

Real Feedback the LLM Receives

With these tests in place, mistakes become precise, actionable feedback:

CASE 1: LLM creates a service package with a service class

Feedback:

Unexpected package service detected
Only allowed root packages are A, B, C
Service classes are forbidden, use application

CASE 2: LLM adds a public Service inside application

Feedback:

Public class violates application-layer rules
Internal abstractions are allowed, but public Service classes are not

CASE 3: LLM sends a command from one application slice to another

Feedback:

Application → Application communication is not allowed
Use Domain Events instead of cross-slice commands

6. Preventing LLMs from Modifying the ArchUnit Tests Themselves

If you want coding agents to work autonomously, you need to guard the tests from being “helpfully fixed” by the model.

For example, a simple Claude Code hook can block edits to test files:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | grep -qE '/architecture/.*Test\\.java$' && exit 2 || exit 0"
          }
        ]
      }
    ]
  }
}

Engineers can manually update tests; the agent should not.

Handling Mixed Codebases with Freezing Rules

Many teams operate in a mixed codebase: part legacy and part modern. In our case, the new approach is CQRS, while the existing implementation still uses traditional Service classes. Fixing everything at once is not realistic and exposing both implementations to the LLM creates confusion. The model sees two competing patterns and does not always pick the correct one.

Freezing Rules help stabilise this situation by letting you introduce new architectural constraints without breaking existing code or overwhelming the LLM with conflicting signals.

ArchRule rule = FreezingArchRule.freeze(
  classes().should(). /* your actual ArchRule */
);

Putting It All Together

This architecture-focused approach gives you:

A tight feedback loop
Deterministic, test-driven constraints
Cleaner prompts (smaller CLAUDE.md / SKILLS files)
A more predictable LLM-assisted workflow
Less “LLM drift” into legacy patterns

It will not verify everything, for example ensuring that a repository query has the right index would require deeper static or runtime analysis. But it significantly reduces architectural mistakes while keeping guidance lean.

What’s Next?

ArchUnit also exposes metrics.

Next time, we can explore whether those metrics can help keep autonomously generated codebases:

clean,
analysable,
and maintainable

…for both software engineers and coding agents.