Just a bunch of random thoughts & scribbles from my January adventures in codingland.

Data Quality

Data Quality is an ongoing challenge I’ve been dancing around for the last 2 years. This is a topic that required a big mindshift when I switched from software engineering to data worlds.

With software it’s (usually) quite easy to say if something works, or doesn’t. From a developer point of view, if there’re no exceptions and alerts coming in after a release then I could assume something works.

With data? It’s a completely different topic, especially with data at scale. The sole fact that things are inserted in the database doesn’t mean that things are working well. At all.

So, in January I spent quite a lot of time on:

  • High-level dbt models to store daily Data Quality metrics
  • Removing non-critical alerts to limit the noise
  • Scoping down the dashboards to get an instant overview of the system health
  • Custom Claude Skills to aid dbt model debugging, fixes & rebuilds

BigQuery Infrastructure

I dug deep into the BigQuery pricing model and optimizations in terms of price vs performance ratio. I realised I’ve been burning tons of money because of uncapped On-Demand queries.

I moved towards Capacity compute pricing and instantly the costs went down. That would be a win, but performance of the queries also degraded.

So I went down into adjusting the BigQuery slot capacity, played with Materialized Views to optimize some queries, and started investigating the most expensive queries in the system looking for optimization spots.

Still, the main benefit came from the simple change of the pricing model. BigQuery became about 7 times cheaper in the final setup with satisfying performance.

n8n Workflows & Automation

I started using n8n a lot for both personal and professional projects. I got rid of all the personal workflows built with make.com, removed any cron-based scripts, and put everything in n8n.

For professional projects, I pushed n8n as an experimenting platform for building custom AI Agents and automation workflows. A lot of back and forth came here, but in the end it became quite a usable platform.

I’m still (very) sceptical about the maintenance of the workflows, especially seeing as they grow. I see n8n as a great prototyping toy, but for bigger scale it’s still that – a toy.

The graphical interface of n8n never convinced me, I’d rather write code than drag & drop boxes. So, I work with the workflows only via Claude Code with n8n MCP . This works fantastically for development.

What I miss:

  • Proper monitoring (OTel, please?)
  • A way to structure workflows and visualize dependencies
  • Better export format (JSON is painful, YAML would be nicer)

And the pricing doesn’t help — the free plan is poor, self-hosted paid is too expensive.

I guess I’ll keep it for some time, but now with AI tooling to generate code I see less and less value for n8n.

Claude Code & Dev Environment

Claude Code became my main interface to work with code back in December, but I still used it without spending too much effort on making it my own tool.

In January I went all-in. Custom skills, agents, context management, prompt tuning — I experimented with everything Claude Code had to offer.

So I started tuning my development environment to support my AI-driven development. I changed my thinking from “How can I implement this?” to “How can an AI tool implement this for me?”.

And in the spirit of a lifelong Vim user, I now have capacity to tweak that environment as I go thanks to my dev-env and own-cloud projects.

Poland Technology Grant

It’s a scholarship initiative by Relativity and Fundacja Sarigato supporting young IT students (18–26) facing financial or social challenges. More about the program: https://hakersi.pl/wspolnie-z-relativity-wspieramy-mlode-talenty-it/

I’m working with 6 participants, helping them navigate all kinds of challenges. And after a few calls, I can say the needs really vary. Some need a gentle push to show they can do more, some need help with pure tech skills, and some are juggling so many things on their plate that we’re working on doing less.

I like working with Hakersi so much. It gives me a fantastic opportunity to stay in touch with people who are making their first steps in IT. Putting me out of the bubble, showing that things which I consider obvious and take for granted, for others are huge game changers.

It also makes me extremely worried about the state of education, as the university programmes are so extremely outdated. And the constant question that keeps coming back to my mind is: what skills would one prioritize now to start working in IT? Coding? Jumping straight to agents and building?

OpenSpec & Spec-Driven Development

The main problem I had so far with jumping on the AI hype train, and the reason why I never was interested in the “vibe coding” trend was that a big chunk of work was eventually removed.

In the old-school development mode I’d use some special words (programming language keywords) in a text file. I’d then use a special extension of that file, so that a computer would do a thing I want it to do. Finally, I’d git commit those artifacts, maybe enrich them with some documentation, related tasks, company communication etc.

The reason for that would be to communicate to my colleagues, or my future self, or people I would never meet in my life, about the intent of the code. With LLM-generated code all of that information got lost. I no longer work on those artifacts directly. I converse with a non-deterministic thing so that this thing produces artifacts for me. I interact with the prompts right now.

And those prompts I eventually removed, and committed the artifacts created by the thing.

So, for me it was always obvious that to start treating code as a mid-layer, kinda like we do with compiled code now, I would need to get a way to clearly commit & communicate my intent. Some text files that would compile into the codebase. And Spec-Driven Development is exactly that approach.

I started using openspec.dev immediately when I saw it. I liked the ease of use, and the introduced concepts. This was the single thing that convinced me that AI-driven development is actually viable.

It’s early days, but it already pays off — I can revisit a change from days ago and understand exactly what I wanted and why, without digging through prompts or chat history.