I Built This Out of Curiosity. It Became a Real Tool

I’m lazy.

Not the kind of lazy that avoids work. The kind that refuses to do the same boring task twice if a machine can do it better.

Around a year and a half ago — long before “vibe coding” became part of every engineering conversation — I was experimenting with Lovable, mostly out of curiosity. Barely anyone was talking about it at the time.

I wasn’t trying to build a startup. I wasn’t trying to build the next AI product. I just wanted to see if I could eliminate one repetitive piece of my own work: comparing JMeter JTL results.

If you’ve ever compared two high-concurrency performance tests manually, you know the drill.

Open spreadsheets. Compare metrics. Calculate differences. Explain them. Double-check them. Then repeat the same exercise with developers and operations until everyone agrees what actually changed.

The comparison wasn’t hard. It was just painfully repetitive and boring.

So I used Lovable to prototype a small utility. Upload two JTL files. Click Compare. Done. I tested it with a handful of JTLs just to see if the idea held up — and it did.

But a public, hosted prototype isn’t something I was comfortable running real test data through. So I took what I’d learned and rebuilt it properly: a local-first version that runs entirely on my machine, no files ever leaving it. Same core idea, actually usable for real work.

Ironically, the biggest value was never the few minutes saved. It changed the conversation.

Instead of debating numbers, teams started discussing why the numbers changed. Developers, operations, performance engineers — everyone looked at the same report. The discussion shifted from “whose numbers are correct?” to “what changed in the system?”

That one shift removed more friction than the tool itself.

We’re entering an AI era where it’s tempting to overthink every solution — multi-agent workflows, autonomous systems, complex architectures, LLMs connected to everything. Those projects are exciting. But they’re not always the highest-value ones.

Sometimes the best use of AI is astonishingly simple: remove one repetitive task, reduce one source of friction, give engineers back their thinking time.

That’s exactly what this tool does now — it didn’t replace performance engineering, it removed one boring part of it. And because of that, engineers spend more time investigating bottlenecks instead of comparing spreadsheets.

Today, when someone asks me what the best use case for AI is, I don’t think about the most sophisticated system.

I think about the most annoying task. Because if AI can remove that, everyone wins — and sometimes that’s more impactful than building the next shiny thing.

Curious to hear from others: what’s the simplest AI-assisted tool you’ve built that ended up saving your team the most time?

Views and this project are my own, independent of my employer.

Transparency note: The ideas, experiences, and opinions shared here are my own, shaped over two decades in enterprise engineering. I used AI as an editorial partner to help refine the writing and improve readability.