How I AI: My GPT-5.5 Review—A 6-Hour Autonomous Task and the Bluetooth Hack No Other Model Could Solve

GPT-5.5 earned its keep for me on the kinds of engineering problems I usually postpone: messy migrations, security cleanup, and a Bluetooth reverse-engineering project that other models could not finish. In this episode of How I AI, I tested it on everything from a simple subtraction app to a nearly six-hour autonomous repair loop running against production-like data.

What stood out was not that GPT-5.5 suddenly made every workflow better. The difference showed up on high-complexity tasks with real validation loops, large repositories, edge cases, and enough context to get lost in. On those projects, it stayed focused longer, made fewer obvious mistakes, and produced outputs I could actually test. On the simpler app work, the extra reasoning felt expensive in both time and tokens.

The workflows in this episode separate three very different use cases: everyday app generation inside ChatGPT, long-running technical maintenance work in Codex, and protocol reconstruction on hardware I already owned and had permission to inspect. See Reverse-Engineer a Proprietary Hardware Protocol with AI.

Testing GPT-5.5 on a simple educational app

I started with a deliberately ordinary task: building a small learning app for multi-digit subtraction. This is the kind of thing I regularly use AI coding tools for when I want a quick teaching aid for my son.

The request was straightforward. I asked GPT-5.5 to create an app that teaches more advanced subtraction concepts to a second grader, including lessons, practice modules, and word problems.

The interesting part was not the app itself. It was the amount of reasoning the model applied before returning anything. GPT-5.5 spent 17 minutes and 27 seconds planning, thinking through the structure, and generating the implementation before producing a functional result. The final app worked in my testing and included multiple learning modes, but the wait felt disproportionate to the complexity of the task.

This is the "intelligence overhang" I felt in the test: the interface applied substantial reasoning to a job that may not need the most capable model. The harder Codex tasks gave that effort a clearer purpose. For lightweight app generation, I was less convinced that the additional thinking time created proportionally better output.

Using Codex to clean up technical debt

The more convincing tests happened inside Codex with GPT-5.5 Pro. I used it against two ongoing ChatPRD maintenance problems where I had concrete ways to validate success instead of relying on whether the generated code merely looked plausible.

Turning a security backlog into grouped fixes

The first task started with a list of low-severity findings generated by Codex Security. Instead of addressing each issue manually, I asked Codex to review the findings architecturally, identify themes across the issues, propose changes, and then implement those changes directly in the codebase.

1. Input: A CSV export containing the security findings and related metadata.
2. Action: Upload the CSV directly into the Codex coding session so the model could inspect the issues together instead of one at a time.
3. Instruction: Review the findings holistically, group related patterns, propose remediation approaches, and implement the fixes in code.
4. Result: GPT-5.5 grouped the findings into broader architectural categories and implemented the associated changes with surprisingly little supervision. We still performed human review and code review afterward, but the quality was high enough that it meaningfully reduced the cleanup burden. Soon after, the annual penetration test for the system came back clean. That does not prove the model alone caused the result, but it was useful independent evidence that the remediation work held up under external testing.

Running a nearly six-hour migration and repair loop

The second project was much harder. ChatPRD had accumulated millions of stored conversation threads across changing provider response formats, partial migrations, attachments, tools, and years of edge cases. Every previous cleanup attempt fixed one class of issues while exposing another.

GPT-5.5 Pro first generated a migration that handled roughly 98 percent of the identified edge cases in the initial pass. That alone was already better than prior attempts. The more important step came next, when I asked it to design a reusable validation and repair system that could continuously test migrated threads against multiple providers and detect failures automatically.

Example long-running task: Build a programmatic way to test every thread in the local production-like dataset against Anthropic, OpenAI, and the other providers we use. Make it scalable and accessible through a CLI so any agent can test a thread for data issues. Use subagents where helpful, validate the system, identify and repair problems, and leave it ready for production.

The run continued for five hours and 57 minutes without additional prompting from me. During that time, the model spawned a subagent, built a smoke-test CLI, exercised production-like data against provider APIs, identified failures, repaired them, and reran validations. Aside from approving one sandbox-related action, I did not have to steer the process. This was the first time I personally saw an AI coding workflow sustain a genuinely long-running autonomous loop on a constrained engineering task. You can follow the full implementation in Perform an Autonomous Data Migration with an AI Agent. See Perform an Autonomous Data Migration with an AI Agent.

In the reported validation results, two million rows passed through the migration with a single uncaught edge case remaining. After deployment, Sentry error volume also dropped sharply. I do not treat that as proof that every historical format or production condition was perfectly handled, but it was enough evidence to materially increase confidence in the migration quality.

What mattered here was not just that the migration worked. GPT-5.5 built tooling around the migration: reusable smoke tests, repair loops, and a validation surface the engineering team could continue using afterward. That combination of autonomy plus inspectable output is where the model felt meaningfully different from earlier coding systems.

Reverse engineering a Bluetooth display protocol

My final evaluation was the one I cared about most personally. I had been trying for months to control a Divoom MiniToo Bluetooth speaker and pixel display directly from the terminal instead of relying on the proprietary phone app.

Capturing the Bluetooth traffic

On my own phone and speaker, I installed a Bluetooth development profile and routed the communication through packet inspection tools so I could capture the traffic exchanged between the mobile app and the display. The raw logs alone were not enough. The hard part was interpreting the packet structure, bitmap encoding, and command format hidden inside the traffic. Anyone experimenting with similar workflows should confirm they have authorization to inspect their devices and understand any warranty or platform implications before modifying hardware behavior.

Giving Codex the failed experiments and raw evidence

I supplied GPT-5.5 with the captured packet logs, my notes, failed theories, partial documentation, and prior dead ends from earlier attempts with other models. The request itself was intentionally broad because at that point I mostly wanted persistence and experimentation:

Example Bluetooth prompt: This device connects over Bluetooth. Use the packet logs and everything else you have learned to determine how to display an image on it. Try any reasonable approach and keep working through the failed experiments.

GPT-5.5 analyzed the Bluetooth captures, inferred enough of the bitmap protocol to reconstruct valid display commands, and eventually generated a working method for controlling the screen. Earlier attempts with other coding models had stalled on the protocol interpretation step.

Connecting the device to my local workflow

The final result was a small command-line tool that can send approved messages directly to the speaker display from the terminal. I then wired that tool into my local Codex workflow so the display can act as a notification surface when coding tasks complete. It sounds small, but this was months of trial and error condensed into a working implementation once the model had enough evidence to reason over.

Where GPT-5.5 actually changed my workflow

Across these tests, GPT-5.5 consistently performed best on difficult engineering work that had four ingredients: large context, available tools, enough time to iterate, and a clear acceptance check. The subtraction app demonstrated the opposite case. The model could absolutely do the work, but the extra reasoning depth did not create a noticeably better outcome relative to the waiting time and cost.

I now reach for GPT-5.5 Pro when the work involves migrations, bug backlogs, flaky tests, security remediation, or difficult debugging where I can feed the model evidence and independently verify the result. I still would not skip review, especially for production data handling, security-sensitive changes, or hardware control. The useful shift is not blind trust. It is that the model can now stay productive long enough on hard tasks that those review loops become worth running. See Automate Security Vulnerability Remediation with AI.

What is actually worth copying from these workflows

• The subtraction app reinforced that the largest reasoning model is often unnecessary for straightforward generation tasks, especially when speed matters more than exhaustive planning.
• The migration workflow is the strongest pattern in this episode: pair an autonomous coding agent with a reusable smoke-test system and a production-like validation environment so the model can detect and repair its own failures over long runs.
• The Bluetooth project showed that persistence plus evidence matters more than polished prompting. Once the model had packet captures, failed hypotheses, and enough room to iterate, it could reason through a narrow protocol problem that earlier systems never resolved.
• The common thread across all three tests was inspectability. GPT-5.5 became genuinely useful when I could validate outputs against real systems, real data, or observable device behavior instead of trusting the model's explanation of what it thought it had done.