New year, same bugs: why we're building Testomatica

Every January we make the same promises. Sleep more, read more, finally write proper tests for the checkout. By the second week of the month the sleep is gone, the book is face down on the nightstand, and the checkout still has the same three tests it had last spring.

This year we're making a different kind of resolution. Not a personal one, a company one. Testomatica is a small team, a lot of notes, and one question we couldn't stop asking each other over the holidays: if AI is writing so much of the code now, who is checking it?

The code got faster. The checking didn't.

Over the past year, plenty of teams we know started shipping with coding agents. A feature that used to take a week shows up as a pull request on Tuesday afternoon. The review is a skim, because the diff is long and the tests are green. The deploy goes out. Then on Thursday someone in support notices that a coupon applies twice if you hit back and forward in the browser, or that order confirmation emails show yesterday's date for anyone east of the server.

Nothing about that is new. What's new is the pace. Testing didn't speed up the same way. Regression suites are still written by hand, still break when a button moves, still get skipped when the release is late. Manual QA is still a person with a checklist and not enough hours. The distance between how fast code arrives and how fast anyone can verify it keeps growing.

That distance is the reason we exist.

What we want to build

The short version: agentic QA for teams that ship with AI. Something that runs on its own machine, notices when a new build lands on staging, tests it the way a careful person would, and tells you what it found with enough evidence that you'd actually believe it.

The long version is still being written, and we'll write a lot of it here. A few things we already feel strongly about:

• Deterministic tests should do most of the work. Agents explore, but they don't get the last word on what's broken.
• Every finding needs proof: the steps, a trace, screenshots, and a replay that doesn't depend on a model's mood that day.
• Anything we find once should become a test, so nobody has to find it twice.
• The system should run itself. A QA tool that needs its own QA team has missed the point.

None of this is a product yet. Right now it's research, sketches on a whiteboard, and long arguments over coffee about what "a bug" even means. One of us has a notebook that is mostly arrows.

Why write about it now

We could build quietly and show up in the fall with a launch post. We'd rather think out loud. Writing forces us to be precise, and putting ideas in public is a cheap way to learn which ones are wrong before we've spent months building them.

So this blog will be weekly. Expect posts about the research we're reading, the design choices we make and why, and the occasional opinion we may later regret. When we start building pieces, you'll see those too. When we finally point the thing at a real site, we'll tell you how it went, including the parts that don't flatter us.

The bugs didn't take the holidays off. Honestly, neither did we. Happy New Year.

So, what's the one bug you'd love to never see again in 2026?