Every seasoned software engineer has an internal alarm that rings the second they duplicate code.

We’ve had the rules beaten into us for decades: Don’t Repeat Yourself (DRY). Abstract early. Build configurable components. How about- never fork a whole repo just to swap out data 😂

Last week, I ignored every single one of those rules. On purpose.

I had already built a deep, interactive data visualization mapping the census distribution of the 20 Golden Age comic book keys. As any good data visualization that tells a story should be- it  was handcrafted.

Then came time to build the Silver Age version.

The “correct” software engineering approach was obvious: pause, step back, extract the rendering engine into a shared, configurable library, parameterize the data, and build a unified architecture that could ingest either era. That would make the inevitable Bronze Age version so easy! A no-brainer. 

The thing is, doing that properly would have taken hours of typing before I even touched the new dataset. And with data visualization, code is only half the battle—the actual value comes from human interaction with the data. You need to see how the data actually visualizes, how the labels overlap, and how the narrative feels on screen.

So, I committed the cardinal sin of software development:

I forked the Golden Age repo, and edited the code in place.

The Old Cost of Technical Debt vs. The New Reality

In 2018, doing that was reckless. You were creating two diverging codebases. Any bug fix in the core layout logic had to be manually ported. You were saddling your future self with an afternoon of tedious, soul-crushing refactoring.

In 2026, the calculus has fundamentally changed.

I knew the fork was “stupid” in the traditional sense. But I also knew two critical things:

• Speed to human insight is all that mattered in the moment. Copy-pasting the repo got the Silver Age visualization alive and interactive in minutes, letting me focus on the actual content and UX nuances.

• AI has reduced the marginal cost of architectural consolidation to essentially zero.

I deliberately accrued human technical debt because I knew I wasn’t going to have to manually pay it back. I was going to throw tokens at it.

The Cleanup: Delegating the Merge

Once both visualizations were built and validated, the architectural cleanup was trivial.

Instead of sitting there trying to unify two divergent codebases and then ensure they were properly abstracted, I fed both implementations to an LLM alongside clear constraints:

• Extract the shared DOM and SVG rendering code into a single Age agnostic engine.
• Parameterize the data so that differences between eras (census grading ranges, era-specific metadata) were handled via configuration, not logic.
• Ensure the two variations remain intact

What used to be a half-day chore of tedious refactoring turned into a ten-minute code review after the agent was done. The AI did the structural heavy lifting of turning two copy-pasted implementations into a clean, reusable architecture.

Intentional Debt as a Strategic Tool

Engineers often treat technical debt as an accidental failure of discipline. But technical debt is called debt for a reason: sometimes borrowing against the future is the rational financial choice to seize an immediate opportunity.

The difference today is the interest rate.

Historically, the interest rate on copy-paste technical debt was usurious. You paid for it in drift, regressions, and manual cleanup. Today, when the cleanup consists of prompting a model to normalize data and extract abstractions, the interest rate has collapsed.

If your core bottleneck is human creativity, analysis, or design validation, don’t let architectural purity stall your momentum. Write the dirty script. Fork the repo. Edit in place. Ship the insight.

You can always let the machines clean up your mess on Monday morning.