DEV Community: Caleb Wodi

I Removed An Entire Implementation Of My System To Fix An Architectural Duplication That Was Painful To Maintain Alone (Deleted ~1300 lines)

Caleb Wodi — Thu, 30 Apr 2026 12:41:28 +0000

The real problem with duplication

Having two implementations of one system didn’t look like a problem to me at first, I built it once and it worked, then I re-implemented the same system again in another language, keeping feature parity and that also still worked.

I'm building ExplainThisRepo, a CLI tool for understanding unfamiliar codebases that shows you where to start, what matters and what to ignore using real signals; entrypoints, configs, dependencies, manifests, not blind AI guessing

Before now every time I ship a feature I’m not building it once, I’m actually building it twice, same with bugs, I’m not fixing them once, I’m fixing them twice

Initially it seemed manageable, but what I had actually created was two sources of truth.

And now I also have to make sure both implementations behave the same way in different languages: Python and TypeScript

They were not wrappers of each other, they were just two independent systems with the same features, behavior, outputs and edge cases, implemented differently in each language, and I had to keep aligning them and maintaining ecosystem feature parity.

That slowed everything down and was very painful to maintain alone

At some point, I stopped moving fast not because the system was complex, but because I was maintaining two of everything.

So I removed the duplicate TypeScript implementation, deleted ~1300 lines and made Python the only core implementation and source of truth, Node now only bundles into npm distribution and launches the Python binary, it no longer runs any logic, all the logic lives in Python.

All the CLI behavior, repo analysis, providers, output, everything, runs inside the prebuilt Python binary. It runs without requiring Python installed on the user's machine. No duplication, one system

Link to PR: https://github.com/calchiwo/ExplainThisRepo/pull/208

Why Python became the core implementation

The decision was not about “which language is better”, it was:

Which implementation should remain as the single source of truth?

One system should have one source of truth, everything else is distribution.

I chose Python because it’s the correct long-term place for the system to live. It was already the implementation I was building on most actively, new features were landing there first and that’s where the system was already evolving.

In short Python was where the core logic was stable and iteration was fastest

Keeping TypeScript as the core would mean either shifting development entirely to it or continuing to duplicate work, both increase long-term cost.

So instead of moving the system, I kept it where it was already being developed, removed the TypeScript implementation, and made Python the only core implementation, Node now just acts as a launcher for the Python binary and distribution.

Why maintaining both breaks down over time

At that point, it was tempting to say:

“I’ll just keep both implementations and manage them”

and yeah that works early but it doesn’t scale.

Because the real cost isn’t just duplication, it’s coordination, you now have to keep both implementations aligned, every change now means doing the same work twice, making sure behavior matches, remembering what changed where, and that turns simple changes into tracking problems, so you hesitate to ship, small differences start creeping in, edge cases multiply and over time the system becomes harder to trust, harder to maintain and slower to evolve.

This gets worse when you’re maintaining it alone, there’s no distribution of effort, you’re the one building, reviewing and maintaining consistency, and at some point it slows everything down not because the system is complex, but because you’re maintaining two of everything.

The hidden trap is this: duplication creates the illusion that things are fine, but in reality it removes clarity, you no longer have one system (or single source of truth) you can reason about, you now have two systems that must stay consistent, and that is a fundamentally harder problem.

What this actually is

This isn’t just a refactor, it’s a correction, I moved from a multi-runtime tool to a single-engine product with a distribution wrapper, the mistake was letting the same system exist in multiple places, so I changed how it’s distributed, Node no longer re-implements anything, it just detects your OS, picks the right binary and executes it as a separate process.

When to use this approach

This pattern works when:

• you need to distribute across multiple ecosystems without rewriting the system
• the interface is clear and bounded (clear inputs, a defined process and predictable outputs)
• cross-runtime execution is acceptable

Common cases:

• CLI tools
• automation tools
• backend services with well-defined boundaries
• internal tools shared across environments

When not to use it

This pattern does not fit when:

• you’re building libraries that must run inside a specific runtime
• tight, in-process integration is required
• performance is sensitive to process startup or cross-runtime latency
• the system relies heavily on features tied to a specific runtime

The test

Before you build the same system twice, ask:
If I change this tomorrow, do I have to update it in more than one place?
If the answer is yes, you don’t have one system, you have duplication.
And if you keep going, you’re choosing coordination over progress.
You don’t fix duplication by maintaining it better, you fix it by removing the second place it exists

Tradeoffs

This change simplifies the system, but it isn’t free, bundling Python into the npm package increases the binary size so install size goes up compared to a pure Node tool, startup also has a cost because the Node launcher starts a separate Python process which adds extra startup time before execution, cross-platform support becomes more complex since you now need to build and maintain binaries for different operating systems and architectures, and debugging is less direct because issues can sit across the boundary between Node and Python, so you end up tracing problems across two environments.

These are real costs, but they are contained costs, not duplicated logic, and I chose to pay them because they scale better long-term than maintaining two implementations of the same system.

The conclusion

Maintaining both is not something you can sustain, the cost keeps increasing over time until it forces a decision, you either accept the growing cost or enforce a single source of truth, I chose the second.

Day 3 of building ExplainThisRepo, a CLI tool that explains GitHub repos in plain English

Caleb Wodi — Thu, 08 Jan 2026 13:38:42 +0000

Ollama needs 1.2gb to install. I just ran away 🏃😂

Too heavy

Switching to Gemini next

Ship 🔱
Twitter

Day 2 of building ExplainThisRepo, a CLI tool that explains GitHub repos in plain English

Caleb Wodi — Thu, 08 Jan 2026 13:34:24 +0000

I integrated OpenAI into the CLI to generate explanations

But API keys + cost per call failed the idea for something people can just run

V1 has to work without paid APIs

So I’m checking out local models like Ollama

Back to the drawing board

Ship 🔱
Tweet

Day 1 of building ExplainThisRepo, a CLI tool that can be used to explain GitHub repos in plain English

Caleb Wodi — Thu, 08 Jan 2026 13:29:27 +0000

Day 1 of building ExplainThisRepo, a CLI tool that can be used to explain GitHub repos in plain En

Built the CLI skeleton and got GitHub fetching working
Imports broke when I ran scripts directly, fixed by understanding module execution
V1 is taking shape

I'm trying to build a CLI tool that can be used to explain a github repo in plain english And i will be sharing what works and what doesn't Let's see how i push this

Caleb Wodi — Thu, 08 Jan 2026 13:27:06 +0000

Successfully made my first pull request today for Rocjet Technologies Ltd

Caleb Wodi — Thu, 09 Oct 2025 11:13:59 +0000

Successfully made my first pull request today for Rocjet Technologies Ltd! 🎉

Added workflow badges to our demo repo

Check it out here 👇
https://github.com/RocjetTechnologies/demo-repository/pull/1

Day 32 of me coding games on my phone

Caleb Wodi — Thu, 09 Oct 2025 11:12:57 +0000

Day 32 of me coding games on my phone

Small setups, big dreams.
Every line of code counts.

Took my time to understand this COLLISION thing

It was tough, but that’s how every game.... from Minecraft to Subway Surfers actually works behind the scenes

https://youtube.com/shorts/myl9n6nbToA?si=l3HBEtoIMTxGU_t_

Day 31 of coding games on my phone: learned collisions and physics today

Caleb Wodi — Tue, 07 Oct 2025 22:56:36 +0000

Day 31 of coding games on my phone

I learned collisions and physics today

Now the player can jump, fall, and land properly.

I made the enemies collide, touch one, Game Over.

Day 30/60 Days Game Dev On Android Challenge

Caleb Wodi — Tue, 07 Oct 2025 22:56:13 +0000

Day 30/60 Days Game Dev On Android Challenge

30 days down. 30 more to go.

We’re halfway there, but the fire’s just getting started.

See you for Day 31 🚀

Day 29/60 of my game dev on Android challenge

Caleb Wodi — Sat, 04 Oct 2025 18:47:18 +0000

150+ days solo-founding Rocjet Technologies at 15.

Some days feel like I’m fighting the code more than I'm writing it, but faith keeps me grounded.

Day 29/60 of my game dev on Android challenge:
🎨 Leveled up the visuals
🌄 Updated the background color

Trust the process.

God’s timing > your timeline.

Coding on my phone’s tough, but working with less forces me to be more resourceful.

Caleb Wodi — Fri, 03 Oct 2025 22:18:35 +0000

Coding on my phone’s tough, but working with less forces me to be more resourceful.

Day 28/60 of game dev on Android challenge:

Added:

onscreen buttons
multiple enemies

To everyone building, guard your time like gold
every hour you waste delays your dream.

Keep building, keep learning, keep going

God never fails ✝️

Day 28/60 of game dev on Android challenge

Caleb Wodi — Wed, 01 Oct 2025 01:11:01 +0000

Day 28/60 of game dev on Android challenge:

Added onscreen buttons and multiple enemies today 🎮.

Coding on my phone’s tough, but limits breed creativity.

Founders, guard your time like gold
every hour you waste delays your dream.

Keep building, keep learning, keep going

God never fails ✝️