For a long time I used AI as autocomplete on steroids. It suggested the next line, I took it or I didn’t, and on I went. Useful, but not much more than that.
What changed was using it as an actual agent: give it a goal, let it read the repo to figure out how everything fits together, let it make the change across several files, run the tests, and work through the errors until they pass. I review the result, not every keystroke. That’s when things shift. Tasks that used to eat half an afternoon drop to half an hour.
But “using an agent” isn’t tossing it random requests and praying. Do it that way and it gets in your way more than it helps. What makes the difference, at least in my experience, comes down to three things.
Give it access to real tools
This is where MCPs come in. They hand the agent a door into the database, the ticketing system, the test environment. Without that, the model guesses. With it, the model checks the real state and stops making things up. It’s the difference between “I think the endpoint returns this” and “I just called it and it returns this”.
Stop making it relearn the context every time
Skills are saved procedures: how we set up a test environment, how we validate a given integration. Instead of explaining the same thing every Monday, the agent applies it the same way every time. Sounds trivial until you’re on the fifth time walking it through the same flow and you realize how much time that eats.
Write the request properly
Here’s the part nobody wants to hear: the quality of what comes back depends on how clear you are. Goal, constraints, what counts as “done”. Vague prompt, vague result. There’s no magic to it.
How I use it in QA
At work I built my own Claude-assisted QA tooling out of these pieces. What I lean on most:
For planning, I give it the change and it proposes the risky cases; I adjust the coverage. Going from a blank page to a plan you can review in a few minutes is worth a lot. For tests, fast scaffolding with Playwright, refactoring to page objects, and diagnosing the flaky ones (I get into that in the other post). And for environments, skills that set them up and validate them the same way every time — which is how you kill off the classic “works on my machine”.
The result isn’t that the AI does QA. It’s that I do more QA, and better: less time on the mechanical stuff, more on the part that actually adds value.
On the fear that this replaces you
I get it, I’ve thought about it too. But in practice it goes the other way. The agent eats the repetitive work and leaves you with the part that’s genuinely hard and that nobody else is going to do for you: deciding what to build, what to test, which risks matter, and whether the result is any good.
Being more productive isn’t writing more lines. It’s spending fewer hours executing and more hours deciding. And on that field, a good engineer wins every time.