DjangoCon US 2017 - Preventing headaches with linters and automated checks by Flávio Junior While it’s very common to enforce PEP8 code style with tools like flake8, it’s rare for Django projects to…

Learn how to write readable, high-quality Python code by following the PEP 8 style guide and using linters and autoformatters to enforce it.

Writing Go code that reads well - names, named constants, guard clauses, small functions, comments that explain why and linters that hold the style.

A linter is a tool used in software development to analyze source code for potential errors, stylistic issues, and adherence to coding standards. It essentially acts as a static code analyzer, examining the code without actually executing it. Linters help developers catch issues early in the development cycle, improving code quality and maintainability Linters are useful tools for maintaining code quality and consistency in your Clojure applications. They analyze code for potential issues, enforce coding standards, and help catch errors before they are pushed into production. Linters are not necessarily a quick fix, can be a distraction, and it’s not inconceivable that they may not be helpful with old, large code bases. This article picks some useful tools to help you fix Clojure code. Here’s our verdict captured in a legendary LinuxLinks-style ratings chart. Only free and open source software is eligible for inclusion here. Click the links in the table below to learn more about each tool. **Clojure Linter Tools** --- **kibit**| Static code analyzer for Clojure, ClojureScript, cljx and other Clojure variants **Joker**| Small Clojure interpreter, linter and formatter **Eastwood**| Inspects namespaces and reports possible problems **clj-kondo**| Static analyzer and linter for Clojure **clojure-lsp**| Language server providing Clojure and ClojureScript tooling **Splint**| Focuses on style and code shape **Carve**| Find and remove unused functions and namespaces in Clojure **clj-depend**| Analyse and enforce namespace dependencies in Clojure projects LinuxLinks helps you discover the best free and open source software for Linux. Explore our extensive collection of **recommended applications** , including alternatives to popular proprietary software. We also publish software reviews, Linux tutorials, hardware reviews, free programming books and articles covering the wider open source community. Browse our **Linux resources** to discover more. Know a useful free and open source Linux application we haven't covered? **Suggest a program** for inclusion. Has your software been featured on LinuxLinks? Display one of our **Featured on LinuxLinks badges** on your website or GitHub README. ---

Static code analysis catches patterns, and code review catches intent, design and impact across files and repositories. No pattern rule can tell you whether a change does what the ticket asked: 13.2% of developers named matching code to intent as their top AI code review challenge in Qodo's State of AI Code Quality 2026 survey. As an architect, I layer linters, SAST and an independent AI reviewer, then hand humans only the calls that need judgment. Automated checks are one of the types of code review in my code review guide. Here's what I cover: 1. What static code analysis is and how it works. 2. Static vs dynamic code analysis, and SAST vs DAST. 3. What static analysis catches compared with code review. 4. Where AI code review sits as a third layer. 5. Where each check runs, from the IDE to the PR. 6. Strengths, limits and false positives. 7. How to layer linters, SAST and AI review in one workflow. ## What Is Static Code Analysis? Static code analysis is the automated inspection of source code without running it. An analyzer parses the code and applies rules, type checks and data-flow analysis to find bugs, security flaws, style violations and risky patterns. Because it doesn't need a running system, static analysis can check every change, early and cheaply. Linters are the simplest form of static analysis. Full static analysis platforms add cross-file data flow, quality gates and dashboards, and static application security testing (SAST) focuses the same techniques on vulnerabilities. ## How Static Analysis Works Most analyzers follow the same pipeline: 1. **Parse** the source into an abstract syntax tree (AST), a structured model of the code. 2. **Match rules** against the tree: an unused variable, an unchecked return value, a string concatenated into a SQL call. 3. **Track data flow** across functions and files, including taint analysis that follows untrusted input from a source to a sink. 4. **Score and report** each finding by severity and rule. 5. **Apply a quality gate** that passes or fails the change, usually on new code only. The output is deterministic: the same code and the same rules give the same findings every time. Repeatability makes static analysis easy to audit, and it also caps what static analysis can find. ## Static vs Dynamic Code Analysis Static analysis reads code without running it. Dynamic analysis watches the code while it runs, through tests, fuzzing or attacks against a running application. Aspect | Static analysis | Dynamic analysis ---|---|--- When the code runs | Never; source only | At runtime, in a test or staging system What it finds | Patterns, data flows, rule violations | Runtime behavior, configuration and integration flaws Cost per run | Low, so it runs on every change | Higher, so it runs less often False positives | More, because it can't see runtime context | Fewer, but it misses code paths it never exercises ### SAST vs DAST SAST is static analysis aimed at security: it reads source code for vulnerable patterns and data flows. DAST, dynamic application security testing, attacks a running application from the outside, the way a pentester would. SAST finds issues early, with line numbers. DAST confirms which ones are exploitable in a deployed system. Most security programs run both. ## Static Code Analysis vs Code Review: What Each Catches The cleanest split I know: machines apply rules, and people, and now AI reviewers with enough context, apply judgment. Aspect | Static code analysis | Code review ---|---|--- What it checks | Known patterns, rule violations, data flows | Correctness, design, intent, readability, impact How it decides | Deterministic rules | Judgment, from a person or a context-aware AI reviewer Context | The file, or the repository the rules can see | The ticket, the system and other repositories Speed | Seconds to minutes, on every change | Minutes to hours, depending on the reviewer False positives | Common, tuned through rules | Fewer, but depends on the reviewer Who acts on it | The author, guided by a rule ID | The author and reviewer, in a discussion One naming trap: "static code review" sometimes means a manual review of code without running it, done by people. Don't confuse it with static analysis tools. Generation and governance need different things. Intelligence is enough to generate code, but governing it takes wisdom: knowing your team's standards, your architecture and what went wrong last time. Rules encode some of that. Review supplies the rest. Qodo calls that layer Codebase Wisdom: the codebase context and Git history its reviewer and your coding agents share. ## Where AI Code Review Sits: The Third Layer AI code review sits between static analysis and the human reviewer. A context-aware AI reviewer reads the change against the codebase, the ticket and the team's standards, so it can ask questions no rule can: does this change do what the ticket asked, and does it break a caller in another repository? Context is what separates useful AI review from noisy AI review. A reviewer that sees only the diff guesses, while one fed by a context engine across the whole codebase can reason about callers, contracts and history. Only 34.6% of developers said their agents always follow the org's standards, in Qodo's State of AI Code Quality 2026 report. Censuswide ran the survey with 500 US developers and 300 US leaders in August 2026, and all answers are self-reported. For a longer comparison, Qodo's blog weighs static analyzers vs AI code reviewers by use case. ## Where It Runs: IDE, Pre-Commit, CI and the Pull Request Static analysis can run at four stages of the SDLC, and most teams use all four: * **IDE:** a linter flags issues as you type. * **Pre-commit:** a formatter and fast linter run before code leaves the laptop. * **CI:** the full analyzer and SAST run on every push, with quality gates on new code. * **Pull request:** results appear as PR decoration or comments, next to the human and AI reviews. AI code review now runs at two of those stages: before the PR, when a coding agent reviews its own change, and on the PR itself. ## Strengths and Limits, Including False Positives Static analysis is consistent, quick and broad. Every line of every change gets checked against the same rules, the analyzer never gets tired, and the audit trail shows which rule fired where. The limits are just as clear. Static analysis can't see intent, so it can't tell whether a change matches the ticket. Most analyzers see little across repository boundaries. And rules need upkeep: every new framework and pattern means new rules, or new false positives. False positives are the expensive part. One traditional analyzer raised 6,345 warnings on a single project, with a sampled false-discovery rate of 76%, in a January 2026 project-scale study of LLM-based vulnerability detection. The same study found LLM-based agents recalled more known vulnerabilities, though every tool raised many false alarms. LLM-based scanners had higher recall than rule-based SAST across 15 scanners and 26 intentionally vulnerable Python repositories in RealVuln, a second 2026 preprint. The authors sell a scanner that ranked first, which they disclose, and the test repositories are denser with flaws than real code. Both studies are preprints, so treat them as direction, not verdicts. Qodo's glossary explains how teams track the false positive rate in code review. ### My Experience: The Bug Every Analyzer Misses The bug class I worry about most passes every check. A service renames a field in its API response, and lint, types, tests and SAST all stay green. A consumer in another repository keeps reading the old field and quietly falls back to a default. No rule can flag it, because nothing in either repository is wrong on its own. The failure exists only across the two. Patterns like this one are why I put a review layer with cross-repo context into every stack I design, and why I don't treat a green pipeline as a reason to merge. ## How to Layer Linters, SAST and AI Code Review in One PR Workflow Here's the stack I recommend, in order: 1. Formatter and linter in pre-commit. 2. SAST and secrets scanning in CI. 3. AI review with full context, before the PR and on the PR. 4. Human review for design and risk. 5. Analytics after merge, to see which findings get acted on. Green CI plus the coding agent's own "looks good to me" isn't enough to merge on. Your team's rules shouldn't be left to the system that generated the code. Qodo's academy has a guide to integrating AI code review into your tool stack for teams wiring this up. The third layer covers changes that pass every rule but still break a contract in another repository, or ignore how the team works. Qodo Review fills that gap. Qodo sits after linters and SAST, before the human, and reviews each PR against the codebase, PR history, tickets and team standards. Over time, Rule Miner can turn accepted review comments into rules on GitHub, GitLab and Azure DevOps, and Qodo switches off rules whose findings are rarely fixed, which cuts noise instead of adding one more bot. For multi-repo teams, cross-repo findings can link to the affected lines in the other repository. Coding agents run the same engine before the PR through the Qodo Agentic Toolbox. Auto mode matches review depth to the risk of each change, so a config tweak gets a fast pass and a contract change gets a deep one. Findings are advisory, and the human still decides. Choose Qodo if static analysis is green but reviewers still catch design and intent issues by hand. Qodo complements your linters and SAST rather than replacing them. Enterprise teams get one list of standards checked on every PR across GitHub, GitLab, Bitbucket Cloud and Azure DevOps, and high-velocity teams merge sooner because the repeat checks no longer wait for a human. Qodo's glossary covers bug detection in AI review if you want the background. Qodo isn't focused on test generation, even though some authors still point to it as a key strength. In my experience, Qodo is best at AI code review and code governance for the layer static analysis can't cover: intent, team standards and impact across repos. ### Tool Categories at a Glance Each layer has its own category of tools, with one or two examples below. * **Linters** , such as the open source ESLint for JavaScript and Ruff for Python. * **SAST** , such as Snyk Code, a developer-first SAST tool with PR Checks that fail only on new issues. * **Static analysis platforms and quality gates** , such as SonarQube, which Sonar describes as code verification and governance, with quality gates that can block a merge. * **AI code review** , such as Qodo, for intent and team standards. For a wider list, Qodo compares code analysis tools for large codebases. For how all the code review tools group together, see my guide to code review tools. For security-specific review, see my guide to secure code review. ### Static Code Analysis Best Practices For AI-heavy codebases, a few practices matter most. 1. Run quality gates on new code, so old findings don't block every PR. 2. Tune rules quarterly, and delete the ones nobody acts on. 3. Track false positives per rule, rather than total findings. 4. Keep the code generator separate from the verifier. 5. Route findings by severity, so high-severity ones stay visible. 6. Measure which findings get fixed, and feed that back into the rules. ## Summary Static code analysis checks code against rules without running it, and it's the right first layer for every team. Code review checks intent, design and impact, which rules can't express. Layer them: linters and SAST in CI, a context-aware AI reviewer before and on the PR, and humans for design and risk. ## FAQ ### What is static code analysis in simple terms? Static code analysis is software that reads your code without running it and flags patterns that match known bugs, security flaws or style problems. Think of it as a spell checker for code that also follows data from one function to another. ### In which stage of the SDLC is static code analysis performed? As early as possible, and then repeatedly. Linters run in the IDE and pre-commit, full analyzers and SAST run in CI on every push, and the results show up on the pull request. ### What's the difference between static and dynamic code analysis, and SAST vs DAST? Static analysis reads code without running it, and dynamic analysis tests the code while it runs. SAST and DAST are the security versions: SAST scans source code, and DAST attacks a running application. ### Linter vs static analysis: what's the difference? A linter is a simple, fast kind of static analysis focused on style and obvious bugs, usually one file at a time. Static analysis platforms add cross-file data flow, security rules, quality gates and reporting. ### Can static analysis replace code review? No. Static analysis checks rules, while code review checks whether a change does what it should and works with the rest of the system. Most teams run static analysis first so reviewers can spend their time on design and intent. ### What are the benefits of static code analysis? Static analysis finds known problems early and cheaply, applies the same rules to every change, and leaves an audit trail. Teams also stop arguing about style in review comments. ### Should AI code review run before or after static analysis? After. Linters and SAST clear the known patterns first, so the AI reviewer spends its attention on intent, standards and impact across repositories. Qodo sits after linters and SAST and before the human reviewer.

Cosmo's shirts for people who build with AI. People who build with AI tools but still review the diff; debates about vibe coding quality and human review.

English, rewritten in Rust: grammar as trait bounds, pronouns as borrows, and englishc, a compiler with rustc-style diagnostics for prose - Aaryan-Kapoor/english-rs

Sluice is a verification queue and cache shared by all the AI agents on a Linux machine: it runs each _gate_ (tests, linters, type checks) only once per git tree, under a common CPU and memory budget, and stores the result. It is open source (MIT license), written in Rust, and works with any AI coding agent: the git hooks need nothing from the agent, agents that support MCP connect to its MCP server, and Claude Code also has a plugin. I built it, and in this article I tell you why, how to install it and what has changed on my machines, with the measured numbers. ## What problem does it solve? In my day job I build software for clients with AI agents. On a normal day I have dozens of agents running at once (I use Claude Code), each in its own git _worktree_ , on projects with expensive checks: test suites that take several minutes, linters and type checks wired into `pre-commit` and `pre-push`. Those hooks are defined by each project's team and I can't always touch them. Nothing coordinated those agents. Working with several AI agents in parallel, my machine spent the day running the same tests and builds over and over, until it ran out of memory, and pushes took forever. What made me say "enough" was watching the desktop give up: GNOME stopped responding and Linux started killing processes on its own. The kernel's OOM killer took out the browser and the applications, and `systemd-oomd` took out the agents' own tools. There were three separate causes behind it: 1. **Uncontrolled concurrency.** Each agent launches its checks on its own, directly or from git hooks. 2. **Redundancy.** The same tree is verified many times: the agent before committing, then `pre-commit`, then `pre-push` (which repeats `pre-commit`), and again after a _rebase_ that changes nothing. I measured it with Sluice itself: of all the checks requested, 52% on the development machine (1,426 of 2,742) and 38% on the second machine (1,142 of 3,016) were on code that was already verified. 3. **Excessive scope.** Full suites where a subset would do. That is up to each project, not Sluice. And one constraint that complicates everything: an agent's shell tool has a timeout. A hook that sits waiting in a queue inside `git commit` ends up cut off, and the agent still doesn't know whether the commit happened. That's why Sluice answers fast in hooks and really waits over MCP. ## What do you need? * Linux (it only works on Linux) with `git` 2.31 or later. There are static binaries for x86_64 and aarch64. * An AI coding agent. Any agent that supports MCP can use the MCP server (`sluice mcp`); for Claude Code there is also a plugin that sets everything up. * To isolate jobs: cgroup v2 and a systemd user manager. The memory policy uses `systemd-oomd` with systemd 257 or later. `sluice doctor` tells you what you have. ## How do I install it? The binary installs to `~/.local/bin`: curl -fsSL https://raw.githubusercontent.com/josegarridodigio/sluice/main/scripts/install.sh | sh `SLUICE_VERSION` pins a specific version and, later on, `sluice update` updates in place while verifying the checksum. Then connect your agent. In Claude Code, install the plugin: /plugin marketplace add josegarridodigio/sluice /plugin install sluice@sluice With any other agent that supports MCP, register `sluice mcp` as an MCP server in its configuration and paste into its `AGENTS.md` the instruction block from the agents guide. If the agent sets no variable Sluice recognises, export `SLUICE_AGENT=1` in its shell so the hooks know it is an agent; and if it only has a shell, `sluice shim install`, with the shims directory first in its `PATH`, puts its builds and tests in the queue too. And in each repository, first look at what it would do and then write it: sluice init --dry-run # detects the stack and your hooks; shows the plan, writes nothing sluice init # writes .sluice.toml and rewires your hooks With the Claude Code plugin you don't need to touch the `PATH` or `CLAUDE.md`: at the start of each session, it installs some shell _shims_ , puts them first in the session's `PATH` and gives the agent the rules. A _gate_ is a named command in `.sluice.toml`: version = 1 [gates.test] cmd = "npm test -- --maxWorkers=2" weight = 4 hooks = ["pre-commit", "pre-push"] `weight` is how many units of the budget the _gate_ takes up, roughly the CPU threads it uses. With `weight = "auto"`, Sluice starts at half the budget and learns a lower one from the measured runs. ## What happens when a tree has already passed? It doesn't run again. The cache key is the exact content of the working tree plus the _gate_ definition, and all the repository's _worktrees_ share it. If another agent, or your `pre-commit` hook, already verified that tree, the answer comes from the cache without even going through the daemon: That `typecheck` took 54 seconds the last time it really ran; now it answers in 0.22 s. In this repository the answer includes running `pnpm --version`, because it's declared in `key_inputs`: the output of those commands goes into the key, so changing pnpm version invalidates the cache, and they run on every query. Without them, on my development machine, a cache answer costs about 25–30 ms. If you want to see why Sluice decides what it decides, `--explain` shows you the tree, the key and the lookup result without running anything: If two agents ask for the same thing at the same time, it runs once and both get the result (_coalescing_). This is what has been saved, measured in each daemon's database, not counting cancelled jobs: | Second machine (12 threads, 30 GB) | Development machine (20 threads, 30 GB) ---|---|--- Period | Oct 24 → 29 (5.8 days) | Oct 22 → 28 Checks run | 1,874 | 1,316 Cache answers | 1,142 | 1,426 Run time saved | 19.2 hours | 8.6 hours In total, about 28 hours of tests and linters that did not run in a week, because that exact code was already verified. On the second machine, the daily saving ranges from 1.9 to 5 hours. The screenshot at the top is from that machine, a few hours later, with a few more cache answers. Sluice doesn't make tests faster: it avoids repeating them, orders when they run and protects the machine. ## How does it keep the machine from running out of memory? On the second machine, with 5 agents working at once, the system log shows out-of-memory episodes on three different days (October 22, 25 and 26). In the worst one, on the morning of the 26th, the system was killing processes for about 20 minutes, up to 6 per minute. Sluice recorded 15 interventions by the kernel or `systemd-oomd` on agent sessions, and a single _gate_ reached 18 GB. Version 0.6.0 (October 26) changed three things: * **Memory admission.** Sluice learns how much memory each _gate_ uses (the largest _working set_ of its last 5 runs, plus 20%) and doesn't start one that doesn't fit in the available memory minus a reserve for the desktop and the agents (by default, 10% of memory). * **Isolation.** Each job runs in its own cgroup. * **Preferred victims.** If memory still runs short, the kernel and `systemd-oomd` pick a verification job before your desktop or your agents. `sluice doctor` shows you how it ends up configured on your machine: Since the afternoon of October 26: **0 out-of-memory episodes** on the second machine, across about 780 checks and 2.5 days of agents working, nights included. I don't count a deliberate, bounded test I ran that same day at noon. Version 0.8.0 fixed the opposite case: a _gate_ with no history reserved an inflated estimate. A `pytest` reserved 13.8 GB, waited 26 minutes, ran in 1 min 40 s and used around 1 GB. Now the first run starts as a probe, measures what it really uses and also learns from the ones that fail: waits caused by guessed estimates went from 7 in one day to 0 the first night. ## Why did a 0.1-second linter wait 23 minutes? Because it was waiting behind a giant. On October 28, with the previous version, the test suite of a pnpm monorepo used about 12 GB on each run (20 measured runs, between 11 and 13 GB). With 30 GB only one fits at a time. When that suite waited for memory at the head of the queue, it reserved its turn and everything else waited behind it: * a linter that takes 0.1 seconds waited between 15 and 23 minutes; * a 19-second `typecheck` waited about 4 minutes; * 48% of all queue time was of this kind, and 91% of those jobs lasted less than a minute. Meanwhile the CPU was almost idle: 40% of the time with jobs in the queue, it was idle. Version 0.8.0 brings _backfilling_ , the technique used by supercomputing schedulers such as Slurm. Sluice predicts when the head job can start from how long the running jobs take, and lets one from behind go ahead only if it fits now and doesn't delay the head: either because the head will still fit next to it, or because its learned duration, with margin, ends sooner. `[scheduler] backfill = false` goes back to strict reservation. | Before: Oct 28 day, 12 h | After: night of Oct 28–29 with 0.8.0, 12 h ---|---|--- Checks | 316 | 202 Run minutes | 510 | 380 Queue wait minutes | 981 | 167 **Wait per minute of work** | **1.92 min** | **0.44 min** Worst wait of a job under 1 min | 27 min | 12 min Idle CPU while there was a queue | ~40% | 4.8% Jobs that went ahead of the head | — | 10 Total delay that caused to heads | — | 4 min 52 s Read it carefully: it is not a controlled experiment. It's 12 hours of daytime with the old version against 12 hours of night with the new one, with different workloads. That's why I compare wait per minute of work, about 4.4 times lower, and not absolute wait. And there is a cost: letting jobs through delayed the heads by 4 min 52 s in total that night. Sluice measures it and shows it in `sluice status` (the `backfill` line in the screenshot at the top) precisely so you can keep an eye on it. ## What if a test hangs? On October 28, a project's tests hung four times, waiting for something that never arrived. Each time they held the queue and up to 7.6 GB of memory for the 30 minutes of the limit. In three of them the tests had already finished and a single file hung for 25 minutes or more. Since 0.8.0, every 5 seconds the daemon looks at what each job is doing: CPU time, disk I/O, page faults, number of processes and log bytes. A job with no progress at all for `max(5 min, 3 × its usual duration)` shows up as `STALLED` in `sluice status`, and the agent gets the warning in the `verify` progress. Sluice never kills it: the _gate_ 's `timeout` is still the only limit. I decided it this way so there is no false positive that costs a good job. A _gate_ that is meant to stay still (a `watch`, a server) can set `stall_timeout = "off"`. The first night: 0 hangs and 0 false warnings across 177 jobs. The longest silence of any job was 20 seconds. ## What if I can't touch the repository's hooks? It happened to me in a client's Angular repository that uses husky. The hooks belong to the client and their team, so I couldn't rewrite them, and husky prepends its own `PATH`: each commit's tests ran outside the queue and the cache. Minutes per commit, competing with everything else. Since 0.7.0, Sluice can be the entry point for your clone's hooks without modifying the repository: sluice hooks on # or, when configuring: sluice init --hooks entry sluice hooks status # which hook goes through the queue and which is delegated, and why `on` points `core.hooksPath` to a hooks directory inside the clone's git directory, from a file included in its configuration, so husky's write on each install doesn't displace it. `off` removes it, and if the `sluice` binary is missing, the repository's hooks keep working. The design rule is: either I understand it entirely, or I run it untouched. Before writing it I read the source code of husky, lefthook and pre-commit. A hook that Sluice fully understands runs its commands as queue jobs, in the manager's order: read-only ones, like tests or linters, go to the cache, and those that can change files, like `lint-staged`, always run. Any other hook runs exactly as before. In a repository without `.sluice.toml`, those hook units become the `verify` _gates_ , with the same cache inputs: a `verify` before `git commit` turns the commit hook into a cache answer. ## How does an agent use it without hitting the shell timeout? Through MCP. `sluice mcp` exposes a `verify` tool that blocks until the _gates_ finish and sends a progress notification every 15 seconds. Claude Code, for example, only cuts an MCP call if its inactivity window (30 minutes by default) passes with no response or progress, so the agent waits as long as needed, without the shell's limit. In Claude Code, the rest of the plugin steers the agent that way: a _skill_ that teaches it to use `verify` and the merge queue, and a _guard_ that rewrites the _gates_ ' commands to `sluice run <gate> -v` and heavy ones (builds, test runners) to `sluice exec -- ...`, so they share the budget. With other agents, the `AGENTS.md` block carries the same instructions as the skill. And if an agent commits with a tree that isn't in the cache, the hook rewired by `sluice init` answers immediately with exit code 3 and tells it to use `verify`, instead of waiting inside `git commit`. ## How do I integrate the branches of several agents? With the local merge queue. An agent finishes its branch, passes `verify`, commits and enqueues it. The daemon combines the queued branches onto the target in a disposable _worktree_ (a "train") and runs the _gates_ once on the combined tree, with the same cache and the same budget: sluice queue enqueue # the agent does this, or you sluice queue status # the plan: trains, conflicts and what is ready sluice queue approve <train> # you do this By default, nothing is pushed until a person approves the train: the daemon rejects an agent's approval, over MCP or from the terminal, and the Claude Code plugin blocks it too. You can allow it explicitly in your personal configuration (`allow_agent_approval = true`); a repository can't turn it on by itself. Even so, two cases remain human-only: a train that changes the project's own verification configuration and landing through a _pull request_. If your target branch is protected and only accepts _pull requests_ , `[queue] land = "pull-request"` pushes the verified result to a `sluice/train/<id>` branch and, on approval, opens the _pull request_ with your own `gh`. Sluice never does the merge. ## How did I build it? With AI agents, and verified with Sluice itself: every commit of the project goes through its own queue and its own cache. The first commit is from October 22 and 0.8.0 came out on the 28th: from 0.1.0 to 0.8.0 in a week, with about 190 commits, about 105,000 lines of Rust and 25 architecture decisions (ADRs) documented in the repository. Each big change followed the same cycle: analysis of the code and of real data from the two machines, proposals with their risks, my decision recorded in an ADR, implementation in waves with agents, and review. Before each version, CI on 7 combinations: Ubuntu 22.04 and 24.04, Debian, Fedora, Alpine, ARM and the minimum git version. Several times the review found bugs the tests didn't see, and CI uncovered problems that only existed on Alpine or Fedora. And almost every version was born from a problem I saw using Sluice daily: memory in 0.6.0, hooks in 0.7.0 and the stuck queue in 0.8.0. ## Try it Install the binary and connect your agent as above, and in your repository: sluice doctor sluice init --dry-run sluice init sluice status The code, the documentation and the 25 ADRs are at github.com/josegarridodigio/sluice. If something doesn't work for you, `sluice doctor --bundle` generates a diagnostic bundle, with sensitive data removed, to attach to an _issue_.

How iterative test suites, human intuition, and unified data lineage can help verify agent-generated analytics.