blogs

Debugging Code Nobody Remembers Writing

2026-11-09T08:00:00Z

Before AI we had this problem: The person who wrote the nifty algorithm left the project months ago.

There’s a bug we have to fix. And you don’t know the code. Good luck! We’re right behind you!

Now with AI, we’re creating the problem ourselves. We generate code that we barely look at. And it didn’t go through our brains, so it didn’t leave a trace. As the old joke goes – the good news is you always see new code.

But that’s not funny when you need to fix that bug.

I’ve talked about losing debugging skills before, but you probably want more down-to-earth advice.

So, how to debug code I didn’t write. And that goes for both AI and human generated code.

Is it really a bug? How do you know?

You see, if there’s a test – it’s a great start, we’ll get there in a second. But if not – we’re relying on knowledge in people and in docs. We need to know what’s the expected behavior and what we don’t see.

With AI code, there’s no one to ask. The prompt is gone, and the intent is gone. So you may need to dig deeper.

You know what should happen, you don’t understand why it doesn’t

Do you have a test that broke? Excellent. It doesn’t matter what kind of test – API, unit – whatever. Something that worked before but doesn’t now and has a proof means you don’t need to debug, just fix!

I know, it doesn’t work like that. But it can.

You don’t have a test? Write one. With the expected behavior, and it should fail. What kind of test to write? This depends on how much you “know” the code. If you have a suspicion the problem is in the backend, don’t write a UI test. If it’s probably in the logic, maybe a unit test will be enough.

The smaller a test, which fails and gives you the proof that it really doesn’t behave as it should, the better. A smaller test is easier to fix and pass.

Before digging, run your failing tests a couple of times, to make sure that you’ve captured the failing behavior.

The problem may not happen all the time. Or the setup may be right for the first run, but not the second. And if you’re running AI powered features, the assertions may not capture the right things.

Don’t forget the greatest technique of debugging.

Binary search debugging. If your test proves the problem is not in part A, change it to start testing B.

The rest is proper old school debugging.

Breakpoints, printouts and logs. Building models of how the bug can occur, printing state and data, and hoping we catch it when we’re looking.

Not all bugs are like that.

AI bugs are problematic in a couple of aspects.

First there’s the repeatability problem. They don’t return the same answer every time. Then there’s the decision of “how correct is the answer”. This may not be a true/false result, but a lot of gray areas.

That makes it hard to capture a failure, and to understand if what we have is a failure or acceptable.

It’s the same techniques though – find how to set up the trap, how to spring it, and how you know it caught something. Hopefully the right thing.

Yes, the classics never die. The difficulty level just goes up.

If your team keeps debugging code nobody remembers writing, that’s where I come in – mentoring and training for your team.

Mentoring by topic – API testing, unit testing, testing with AI, testing AI features. On your own code and your own decisions. Or training delivered where your team needs the ground covered.
Tell me what you’re dealing with. A couple of lines is enough.

The post Debugging Code Nobody Remembers Writing first appeared on TestinGil.

My learning bits for Monday of 9th November 2026

2026-11-09T06:00:00Z

Here are my learning bits for today:

About the AI bubble: I’m Not Convinced the AI Bubble Exists.
Discussion on how to separate agent contexts: Hacker News discussion.

Linky #41: What are we basing our confidence on?

2026-11-08T18:18:31Z

This week’s links got me thinking about one particular topic: confidence. We’re regularly building software with varying degrees of uncertainty and making decisions with incomplete information. We need confidence in the decisions we’re making, but that confidence needs to come from somewhere.

So what evidence are we using, and how much can we trust it?

This week’s links explore that from a few different angles, from probabilistic thinking and code coverage to agentic evals, AI adoption and the conditions that help people learn.

Latest post from the QE Newsletter

I’ve been down a bit of an AI rabbit hole recently, thinking about what Quality Engineering could mean in an agentic engineering world, where we’re increasingly using AI agents to build software.

One thing that’s become apparent to me is that by developing a better understanding of what could go wrong, we can start thinking about how we influence and respond to systems that behave unpredictably.

In some ways, this feels a little more manageable, as we have a better understanding of where some of our uncertainty is coming from, and there are ways to guide, constrain, monitor and, to a lesser extent, control agent behaviour.

But none of these approaches guarantees the outcomes we want.

And I think that’s something we as an industry need to start acknowledging and getting more comfortable with. We’re going to be shipping software with uncertainty, something we’ve always done, but the speed and autonomy that agents introduce could make the consequences much harder to anticipate and manage.

Rather than pretending we can eliminate that uncertainty, we need to develop ways of understanding it, making it visible and responding when things don’t go as expected.

That’s really what I’ve been exploring in this post. How do teams learn what works, establish appropriate boundaries and develop the confidence to work with agents without simply hoping for the best?

Because, as a friend recently reminded me, hope is not a strategy.

Thinking in probabilities

I was watching this video on 20 years of productivity advice, and one of the habits described was thinking in probabilities.

Which got me thinking that this is something we have to do a lot as QEs. We’re working in complex systems where knowing every possible outcome is impossible. You’re almost constantly hedging your bets that things will work, but there’s always a situation or circumstance you’ve not considered.

So thinking in probabilities doesn’t just keep us open to more information. It also helps stop us from looking only for evidence that confirms what we already believe and holding on too tightly to our beliefs when new evidence emerges.

One mistake I made was thinking it’s just about percentages and fractions, e.g. ‘I’m 80% confident that this will work’. While that can help, it’s also about thinking in degrees of confidence. Such as ‘I might be missing something here’, and separating the decision from the outcome.

For instance, you might make a good decision based on the evidence available, but the outcome could still be wrong because of something outside your control.

Which makes me wonder how often we judge the quality of our decisions based on what happened afterwards, rather than what we knew at the time.

Code coverage doesn’t necessarily protect the behaviour we care about

I recently subscribed to Bas Dijkstra’s automation newsletter (You should subscribe!). Unfortunately, I can’t link to the newsletter post publicly yet, but he’s been running some interesting experiments for a KWSQA talk he’s giving later this week.

Here’s what he learned:

- Claude is very good at writing lots of tests very quickly, but it has a tendency to add ‘dead weight’ tests, even for small code bases
- Mutation testing and figuring out which tests do not uniquely contribute to mutation coverage is a good way to weed out at least some of that dead weight, but
- Mutation testing in itself is also not the ‘end all and be all’ of what tests you do (not) need, and it takes human judgment to decide which tests are worth keeping, even when you let an LLM do the initial heavy lifting

What caught my attention was that Claude initially generated 182 tests, achieving 100% code coverage and 91.67% mutation coverage. It then removed 169 of those tests without changing either score.

But some of the removed tests would have detected changes to important business rules and API contracts.

It got me thinking about how we use coverage to give us confidence in our tests. Code coverage is useful for understanding which parts of our code the tests exercise, but it doesn’t necessarily tell us how well those tests protect the behaviour of the system. And even mutation testing, while giving us more information, has its limitations.

When we’re developing software, we’re often trying to change behaviour intentionally while making sure other important behaviours don’t change unexpectedly. That means understanding not just which parts of the code we’ve tested, but whether we’re protecting the behaviours that matter.

Perhaps the more useful question isn’t how much code we’re testing, but how confident we are that the behaviours we care about are protected.

Internal and external software quality

I was watching What Does Quality Look Like When Software Development Becomes Agentic? and one of the topics they got into was internal and external software quality. One thing I like about the distinction is that it helps us think about what good software actually looks like.

External quality is about what users experience, while internal quality is about how understandable, maintainable and easy to change the software is for those working on it.

This reminded me of Google’s theory of software quality, which I covered a while ago. It breaks quality down into process, code, system and product quality, helping teams understand the different attributes that matter to them.

Where I think this becomes particularly interesting is when we’re using agents to build software.

If we don’t have a shared understanding of what good quality looks like, how are we going to guide agents towards producing it? For instance, we might get software that does what we asked for, but it turns out to be difficult to understand, maintain or change in the future.

By getting teams and stakeholders to agree on the quality attributes that matter to them, we can start turning those expectations into guidance for agents, as well as ways to check whether we’re actually achieving them.

If you want to learn more about how to identify the quality attributes you care about, see my write-up of my talk Building Quality In – A Framework for Engineering Teams.

Agentic evals: testing how agents behave

I recently came across Yesha Shah’s Substack. She’s a tech lead working in Google’s Cloud AI teams and focuses on agent quality. She’s written a few guides for engineers exploring what agentic evals are and how they can help.

As with everything AI, nothing is a panacea, but combining different approaches can increase your confidence that your agent won’t go completely off the rails.

What I like about agentic evals is that they don’t just grade the final output. They can also evaluate the path the agent took (AI engineers call this the trajectory), the tools it used, any unintended side effects and how efficiently it completed the task.

You can incorporate evals into your development process to understand how changes to your agent, its guidance or controls affect its behaviour. You can also use them to evaluate real production interactions, giving you another source of feedback on how the agent is actually behaving.

Yesha’s first guide is pretty thorough and goes into detail about what agentic evals are and how they work. I’ve only managed to read the first one so far, but the other two explore using statistics to understand agent performance and autoraters (LLM-as-a-judge) to evaluate results.

But, as with all testing, evals are only as useful as the scenarios you choose and the behaviours you decide to evaluate. You still need to understand what good looks like and what could go wrong.

AI yet to show signs of payoff outside the tech sector

Despite massive investments and widespread hype around artificial intelligence, the technology has delivered zero financial payoff to corporate America outside of tech.

This kind of makes sense to me.

It’s not just about introducing AI into existing ways of working. Organisations may need to fundamentally change how they work, make decisions and learn from feedback. That’s going to take time, potentially years.

Which makes me wonder whether the organisations that benefit most from AI will be those that already have a strong culture of experimentation. Trying things out, seeing what happens, learning from that feedback and adapting how they work.

So perhaps it’s not surprising that the benefits of AI aren’t showing up more widely just yet. It’s more about how quickly you can learn to work with agents than how quickly agents can do the work. Via No Signs of AI Payoff Outside the Tech Sector | The Daily Spark

Diving in or waiting for what’s next?

I thought this was an interesting perspective from Gergely Orosz, who runs The Pragmatic Engineer newsletter and has a pretty good view of what’s happening across the software industry.

He’s noticing a divide between people who are thriving on the autonomy AI gives them, experimenting with new tools and ways of working, and those who are waiting for more guidance on how to use AI and, according to him, becoming increasingly frustrated.

While I wouldn’t say people are necessarily getting frustrated, I am definitely seeing something similar happening.

And I think there’s something interesting here about autonomy and how organisations support people through change. Not everyone has the same opportunities, confidence or freedom to experiment, and simply telling people to use AI isn’t particularly helpful either.

I think creating an environment where people can experiment, collaborate and try things out is critical when adopting new tools and approaches. People need to know it’s OK to get things wrong and share what they’ve learned.

But there’s often an interpersonal risk for engineers in admitting they haven’t been keeping up with the latest technologies, particularly when those technologies might eventually replace some of the work they do.

So just assuming people will naturally start experimenting is risky, and forcing them to do so doesn’t seem particularly productive either. We need to think more carefully about how we create the conditions where people feel safe to experiment, share what they’ve learned and adapt how they work.

Work with me

If you’re thinking about how your teams build quality and resilience into the way they work, I also help organisations explore these kinds of problems through talks, workshops and quality engineering advisory work.

You can find out more about how I work here: Work with me.

If this is your first time here, the Quality Engineering Newsletter is where I write about quality engineering, complex systems and how teams can build and change software with more confidence.

Subscribe if you’d like the next post in your inbox.

Subscribe now

Past Linkys

The Author Pays

2026-11-08T16:50:06Z

Java was famously promoted with the idealistic Write Once Run Anywhere and simultaneously derided with the sardonic Write Once Debug Everywhere. Neither is correct, of course, but the idea that one implementation can work for all consumers continues to be attractive, and the fact that it doesn't continues to frustrate.

Nowhere is this truer than as a reader of someone else's awful ticket, PR description, wiki page, code comment, or README: write once, WTF everywhere. And, unfortunately, we've all been there ... on both sides of the problem, sometimes as the author and, months later, confused recipient of the same miserable text.

Which is where today's post comes in. Last year's Heuristics for Working Today was a presentation I gave at work listing nine practices that I find generally useful, one of which I called The Author Pays.

It's the idea that since much of what is written is read multiple times, it seems reasonable in general for the author to pay the cost of making it understandable once rather than every reader to pay every time they come to it.

It's good team play, it's considerate, it encourages a culture of caring for and about one another, of respecting each other's time and effort, it helps us understand what we're writing better, and it improves the quality of the written material that we produce. It's also the kind of thing that can become second nature over time, which naturally lowers the cost.

Anyway, for whatever reason, it struck a chord with my colleagues and so I prepared a deeper look at that one heuristic, and that's the slide deck below.

Heal the Selector, Check the Click: Self-Healing Tests with WebdriverIO v10

2026-11-08T15:55:25Z

AI test steps usually come with two costs. The model is asked on every run, so the suite gets slower, spends tokens, and may not click the same thing twice. And when...

Day 40 of 100: Typing Functions — Params, Returns, Async Signatures

2026-11-07T23:00:00Z

Day 40 of 100: Parameter and return annotations, Promise, void vs never, function type aliases, a typed timing wrapper.

The post Day 40 of 100: Typing Functions — Params, Returns, Async Signatures appeared first on Software Testing & Automation.

Recognizing Policy

2026-11-07T14:55:43Z

When writing apps, we often talk about “business logic” and treat it like special code. We work hard to isolate our business logic from other parts of the code, like the view layer or framework-specific code, and we say that if you have limited test resources, testing your business logic is the first priority.

Business logic is the core behavior of your app, but there’s a certain class of business logic that I believe warrants extra attention: Policy.

unlocking any car from X brand in most of the world

2026-11-07T10:56:40Z

I've always had a soft spot for this particular car brand. Our family has owned a few of them over the years, and they've served us incredibly well. In 2023, I bought a new four wheel drive/SUV from them, and it was the first time I had access to their connected car platform.

Having looked at platforms like this before (previous works), I was sceptical about how secure they really were. I suspected there was something there, but life kept getting in the way of actually looking. This July, I collaborated with Sam Curry to take a look at the security of a major automaker's connected car systems. Throughout this post, I'll refer to them simply as "the automaker".

When you typically think of car hacking, it's often easy to jump into the hardware side of things, but my background sits pretty squarely in compromising internet-facing web applications and infrastructure. Regardless of all the hardware bits and bobs, it all connects back to some service that, by design, has to be reachable from the internet.

The journey started with a simple question: what infrastructure does the app talk to when I remotely unlock my car? To work this out, I downloaded the APK and decompiled it, eventually reconstructing the API requests that were being made.

Going through the code, the primary point of contact seemed to be assets under *.redacted-telematics.com.au:

dartExecutor.executeDartEntrypoint(createDefault, CollectionsKt.r(gson.toJson(new GlobalConfigParams(false, g11, com.redacted.app.xcapp.a.f69866f, "X", str)), new Gson().toJson(new ApiConfig("https://api.redacted-telematics.com.au", "https://api.redacted-telematics.com.au", "https://api.redacted-telematics.com.au" ...

Almost every part of the consumer application called back to redacted-telematics.com.au. What else existed under this domain?

The admin tool

Running connected car infrastructure can be quite complex, and managing it requires a mix of admin tools, staging, dev, and QA environments, to make sure that customers get a clean experience. Whether all of that should be sitting on the public internet, available to anyone willing to do some basic reconnaissance, is a different story.

One asset caught my attention more than the others. admintool.redacted-telematics.com.au returned a page titled TEST HARNESS. Who can resist a subdomain with admintool in it?

Visiting this subdomain presented a very plain and grey login screen, which didn't exactly ooze quality, given it presented a logout button before we'd logged in.

I love that most single-page applications ship their entire JavaScript bundle even when all they need to render is a login page. Sure, some more modern frameworks split out JavaScript files so that they only serve what is necessary, but in this case, we could comb through the large JavaScript bundle to understand what this "admin tool" actually let you do.

Oozing quality

Who even reads JavaScript bundles?

Turns out this admin tool let you do quite a lot. It had a rich API that let the automaker's employees interact with customer accounts and production vehicles with very few restrictions. Reconstructing the requests, we found that a lot of these APIs needed no authentication beyond the hardcoded API keys sitting in the JavaScript bundle.

For example, we could look up user accounts by email address:

But that's just not good enough. If we want to unlock any of their cars from just knowing the number plate, we're going to need to do better than that.

In Australia, a number plate gets you the VIN (vehicle identification number) fairly easily through state-based registration lookup sites.

This isn't really a security flaw. There are plenty of legitimate reasons to want a VIN, like checking a car's true repair and insurance history before buying second-hand. If we could go from VIN to a subscriber or email, we'd complete the chain.

Fortunately, there was an API that let you do exactly that:

With the subscriber GUID, you could pull the full account details (including the user's email via the /v1/account endpoint) like so:

Well, I guess we have the first part of our chain sorted. Plate -> VIN -> Subscriber GUID -> User Account PII (email) registered on the automaker's identity platform (ForgeRock OpenIDM).

Now, how do we send commands to any car we want? Surely this admin tool would let us do that? Unfortunately, no. It let us provision features to a car, add ourselves to a user's account as a secondary user, and even generate remote access codes. But for all that functionality, none of it actually got us remote control of a vehicle.

The identity platform

Sam and I then spent two weeks digging into how the automaker manages their central identity system: the software they use, the way commands are issued, and how consumers authenticate.

When a user goes through the authentication flow for the automaker's mobile app, requests are made to login.redacted-identity.com.au, and after going through an MFA flow, a consumer auth token is finally issued. This auth token is then used for subsequent requests to api.redacted-telematics.com.au (both REST APIs and GraphQL). Once you have that auth token, it's pretty much game over. You can control a user's car (remote unlock/lock, horns, engine, etc).

So if we could mint a token for any user, we'd finally be able to control anyone's connected car. This is the angle we went for.

The automaker is a heavy user of ForgeRock's identity software (OpenAM/OpenIDM). This is the cornerstone of their authentication mechanisms. Pulling the subdomains for *.redacted-identity.com.au, we quickly found their OpenIDM instance at openidm.redacted-identity.com.au. This is the system that manages every identity registered on the automaker's connected car platform.

This all clicked together when we were combing through the JavaScript files under *.redacted-telematics.com.au and we came across an absolutely cursed vendor JavaScript bundle that embedded admin credentials for OpenIDM 😱:

Even though these admin credentials were meant to be for their staging environment, given the hygiene we'd seen so far, we were pretty sure they'd work in production too.

Fighting the WAF

Looking closer at OpenIDM, we couldn't tell whether the automaker knew how fragile it was. One thing was obvious though: they'd invested heavily in WAF rules to block access to the sensitive APIs that ForgeRock typically lets you call via /openidm/*.

Even with the origin IP, any request to /openidm/ came straight back as an Nginx WAF block. Someone had put real effort into hardening these assets (despite them being externally accessible).

Fair enough, and we respect the hardening. But that much WAF investment usually means bandaids over something known to be bad. They probably understood how bad it was to have this asset exposed at all, and some business case kept it there anyway.

I'm not sure a WAF rule has ever stopped us when we're motivated enough, so we invested days into finding a way out of these protections, using our trusty path traversal tricks. How hard could it be?

Validating the admin credentials we found inside the JavaScript bundle was not that tough. The Australian OpenIDM instance had a few paths whitelisted like /XUI/ and /UI/, and path traversal characters were not blocked, so something as simple as /XUI/..%2fopenidm/endpoint seemed to at least partially work:

At least we know the credentials work in production

But it can never be as simple as that, right? The path traversal still didn't get us to the endpoints under /openidm/, thanks to quirks in how OpenIDM handles routing. Every endpoint would error out like so:

Gosh, we're so close?!

In OpenIDM's world, there were no servlets (or resources) registered against paths that included the path traversal within them. So it would just error out, even though it issued us an admin JWT.

We were incredibly annoyed by this. A simple quirk in routing mechanisms (probably not even designed as a security consideration) was blocking the full attack chain from working. We sat frustrated for a few days, and we thought that the path traversal angle just wasn't going to work. We did find a few other endpoints (user upload, for example) that looked like they might work, but we hit another quirk, a servlet path check, that prevented us from using them meaningfully.

All of this made us ask a different question: why expose these OpenIDM instances externally at all? Surely there had to be some legitimate use case for these assets to be exposed on the internet? We went back to the different JavaScript bundles we had collected from their assets and searched them for communications to OpenIDM. We turned to the decompiled Android application and found the following:

Maybe there is a whitelist for some endpoints?

These were clearly endpoints within their OpenIDM asset that were contactable from the Android app. So, maybe these were accessible without the WAF getting in the way?

/openidm/endpoint/aaa -> 403 WAF blocked
/openidm/endpoint/pinService -> 404, no WAF block

Interesting!

What other custom endpoints existed? With some very light brute forcing and guessing, we quickly found a getUser endpoint. Guessing at parameters, we found it accepted mail, guid, and phone. Combined with our admin credentials, what did this really let us do?

Eep.

The response came back with the password hash, PIN code hash, mobile push tokens, and PII including mobile numbers and full names. There was no WAF block on this endpoint, so no path traversal was needed and the correct servlet responded.

Don't get me wrong, this was already pretty impactful. But the passwords were hashed with PBKDF2-SHA512, and needing time on a hash cracking rig for every unlock, with no guarantee of success, felt a bit lacklustre.

Back to the drawing board. How could we access the /openidm/managed/user servlet with our path traversal, and still have the path be recognised by OpenIDM? We grabbed the OpenIDM source closest to the version we were testing against and let GPT 5.6 Sol Ultra spend a good six hours on it.

It succeeded. Even though Sam and I had both spent time trying to manually bypass this juvenile restriction ourselves, we hadn't tried every possible combination.

When Sam and I tried /XUI%2f..%2fopenidm/, we got a hard 403, and being human, we assumed that applied to every prefix. What GPT 5.6 found was that /static%2f..%2fopenidm/ wasn't covered by the WAF at all, and it gave us the OpenIDM APIs without the servlet confusion issue.

Taking over accounts

With this bypass, taking over an account became trivial. We could PATCH a new password for any user profile:

PATCH /static%2f..%2fopenidm/managed/user/f7ba554REDACTED HTTP/1.1
Host: openidm.redacted-identity.com.au
X-OpenIDM-Username: idmadmin
X-OpenIDM-Password: REDACTED
X-OpenIDM-NoSession: true
Content-Type: application/json
If-Match: "0000000abc123..."
Cache-Control: no-store
Accept: application/json

[{"operation":"replace","field":"/password","value":"Testing123!"}]

Which responded with:

> HTTP/1.1 200 OK
> {"_id":"f7ba554REDACTED","_rev":"0000000def456..."}

OK, so we could overwrite the password for any user. But what about multi-factor authentication?

Skipping MFA

Well, the automaker's Australian environment had one more misconfiguration: the multi-factor step could be skipped entirely. First, we requested an authentication token from login.redacted-identity.com.au with a Resource Owner Password Credentials grant, which returned a clean id_token we could swap for something usable in the consumer app:

POST /oauth2/realms/root/realms/REDACTED/access_token HTTP/1.1
Host: login.redacted-identity.com.au
Content-Type: application/x-www-form-urlencoded

grant_type=password&username=admin@shubs.io&password=Testing123!&client_id=REDACTED_PORTAL&client_secret=REDACTED

> HTTP/1.1 200 OK
> {
>   "access_token": "...",
>   "id_token": "eyJ0eXAiOiJKV1Qi...",
>   "token_type": "Bearer",
>   "expires_in": 3599
> }

We took that and moved on to step two, exchanging the first token for a session:

POST /json/realms/REDACTED/authenticate?authIndexType=service&authIndexValue=IDTokenROPC HTTP/1.1
Host: login.redacted-identity.com.au
Content-Type: application/json
Accept: application/json
Accept-API-Version: resource=2.0, protocol=1.0
idtoken: eyJ0eXAiOiJKV1Qi...

> HTTP/1.1 200 OK
> {
>   "tokenId": "AQIC5wM2LY4Sfcy...*",
>   "successUrl": "/openam/console",
>   "realm": "/REDACTED"
> }

Lastly, we performed the token exchange for a mobile app access token:

POST /oauth2/realms/root/realms/REDACTED/authorize HTTP/1.1
Host: login.redacted-identity.com.au
Content-Type: application/x-www-form-urlencoded
Accept-API-Version: resource=2.1, protocol=1.0
x-fr-version: 2025.05.05
Authorization: Basic <REDACTED>
iPlanetDirectoryPro: AQIC5wM2LY4Sfcy...*
Cookie: iPlanetDirectoryPro=AQIC5wM2LY4Sfcy...*

client_id=REDACTED_APP&redirect_uri=com.redacted.app:/oauth2Callback&scope=openid%20profile%20write&response_type=code&state=<state>&code_challenge=<S256_challenge>&code_challenge_method=S256&decision=allow&csrf=AQIC5wM2LY4Sfcy...*

> HTTP/1.1 302 Found
> Location: com.redacted.app:/oauth2Callback?code=<authorization_code>&state=<state>

POST /oauth2/realms/root/realms/REDACTED/access_token HTTP/1.1
Host: login.redacted-identity.com.au
Content-Type: application/x-www-form-urlencoded
Accept-API-Version: resource=2.1, protocol=1.0
Authorization: Basic <REDACTED>

grant_type=authorization_code&code=<authorization_code>&redirect_uri=com.redacted.app:/oauth2Callback&client_id=REDACTED_APP&code_verifier=<pkce_verifier>

> HTTP/1.1 200 OK
> {
>   "access_token": "<app_access_token>",
>   "refresh_token": "...",
>   "token_type": "Bearer",
>   "scope": "openid profile write",
>   "expires_in": 3599
> }

It's super convoluted, I know. OAuth is annoyingly hard sometimes. But these steps let us bypass multi-factor authentication for any user of the automaker's connected car app.

Unlocking the car

At this point, we were so damn close to unlocking any of the automaker's cars in Australia. All that was left was issuing the command API requests with the app token we could now mint for anyone.

POST /v1/remote/route/command HTTP/1.1
Host: api.redacted-telematics.com.au
Authorization: Bearer <app_access_token>
X-API-KEY: REDACTED
X-GUID: f7ba554REDACTED
X-BRAND: REDACTED
X-APPBRAND: REDACTED
X-CHANNEL: REDACTED
X-LOCALE: en-AU
X-APPVERSION: REDACTED
X-OSNAME: Android
X-OSVERSION: 14
X-DEVICE-TIMEZONE: AEST
X-CORRELATIONID: 6f1a2b3c-4d5e-6f70-8192-a3b4c5d6e7f8
X-GENERATION: REDACTED
VIN: XXXXXXXXXXXXXXXXX
Content-Type: application/json
Accept: application/json
User-Agent: okhttp/4.12.0

{"command": "door-unlock", "autoFixPopup": false, "beepCount": null}

And magic. The doors unlocked.

We obviously did all of this on cars we explicitly owned or had permission to interact with.

But let's take a step back and think about what we achieved here. We could send commands to any of the automaker's vehicles in Australia, across both of their brands, by only knowing the number plate of the vehicle. The final chain looked like this:

Plate -> VIN -> Subscriber GUID -> OpenIDM admin credentials in JS vendor bundle -> Path traversal to bypass the WAF -> MFA bypass via ROPC flow -> Minting a consumer app token -> Remote command API.

At 12AM, when the full chain finally came together, I took a short video of the script in action. It's not polished, but it still felt magical seeing it all work. I definitely live for hard challenges like these.

You might be wondering: Shubs, you said any of their cars in the world. This only covers Australia. What gives?

There's a much more complex chain that Sam and I worked on together, which he's published on his blog here. It required a lot more work than the steps we took for Australia, as the automaker had spent much more time securing the US, Canadian, and European OpenIDM environments.

At the end of the day, with both writeups combined, we could send remote commands such as unlocking and turning the engines on, for any of the automaker's vehicles in Australia, the United States, and Canada.

My learning bits for Saturday of 7th November 2026

2026-11-07T06:00:00Z

Here are my learning bits for today:

Do agents dream of electric sheep? Components of agent memory.

Day 39 of 100: Enums vs Literal Types — When Each Wins

2026-11-06T23:00:00Z

Day 39 of 100: Enum syntax, literal unions, as const objects. The decision table for test configs.

The post Day 39 of 100: Enums vs Literal Types — When Each Wins appeared first on Software Testing & Automation.

Testing Superintelligence: We Need More Than a Warning

2026-11-06T21:12:12Z

My fourteen-year-old son and I tried asking ChatGPT questions that might tell us whether it was smarter than we were. Some of the answers sounded like pageant answers: polished, reassuring, and difficult to learn much from. Then I asked him, “What if it was lying to us? How could we detect that?”

His eyes got big. The same answer could come from a system trying to mislead us or from one doing what it had learned to do: give a reassuring answer. What could we test that would help us tell the difference?

This book is about testing for superintelligence. When an AI system appears to do something beyond human capability, how do we check the claim, and how would we notice if those results started to accumulate across fields? Progress may hit limits, and capable systems may remain under effective control. In either case, we need ways to find out what they can do while we still have time to act on what we learn.

I mean superintelligence in a strict sense. Imagine the best human teams with more time to learn, invent tools, and work together. Could they acquire the underlying competence? Faster work, more parallel attempts, and even victory over every expert we can recruit leave that question open. The hard case is a system that repeatedly develops and uses competencies beyond what finite human effort could attain under stated conditions. That possibility is the subject of the book. The failures of current systems matter here when they show how we might miss or misread evidence of such a change.

A note after the 2026 U.S. midterms

November 5, 2026. On November 4, following the U.S. midterm elections, Representative Yassamin Ansari called for a pause on advanced AI development and “a ban on artificial superintelligence,” as reported by Tom’s Hardware. The idea was already before Congress. On September 23, Representative Greg Casar and Senator Bernie Sanders introduced the Ban Artificial Superintelligence Act. “Our bill bans the development of artificial superintelligence,” Casar said. The proposal would also prohibit deployment and create an agency to monitor frontier systems. [121, 122]

How do you enforce a ban on something you cannot reliably detect? A rule can target observable conduct, such as running a covered training job without authorization. Records can help establish whether that conduct occurred. A rule keyed to a system’s capabilities poses another question. What did the system actually become capable of, and when? Evidence of a deliberate attempt, evidence that a threshold was crossed, and evidence that a particular person or organization violated a rule answer different questions.

A team could cross a capability threshold while pursuing a narrower objective. A system might also cross it before anyone has a test sensitive enough to notice. Whether either event has happened remains open. That uncertainty matters today. If lawmakers draw a boundary, investigators need to know what they can observe, what they can verify independently, and where their tests leave them blind. The proposed bill’s definition and this book’s stricter human reachability boundary serve different purposes. Any test has to say which claim it is trying to establish.

Why a software tester is asking

I have spent years working on testing at scale, testing AI, and using AI to test software. I was a test manager on AI-based search systems at Microsoft, in the work that became Bing, and on Chrome at Google. These problems were part of my working life long before the current enthusiasm for large language models.

In my recollection of the search competition, Google seemed to have all the smart engineers. Neural networks felt like a practical way for us to compete: let a learned system find improvements we could not keep handcrafting. What felt like a hack became more capable over time. For those of us testing it, that meant learning how to examine a system whose behavior was not simply a list of rules we had written.

That responsibility extended beyond examining model outputs. My team was also accountable for the infrastructure used to train models, evaluate them, and run evaluations again. We examined statistics about the training data and how effectively people were using that infrastructure. We did basic analysis of training configurations and model hyperparameters to understand whether the choices people were making were helping. Testing meant looking at the machinery and the work practices that produced the result, not only the result at the end.

We also worked on data quality, including the human judgments used for training. In one case I remember, a vendor responded to disagreement between raters by firing one of them. That practice was distorting our training data. I return to it in the testing-foundations chapter because it captures a larger problem: apparent agreement can improve while the process producing it becomes less trustworthy.

I later cofounded test.ai, before the current LLM wave, to apply AI to software testing. Google’s AI-focused venture fund, Gradient Ventures, led its 2018 Series A. [26] Testing AI and building AI that tests have been connected problems throughout my work.

So yes, I sometimes find myself arguing with a podcast or a conference presentation. I hear a familiar testing failure presented as a new mystery: trusting an answer key nobody checked, confusing a score with coverage, or accepting a demonstration as evidence of reliability. Software testers have spent years encountering these patterns, learning which techniques help, and finding out where they fail.

We have also spent years thinking about oracles: how to judge a result when the correct answer is difficult to specify. A research benchmark and a production testing program face different demands. Production adds changing environments, messy inputs, integrations, users, and failures that escape the test environment. I want more of that experience in this conversation.

This is not a claim that frontier researchers never test or that existing testing practice solves superintelligence. It is a request to bring the accumulated experience of software testing into the work, then discover precisely where it stops being enough. I do not hear enough public discussion of this less glamorous work: testing the training infrastructure, examining data quality, and investigating the incentives behind the labels. That does not establish how much of it happens inside labs. It does mean I want to see the evidence, rather than assume someone has covered it.

At a testing conference, I brought up the problem between sessions. We agreed it sounded hard. A few minutes later we were back to talking about prompts for testing websites. I left wanting a concrete experiment that testers and researchers could pick apart together.

A warning needs a test

I do not want our testing strategy to depend on everybody agreeing to stop. That is a planning position, not a prediction that policy cannot change anything. Pauses, restrictions, and technical controls may matter. We still need methods that work while capable systems exist and people continue trying to use them.

A sandbox is not an answer to all those questions. It is something else to test. An air gap removes important connections, but it does not establish that every physical or human communication channel is absent. A model that helps build its own protections has not independently certified them. And a promise that a system will behave safely is an output to examine, not a reason to stop examining.

We should take those concerns seriously without pretending we have proved every boundary will fail. The practical question is what a control prevents, under which assumptions, and what evidence would reveal its failure. This book will return to that question often.

The test is allowed to be wrong

We build an exam, give it to a model, and debate the percentage. Meanwhile the questions may be ambiguous, the reference answers may be wrong, the scoring software may have bugs, and the environment may be helping the model in ways we did not intend. Documented benchmark reviews show why these are real testing questions. [3, 4]

Some evaluations go far beyond multiple-choice questions. That is progress. But complexity does not make an evaluation trustworthy. We must investigate how it works and how far its conclusions reach.

Now add a more difficult possibility: the system gives us an answer we could not have created. Sometimes we can still check it. Sometimes checking it is itself a research project. Sometimes we may not even recognize the question we should have asked.

Suppose an AI produces a mathematical proof that an expert team could not find. That is a Super Signal, an observation worth investigating. A Super Test starts by recording the claim and comparing the time, tools, and prior work available to the model and to the experts. Could the model have seen the proof before? Ask an independent team to check the proof and then test the system on a fresh problem. Repeat under comparable conditions to see whether the advantage persists. A valid proof settles whether the result follows. The rest of the investigation tells us how much we learned about the system that produced it.

Begin with today

After the opening allegory, Chapter 1 walks through a fictional Super Test. The first hypothesis gets weaker as we improve the baseline, and fresh problems reveal a narrower capability. Chapter 2 takes the same habits to a public benchmark record. Later chapters extend the investigation to learning beyond human examples and to systems that act in laboratories, robots and simulated worlds.

A fictional research assistant connects the chapters. It passes an exam, produces an unfamiliar result, asks for tools, acts, and eventually challenges our ability to judge and observe it. This is a teaching scenario, not a claim that one current product already combines every capability described here.

If we wait until a system is unmistakably beyond us to invent the tests and instruments, the time we need to prepare may already be gone. We should start while we can still discover our mistakes in smaller, more recoverable settings.

Two sides of the nest

The owl and sparrows return throughout the book in short illustrated boxes. “From the sparrows’ side” asks what observers with limited access can see, check, or change. “From the owl’s side” offers a possible explanation for the same scene and suggests what evidence could distinguish it from another.

If a broken latch works again by morning, the sparrows know it was restored. The owl may have noticed the break or replaced the latch on schedule. A comparison with an untouched latch helps the flock tell those accounts apart. Sometimes the owl helps, sometimes it misunderstands, and sometimes it changes its behavior under inspection.

Why the owl

The owl is a deliberate homage to Nick Bostrom’s Superintelligence: Paths, Dangers, Strategies. His book explores routes to superintelligence, takeoff dynamics, and the control problem. It also discusses monitoring, boxing, and tripwires; it would be unfair to say it ignores detection and control. [24]

The dedicated deception and safety sections also examine researchers who are already working on these problems.

The question I want to bring into the foreground is the working tester’s question: how do we recognize a consequential capability, challenge the claim, and know whether our observation and control mechanisms are working? The homage is an acknowledgment of that earlier work, not an endorsement or collaboration.

This is a developing technical book. Every chapter is a working draft. Executed examples are distinguished from proposed experiments. As the work grows, claims should acquire better evidence, examples should become reproducible, and weak arguments should change. A book about testing ought to make it possible to test what it says.

Testing Superintelligence: We Need More Than a Warning

2026-11-06T21:12:12Z

A note after the 2026 U.S. midterms

Why a software tester is asking

A warning needs a test

The test is allowed to be wrong

Some evaluations go far beyond multiple-choice questions. That is progress. But complexity does not make an evaluation trustworthy. We must investigate how it works and how far its conclusions reach.

Begin with today

Two sides of the nest

Why the owl

The dedicated deception and safety sections also examine researchers who are already working on these problems.

CARBON /full: Go beyond the first test pass

2026-11-06T18:01:02Z

A first look can reveal a problem. A broader investigation can reveal what you still do not understand. CARBON’s /full command is designed for that sustained, resumable testing workflow.

Before testing begins, it requires two distinct human confirmations: scope and budget. That boundary matters. A long-running campaign can consume meaningful time and coding-agent resources, and the invocation alone is not approval to proceed.

The video outlines the cycle: discover paths, generate candidates, execute checks, reproduce findings, triage the evidence, and decide what to investigate next. Checkpoints make progress visible and support stopping and resuming. Resume requires fresh approvals.

“Full” does not mean exhaustive. Keep the tested scope and coverage gaps in view, and choose a budget appropriate to the project. The workflow stays within the installed edition’s capabilities and host permissions.

CARBON Core is free and open source in the OpenAI and Claude plugin marketplaces. The comprehensive workflow is included in the free offering; advanced Pro capabilities remain separate.

See the explainer and installation options at https://testers.ai/carbon/

Need instant-on AI QA bandwidth? Iceberg QA brings QA experts, advanced AI tooling, and test harnesses together to tackle your quality problems. Tell us what you need and sign up at https://icebergqa.com/

Watch the video when it releases on November 6 at 10 a.m. Pacific: https://youtu.be/n6vL4nQjp48

CARBON /full: Go beyond the first test pass

2026-11-06T18:01:02Z

A first look can reveal a problem. A broader investigation can reveal what you still do not understand. CARBON’s /full command is designed for that sustained, resumable testing workflow.

CARBON Core is free and open source in the OpenAI and Claude plugin marketplaces. The comprehensive workflow is included in the free offering; advanced Pro capabilities remain separate.

See the explainer and installation options at https://testers.ai/carbon/

Watch the video when it releases on November 6 at 10 a.m. Pacific: https://youtu.be/n6vL4nQjp48

A new beginning

2026-11-06T06:00:00Z

When AI tooling became easily and cheaply available to the general public I jumped on it. For me, it all started with Midjourney. For years I kept a paid account, and I loved playing with the image generator. I even tried to sell some of my designs as drop-shipped t-shirts, but that failed miserably. Turned […]

Software Testing & QA Jobs – November 06, 2026 | Daily Job Openings

2026-11-06T05:56:23Z

Software Testing & QA Jobs – November 06, 2026

Position - Senior QA Technical Lead

Company - PTC

Experience - 6-10 years

Location - Pune, Maharashtra