SDD is the new TDD, meetups, and reshaping repos

Spec-Driven Development became my default. My Claude Code environment got some love with custom plugins, and I kept reshaping repos to be friendlier to work with.

One email, four services

One of my favourite tech challenges is working with legacy codebases — cleaning up the mess gathered in forgotten corners of a system that “works now, but nobody wants to touch”. The problem is that such projects usually come with a real risk of growing in scope while delivering little value.

In March I got a perfect excuse to open one. We needed to add a new variant of a daily customer insights email. It looked like a small feature, but behind it we had:

• An Argo Workflows data pipeline running nightly
• DBT models generated as part of it
• Business-logic SQL extracting the final dataset
• A Ruby on Rails app that actually sent the email

Four different people had contributed at different points in time. Argo belonged to the infrastructure guy. DBT to the data engineer. The mailing selection SQL to a data scientist working with the business stakeholder. And the actual sending? The dev who owned the crawling pipeline. So naturally it lived in the crawlers repository. 🤯

A small feature now meant changes across two repos. It wasn’t the first time we had this problem with this setup, so we decided to clean it up properly. Using Claude Code , the path was straightforward:

1. We created specifications based on the codebase of each repo
2. Then re-implemented them in a brand new Ruby on Rails repository, responsible for generating and sending the email based on BigQuery data

What would’ve been at least a two-week project not long ago took a few days.

Borrowing from plugins

I packaged my common Claude Code skills into claude-plugins — a shared set of workflows I plug into every project. The biggest one is the SDLC plugin: PR creation, pre-merge checks, code review, TDD, debugging, parallel agents.

I don’t install other people’s plugins. When I find one that looks useful, I ask Claude to read its source code, analyze my project history and conversations, and pull in the concepts that fit.

This gave me a solid base of reusable Claude Code plugins, with both ideas borrowed from open source tooling and customization tailored to my workflow.

SDD is the new TDD

OpenSpec became my standard tooling. I played with custom schemas — blog for keeping ideas for blog posts, rspec for creating specs as test cases in Ruby projects.

Spec-Driven Development is my Test Driven Development for the AI era. I was always amazed seeing a senior developer clicking through the web interface after making changes. Like, what the fuck, are you a monkey? Now I feel the same about generating code without specs first.

Doesn’t matter if it’s OpenSpec, Spec Kit , or a self-developed solution. Specs come first, and specs get in the VCS. Period.

One talk, one discussion

First was Brave AI Meetup — another intro to Spec-Driven Development, and probably my last one of those. After two rounds of explaining what SDD is, I’m done. Next time I want to talk about how it actually plays out: where it breaks, what it costs, what it changes about the way you think.

The second wasn’t really a talk. Data Community Bielsko-Biała was two days later, and I had nothing prepared. So I skipped the slides, opened a production DBT repo, and let the audience drive. They asked questions, I showed whatever part of the codebase they were curious about, and the whole session built itself around that.

Designing without designing

Design has always been my bottleneck. This month I started playing with Stitch . It generates designs, I wire them into Claude Code via MCP , and the implementation phase stays in my regular workflow. That split is exactly what I needed.

This blog is my first Stitch project. I used to use a generic Hugo theme, so I decided to give it a shot. Still early days, but it’s the first design tool I’ve stuck with for more than a weekend.

Paying to learn what’s free

AI Devs #4 is my third round. A friend asked me before it started — why pay for AI courses in 2026 when everything’s available online?

True — everything is available online, but “available” isn’t “free.” Reaching the level of knowledge packed into AI Devs would cost me a month or two off from daily work, just to find, gather, and filter the materials myself. I don’t have that learning budget. Paying someone to do it for me is the shortcut.

I’m way behind. The cohort finished today and I’m only past the first three missions. But even the first lessons improved my workflow enough to justify the investment. I wrote up the first mission here .

Side note: Brave Courses run their community on circle.so . They’ve got the team to easily build their own platform — they chose not to. Worth remembering next time you get the urge to build your own CRM.

Poland Technology Grant

The highlight of the month was meeting all my mentees in person for the first time. After months of online calls, watching them meet each other was the best part.

Everyone traveled from different parts of Poland to Relativity’s Cracow office. What Relativity put together was fucking great — a tour around the office, introductions from senior people explaining what their departments do, and an open floor for any questions. The guys got so into it that I actually left before they did.

Hakersi coordinates the whole project, Relativity sponsors it.

Other stuff

A couple of background threads:

• I joined Easy’s League of Makers — a free product challenge for digital creators. Recap in a separate post.
• Three product ideas in the oven, scoped from what I learned during the challenge — that’s the April story.