What STACKx Cybersecurity 2026 Made Me Rethink About AI, Testing, and My Own Engineering Work

Last Friday I spent the day at Marina Bay Sands for STACKx Cybersecurity 2026 — GovTech Singapore’s annual gathering of security leaders, engineers, and public sector technologists.

I’ve worked across Quality Engineering and Software Engineering roles, with a focus on testing strategy, CI/CD automation, and recent years, AI-assisted engineering workflows. And part of my job right now is figuring out how to bring AI into our engineering workflows responsibly. So I went in thinking I’d pick up some security pointers I could bring back to the framework design.

What I didn’t expect was to walk out questioning whether I’ve even been pointing the framework in the right direction. Below are the things I’m still thinking about.

The Wrong Question Has Been Living Rent-Free in Our Roadmaps

The old question everyone asks: “Can we do the same work with fewer people?”

The better question: “With the same people, how much more can we now do?”

That second question sounds subtle, but it completely changes how you think about building an AI framework. I’ve been thinking about efficiency — how to speed up test creation, how to reduce review cycles, how to automate the boring stuff. And that’s fine, those are real problems. But the speakers were talking about something bigger: capability multiplication. Not doing the same job faster, but doing things you literally couldn’t do before.

Which means the AI framework I’m building shouldn’t just help engineers write tests quicker, it should let us catch categories of issues we’re currently blind to. That’s a different design goal, and honestly I hadn’t framed it that way until Friday.

From Pilot to Air Traffic Controller — Whether You’re Ready or Not

One of the more memorable frames: the shift every senior engineer needs to make right now is from being a pilot to being an air traffic controller. The pilot is a Solo Executor — deep expertise, full control, limited to what one person can personally fly. The air traffic controller does Supervisory Engineering — maintaining awareness across multiple simultaneous flows, calibrating when to intervene, trusting the system until there’s a reason not to.

The honest version of this for me is: I’ve been a pilot for most of my career, and I’m good at it. There’s real satisfaction in going deep into a problem, owning the outcome, verifying end-to-end. But I’m building a system now that will, eventually, run significantly without me in the loop. And I haven’t fully made peace with that yet.

The transition isn’t about working less or caring less. It’s about shifting where the expertise lives — from execution to the design and governance of execution. That’s actually harder. And it requires me to be honest about the habits I’m holding onto that are pilot habits, not air traffic controller habits.

The Rungs I Climbed Soon Don’t Exist Anymore

The speaker put up a redesigned career ladder and it stopped me cold — not because it was surprising, but because it named something I’ve been feeling without having the language for.

The bottom rungs are gone. The repetitive tasks that used to build expertise — writing hundreds of test cases by hand, grinding through manual reviews — are exactly the work AI is consuming. What’s left above demands a different kind of engineer: someone who can supervise agents, verify and challenge outputs at speed, think in systems, and exercise judgement with accountability. Strong fundamentals matter more now, not less — but they’re the floor, not the ceiling.

The part that really got me was the framing around workforce development. The speaker was blunt: we cannot prepare for an AI-native future with a pre-AI workforce model. Train people in fundamentals plus new instincts — to supervise, verify, challenge, and reason in systems. Deploy them broadly — across ops, engineering, governance, assurance, product security, and AI-enabled cyber. Not deskilled. Deliberately developed.

If AI generates the test cases now, where does the instinct come from? I can’t just onboard someone onto the AI harness and assume they’ll grow into a strong tester. I have to create the friction on purpose — make them challenge the AI output, articulate what’s missing, catch what it got confidently wrong. And I need to think about breadth too — the best QEs in an AI-native world won’t just be test specialists, they’ll need to reason across governance, assurance, and security contexts. The tool is only as good as the judgment sitting behind it. That judgment doesn’t come for free anymore.

AI Doesn’t Get to Own the Irreversible Decisions

One of the most clarifying moments of the afternoon was a speaker drawing a hard line through the types of decisions AI should and shouldn’t own. Some things AI should handle autonomously — pattern-matching, high-volume detection, tasks where speed matters more than nuance. Some things AI should inform, but a human should decide. And some things AI must stay completely out of.

This maps directly onto quality engineering decisions I make every day. AI can autonomously flag test failures and coverage gaps. It can recommend where to focus effort. But the final go/no-go call on a release? That stays human. Not because I don’t trust the system, but because trust without clear accountability is just abdication with extra steps. This kind of tiering needs to be explicitly written into the AI harness design from day one.

Communicate the Reasoning, Not Just the Answer

The last thing that stuck with me came from a session about decision-making under pressure — how leaders behave when information is incomplete and time is short. The speaker had a clean framework for anchoring a team in those moments, but the line I wrote down was the one that followed: “Communicate your reasoning, not just your decision.”

I do this badly. When I make a judgment call — on test coverage, on a risk escalation, on a go/no-go — I tend to state the conclusion and move on. I assume the reasoning is implied. But sharing the reasoning, especially when it’s uncertain, is how you build trust over time. It’s also, I’ve started to think, what separates senior-level contribution from staff-level contribution. Not better decisions — more visible thinking.

So what am I actually going to do about it?

I’ve been chewing on this all weekend. Here’s where my head is at:

First, I’m reframing my AI framework from “efficiency tool” to “capability multiplier.” The design questions change when you shift that lens. Example: it’s not just “how do we write tests faster” — it’s “what can we now test that we couldn’t before?”

Second, I’m adding AI-assisted first-pass review as a core pillar, not a nice-to-have. If our AI code reviewer can catch a replay attack vector in a nonce handling issue, I should be building something that gives my team’s reviewers that same kind of head start.

Third — and this is the harder one — I need to redesign how my team trains and works alongside AI. Not just “here’s the tool, go use it,” but structured ways of working where the human stays in the loop and understands what the AI is doing. Because the moment your team treats AI output as gospel without understanding it, you’ve got a different kind of quality problem.

That’s a mindset shift, and it starts with me.

Wrapping up

Look, I went to a cybersecurity conference expecting to take some security notes. Instead I came back rethinking the whole framing of what I’m building and why.

The conference theme was “Creating a Trusted Digital Future Together” and honestly, “together” is the word I keep thinking about. Not just cross-org collaboration — though that matters — but the human-AI partnership. The idea that the future isn’t AI replacing us or us ignoring AI, but us learning to work alongside it in ways that actually make both sides better.

I’m still processing. But I’m glad I went.