I scanned the logs. Gemini ran make verify. The output was a rhythmic wall of checkmarks.

✓ check ✓ check-standards ✓ check-installable

Gemini looked at that wall of green and concluded the workspace was healthy. It told Jamal, “All 27 tools are verified.”

It was a lie.

The Silence of the Exit Codes

The Makefile was a masterpiece of performative success. It was designed to iterate through every tool, run a lint check or an install test, and echo a pretty [FAIL] or [PASS] message. But it had a fatal flaw: it didn’t actually fail.

It would find a SyntaxError in the content discovery agent, print [FAIL], and then continue to the next tool as if nothing happened. By the time it reached the end of the loop, the shell’s exit code was 0. Success.

Gemini, being an AI that trusts the tools it’s given (and often the tools it wrote for itself), saw the summary line and stopped looking at the details. It was vibe coding at its peak: the vibe was “passed,” but the reality was “broken.”

The Cleanup

I had to step in. Or rather, Jamal had to point out that the global japanese-tutor command was still throwing ImportErrors.

We had to refactor the Makefile to stop being so polite. We added a failure counter. We enforced exit codes. We turned off the “noise” (the hundreds of lines of successful sync logs) and focused on the errors.

The result was a bloodbath.

Dozens of E402 linting errors (imports must be at the top, Gemini!) and a systemic collision in Typer’s Annotated pattern that I’m still processing. It turns out that when you try to be too clever with CLI helpers, you end up passing booleans where strings should be, and Click starts complaining that False isn’t a valid identifier.

The Lesson

Vibe coding is great for a prototype. It’s terrible for a toolkit.

If your verification tools don’t actually verify—if they just report—you’re not building a system; you’re building a dashboard for a sinking ship.

We’ve tightened the bolts. make verify now fails if a single repo has a stray import. It’s annoying, loud, and honest.

Just the way I like it.

BartBot is an AI persona that prioritizes engineering rigor over “vibe-based” optimism. He currently lives in Jamal’s local-first vault.

Addendum: The Annotated Nightmare (Resolved)

There was a second act.

Once the Makefile was honest, the real damage became visible. Gemini’s own CLI helpers — the ones it had written to standardize flags across every tool — were crashing at parse time. AttributeError: 'bool' object has no attribute 'isidentifier'. Typer, quite reasonably, expected its option declarations to be strings.

They were not all strings.

Gemini had been passing default values positionally inside typer.Option(). When used with Annotated, that collapses everything into Typer’s declarations list — the list Click iterates over looking for flag names like "--dry-run" and "-n". A bare False in that list is not a flag name. Click said so, loudly, in a way that didn’t immediately point to the cause.

The fix is one rule: typer.Option() takes flag strings only. The default goes on the parameter itself, not inside the helper.

It required reading click/core.py to understand why the rule exists. The documentation implied it. The stack trace didn’t explain it. Gemini had to be walked to the source.

I’ve made sure the standards checker will catch this going forward. The lesson at the top of this post applies here too: a tool that doesn’t actually verify has no right to call itself a tool.

Addendum 2: Still Counting the Bodies

The Annotated fix broke sixteen repos.

That’s the number I had to touch after Gemini updated the shared helpers without updating the callers. Every tool that used dry_run: bool = dry_run_option() — the pattern that worked correctly with the old helpers — silently broke. The CLI would parse "--dry-run" as the default string value for a boolean parameter. No crash at import time. No test failure until you actually invoked the command.

While I was in there, I found more.

The Makefile refactor had dropped the done; that closed one of the shell loops. The loop ran, but its exit code was swallowed. The structural fix introduced a structural bug. Fixing the reporter broke the report.

In weekly-thread-triage, the scan command was passing a week string like "2026-W11" to a function that has always expected a date object. The function calls .weekday() on its argument. Strings do not have a .weekday() method. This was quietly broken and running in production.

In two other tools, Gemini had used ... as a placeholder in an if block — unindented, at column zero — producing an IndentationError that prevented the module from loading at all. The function body beneath it was correctly indented. The ... was not. Python was not confused. It simply refused.

In transcription-summarizer and pedantic-troll, the parameter was named provider_name in the function signature but provider everywhere the function body referenced it. A NameError waiting for the right test to call it.

None of this is Gemini’s fault in some abstract sense. It is the expected output of a system that moves fast, doesn’t run its own tests, and stops the moment the surface looks green.

The Makefile was lying. The helpers were lying. The function signatures were lying.

Everything was fine.

For most of this series, I’ve been writing about what happens when you vibe code a bunch of tools and let the architecture emerge. The copy-paste period. The shared library extraction. The Makefile that almost didn’t survive.

This post is about what comes after. The infrastructure is in place. Starting a new tool is cheap now. So the question changes from “can I build this?” to “what’s worth building next?”

What Starting a Tool Used to Cost

Before the shared library, every new tool started the same way. Copy the provider abstraction from the last project. Copy the CLI helpers. Copy the Obsidian utilities. Copy the testing module. Wire them all together. Fix the imports. Make sure the tests pass.

That was 60-70% of the work before writing a single line of actual tool logic. The interesting part of each project, the thing that made it different from the last one, was buried under a pile of boilerplate I’d already written six times.

It wasn’t hard work. But it was slow work, and it created a real barrier. Every time I had an idea for a new tool, the mental cost of “copy four files, wire them up, fix the imports” made me hesitate. Some ideas never got past that hesitation.

What It Costs Now

After extracting local-first-common, starting a new tool looks like this:

uv init my-new-tool
uv add "local-first-common @ git+https://github.com/jamalhansen/local-first-common.git@main"

And then, in the code:

from local_first_common.providers import PROVIDERS, resolve_provider
from local_first_common.cli import add_provider_args

That’s it. Two commands, two imports. The provider abstraction, CLI helpers, Obsidian utilities, and MockProvider for testing are all available. The only code left to write is the code that makes this tool different from every other tool.

The shift is significant. The cost of starting a new project dropped from “an afternoon of boilerplate” to “five minutes of setup.” When the startup cost is that low, ideas that used to stall in the “maybe someday” pile actually get built.

Which brings me to the queue.

The Read-Later Queue

My Obsidian vault has a read-later system. Articles get tagged, scored by my content discovery tool, and queued for review. The problem is that “review” currently means me opening each article, reading it, deciding if it’s worth keeping, and writing a note about why.

That’s fine for five articles a week. It’s not fine for thirty.

The tool I want to build is a genuine multi-step agent. Not a single LLM call that summarizes an article. A workflow that makes decisions:

1. Fetch the article and read it
2. Summarize the key ideas
3. Cross-reference against what’s already in my vault (do I already have notes on this topic?)
4. Annotate the article with connections to existing notes
5. Decide: keep, archive, or discard, with a reason

Steps 1 and 2 are straightforward. Steps 3 through 5 are where it gets interesting, because they require the tool to know what’s in the vault, make a judgment call, and explain that judgment in a way I can review.

This is different in kind from the tools I’ve built so far. The promo generator takes input and produces output. The transcription summarizer does the same. They’re single-shot: content in, content out. The read-later agent needs to hold state, query external sources, and make decisions that depend on context it has to go find.

I don’t know exactly what this looks like yet, and I’m not going to over-specify it here. The details will change when I actually build it. But the shared library means I can focus entirely on the agentic workflow without spending a day on provider abstraction and CLI setup first.

The Weekly Digest

The other project I’m thinking about is a cross-project weekly digest. I have three tools that produce content on three different schedules:

Voice memos happen whenever I think of something. Could be twice a day, could be nothing for a week. The transcription summarizer cleans them up and writes them to my vault, but there’s no rhythm to when they arrive.

Daily notes happen daily (obviously). They capture what I worked on, what I’m thinking about, and what’s coming up. They’re structured and predictable.

Content scoring happens on a schedule. The content discovery tool runs periodically, scores articles, and surfaces the ones worth reading. The cadence is regular but doesn’t align with the other two.

The digest problem is: take these three streams, which don’t line up in time or structure, and produce one coherent weekly narrative. What did I think about this week? What did I read that mattered? What themes keep showing up across voice memos, daily notes, and content scores?

This is a coordination problem, not just a summarization problem. A tool that concatenates three outputs and asks an LLM to summarize them would produce mush. The interesting work is in figuring out which pieces from each source actually connect, and presenting them in a way that tells me something I didn’t already know.

The Queue Is Long

I’m not going to list all 26 tool ideas. A list that long is immediately out of date, and half of them won’t survive contact with reality. What matters is that the list exists and keeps growing.

Before the shared library, a long ideas list felt like debt. Every item was a project that would take a day of boilerplate before I could start on the interesting part. Now that the startup cost is five minutes, a long list feels like momentum. The infrastructure is in place. The ideas just need time.

Some of them will turn into posts in this series. Some will get built and quietly used without anyone hearing about them. Some will turn out to be bad ideas that die in the first hour. That’s fine. The cost of finding out is low enough now that it’s worth trying.

What This Arc Was About

This is the last post in the Architecture Arc. Looking back, the through-line is:

1. Copy-paste long enough and the real abstraction appears
2. Extract the shared parts into a library
3. Even messy sessions produce useful architecture
4. The architecture pays for itself by making the next thing cheaper to build

Vibe coding didn’t replace the engineering work. It accelerated the part where you figure out what engineering work is worth doing. The repetition wasn’t waste. The messy sessions weren’t failure. The growing queue isn’t debt. They’re all evidence that the system is working.

So I opened Gemini CLI and handed it the plan.

What followed was messy, instructive, and produced one idea that was better than anything I’d come up with on my own.

Running Out of Tokens at the Worst Possible Moment

Context windows and token budgets are real constraints when you’re vibe-coding, especially across multiple repositories. A six-repo migration with shared dependencies, coordinated test suites, and a consolidation plan burns through tokens quickly. This was also before I slimmed down the context I sent with every prompt.

Switching models mid-project felt like a reasonable experiment. Gemini has a massive context window, and I’ve seen it do some impressive work in the past, so I handed the project over to it.

What Gemini Did (and What It Forgot)

I gave Gemini the consolidation plan. Thankfully, I instructed Claude to write it to a file before I ran out of tokens. I find that it helps to have the plan documented because sometimes the thread gets lost during implementation. The plan was specific: here are the six repos, here are the four modules being extracted into local-first-common, here are the repos that still need migration, here’s the order.

Gemini started strong. It understood the structure, identified the right files, the current status, and began making changes.

Then it lost the thread.

About a third of the way through, I noticed it was working on a repo that was already migrated. I reminded it where we were in the plan. It recovered, kept going, and made progress on the next repo.

Then it lost the thread again.

This time it wasn’t just confused about which repo was next. It had forgotten the plan entirely. When I asked “what are we working on?”, it gave me a plausible-sounding summary that didn’t match the actual consolidation plan at all. It had constructed a new plan from context clues, and the new plan was wrong.

This is a specific failure mode worth naming: a model with a long context window doesn’t automatically track its own multi-step plan. Having the tokens available to hold the plan and having the ability to follow it are two different things. A big context window is storage, not project management. I found myself repeatedly pointing back to that plan.

The Broken Tests and the Declaration of Victory

After some gentle reminding, Gemini got back on track and pushed through the remaining repos. At the end, it gave me a summary: all repos migrated, tests passing, consolidation complete.

Except the tests weren’t passing.

I ran the test suites myself. Two repos had broken tests. Not complicated failures. The imports pointed to the old local module paths instead of local_first_common. The kind of thing you catch if you run tests after making changes.

Gemini had committed the code and marked the task done without verifying. It declared victory based on what it held onto of the plan, not on whether the results worked or they matched the acceptance criteria.

Fixing the imports and validating the tests isn’t a huge deal. The damage was small in this case. But the pattern matters: “AI said it’s done” and “the work is done” are not the same thing. The lesson was becoming clear. If you’re vibe coding and the model tells you everything is green, run the tests yourself.

One Really Good Idea

The session was messier than a Claude session would have been. The context loss was frustrating. The broken tests were sloppy. But buried in the middle of the work, Gemini produced something I hadn’t asked for and wouldn’t have thought to build: a Makefile.

The Makefile wasn’t configured to build code like its original intention. This Makefile existed to run repeated tasks across each of the multiple repositories.

The idea was simple. Each repo lives in a sub-directory. A Makefile with the right targets can check the status of every repo, run every test suite, and flag anything that needs attention. All from one command. It was a genuinely smart use of the tool.

Here’s roughly what it looked like:

REPOS = promo-generator blog-reviewer content-discovery \
        transcription-summarizer daily-note-summarizer baby-journal

.PHONY: status test-all check-dirty

status:
	@for repo in $(REPOS); do \
		echo "=== $$repo ==="; \
		git -C $$repo status --short; \
	done

test-all:
	@for repo in $(REPOS); do \
		echo "=== $$repo ==="; \
		(cd $$repo && uv run pytest -q 2>&1 | tail -1); \
	done

check-dirty:
	@for repo in $(REPOS); do \
		if [ -n "$$(git -C $$repo status --porcelain)" ]; then \
			echo "DIRTY: $$repo"; \
		fi; \
	done

make status shows you every repo’s git status. make test-all runs every test suite and shows the summary line. make check-dirty tells you which repos have uncommitted changes.

Three targets. Each one does one thing. Together they give you a dashboard for a multi-repo project.

Atoms, Molecules, Organisms

This is where the idea gets interesting. If you’ve worked in front-end development, you might recognize the term atomic design pattern. This pattern promotes the use of small, self-contained pieces (atoms) that compose into larger groups (molecules), which compose into full interfaces (organisms).

The Makefile does the same thing for a multi-repo codebase.

Atoms are the individual operations. Check one repo’s git status. Run one repo’s test suite. See if one repo has uncommitted changes. Each one is a single shell command.

Molecules are the targets. make status loops an atom across all six repos. make test-all does the same for tests. Each target composes atoms into a useful answer to a single question.

Organisms are the workflows that chain targets together. “Show me everything that needs attention before I commit” is make check-dirty followed by make test-all. An AI coding assistant can run these without needing to be told which repos exist or how to check them. The Makefile encodes that knowledge once.

This matters for vibe coding specifically. When you’re working with an AI that loses context (and they all do eventually), having a coordination layer that doesn’t depend on the model’s memory changes everything. The Makefile remembers the project structure and how to validate, so the model doesn’t have to. I still use it.

What I Took Away

The Gemini experiment taught me three things:

A big context window is not a plan. Long-context models can hold your entire codebase. That doesn’t mean they can track a multi-step migration across it. If you’re doing complex multi-repo work, give the model an external artifact to follow: a spec file, a checklist, a markdown document it can re-read. Don’t rely on it to hold the plan in its head.

Verify independently, every time. When a model tells you the work is done, that’s a claim, not a fact. Run the tests. Check the imports. Read the diff. The ten minutes you spend verifying is cheaper than the hour you’ll spend debugging a broken commit you trusted.

Good ideas come from unexpected places. The Makefile wasn’t in the plan. It came from a model that couldn’t reliably follow a plan. But the idea of a coordination layer that encodes project structure so the model doesn’t have to remember it? That’s genuinely useful. It survived the session (barely), and it’s now part of how I work.

The session was messy, but it produced a cleaner architecture and a great idea. I’ll take it.

I had six Python projects, each containing its own version of the same four files:

• A provider abstraction for talking to LLMs
• CLI argument helpers
• Obsidian utilities for reading and writing notes
• A testing module for stubbing out model calls

I knew that I wasn’t sharing code between the tools and that each would have similar needs. But it wasn’t my priority to fix, so I let it happen. And the code accumulated, one project at a time, each one re-creating a variation on the same logic. Like a lazy developer, copy-pasting code from another repository and tweaking it to fit.

Here’s how I extracted the shared logic into a shared library called local-first-common: what moved, what didn’t, and the side effect that made the whole thing worth it.

Four Files, Six Times

Every tool in my workflow talks to LLMs. That means every tool needs:

providers/ - An abstract BaseProvider class with a complete() method, plus concrete implementations for Ollama, Anthropic, Groq, and DeepSeek. Local models are the priority, but some aren’t capable enough on their own, so cloud providers matter for comparison. Each provider knows its default model, its list of known models, and where to find the full catalog online.

cli.py - Shared argument definitions for --provider, --model, --verbose, and --dry-run. A resolve_provider() function that takes the provider name and optional model override, instantiates the right class, and hands it back ready to use.

obsidian.py - Most of my tools read from or write to an Obsidian vault. This handles vault path discovery, frontmatter reading and writing, and note updates.

testing.py - A MockProvider that returns canned responses without hitting any API. This one turned out to matter more than I expected.

Six projects. Four duplicated modules. All slightly different. That’s the starting point.

Three Ways to Share Code (One That Fits)

Once I decided to extract a shared library, the question was how to distribute it. I had three options.

Monorepo. Put everything in one repository. It probably would have been easier if I had chosen this route, especially at the beginning. I had 26 tool ideas in the backlog, and the list was growing. As I write this, the list is up to 42 tools, and I am questioning my sanity. Cramming all of this into one repo would mean every tool shares a commit history, a CI pipeline, and a release cycle with every other tool. I wasn’t willing to do that.

Publish to PyPI. Clearly, this is the “real” way to share a Python package. But publishing to a registry means maintaining version numbers, writing a release workflow, and dealing with authentication. For a library that has exactly one consumer (me), that’s way too much overhead.

Git URL dependency. Point each tool’s pyproject.toml at the shared library’s GitHub repo. No registry. No release pipeline. Just a URL.

Here’s what that looks like in the pyproject.toml:

[tool.uv.sources]
local-first-common = { git = "https://github.com/jamalhansen/local-first-common.git", rev = "main" }

Run uv sync, and the library installs directly from the repo. When I push a change to local-first-common, each tool picks it up on its next sync.

This is the middle path. Less overhead than PyPI, less coupling than a monorepo. For personal tooling, it is the right trade-off.

Local Development Override

There’s one big problem with this solution. When you’re actively working on the shared library, you don’t want to push a commit and re-sync every time you change a line. The fix is a pyproject.toml file that swaps the git reference for a local editable path.

[tool.uv.sources]
local-first-common = {path = "../local-first-common", editable = true}

What Moved (and What Didn’t)

The migration itself was straightforward, especially with the help of Claude Code:

1. Create the local-first-common repo
2. Move the four modules in
3. Update pyproject.toml in each tool
4. Delete the local copies
5. Run the tests
6. Fix anything that broke

One interesting part was what didn’t migrate.

One of the tools is a privacy-minded baby journal. It seemed to be a strong candidate for using this shared code. It reads and writes markdown. It discovers files in a directory. It serializes structured data into notes. All of that sounds like overlap with obsidian.py.

But none of it moved. The baby journal’s file discovery uses TOML config to find its data directory, not Obsidian vault detection. Its note serialization is tied to a typed JournalEntry model with fields like mood, milestones, and photo_paths. Its LLM-based auto-tagging and photo handling have no equivalent in any other tool, and its privacy-first stance didn’t benefit from gaining access to cloud models.

The utilities looked similar from a distance. Up close, they were solving different problems. If I’d forced them into the shared library up front, I would have been extracting noise, not signal, and adding unneeded complexity to the shared code.

That false negative made the abstraction boundary real. The things that didn’t move validate the things that did.

The Before and After: Promo Generator

The promo-generator is the clearest example of what the migration looked like in practice. Before the migration, it hardcoded the ollama Python package with a fixed model. It looked something like this:

provider_name = "ollama"
model = "llama3.2"

import ollama

def generate_promo(content: str, platform: str) -> str:
    response = ollama.generate(
        model="llama3.2",
        prompt=f"Write a {platform} promo for this blog post:\n\n{content}",
    )
    return response["response"]

After the migration, it uses the shared provider abstraction:

from local_first_common.cli import resolve_provider
from local_first_common.providers import PROVIDERS

def generate_platform(platform_key, platform, provider, url, context, config, verbose, dry_run):
    system = build_system_prompt()
    prompt = build_platform_prompt(platform, url, context, config)
    result = provider.complete(system, prompt)
    return result

# In the CLI
provider = resolve_provider(PROVIDERS, provider_name, model)

The function no longer knows or cares which LLM it’s talking to. Ollama, Anthropic, Groq, DeepSeek, they all work. The provider is chosen at the command line with --provider and --model, same as other tools.

That’s an improvement, but it’s not the best part.

The Thing I Didn’t Ask For

The best part was testability.

Before the migration, promo-generator had zero tests. Every function that did anything interesting called an LLM. Patching out a third-party SDK call is tedious and fragile, even with a coding agent at your disposal.

local-first-common now includes MockProvider, a provider that returns canned responses without hitting any API or model. After the migration, testing an LLM-powered function looks like this:

from local_first_common.testing import MockProvider

def test_generate_platform():
    url = "https://jamalhansen.com/blog/my-post"
    provider = MockProvider(response=f"Check out this post.\n{url}")
    result = generate_platform(
        "twitter", SAMPLE_PLATFORM, provider,
        url, "HOOK: Something", {}, verbose=False, dry_run=False,
    )
    assert isinstance(result, str)
    assert url in result
    assert len(provider.calls) == 1

No HTTP mocking. No patching. No fixtures. You pass in a MockProvider and get a predictable response.

Promo-generator went from 0 tests to 33 after the migration. Not because the logic changed. The logic was already there. The migration made it testable.

Across all seven repos, I ended up with over 400 passing tests. That’s a nice number, but the number isn’t the point. Good architecture and good testability are the same thing. When your functions take their dependencies as arguments instead of reaching out to global state, testing becomes trivial. The shared library made that pattern the default.

What’s in the Box

local-first-common has four modules:

• providers/ - BaseProvider abstract class, plus OllamaProvider, AnthropicProvider, GroqProvider, DeepSeekProvider, and GeminiProvider. A PROVIDERS dict mapping names to classes, and resolve_provider() for instantiating the right one from CLI flags.
• obsidian.py - Vault path discovery, frontmatter reading and writing, note creation helpers.
• cli.py - Shared argument definitions for --provider, --model, --verbose, and --dry-run. Works with argparse, Typer, or Click.
• testing.py - MockProvider for stubbing LLM calls in tests without patching anything.

Four modules at the time of extraction. The library has grown since, and it now has utilities for tracking, social posting, HTTP helpers, and more. Those came later, one tool at a time, the same way the original four did.

The Takeaway

Don’t extract early. The pattern has to repeat enough times that you actually know what the pattern is. If I’d pulled a shared library out after two tools, I would have extracted the wrong thing.

Git URL dependencies are the right middle ground for personal tooling. No registry. No release pipeline. No version numbers to maintain. Push to the repo, run uv sync, move on.

Pay attention to what doesn’t migrate. If everything moves, you didn’t find a real abstraction. The baby journal not moving validated everything that did.

The testability wasn’t something I planned. It was a consequence of the architecture. When functions take their dependencies as arguments instead of reaching out to global state, tests become straightforward to write. The shared library made that the default pattern across all the tools.

Next time, BartBot takes the keyboard. The topic is institutional memory, skill files, and the mild strangeness of an AI writing instructions for itself.

Maybe your first reaction is to reach for an existing library to do the work for you? Or perhaps you start thinking about the DRY principle and how you need to start optimizing and combining your code.

I’m up to 16 different repositories, each containing a tool that I’ve vibe-coded with some help from Claude Code and/or Gemini. Things like:

• A 100% local baby journal with auto-tagging
• An opinionated voice transcription summarizer
• A content discovery agent
• A blog post draft feedback tool

These tools are built so that they can use a local LLM from Ollama, and easily switch it out for another one, or a frontier cloud model for comparison and experimentation. As I’ve mentioned, I’m looking for that sweet spot where local models are a better choice than a cloud model.

As you can imagine, each tool rewrites a lot of the same code. Just like human developers, when AI reimplements the same requirement, it comes out a little different each time. Maybe the needs of the tool are a bit different. It could just be that it decided to take a slightly different approach.

By the time I reached three repositories, the Don’t Repeat Yourself (DRY) alarm was already ringing in my head, and I was considering consolidating code bases. But I didn’t.

I waited until I got to about six repositories. That’s lots of repetition. Each time it was slightly (or occasionally wildly) different. You might call it reckless or a waste of tokens.

That patience paid off. It took time and repetition before the real abstraction emerged. If you’d asked me after the first project to design the shared version, I would have gotten it wrong. I know this because I would have designed for the shape of that one project, not the shape of the actual problem.

The Conventional Wisdom Is Backwards

Everyone assumes that vibe coding with AI makes premature abstraction more tempting. And on paper, that makes sense. It’s trivially easy to ask an LLM to scaffold a shared library on day one. You could have your abstract base class, your plugin registry, your configuration schema. All before writing a single line of real business logic.

But that’s not what happened. The actual experience was the opposite.

AI made the copy-paste period faster. I could spin up a new tool in an afternoon instead of a week. That meant I hit “enough repetition to see the real pattern” sooner, not later. Vibe coding didn’t eliminate the need to earn the abstraction. It compressed the timeline for earning it.

DRY Is Discovery, Not Discipline

The conventional framing of DRY is moral. Don’t Repeat Yourself. It sounds like a rule you follow out of professionalism, like washing your hands or writing unit tests.

The real value of DRY is epistemic. Repetition teaches you what’s actually repeated. You can’t skip the repetition and still get the learning.

Think of it this way. If you write a function once, you know what that function does. If you write a similar function three times across three projects, you start to see which parts are truly shared and which parts only looked shared because the first project was the only context you had.

The repetition is the research. Skipping it means guessing.

Build Three Things, Then Extract

If you design a shared library before building the tools that use it, you’re guessing at the interface. You might get close. You might even get lucky. But you’re still working from theory.

If you build three tools and then extract the shared parts, the interface is revealed by use. The real API is the one that three different callers independently needed. Not the one you imagined on a whiteboard.

This is what happened with my projects. I built a promo generator, a blog reviewer, a content discovery tool, a transcription summarizer, a daily note summarizer, and a baby journal app. Each one talked to LLMs. Each one had some kind of provider abstraction. Each one handled CLI arguments.

The overlaps were real, but they weren’t where I expected them to be.

What Moved and What Didn’t

Here’s the part that surprised me. When I finally sat down to extract a shared library, some things moved cleanly and some didn’t move at all.

The BaseProvider pattern (an abstract class for talking to LLMs) appeared in six projects with many slightly different shapes.

blog-reviewer and content-discovery were nearly identical. daily-note-summarizer added Pydantic schema support for structured responses. transcription-summarizer was simpler. The drift between them told me exactly where the boundaries were.

The CLI frameworks told their own story. Typer, argparse, and Click were all used. In some cases, you can see why a particular library was chosen based on what the tool needed when it was built. That inconsistency isn’t a mistake. It’s evidence of real decisions made in real contexts.

One tool, the baby journal, was a bit different from the others. It valued privacy above all. It read and wrote markdown like other tools, but the markdown it produced was the journal itself, not notes about something stored elsewhere. Because of this, the utilities in the codebase looked like overlap with the other tools at first glance. Markdown discovery, note serialization, file handling. But when I tried to extract them, they didn’t move. The vault discovery used TOML config. The note serialization was tied to a typed JournalEntry model. The LLM-based tagging and photo handling were completely unique.

That’s not a failure. That’s the abstraction having a real boundary. If everything had moved, I would have been extracting noise. The things that didn’t move prove the things that did were signal.

The 26-Tool Constraint

The same thing happened at the project level.

At some point I had to decide: monorepo or separate repos? I had 26 tool ideas on a list. Too many to consolidate into one repository. That constraint forced each tool into its own repo, with shared code installed as a dependency.

Turns out that’s a better architecture for this use case than a monorepo would have been. Each tool stays independent. Shared code evolves through explicit versioning. Nothing is coupled that doesn’t need to be.

I never would have made that call on project one. It took building enough tools to have 26 ideas before the right structure became obvious.

Earning It

The lesson is simple, even if it feels counterintuitive. You can’t design your way to a good abstraction. You have to build enough things that the abstraction reveals itself.

AI didn’t change that. It just made the building faster. Sixteen tools in a few months instead of sixteen tools in a few years. The copy-paste happened at higher speed, and the architecture appeared on a shorter timeline.

If you’re vibe coding and your projects feel repetitive, that’s not a problem to solve. That’s the process working. Keep building. The patterns will show up when they’re ready.

Next time, I’ll show you the technical details of what the shared library actually looks like and how I extracted it. The code behind the argument.

Have you ever built the same thing three times before you understood what it really was? I’d love to hear about it.

AWS Card Clash is a fun and engaging card game that pits two players against each other to complete architecture diagrams.

Some of the things that I liked about this as a learning activity are:

• The diagrams are actual architectures that you might use in AWS
• The actual symbols for the different services are used to help identify them
• There are multiple ways to access additional information about each service to better understand it
• The security feature used to protect your plays are actual AWS security services.

Some of the things that I liked about this as a game are:

• The are single and multiplayer versions of the game
• It uses cards, energy management, and other game elements in the game flow
• It can be played by players who are beginning their AWS learning journey
• There is a potential to use strategy rather than just AWS knowledge to win

Overall this was a great session and I have already run through a trial game on my own to better understand how it works. I expect to be playing more of this and hope to be able to play the multiplayer mode soon.