How AI saved my life instead of destroyed it, with monorepository, architecture and patterns (Part One)

(Free code and how to support me at the end!)

Two years ago I was like all of you at that time. I sat down to try and figure out what to create with this AI hype. I was apprehensive and didn't know what to make of it. So this thing, it can code, and replace me? The knee-jerk reaction was to say, human quality would always be better. But I knew that was a fragile argument. It might be true, it might not be, but if AI was getting better over time, I would be in a rat race not only with people now but with machines. Rise of the Machines.

The machines are coming. They're faster, smarter and sexier than you.

I knew that I had to take advantage of AI no matter what.

The main thing was I wanted to create some store of code that would last the rest of my life. Some way to bring my project to life. I won't talk very much about my specific project here, because it's not relevant to the point. What's the point is I wanted to reuse code, structure the code and create the code in such a way that AI could understand it and use it. AI that I told what to do, because I was the boss.

Most importantly, I wanted it to be mine. I wanted to own it, to do whatever I wanted with it, to sell it, to throw it out. I wanted it to be the capstone artifact of my entire career, to carry the lessons forward. I wanted to keep using it, forever.

This was long before MCP connectors and I'm fairly certain long before the Claude Code plugin for VSCode (at least I am 99% sure!) There was also an absolutely tiny context window of a few thousand tokens in Claude.

I also found that the Web UI, not being able to access my GitHub repository, needed the context not just of previous features but the architecture itself. To me, the entire point of having a machine do it all was consistency. Why do it myself, if a machine could do it and follow the rules? The point was to make it all mechanical, so I could focus on the code I wanted to or the work I wanted to and make a process all the work that I didn't want to.

So I made some immediate decisions

• I wanted a monorepo. I never fully bought the idea of everything into one repository, but I was certain I wanted the code to be shared. But at the same time I wanted it all loosely coupled and zero dependency. I also wanted a shared CI/CD (if I wanted to make CI/CD). I was well aware of the simplicity and power of new repos every single time and working with Github Actions. But I knew that AI should have access to all the surrounding code and I thought maybe it would help
• I wanted a monorepository packaging tool for caching, dependency management and folder structure
• I wanted to use TypeScript and centralize all the typescript config files. Separate typescript config files for public and private, and separate typescript config files for each type of package such as library packages, backend packages, frontend packages and so on.
• I wanted frontend and backend code in the same repository. But frontend and backend code have totally different packaging needs. So I would need separate configuration, but still centralized
• I wanted to "manage the AI" somehow. Not just review the code, but make sure that the AI remembered what was happening between contexts.

I began in a very naive way cut ad pasting entire packages between new chat contexts. Since I wanted a foundation of code for potentially the rest of my life (ha) it had to start from zero dependencies. I had no idea what the database layer would be like, so I wanted to be database agnostic. I settled on an oldie but goodie -- the repository design pattern. But underneath it wouldn't be an ORM or anything like that. This was going to be raw, unrestricted power.

In order to ensure that the architecture was adhered to in the early days, I used an architectural document, examples document, progress tracker and code style document. When uploading the packages got too big (this was before Sonnet's 200k tokens) I vibe coded a summary tool. It would look at a package, extract all the function and class signatures and give the next context the calling surface, inputs and outputs. A lot of my architectural decisions began to pay off, like asking for pure functions with no side effects, and the strictest possible typescript settings. I began to realize that there was no way a human or a human team could maintain this discipline across dozens of packages without machine help. Either a linter would work or more likely the architecture would drift.

I had to conduct a major pivot from one cloud provider to another, and in fact to a completely different platforms (web to desktop then to web again). Some would call this learning, and maybe even a waste of time. But if you're reading this, you know that certain things can only be found out by doing it. It is not obvious, especially in the beginning, what kind of tech stack you should use. And you should be ready to pivot away from your tech stack, if a better choice comes available for the use case. Not just use what you know or what you're comfortable with.

It is now two years later and I have the following high quality of life for my side projects

• Monorepository tooling that builds backend and frontend in seconds
• Hundreds if not thousands of unit tests, for a project that has real staying power. I deliberately picked a topic that AI should have complete and total mastery on, where the examples are abundant and the field well understood for decades.
• Deploy, revert and testing of database schema.
• A future path for web, desktop and mobile applications, all in the same repository (I will talk about this more in a future article about how I am setting up the frontend and how the frontend will talk to the backend through shared React hooks)
• Consolidated TypeScript and other configs so I would never have to setup config files again (yeah right)
• An almost mechanical way of improving the architecture and design of my packages and monorepository. Paste handoff, list the required packages, ask the AI to "avoid technical debt and leaky abstractions", get a summary of the work, correct the AI as it made assumptions or mistakes and if satisfied with the work generate a handoff for the next context.
• Constant progress towards my personal life goals

I truly think that without this, without doing this, I might be lost in a sea of despair looking at the future of AI as removing me from my work someday. Not everyone does machine learning. A lot of us are frontend developers, devops people, even just ordinary software engineers who use AI but don't make AI. There has to be a future for us, right?

In guerilla warfare, you try to use your weaknesses as strengths. They're big and you're small. You're mobile and they're slow. You capture your weapons and use them against them. That way they're supplying you.

Here is the free bit. Configuration files for your monorepository, to centralize all your Vite and Typescript configuration along with instructions. Adapted from my existing monorepository and cleaned for your use.

brian-lim-42 / typescript-config-public

Public TypeScript Configurations for a Monorepository for Libraries, Frontend and Backend

@yourscope/typescript-config

Centralized TypeScript, build, and test configuration for a monorepo. One place to define how strict your types are, how your packages build, and how your tests run -- every package extends from here instead of hand-rolling its own tsconfig.json.

Rename @yourscope to your actual npm scope before publishing. Everything else works as-is.

Why centralize this

In a monorepo, config drift is the default outcome, not an edge case. Twenty packages means twenty chances for one tsconfig.json to quietly diverge from the rest -- a missing strict flag here, a different module target there -- and nobody notices until a build breaks in a way that only reproduces in one package. Centralizing it doesn't just save you from writing the same JSON twenty times; it means a change to your standards is one edit, not twenty, and every package is provably consistent because they all extend the same file.

…

View on GitHub

And of course here is the shill. You had to know it was coming. I packaged the past two years of learnings and pivots and lessons into SKILL.md format, with commands and an actual mechanical workflow for building. For a small fee you can have it all. If you want it and you can't actually afford it (say you were laid off or you have a lot of obligations or commitments) contact me and I will give it to you free. If you buy it and you aren't satisfied, I will refund it. If you buy it, you'll be supporting someone like you, a coder, and fighting the good fight. And also getting two years of lessons and dead ends and false starts in a mechanical, systemic and repeatable process. I will be updating it as time goes on, so you will be getting a lifetime process that will update and grow with you.

All you have to do is install it with the python script into your git repository, and you can /kickoff and go. A few questions later and your feature or bug is dealt with by Claude Code.

(please click below)

Claude Code hooks and skills that mechanically block edits to files the agent hasn't read this session. Not a checklist but a working system for features and bugs.

Description: Claude Code doesn't fail loudly. It fails by being confidently, plausibly wrong — stating something about your code it never actually checked, assuming a shared type's shape instead of reading it, editing a centralized config without knowing what else depends on it. A green test suite doesn't catch this. A code review doesn't always catch it either, especially when you're the only reviewer. This kit is the discipline that does. It isn't a set of prompts to remember or a checklist to follow through willpower — it's two hooks that mechanically block an edit to a file Claude hasn't read this session, and nine skills that run the discipline instead of describing it: one that scopes a new feature or migration from a few keywords automatically, one that enumerates every real consumer of a file before you touch it, one that reads your own diff like a stranger would before you call it done. All of it was tested end-to-end against real Claude Code payloads before it shipped — not just described — including a TypeScript example that actually compiles under --strict and an installer verified against four real scenarios, including a project that already has its own hooks. Behind the mechanics is a twelve-stage methodology and six real failure patterns, generalized from two years of exactly this kind of work, so every rule comes with the reasoning for why it exists — not just the instruction to follow it. What you get: Two Python hooks enforcing read-before-edit, zero dependencies, tested against six real allow/block scenarios Nine Claude Code skills — six auto-invoke on their own when the situation fits, no command to remember METHODOLOGY.md — twelve stages from scope to handoff, including the closing-the-loop step most kits like this skip: verifying your own last session's handoff before trusting it LESSONS.md — six real failure-pattern case studies, each tied to the specific rule or skill that catches it faster A one-command installer, tested against four scenarios including a project with pre-existing hooks — never overwrites what you've already built A plain-text version for ChatGPT, Cursor, or any tool without hooks or skills Private GitHub repo access after purchase (invited within a week or two if GitHub User is provided to my email) — updates land there as the system improves, not a zip you download once and it goes stale An invite to a Discord server that's just getting started for buyers — comparing notes on what your own sessions catch, and a say in what gets built next, not an existing community to browse

briandev5.gumroad.com

Thanks for reading and may we all survive in the AI age. In Part Two and later I will go into specifics in later parts about the frontend, the backend, perhaps even talk about the project and how it evens the playing field between AI and humans. Sauce for the goose.

Good vibing everyone.