Stop Rebuilding the Same Things: How I Built a Personal Engineering Toolkit

Every new project starts the same way. Sign-in. Tenant isolation. A FastAPI skeleton. A document parser. An evaluation harness. Search that handles Arabic and English. I have written versions of these many times, and each one was good by the time the project ended, and then it stayed in that project.

Craftspeople do not work like that. A carpenter does not forge a new chisel for every table. Over years they build up a workshop, and each job starts with the tools already on the wall.

So I built one. I called it Warsha, the Arabic word for workshop. It started in late September, and it has since been cut into ToolKit: 14 independent projects holding 153 reusable pieces.

This is how it works, so that you can build your own.

Why a snippets folder does not work

The obvious version is a folder of useful code, or a "shared" repository. It tends to fail for three predictable reasons.

• You cannot find anything. The code is filed under what it was called, not the problem it solves.
• It drags its project along. Useful code tends to import half of the app it grew up in.
• You cannot trust it. You do not remember whether it worked, and nothing proves it still does.

A toolkit is only useful if it fixes those three problems. Everything below addresses one of them.

Step 1: Take inventory before you write anything

I started by reading my past projects, not by writing code. I listed what I kept rebuilding, which came to 96 needs across six projects.

That list matters more than any code. It tells you what is worth keeping, because it has already been needed more than once. It also stops you building a beautiful framework for a problem you only imagined.

A rule worth stating early: inventory your own engineering, and leave out anything that is not yours to reuse. Personal data has no place in it. I dropped one source entirely because it held a real CV, even though 20 capabilities had been planned from it. Check what your contracts say about code you wrote for others, and strip names and identifying details as you go.

Step 2: Give the pieces a throwaway caller

This was the idea that made the project work. Reusable code written in the abstract tends to be useless, because nothing has pressed on it.

So Warsha is built as one running app. The app is not the point, and it has never been deployed. Its only job is to call every piece and prove that they work together. If a piece cannot be used by a real caller, I find out immediately.

Step 3: Split the core from the adapter

Every capability has two halves.

When I lift a piece, I copy the core and its tests, never the adapter. I then write a small adapter for the new project. In the two drills I recorded, those adapters came to 103 and 125 lines. That is what reuse should cost: an afternoon of wiring, not a week of untangling.

Step 4: Catalogue by problem, in searchable words

Each capability gets one row in a single catalog file, written in the words you would use when you have the need. It records the core, the adapter, what to change, the tests, and a dated status.

The status has three levels: tested, running, and hardened. Hardened is reserved for a piece that has survived a real project.

Because the catalog is plain text, a small script can check it. Mine fails if a row points at a path that no longer exists or a piece with no tests. A document that a machine checks stays true longer than one that depends on your discipline.

Step 5: Prove independence with tools

Saying "this has no dependencies" is cheap, so I made it a test.

• A boundary check fails if a core imports something from the app.
• A travelling lift test runs in a child process and blocks undeclared imports.
• A lift drill runs the core in an empty folder, away from everything else.
• Tests use fake adapters and a mock model that needs no API key.

One small trap cost me some confidence. If a test needs a database and the database is missing, many setups skip it and report green. In a toolkit, that is how broken code survives. So a setting forces missing infrastructure to fail. It is the same lesson as my cost work: a check you cannot trust is worse than no check.

Why this matters more with AI coding agents

This is the part I did not expect. I wrote the toolkit for myself, and it may turn out to be more useful to my agents.

An AI coding agent will happily rebuild sign-in from scratch, confidently, in a slightly new way, every time. Give it a searchable catalog and a short instruction file, and it can do what I would do: search by problem, read the README, copy the core and its tests, write a new adapter, and run the tests.

That changes what the agent produces. Instead of fresh code nobody has reviewed, it assembles tested parts, and most of the review effort goes to a small adapter. It fits how I already work, as I describe in my agentic methodology: keep the correctness in deterministic checks, not in the model's confidence.

How to start your own

You do not need 153 pieces. I would start with three.

1. List what you rebuilt in your last three projects. Pick what appears at least twice.
2. Check that you may reuse it. Remove names and anything confidential.
3. Build a tiny throwaway app that calls those pieces.
4. Split each into a core and an adapter, with tests that travel.
5. Write one catalog file, in the words of the problem, with a dated status.
6. Add a script that fails on dead paths and missing tests.
7. Run a drill: copy a core to an empty folder and make it work.
8. Tell your coding agent the catalog exists.

Then use it on your next real project, and promote a piece to hardened only when it has survived contact with one.

The aim is not to avoid writing code. It is to stop spending your best hours on problems you solved two years ago, so that they go to the problem nobody has solved yet.

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise RAG, agentic AI, and AI-assisted software engineering.