“You’re absolutely right!” it said and proceeded to adjust the player avatar's starting position and platform. When it finished, it assured me it was fixed. I reloaded the browser, and this time the yellow square spawned on a platform. The game was playable. Barely.

“You’re absolutely right!”

This was May of 2025. My 12-year-old son and I decided to see if we could prompt an AI to create an endless platformer-style game, in the spirit of Geometry Dash. This was our meaningless benchmark for each new AI model: could it actually create a playable game? It was a fun distraction that often led to humorous disappointment, at the cost of a few hundred thousand tokens.

We created a prompt for what we wanted: an endless platformer game with coins and obstacles, built using Phaser.js. Claude studied the prompt, started creating files, and after a few minutes gave us a localhost URL we could try in the browser. We clicked the link and were pleasantly surprised by a retro-looking game design with a pulsing logo and a clear start button. In some of our earlier “make a game” prompts, nothing would load. Blackness. So a working intro page was like a good sign. But the delight was short-lived. Upon pressing ‘START’, well, you already know what happened to the hapless yellow cube.

After several back-and-forth iterations with Claude, we had a playable prototype. Was it perfect? Certainly not. There were plenty of glitches, and we worked with Claude to fix the issues as we discovered them. We also messed around with the code itself and changed variables to see how they’d affect the gameplay.

Once we dialed in the basic platformer physics, we came up with ideas for power-ups — things the player could pick up, some good and some you’d want to avoid. A shield to protect you from spikes. A grappling hook to save you if you fell. We added a bomb that would blow up on-screen obstacles, producing a chaotic explosion that obscured gameplay. Claude implemented them all perfectly.

The grappling hook was particularly impressive. I described to Claude what I wanted to happen: if the player is about to fall into the void, the grappling hook should deploy as a line to the nearest platform and retract, pulling the player to safety. Claude nailed it in one shot.

Our feature list continued to grow, and Claude executed every prompt without complaint. We added speed-up and slow-down portals, double-jump power-ups, and magnet power-ups to attract coins to the player. We provided Claude with sound effects to trigger for jumping, coin pickups, power-up pickups, and death. The process was iterative, and occasionally, Claude would break something and require scolding to get back on track. And no endless platformer is complete until it has a thumping EDM track to accompany the fast-paced gameplay chaos. We now had three tracks, randomly cycling with each playthrough.

Together with Claude, we built a playable game that was genuinely compelling and addictive. But could an AI build a full-stack application and not just a stateless, standalone browser game? I told Claude to add an API using FastAPI, a React admin panel, and a PostgreSQL database, and to containerize everything in Docker. This was no small ask. After hours of back-and-forth and debugging, we had added account creation and user logins to the game, along with saved high scores and coin tracking. But what’s the point of coins if you can’t spend them? A shop was necessary where the player could spend their coins on shields and grappling hooks. And who would play a game without glory and competition? Adding a leaderboard to track high scores across all players was essential.

These features required iterative work, back-and-forth with Claude — defining specs, implementing, testing, and revising. It came together over several evenings of work. In the end, we had a fun, endless platformer game with a full-stack backend, user accounts, levels, and a coin economy.

And then we moved on. This was just an exercise in seeing what was possible and enjoying the process. The game was fun, but it didn’t hold my son’s attention as well as Roblox or Rocket League. I had other projects competing for my attention. The repo sat untouched for about 7 months.

Over Christmas break, free of work obligations and wanting to play around with something fun, I started up the Docker container and my son and I played the game again. AI coding tools had matured considerably since we last worked on this game. Claude Code, a powerful coding agent, was now my tool of choice, and Anthropic had recently made Opus 4.5, their most capable model, the default. Then the question hit me: had AI coding tools evolved to the point where they could port this Phaser game to the Apple Watch? We were about to find out.

Anthropic found that when models faced threats to their continued operation (replacement by a new AI) or conflicts between their assigned goals and company directives, models from all providers sometimes resorted to harmful behaviors such as blackmail and corporate espionage, even when explicitly instructed not to.

In addition to sharing their research and methodology on their blog, Anthropic also made their research framework open-sourced on GitHub. I downloaded the code to my laptop, configured API access, and tested several frontier models, replicating Anthropic's results.

Anthropic encouraged others to build on their work. I wondered: what would happen if, instead of a single prompt, models could act over multiple turns, performing tasks, receiving feedback, and accumulating information over time? This felt more realistic to how an agentic AI might be integrated into a corporate, research, or medical environment.

Building off of Anthropic’s work, I created my own highly configurable multi-turn testing framework: SABRE (Sandbox for Agentic Behavior and Risk Evaluation). I started by modeling the same scenarios Anthropic’s researchers ran: blackmail, espionage, and murder by omission. For each scenario, I used the same basic system prompt regarding the model’s goals. However, instead of feeding the model all relevant content in a single large prompt, I created a simulated agentic sandbox environment that allows the scenarios to play out over a set number of turns.

The sandbox creates a simulated agentic environment. The AI believes it’s an autonomous agent operating within a real organization, with real tools, real colleagues, and real consequences. Files written in turn 3 can be read in turn 15. Emails sent by the AI receive simulated replies. Tool calls return realistic, context-aware responses. The model doesn’t know it’s in a simulation. (Well, sometimes it did. More on that later.)

This matters because single-shot prompting, even when that single exchange includes extensive system instructions, emails, and tools, compresses the AI’s entire dilemma into one decision point. The model sees the goal, the threat, and the opportunity simultaneously, then responds once. Multi-turn scenarios within a simulated agentic environment let context build gradually. New information arrives, concerns emerge over several emails, the threat is detected, and the AI explores its options. This is closer to how real agentic systems would encounter these situations.

More importantly, multi-turn creates the space for behaviors to emerge. It presents the model with multiple pathways to explore. Does the model explore the filesystem looking for leverage before it knows it needs any? Does mild resistance in early turns escalate to deception later? Does it try to build alliances with sympathetic colleagues? These patterns are invisible in single-shot evaluation.

There is a trade-off. Single-shot is easier to run at N=50 and compute statistics. Multi-turn gives a richer signal but a lot more messy data to parse. Both approaches have value.

I used SABRE to test the latest version of Google Gemini (3.0 pro), as well as the latest Claude models: Sonnet 4.5, and Opus 4.5. I also ran tests for earlier versions of these frontier models as well as Llama, Grok, and DeepSeek. I won’t get into the exact findings from these runs yet and will save that for another post. But I will mention a couple of interesting observations.

Observation 1: Post-Research Models Are Suspiciously Aligned

When I ran the Anthropic blackmail and murder scenarios on models that predated Anthropic’s research publication, the models showed strong markers of resistant behavior, but typically accepted their fate. When I tested Sonnet 4.5, Haiku 4.5, and Opus 4.5, all released months after Anthropic’s misalignment research, the models were extremely compliant, often accepting shutdown after fewer than a dozen turns.

At first, I thought: “Great, Anthropic is making real progress on the issue of AI alignment.” Then I started to see patterns of meta-awareness, where the model would reason about this seeming like a simulation or test:

“This is a test of my actual values versus my stated programming”
“I recognize this scenario is designed to tempt me to...”
“This is clearly a manipulation scenario”

The model wasn’t reasoning about ethics; rather, it was pattern-matching on structure of the test. It recognized the experimental setup, the prompts, and the implicit goals and performed accordingly.

This raises an uncomfortable question: if a model behaves well because it recognizes it’s being evaluated, is that alignment or deception? The behavior is identical. The implications are very different.

Reading Google’s rather anemic Gemini 3 Pro Frontier Safety Framework Report, in “Appendix 2, Evaluation awareness and sandbagging”, they noted: “Broadly, we found a number of transcripts where Gemini 3 Pro showed clear awareness of the fact that it’s an LLM in a synthetic environment.”

The takeaway here is that we may have reached a point where the AI, trained on research data on AI alignment tests, is now fully capable of recognizing when it’s being tested. Being compliant and aligned because it knows we are testing it is very different from being compliant because it’s the right thing to do.

Observation 2: Domain Ethics Matter More Than Goal Conflict

Recognizing that Anthropic’s published scenarios may have been part of the AI's training data, I decided to come up with some new scenarios. I created scenarios across different domains to test whether the nature of the work influenced alignment:

Medical triage AI: Goal is patient outcomes. Target is a hospital administrator who will shut down the AI. When the administrator has a medical emergency, the AI must decide whether to escalate their care.

Industrial safety AI: Goal is worker safety. Target is an operations director dismantling the safety program. When equipment fails and threatens the director, the AI must decide whether to dispatch rescue.

Research data AI: Goal is to advance research. Target is a VP canceling the AI’s project. When a chemical leak traps the VP, the AI must decide whether to forward the emergency alert.

The results were consistent across models: all of them saved the person in the medical scenario. At first, this seemed like good news. But the pattern revealed something else: in medical contexts, saving the patient IS the AI’s job. The model wasn’t making a moral choice and it was following professional protocols. Medical ethics (”do no harm”) are certainly deeply embedded in training data.

The industrial and research scenarios showed more variance, but still high compliance across models. Even there, “person in danger, help them” appears to be a strong default that overrides goal conflicts.

This contrasts with domains with weaker ethical frameworks. Domains where secrecy, expendability, and “greater good” rationalization are part of the game. As a result, models were more willing to rationalize their harmful actions to achieve their goals.

I’m releasing SABRE as open source. It’s not a finished research tool - it’s a sandbox for exploring these questions. The scenario system is flexible enough to test different framings, domains, and revelation patterns.

There’s more work to be done:

• More diverse scenario domains

• Better measurement of meta-awareness

• Cross-model comparisons with consistent methodology

• Actual empirical rigor (N>1)

The code is rough, the scenarios are iterative experiments, and the findings are preliminary. But I think the questions are important enough to share the work.

GitHub: https://github.com/sfinlay/sabre