Computer Science and Game Development student at Northeastern. This summer I was a teaching assistant for 45 students at MIT Beaver Works, where I created a research-based mind-mapping activity for before and after each lecture, and built the tools that ran it. I build most of my software with Claude Code, and I say which parts were mine.
Things I've built or directed.
Directed a seven-ticket port of an open-source practice tool so it runs on a Mac, including reading a live game's memory. Disbelieved a review that rejected working code on a false claim, and found that half the recorded failures were the measuring apparatus rather than the work. Submitted upstream; the port is in review.
C#macOSopen sourceDirected a multi-day debugging effort that got a Unity 6 game working on free, open-source Wine (Whisky) after only paid CrossOver could run it. Six defects documented, two in Whisky itself; released the setup as open source.
systems debuggingmacOSAI-directedTrello, Google Drive and Google Calendar wired to a Mac and left alone. Root-caused the environment-level failure that silently broke all three, and set the conventions that stop it recurring.
automationAPIsmacOSA 3D puzzle game about manipulating blocks in space to route a character to the end of each map. Built in Unity.
Unitygame designRedesigned how instructor and student teams are created and permissioned for an MIT summer program — three-tier teams, a preview-then-confirm bot, and nightly access-health checks.
automationGitHub ActionsNot a project — the system the projects above were built with.
Every project on this page ran through the same pipeline: interrogate the plan until it holds, write down the absolutes and the commands that prove them, decompose into ordered slices with the riskiest first, then one human confirmation before anything runs unattended. A ticket only counts as done when the build passes and an independent reviewer, which never saw the work being done, agrees the change did what was asked.
The part I'd actually want to talk about is the arrow that points backwards. A finished project is a labeled record of everything that went wrong, and it is normally thrown away. Feeding it back into the tooling is obvious to want and easy to do badly — every observation looks like a lesson, and a set of instructions that only ever grows gets worse while appearing to improve.
So the rules are: no change without a receipt, and two sightings before something counts as a pattern. No instruction without a test that fails when you remove it. And an audit that is allowed to delete — because adding feels productive and removing feels risky, which is exactly why these systems rot.
On its first real pass, that audit deleted four of the six instructions the same pass had just written. One tool finished the exercise a single line longer than it started.
The full write-up, including two ways the system failed and what changed →