I was a breaker, now I am a builder

How AI turned a tester focused on bugs and test automation into one who also fixes, implements and... tests more than ever before.

I know how to type fast. “John, TAB, Doe, TAB, 29, TAB September, TAB 1990 ENTER”. This is what I did in the early days of my career to fill in the same insurance form repeatedly, until a colleague passing by showed me a better way, and introduced me to bookmarklets and, more generally, test automation.

See, I was a graduate in psychology and cognitive science and I stumbled into testing as a profession. I’m lucky I did, as it later became my passion. At the beginning I was tasked with manual testing. I was good at it, and I liked it. Even testing on old browsers (IE6!) or slow mobile phones (Samsung Galaxy S4 mini) never bored me. I liked the thrill: will it break this time? I hoped for error messages, crashed sites, misaligned UI elements, wrongly calculated insurance quotes. And most of the time I was able to find at least one thing to report. After all, no software is perfect. A User Story without a bug reported by me? That, as I perceived, was the worst thing that could happen. I was paid to find the glitches before the customer did.

As the years passed, I learned a lot of new aspects of software testing. I learned Selenium WebDriver, Jenkins, Sonar, JMeter and… any other tool that helped me exercise the software under test through different lenses. Now it was not only black box (I don’t know code) and functional (I check what software does) testing, it was… anything that could help with increasing any dimension of quality of our product.

At the same time, I gathered lots of impactful learnings from non-technical angles. I came to realize that testing is far more than just breaking things and raising bugs. It might not even be the most important part. There are plenty of other types of information about software under test a tester could gather. But good tools and good automation for sure help.

In my career I worked with multiple different products and various test automation frameworks. One of the highlights of my career was working with a test automation suite that took close to 8 hours to execute fully. With my improvements we reduced it to 2 hours. Then I kicked off something I was a little scared to do: a migration and refactor. In a year-long effort (squeezed in between other testing duties) the testing team migrated close to one thousand test cases to Playwright.

The result was a big success, as with it, we managed to reduce the test execution time to around 20 minutes, all while increasing test coverage. I was anxious: would it bear the fruits I hoped for? Was shaving off 1h 30m worth the investment? In that particular case it was. A faster feedback loop empowered the project to increase the release cadence and reduce the number of blockers found during release testing.

During migrations like this, I learned about GPT for the first time, when I stumbled upon a Medium article from Gajus Kuizinas, “Migrating from Cypress to Playwright using GPT3”, written in 2022, a few months before ChatGPT came out. This sounded like science fiction to me back then. I recall I tried to replicate a similar workflow but after an hour or two, I ditched the idea completely. I kept coding tests by hand, the artisan way! Remember, this was the AI era when GitHub Copilot autocomplete was proven to leak (real) secrets, a threat that, for the most part, seems to be mitigated.

In September 2025 I joined Apollo.io, a company that builds an AI-powered Go-to-Market (GTM) system that combines data, intelligence, and execution in one loop helping businesses find and win customers. I became the manager of the SDET team and the first goal I had to drive was “Cypress to Playwright migration”. The analysis of pros and cons was done before I joined; similarly, the decision to migrate had already been made. My job: coordinate, execute, start in November, finish by the end of January 2026.

We had close to 2k tests to be migrated. One teammate kicked off the process by spending a few weeks on AI-based migrations only. The goal was to prepare a Cursor command that took a Cypress file, analyzed it and converted it to a working, passing Playwright test. Once the command was ready, the whole team of 8 engineers was tasked with using it to speed up the migration. To my surprise, in many cases the command nailed it nicely, and only very complex test scenarios required a human deep-dive. Most tests were migrated with few adjustments needed from us, especially once we migrated the key helpers and utils, and learned the basic gotchas and flakiness traps. The command was collectively improved with every test migration, resulting in higher accuracy over time. All tests were migrated in 3 months, without any disruption to the other testing activities, as our QEs and SDETs had to support dev squads as well.

Each change still went through human code review and a CI “burn” job that executed each migrated test 10x, to confirm stability. There were a few areas that required true re-coding from scratch, but those were a marginal percentage of the whole suite.

Interestingly, the most wearisome part of the migration was the final cleanup. For example, our CI failed on the first prod deployment, where there were no Cypress tests to execute (exit code 1 blocked the pipeline from further executions). Or renaming cypress to e2e everywhere. It was a low-impact change, yet it felt wrong to keep Cypress in the name of such custom scripts.

The migration would have been even faster if we hadn’t taken this refactor as an opportunity to change our approach to the framework, as we invested more in reusable parts like common utils, reporters, fixtures etc.

The migration would have been even faster if we hadn’t run it last year. Today I am confident it would take less human effort, it would take less time and it would consume a lot more water, in an indirect form of AI tokens. My rough estimate would be 1 month, maybe even less, excluding the initial preparation.

What does it look like today?

Recently, for reasons unrelated to this piece, I became an IC again. I now code daily, raise more PRs a week than ever before, and I do not limit myself to contributions to test automation only. It’s thrilling: in the past I thought that unit tests were the realm of (non-test) developers, or that I was not supposed to edit the application code, except for minor changes like tweaking labels or adding test-ids to otherwise unlocatable elements. Now the line is much more blurry: I can reliably write and stabilize tests in any test framework (RSpec, Vitest, Playwright), fix real application bugs, debug system logs to answer hard customer inquiries or even implement small feature improvements. I am sure, gradually, I will only increase the level of complexity of my contributions. Don’t get me wrong: in the past of course I would have been able to do those things as well, but it was not practical for me to do so. My expertise was in other areas and the number of working hours never changed.

Now the economy has changed. The barrier to entry, to most code, for a tech-savvy person is as low as ever. And it’s only moving down.

My wife’s grandma said that once you’re old, you’re the same as earlier. Just more. If you were grumpy, you become more grumpy. If you were joyful, you become more joyful. A life lesson I cherish. But I think it’s the same with AI. It amplifies who you are, what you can do. I strongly believe that if Stephen King embraced AI, he would give us many more great books. Similarly, George R. R. Martin would have finished A Song of Ice and Fire already.

I believe this AI amplification applies especially to engineering teams. Excellent teams, in excellent environments, i.e., the ones living in dev forests, will outperform everyone else. The ones living in dev deserts will suffer even more. A dysfunctional team will still be dysfunctional, but faster: delivering more bugs, outages and other incidents than ever before.

Luckily, I believe I now work in a forest and I’d like to tell you what it looks like there. And don’t get me wrong: there are still some dangers and traps here, but it allows me to be a better version of myself. And it all starts with… the customer.

Last quarter, the company kicked off a pilot “Support Duty” program for a small subset of engineering. A 3-day training, followed by an on-call schedule where I had to answer people on live chat and help them solve their problems. I was asked to encourage them to connect on a call, to resolve the issue even faster.

What would you expect the training for such a situation to look like? If you’re anything like me, you’d expect a set of presentations: a reminder about key Apollo features, maybe a highlight of the most common issues our customers face, and how to resolve them. It was nothing like that. Apart from setting clear rules of engagement and escalation paths for wide categories of issues, most of the training was about… empathy! The customer reaching out to support might be irritated. Our software failed him or her: maybe it was too confusing, maybe it was a bug. Of course we need to solve the core issue, but we should also know how to handle the emotions, respond empathetically and ease the tension.

And boy, I must say I have never participated in such an eye-opening exercise in my career. Those few days on Support Duty allowed me to get better insights into the customer’s pains than anything else. No report or presentation can replace talking to a real person who actually uses something YOU HAVE BUILT.

For sure I was exposed only to a tiny subset of possible issues but my empathy for the customer increased tenfold. I met, for example, an elderly man from Germany, let’s call him Karl. He was confused by too many options offered by the app, and I’ll never forget our interaction. I will keep on advocating for simplification, wherever I can.

How did I resolve the inquiries then? Yes, with AI. The level of observability we have with it now is just awesome. With MCPs to our logs, code, databases and whatnot, AI is able to debug issues quite reliably. With it, I am able to understand what happened on the backend, why the system behaved in a certain way and why it’s confusing to the user, or whether there is a valid bug that the customer stumbled upon. It still needs human judgment, though: is the analysis correct, which data can be safely shared with the customer or whether I myself can reproduce in the app what the customer is seeing.

Why isn’t AI answering on chat directly then? Well, in some cases it does that already! But many users still prefer to talk to a real human, or there is a limit to what can be shared with chat only. Nothing works better than a screenshare with the customer. However, the number of support tickets answered by AI is slowly growing at our company, as I believe it is across the industry.

OK, we talked. Now let’s imagine the customer stumbled upon a bug. It needs a code change. This brings me back to my regular engineering duties. Similar AI agents, like the one support uses, are able to draft those changes for me, if the task is scoped well enough. For bigger issues, another AI can do a deduplication check among other Jira tickets, check if it’s a new problem or one that others reported as well. How big is the bleeding? AI can gather the list of impacted customers. Why is it a bug? Here is an excerpt from the documentation, the story that introduced the change, the related Pull Request and the part of code that’s relevant for this issue. In other words, a dev looking into the issue has a lot of information pre-compiled for him or her, to fast-track the analysis and the fix itself.

How about delivering the fix? I personally use an Agentic Development Environment (ADE) now more than an IDE, but doing this reliably would not be possible without the ease of setup of the application locally. I can safely run the full backend and frontend on my MacBook. Or even two if I’m using worktrees. All tests can run on CI, as well as on developers’ machines, but practically you would never run all tests on your machine; you rely on a subset before commit. Only parallel workers on CI allows us to close the full feedback loop below 1h.

This unlocks the true power of ADE. With proper guidance, AI can implement and verify the fix itself. Do you need 100 types of specific users? No problem: here’s a seeding script. Repeat a test 100 times? Sure, Playwright CLI will handle that for me. Screenshot of a fix? Here you go: await page.screenshot(); And another agent can even annotate it with arrows; the sky is the limit.

I’m a little shy to say: I don’t even remember the last time I tried to locate a WebElement on a page using devtools. Something I was doing many times a day at every previous job. Now AI helps me with that instead.

We need to remember that AI is non-deterministic. Ask it for the same change 10 times, and you’ll get a set of 10 different PRs. Some might not even conflict with each other after merge! But I think it’s similar to humans. No two developers write the same code. But I see that the AI models and toolsets around them have matured enough that I can delegate some chunks of my work safely, as long as I know and understand what they did in the end: which parts of the system were changed, why, and what the consequences of that are. I never push changes I do not understand.

At Apollo I have access to Cursor, Claude and Codex, with generous budgets everywhere. We’ve had our instances of token-maxxing, but they were quickly stopped. If I use all budgets, I can expect a Slack message from my manager where he asks where the effort went. Nothing different from a similar message I would receive if I worked for a couple of days on a project he was not aware of. If I can justify the effort, I’m good.

I know that if the budgets were not high enough, I could also ask for more. And once again, assuming I can justify the need, I will get a budget increase. But so far I have never been in this situation; limits exceed what I need. For now. I know it’s not the case for all devs at Apollo. But even if I hit the ceiling, I could also use the shared harness, accessible through a bot on Slack, with conversations visible to everybody. It allows me to make code changes and raise Pull Requests, too!

At this moment of AI development, I do not care much about new models anymore. I do not care about Anthropic vs OpenAI either. I think I would be just as productive using Gemini or Mistral models. I do not know which model our Slack-AI uses.

Personally, I still have a yearly plan for Claude that expires in Feb. I am sure I will consider switching to something by then. Yes, there would be a migration tax, but it’s getting lower and it’s not as hard as my migrations to Playwright ;) That’s why I really like the platform-agnostic tools like Orca.dev for orchestration.

I care about the cost, of course. I would not use Fable for editing 1 line of CSS. I would not use Haiku either: we can still type by hand, although I now talk to my agents more and more often with Wispr Flow.

So, I have a code change, verified locally. What’s next? Pull Request with… dozens of comments from the AI Code Review bot (a custom one we’ve built). Some helpful, some not. Some find true bugs in my PRs, some allow me to increase readability of the change, some are small nitpicks and, rarely, some are bonkers. CI runs all the tests.

We do not allow code changes without human reviews. I think that’s good; however, I don’t think code review nowadays needs to assess every single line. I believe it now becomes closer to something like “intent review” that validates whether the intent behind the change is well understood. As everywhere: occasionally some people might be rubber-stamping PRs. I don’t. I still repeatedly get great feedback from my peers at this stage. However, its nature has changed. It’s not “this line of code needs change” anymore; it’s more often higher-level feedback on the nature of the introduced change and its second-order effects.

PR approved, then comes the merge. One hour later our customers can enjoy it on prod. Or complain about it on chat; I might be there to respond.

So I can now do more, and it seems to be easier. Are there any drawbacks? The biggest one I experience personally is context switching. At times I can lose track of which PRs I opened and whose approval I should chase. In the past I thought I liked slightly more chaotic work environments, with many conversations running in parallel. But it turns out that I like talking to many people, not talking to many agents about multiple code changes in parallel.

About testers

With AI I finally feel that I can become a better version of myself. I have the same tools and MCPs that others do. But it was the same, always. Pre-AI, I had the same IDE as the rest of the team, and I read the same requirements as they did. The key distinction is that my focus is different. I was trained to apply skepticism and critical thinking to every change that came my way. My goal was always to seek information and seek problems that matter. Test cases or scripts were never the goal itself, just one of the outcomes of my exploration.

Nowadays, access to information is much easier for me than it ever was. Within my T-shaped skills model, I do not have extremely deep technical knowledge. I am not able to fully understand complex frameworks or remember all the Docker parameters available. However, I understand the concepts deeply enough that I know which tools to use to get more data. Within minutes, I can seed the database with data, I can write a script that checks specific things, I can mock when I need to. I wouldn’t be able to do those things efficiently if I didn’t know the concepts. And on the other side: I wouldn’t be able to find the problems that matter if I didn’t know what questions to ask.

This is why, with those new tools available, I believe testers are now set for success in a unique way, and that the opportunity is even bigger than for, let’s call them, “regular developers”. Once we move further away from reading code, as many now do, the skills commonly attributed to typical programmers become less important. The opposite happens with testing skills: seeking information about the delivered software that should uncover potential problems becomes more and more important.

It’s not that developers didn’t have those skills too. They do. I worked with amazing people hired as developers who were great testers and I worked with people working as testers who did a poor testing job. It’s not about the title, it’s about the craft of finding data about the quality of the product and risks to its value. And in the past my involvement stopped there. I found data, then I gave it to others to make decisions: for devs to fix, PMs to reprioritize, BAs to clarify what is expected.

Now, the line is blurry. With my skills and the tools available to me, I do not need to stop there. I feel that this year I switched gears. Now, the amplified version of me also fixes, implements and deploys changes. I still focus on testing, and colloquially break things. But I’m now more than that. I was a breaker, now I am a builder.

Disclaimer: The opinions expressed here are my own and do not represent the views of Apollo, nor of any of my past employers.