Inspiration
I wanted to build something that solved one of my personal problems. Verifying that my application met its specification is incredibly hard for me. In the age of AI coding assistants, I can generate 500 lines of code in seconds, but verifying that the code actually holds up under nasty, real-world edge cases takes hours. That is a problem I always wanted to work on, and I'm glad to pursue it here.
What it does
In a nutshell, Linus adversarially tests your PRs for regressions. It's primitive right now, but it parses the Abstract Syntax Tree, runs deterministic checks for common errors in AI-generated code, then adversarially red-tests your code.
For each candidate bug, we run the build in an isolated container and ensure that the vulnerability discovered is reproducible. We deterministically block inclusion in the report of anything that cannot be proven by an actual, unhandled runtime crash.
If it’s an indentation debate, a stylistic nitpick, or an unverified LLM suspicion, Linus stays completely silent. Zero comments. When Linus does post on your PR, it’s because it executed an adversarial test in a sandbox, captured the crash traceback, verified that the base branch was immune, and generated a dual-verified defensive patch that makes the test suite green.
How we built it
- Orchestration & Reasoning: Built on the official Strands Agents SDK and Amazon Bedrock AgentCore, powering the multi-step red-team/blue-team verification workflow.
- Deterministic AST & Boundary Parsing: Used Python’s native
astmodule to extract changed functions, parameter contracts, and call sites from raw git diff hunks, identifying boundary edge cases (empty collections,Nonevalues, off-by-one indices). - Isolated Execution Sandbox: Ephemeral containerized subprocesses running
pytestto execute candidate adversarial exploits in complete isolation with strict memory and CPU boundaries. - Serverless AWS Cloud Deployment: Packaged as an Amazon ECR container deployed to AWS Lambda via the AWS Lambda Web Adapter (
RESPONSE_STREAM), scaling to zero with $0.00/month idle cost. - GitHub Integration: GitHub Actions webhook pipeline that listens for PR events, triggers Linus, and posts the reproducible proof and patch directly to the PR timeline.
Challenges we ran into
- Context Blindness in Git Diffs: A git diff only shows the few lines of code that changed—it has no idea what assumptions callers three files away are making. We had to implement AST-based call graph expansion to pull in surrounding type hints and function signatures so the agent wasn't testing in the dark.
- The "Pre-Existing Bug" Trap: If Linus finds a crash in a PR, how do you know the PR introduced it? Often, the base branch was already broken. We had to build a dual-suite verification mechanism: every generated test is run against the base branch first. If base crashes too, it’s not a PR regression—Linus discards it immediately to eliminate false accusations.
- Sandboxing Execution Timeouts: Letting an autonomous agent generate and run dynamic Python code is terrifying. We ran into infinite loops, runaway test fixtures, and hanging subprocesses during development. Enforcing strict SIGKILL execution timeouts and isolated temp directories was painful but essential.
Accomplishments that we're proud of
- 270 / 270 Tests Passing: Built a rock-solid, fully tested core verification engine covered by 270 automated tests.
- Proven Live Regression Detection: In our live PR #1 test run, Linus autonomously caught a silent
IndexError: list index out of rangeon an empty cart edge case, ran the repro test, wrote the defensive check, verified it, and posted the advisory without any human intervention. - Zero AI Slop Guarantee: Actually enforcing the Assured Execution Gate. Building an AI agent whose proudest feature is its ability to shut up when it doesn't have mathematical or runtime proof.
- Live AWS Serverless Deployment: Successfully deploying the full Bedrock + Web Adapter container to AWS Lambda with zero cold-start bloat and scale-to-zero economics.
What I learned
I actually thought it was going to be easy: what could be hard in getting an agent to test your diffs? It wasn't until I started building that I thought about context: diffs may not contain enough diagnostic information. Also, our false-positive filtering engine had an inherent assumption: that the current master branch was bug-free and up-to-spec.
I learned that the hardest part of building agentic software engineering tools isn't prompting the LLM—it's building the deterministic ground truth around it. An LLM without an execution sandbox is just a glorified opinion generator. The agent needs to execute the code, feel the crash, and inspect the stack trace itself.
What's next for Linus
I learnt a lot when building this, and it's one of the projects I aim to commercialize soon. I feel verification is now the bottleneck for SWE work. Generating code has become a commodity; proving that code doesn't silently take down production on a Friday evening is the real problem.
Next up for Linus:
- Multi-Language Support: Expanding AST parsers and execution environments to TypeScript and Go.
- Stateful Property-Based Fuzzing: Combining Bedrock's reasoning with Hypothesis-style property fuzzing to generate complex, multi-step state machine exploits.
- Agentic Memory across PRs: Using Bedrock AgentCore's memory to remember recurring regression patterns across a team’s codebase over time.
Built With
- amazon-web-services
- bedrock
- lambda
Log in or sign up for Devpost to join the conversation.