This content originally appeared on HackerNoon and was authored by Eugene Truuts
Looking back, I do not think AI changed the direction of my career. It arrived after that direction had already been set. Every week brings another comparison of coding models, another prediction about which engineering role will disappear, and another list of tools we are all supposed to learn. Some of those articles are useful, but they rarely describe the change I experienced, because it began long before I opened an LLM chat window.
For years, I explained my path as a sequence of roles: QA engineer, automation engineer, technical expert, leader, architect. The labels now feel less important than the questions I was asking. First: How do I find this bug? Then: How do I automate this check? Later: Why is this process so expensive? Why are several teams losing time in the same place? Could we change the product so this problem does not need another test at all?
I did not wake up one morning with a systems mindset. The frame expanded gradually, usually while I was busy solving something much smaller. AI belongs in that story, but it is not the protagonist. It did not turn me from a tester into someone interested in products, processes, or people. It lowered the cost of acting on observations I had been collecting for years.
This is the story of that quieter change.
The bug was the whole world
My first QA job was in a small company with several outsourced projects and the energy—and disorder—of a startup. I tested features, experimented with automation, and occasionally tried to invent processes despite having very little experience. We did not even have Jira. For some reason, I spent time imagining how I would configure it and organize the workflow if I ever joined a large company.
I look back at that version of myself with a smile. I knew far less than I thought I did, but apparently I was already curious about the machinery around the work.
At the time, my definition of a good day was simple: I found an interesting bug. I liked approaching a feature from an unusual angle, reconstructing the steps carefully, and writing a report that made the failure obvious. Developers praised those reports, which was encouraging in the first days of a new career. I interpreted the praise quite literally. Finding bugs, I assumed, was the point of QA.
I had not yet learned what triage really meant. I did not understand why a serious-looking defect might never be fixed, why severity and business priority could point in different directions, or why a perfectly valid bug report might change nothing. Each bug felt important because I had found it.
The reports were teaching me something else, though. To describe a failure well, I had to reconstruct how a person arrived there: what the interface appeared to promise, which assumption seemed reasonable, and where the experience stopped making sense. Years later, when I began studying UX more deliberately, that way of looking at products felt familiar. I had been practicing a rough form of it while believing I was only documenting bugs.
The surrounding problems became visible too. When the same confusion returned in different projects, I wondered why. When several reasonable decisions produced an unreasonable result, I wanted to understand how the pieces had interacted. Nobody expected me to redesign the organization; I was supposed to test the current task. Still, my attention kept wandering from the defect to the conditions that produced it.
Somewhere in those early projects, the question began to change from “How can I catch this?” to “Why was this possible?” I did not yet know how far that question would take me.
Learning to own the missing pieces
The COVID years widened the frame quickly. I joined my first corporation operating at a national scale, where delivery involved many teams with their own priorities, dependencies, and perfectly reasonable explanations for why something could not move faster. A technically small problem could become organizationally expensive simply because it crossed enough boundaries.
At roughly the same time, I started building things outside my formal role. One of them was CDpie, a service intended to help musicians distribute their music to online stores. There was no AI assistant to turn a rough idea into a working product. I found a designer and a developer who believed in the project, and I gradually became the person responsible for priorities, user flows, processes, and the uncomfortable question of what we should build first.
CDpie did not become a commercial success. We did not make money from it, and I do not want to retrofit a triumphant startup story onto something that was not one. Yet it gave me an experience that was difficult to get inside a clearly defined engineering role. There was no product owner elsewhere in the organization who would eventually make the missing decisions. Every unanswered question became our question—and, increasingly, mine.
I learned how different a feature looks when you are responsible not only for whether it works, but also for whether anyone needs it, understands it, and is willing to use it. I learned that leadership often begins before authority: someone has to create clarity, keep people moving in the same direction, and make a decision with incomplete information. Most of all, I began to see the difference between writing software and owning a product.
Another side project pushed in the same direction. I entered a federal developer competition and reached the final not in a coding track, but in UX design. My idea integrated audio interviews into a social network. To build the prototype, I had to move between roles almost without noticing: product manager, researcher, designer, engineer, and QA. My testing background was not an obstacle to that work. It helped me ask how a user would interpret the product, where the experience would become confusing, and which assumptions would fail outside a presentation.
These projects were imperfect, and that is part of why they mattered. They let me practice responsibility before I had the title or experience to feel fully ready for it.
Two games, years apart
During the same period, while studying at university, I entered Apple’s Swift Student Challenge. I built a game from scratch and won.
It was the COVID year, so WWDC was virtual. The recognition was real, but the experience felt oddly incomplete: no trip, no campus, none of the conversations with other winners that I had imagined. I watched the event from home and then returned to everyday life. For a while, the award existed mostly as an email, a project I was proud of, and a quiet suggestion that perhaps I could build more than I had previously allowed myself to imagine.
Several years later, Apple offered previous winners a chance to enter a lottery for invitations to an in-person event. I applied without expecting much and received one. A story that had begun as an email during lockdown finally carried me through the gates of Apple Park.
Walking through the campus did not magically make me a different engineer, but it changed the emotional weight of the earlier experience. During COVID, the win had felt almost abstract; now I was standing in the place that had existed only in presentations and imagination, among people discussing how products I had known for years were designed, simplified, and shipped. The delayed arrival made the experience feel less like a reward and more like permission to think bigger. Product ambition was not reserved for some distant category of people. It was possible to work at that scale, even if the first attempt began at a desk during lockdown.
Years later, my company announced an internal AI competition. With complete creative freedom, I built another game—this time a management simulation about an engineering organization. It was a very different project, using a very different generation of technology, but I found myself returning to the same form. The game finished second among thousands of engineers.
The ranking surprised me. The repetition surprised me more.
Twice in my career, when given space to explore an idea freely, I had built a game. Neither project was really about games. A game forces you to model a system clearly enough that another person can enter it, make choices, and experience the consequences. In the first project, I was exploring interaction and product experience. In the second, I was modeling incentives, trade-offs, pressure, and the behavior of an engineering organization.
After the internal competition, one of our VPs told me that I should talk about this work more. Until then, I had assumed that useful work eventually became visible by itself. Build something valuable, and the organization will somehow notice. I no longer think that is true. Communication is not decoration around engineering. If an idea stays inside your laptop—or inside one team—the organization cannot learn from it, challenge it, or build on it.
The comment stayed with me partly because it was uncomfortable. Talking about the work can feel too close to talking about yourself. I am still learning the difference. The goal is not to turn every project into self-promotion. It is to give useful work a chance to travel.
The first system that was entirely mine
CDpie taught me what it felt like to share ownership of a product. LuzMap went further: it became the first product where almost every missing piece eventually pointed back to me.
LuzMap began with a practical question. During power outages in Spain, people wanted to know what was happening around them and whether others nearby had electricity. Turning that need into a working service required much more than building a page. I had to think about data collection, infrastructure, reliability, SEO, user experience, monitoring, support, and the long tail of decisions that appear only after a product meets real users.
There was no clean boundary where “my engineering part” ended and somebody else took over. If the data was confusing, that was my problem. If people could not find the site, that was also my problem. If the interface was technically correct but failed to answer the question a worried user actually had, the distinction offered little comfort.
Owning the whole system changed the way I evaluated technical choices. Inside a large company, it is possible to optimize one layer and hand the consequences to another team. In a product you own end to end, the consequences always return. A clever architecture that is difficult to maintain is your future weekend. A feature nobody understands is not a UX department’s problem. It is simply a feature that failed.
LuzMap also made restraint more concrete. When you are responsible for every layer, every new feature creates an obligation: more code to maintain, more states to explain, more ways to confuse users, and more things that can fail at the wrong moment. Building became less about proving what I could implement and more about deciding what the product could afford to carry.
That lesson followed me back into corporate engineering.
Five systems that worked—and one workflow that did not
The problem did not announce itself as an architecture project. For a long time, opening several systems during release regression felt normal because everyone around me did the same.
Start a pipeline in one place. Inspect reports somewhere else. Prepare or update a test plan in another tool. Open Jira to reconstruct the status for a manager. Move back when a failure needs investigation. None of these actions was difficult on its own. Together, they fragmented attention throughout the day.
At some point I stopped seeing a collection of acceptable tools and started seeing one broken experience. The systems worked. The workflow did not.
The idea for a regression Workspace grew from that observation. I wanted QA engineers to manage the release from one place: prepare regression, launch test pipelines, inspect results, build test plans with AI assistance, and understand what still required attention. Managers needed a clear view of progress without learning another set of Jira filters or visiting every underlying system.
The integration work was significant, but the harder decisions were closer to product design. What must be visible immediately? Which information creates confidence and which merely creates noise? When will an engineer trust an AI-generated suggestion? Where should the tool make a decision, and where must it leave control with the person responsible for the release?
When I demonstrated the Workspace to a director, I expected a technical discussion about the implementation. Instead, after looking at it, he told me I should present it to the wider organization.
That short response changed how I understood the project. I had started by removing friction from a routine I knew well. Somewhere along the way, I had stopped building a utility for myself and begun building a product for engineers.
It also reinforced the lesson from the VP: creating the system was not the final step. If it was meant to change how people worked, I had to explain the problem it solved, show why the change was worth learning, and listen when the proposed workflow did not match reality. A technically superior process can still fail on its first contact with human habits.
Leadership, in that context, felt less like telling people what to do and more like product work. You observe where attention is lost, make the better path easier to understand, and accept that resistance sometimes reveals a flaw in your own design.
AI changed the cost, not the direction
The Workspace taught me that the difficult part was not connecting APIs. It was understanding what information people needed, when they needed it, and what they could safely ignore. I encountered the same problem again while building AI systems. What AI genuinely changed was the cost of testing the solution: a few years earlier, proving the Workspace idea might have required several sprints and a small team. With AI assisting the work, I could build a credible version over a weekend.
That can sound like the familiar “one prompt built an app” story. It was nothing like that.
The visible implementation took a weekend; the product context took years. AI did not know which complaints kept returning, why managers avoided certain reports, where QA engineers lost attention, or which integrations mattered during a release. It did not invent the problem or decide what a useful solution should feel like. It made the accumulated idea cheap enough to test.
I saw the same pattern while designing an AI orchestrator for engineering work. At first, it was easy to imagine that prompts would be the difficult part. They were not. The difficult part was the system around the model: what context an agent should receive, which tools it could use, what it must never be allowed to do, how work should be divided, where state should live, and which outputs required another layer of verification.
A model can generate a large amount of code, including tests. But an orchestrator that produces trustworthy engineering work needs more than generation. It needs boundaries, permissions, evaluation, observability, and a clear definition of responsibility when the result is wrong. Those are architecture questions. They would have existed without AI; AI simply made them urgent at a larger scale.
This is why productivity numbers do not capture the most important change. Yes, AI writes code quickly. Everyone knows that. More interesting is the number of hypotheses an experienced engineer can now afford to test. Ideas that once stayed in a notebook because they were too expensive can become working systems before the organization has spent months debating them.
That leverage does not make expertise less important. It makes the consequences of expertise—and the absence of it—larger. AI can accelerate a strong mental model. It can also turn a weak assumption into polished complexity at remarkable speed.
What remains after the tools change
One of my earliest IT interviews included questions about Unix commands I did not know. I said so and added that I could find the answer quickly. The interviewer told me to go ahead, then watched while I searched, made sense of what I found, and explained it back. I got the job.
For years, I told that story as evidence that searching well matters more than memorizing everything. Today, AI retrieves information faster than I ever could, so even that lesson needs revision. The useful part was not the speed of the search. It was being honest about the gap, framing the problem, and recognizing an answer that fit.
Four years ago, if a younger QA engineer had asked what to study, I probably would have said Playwright, XPath, and locator strategies. Today, I could replace that list with LLMs, MCP, agents, and model architecture. All are useful. None is a durable professional identity.
The technical knowledge I trust most is less attached to vendors: HTTP and network protocols, operating systems, file systems, permissions, data flow, and the architectural principles beneath the current abstractions. This matters even more when AI is involved. If you do not understand how an agent reads files, where credentials travel, or what permissions a tool has, you can compromise data without realizing you made a security decision. AI scales weak judgment as efficiently as strong judgment.
Beyond fundamentals, I would study UX and human behavior. Products are still made for people. Users ignore instructions, take shortcuts, misunderstand perfectly reasonable interfaces, and choose a logically imperfect path because it feels safer or more familiar. Calling that user error may be technically correct. It is rarely useful.
Sometimes the best QA question is not “How should we test this?” but “Can we change the product so this failure state cannot exist?” Sometimes the best automation is removing the task. Sometimes a simpler workflow creates more value than a more sophisticated system.
These choices require judgment, and judgment is difficult to compress into a prompt. It includes knowing which trade-off the organization can accept, which attractive idea has failed before, and which problem is not worth solving. As implementation becomes cheaper, restraint becomes part of engineering expertise.
Beyond QA
When people ask what I do, “Staff SDET” is still the easiest answer. It takes two seconds and is increasingly incomplete—not because the role has lost meaning, but because the problems I work on now tend to cross testing, architecture, delivery, product work, UX, and leadership before anyone has time to assign them to one title.
Looking back, I no longer see my career primarily as a sequence of promotions, companies, or technologies. It looks more like a sequence of questions, each one slightly larger than the last.
A bug became a test. A test became a framework. A framework became a delivery process. Processes became products and organizations. Along the way there were projects that succeeded, projects that made no money, competitions that ended with an award, and an award whose story took several years to reach Apple Park. There were tools built for one routine that turned out to matter to a wider organization, and two games—created years apart—that helped me model systems I was still learning to understand.
None of it was a clean progression. I still investigate bugs, write code, review details, and occasionally discover that an ambitious architecture problem was really a missing piece of documentation. The levels overlap. What changed is where I look first.
AI did not begin that journey. It arrived after I had accumulated enough context to use the leverage well. It helps me implement, research, document, and test ideas at a scale that once would have been unrealistic. It also creates more code, more decisions, and more opportunities to scale the wrong assumption.
Perhaps that is why the engineering mindset matters more, not less. The most valuable work is not always producing another artifact. Sometimes it is recognizing that five functioning tools form one broken experience, changing a product so another test is unnecessary, or making an idea visible so other people can improve it. Sometimes it is understanding a meaningful problem well enough that people no longer have to experience it.
AI did not teach me to ask bigger questions. It arrived when I finally had them.
This content originally appeared on HackerNoon and was authored by Eugene Truuts
Eugene Truuts | Sciencx (2026-07-20T04:49:03+00:00) The Engineering Mindset That aI Didn’t Replace. Retrieved from https://www.scien.cx/2026/07/20/the-engineering-mindset-that-ai-didnt-replace-2/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.