Hello everyone,
I did a 3-year diploma in computer engineering before switching paths. I'm now in the final year of my bachelor's in environmental engineering. Most days that means my headspace is somewhere between water treatment systems and emissions modeling, not agent harnesses.
Then I saw Kunal Kushwaha's post about the Agent Harness Hackathon. I don't know exactly what it was, maybe just seeing "agent" and "harness" and "pull request review" in the same sentence, but the computer engineer in me, the one I thought I'd shelved for good, sat up. I registered with one day left before the deadline, and went from an empty repo to a submitted project in under 10 hours.
I'm writing this partly to document what I built, and partly because I think there's something worth saying about how a single post from someone you follow can pull an old skill set back out of you when you least expect it.
What I built
The idea I landed on was simple and personal: every PR review follows the same tedious ritual. Open the diff, mentally context-switch into the logic, run the tests, decide if it's safe to merge. None of it is hard, it's just tedious enough that it's easy to skim a diff, assume the tests probably pass, and move on. That's exactly the kind of gap where a real bug slips through.
So I built ShipSafe: a PR guardian agent that reviews a pull request, runs its tests in an isolated sandbox, and asks for my explicit approval before posting anything back to GitHub. Not a chatbot that talks about a diff, but one that actually pulls it, runs it, and only acts on what it finds.
How TrueForge made this more than a wrapper around an LLM
TrueForge is TrueFoundry's open-source agent harness, the layer that sits between the model and everything it needs to touch. In 10 hours I didn't have time to fight infrastructure, which is exactly the point of using a harness instead of building one. Here's how ShipSafe actually uses it:
Real tools via MCP. ShipSafe talks to GitHub through an MCP server, not a hand-rolled API client. It calls get_pull_request and get_pull_request_diff to pull the real metadata and diff, and later add_issue_comment to post the review, all through the same connector model every other TrueForge agent uses.
Sandboxed code execution. This was the actual point of the project. Instead of reading a diff and guessing whether the tests pass, ShipSafe runs them, inside a Daytona sandbox, never on my host machine. If package.json and test.js exist, it runs npm test; if it's a Python project, it runs test.py directly. The sandbox is the difference between an agent that thinks something is broken and one that knows.
Dynamic subagents. For PRs touching multiple files, ShipSafe spins up a subagent per changed file to review it independently and return a short summary. That keeps the root agent's context clean: it collects verdicts instead of drowning in every diff hunk at once.
A human approval gate. This is the part I care about most. ShipSafe never posts a comment on its own. It assembles the review, shows it to me, and explicitly asks: "Would you like me to post this as a comment on PR #3? Approve and post / Do not post." Nothing irreversible happens without a yes from me.
Session persistence. The review session survives a page refresh, so a dying browser tab mid-review doesn't mean starting over, which mattered more than usual given how little time I had.
What broke along the way
The most honest story from this build is a bug I found because Qodo found it first. My first sandbox test setup had test.py importing add from src.app, a Python module that didn't exist yet in the repo. Locally it looked fine because I'd been testing the JavaScript path (src/app.js + test.js). The moment ShipSafe tried to run the Python path in the sandbox, it failed on the import, not on the actual logic bug it was supposed to catch.
Qodo flagged this on the pull request before I merged it, and the fix was almost embarrassingly small: add src/app.py with the same intentionally-buggy add function so the Python test had something real to import and fail against. It's a small bug, but it's exactly the kind of thing an agent review process is supposed to catch, and did.
Everything I set up for the first time, that same day
Ten hours doesn't just go into writing the agent. A good chunk of it went into infrastructure I'd never touched before this hackathon:
- Docker, installed for the first time, because the sandbox execution piece meant nothing without it.
- WSL, also a first, because half the tooling assumed a Linux environment I didn't have natively on Windows.
- A small progress-tracking website, which I built with the help of opencode, purely so I could checkmark each step (register, agent working, PR #1, Qodo review, sandbox working, final README) and actually see how much of the 10 hours I had left.
None of this made it into the final submission directly, but without it there wouldn't have been a submission at all.
On using AI assistants
To be upfront about this: I used multiple LLMs as assistants throughout the build, but I want to be clear about what that actually meant in practice, because "AI-assisted" and "AI did it" are very different things. I was the one at the keyboard for all 10 hours. I typed every command, ran every test, read every diff before merging, and made every decision about what the agent should actually do.
Where the assistants helped was speed of learning. With only a day and 10 hours to work with, I leaned on Claude and opencode to explain things I was encountering for the first time: how Docker and WSL actually fit together, how an agent's instructions should be structured, and why my sandbox was failing on a Python import. Claude helped me debug the sandbox-python issue, draft and refine the agent/ship-safe.json instructions, and polish the README; opencode helped me build the progress-tracker site. In every case the assistant explained or suggested, and I verified it worked, understood why, and decided whether to keep it before it went anywhere near a pull request.
The architecture decisions, what the sandbox should check, when to gate on approval, how subagents should split up review work, were mine. If you asked me to explain any part of ShipSafe right now without opening a chat window, I could.
What I'd build next
Given more time, I'd want ShipSafe to remember review history across PRs in the same repo, so it can flag recurring patterns of bugs from the same file or contributor rather than reviewing every PR in isolation. I'd also like it to run static analysis alongside the test suite, so it can catch issues even in repos with no tests at all.
The actual takeaway
I didn't expect a hackathon post on my feed to be the reason I opened a code editor again this month, let alone install Docker and WSL for the first time in the same sitting. But that's what happened: one post, one day, one old skill set I hadn't touched in a while, a handful of new tools I'd never used before, and a working agent by the end of it. If you're sitting on a diploma or a degree you think you've moved past, it might take less than you'd guess to put it back to use.
Thank you
None of this happens without Kunal Kushwaha's post landing on my feed at the right moment, so thank you for that, and for the kind of content that makes people like me open a code editor again. Thanks also to WeMakeDevs for organizing the hackathon, to TrueFoundry for building and open-sourcing TrueForge, and to Qodo for the review tooling that caught a real bug in my own code before it ever reached main. This was a genuinely good way to spend a day.
Repo: github.com/idkshitman/Ship_Safe, see the PR history and the "Qodo Code Review Evidence" section in the README for the full trail.
Demo video: youtu.be/iXTnFhyy07w.
Top comments (0)