Vibe Check:
GPT-5.5 Has It All

Our coding testers came away with different impressions about GPT-5.5’s engineering strength depending on how much structure the task provided. Dan’s Senior Engineer Benchmark tested backend-heavy architectural rewriting with an explicit plan. Naveen tested technical vibe coding inside long Codex loops. Kieran’s LFG benchmark tested product-forward engineering with clear prompts, technical planning, and review. Mike tested the purest no-plan case: a one-shot vibe coding prompt meant to simulate a novice user.

GPT-5.5 looked best when the task gave it structure: a plan, a live product loop, or a harness that forced planning and review. In those settings, it was remarkably assertive. It carried plans through, deleted code, resisted ineffectual patches, and kept moving toward the target architecture or product shape.

Rewrites vibe coded codebases (almost) like a senior engineer

Most coding benchmarks test whether a model can solve a clean, bounded problem: fix a bug, pass a test, implement a feature, or complete a well-specified GitHub issue. Those benchmarks don’t match the reality of using AI on messy production code.

Dan’s new Senior Engineer Benchmark poses a harder question: If you give a model a messily coded codebase and ask it to clean the whole thing up, can it do the job the way a senior engineer would?

In our testing, GPT-5.5 consistently identified the right principles for a refactor and carried them through, including deleting thousands of lines of old code, over many hours of work. Other models, including Opus 4.7, identified similar principles but kept patching what was already there instead of rewriting or removing it.

The difference seems to be the plan. GPT-5.5’s own plan had the right concepts and made sense to a human, but Opus 4.7’s plan was terser and more engineering-spec-like: Here is exactly what I want you to do. That style gave GPT-5.5 something better to execute against.

Once GPT-5.5 had a great plan, it did something we haven’t seen from most models: it stayed focused. It stuck to the goal of the rewrite, deleted a bunch of code, ignored the way the codebase currently worked, and rebuilt toward the intended architecture from first principles. Opus 4.7 started toward the big rewrite, then nibbled at the edges rather than taking the full bite.

Holds a product thread together

GPT-5.5’s strongest coding advantage may be long-context product continuity—the ability to hold onto the objective across many rounds of feedback, checks, fixes, and direction changes without getting stuck making small, local changes that miss the larger goal.

The cleanest example was Dayline, a native iOS and Mac to-do app Naveen built in one long Codex thread, shaping the product as he went rather than starting from a polished plan. GPT-5.5 stayed oriented the whole time, tracking what Dayline was supposed to be across messy, imprecise feedback like “move this,” “the row interaction feels wrong,” and “keyboard focus needs to feel right.”

That is a different kind of coding win than a benchmark pass. Weaker models often lose the thread: they overcorrect to the most recent note, forget prior constraints, or treat each iteration like a separate task instead of one continuous product conversation. GPT-5.5 stayed in the loop. Naveen said this was the first app he’d built without looking at a single line of code.

LFG: Reliable at building, but wobbly on design

Kieran’s LFG benchmark tests full-product engineering—whether the model can build something that works, looks good, and feels coherent. Built around the /lfg command in Every’s compound engineering plugin, it uses clear product prompts plus a technical planning and review phase to test how much an engineering harness can improve the base prompt.

GPT-5.5’s planning and review time rose noticeably from GPT-5.4, and its functional output was strong. But LFG asks for the whole product to work and feel good, not just for the backend to be correct. Kieran’s read was that GPT-5.5 did well on non-Ruby backend work, but product engineers need the frontend, design, and language-specific implementation to hold together too.

On Rubber Duck, the hardest task—which asks the model to build a full e-commerce store with a custom product designer—it delivered deep functionality and a working build. Only about 40 percent of models we’ve tested have cleared this challenge.

Design was more uneven. On the landing page design benchmark, GPT-5.5 nailed some details: clean typography, solid buttons, and more original styling. But the page didn’t come together as a whole. “Some things are more structured, some things just don’t really make a lot of sense,” Kieran said. “The design, while being maybe less cliche and boring, also lacks coherence.”

The same pattern showed in Cozy Island, which asks the model to build an interactive 3D island scene in Three.js from scratch, including procedural geometry, animated water and birds, swaying trees, and an orbiting camera. GPT-5.5 added good micro-details: rocks, trees, smoke, gentle motion. But it got the land color wrong, and its bird and fish animations were weaker than Opus 4.7’s.

GPT-5.5 also cannot write Ruby, consistent with every model we’ve tested on this benchmark.

Less reliable for one-shot vibe coding

Mike’s coding test was intentionally a no-plan vibe coding prompt. He wanted to see what a novice user would get from a blank page, without knowing to ask for plan mode or steer the model through a structured loop. In that setup, Opus 4.7 still looked stronger.

The task was to build a Typeform-style app where users speak instead of type to fill in structured data. A successful version needed working OpenAI and Anthropic connectors and a passing test suite. The demo had to run.

Opus 4.7 delivered. The connectors worked, the tests passed, and Mike had something he could use. GPT-5.5 scaffolded a reasonable architecture, but used placeholder code instead of working integrations and did not get the test suite running.

The lesson seems to be about setup. GPT-5.5 can be very strong from scratch when the task unfolds inside an iterative loop, but Mike’s test shows the risk when the model has to infer the plan and ship the demo from one loose prompt. For novice-style vibe coding, Opus still has the edge.

GPT-5.5 is a better writer than we expected. Its writing is natural, accessible, and easy to read, but its real advantage is its grasp of structure. It tends to build clearer arguments than Opus, which makes its drafts easier to revise for publication. But it can still carry some AI tells: over-smoothed transitions, balanced constructions, and sentences that explain themselves a little too neatly.

Easier to keep reading

Mike preferred GPT-5.5’s writing overall. It felt more natural to him than Opus 4.7: easier to read, less showy, and more fully fleshed out. Opus 4.7 can say more in less space, which makes it effective for marketing copy or anything that needs to impress quickly. But it can also feel sparse: each line may be sharp, but the whole leaves you wanting more.

GPT-5.5 explains itself, moves cleanly between ideas, and feels better suited to broader audiences. On course curriculum and run-of-show tasks, it chose simpler topic titles and clear agendas—less clever than Opus, but easier to imagine sending to a broad audience.

Naveen saw the same thing in customer support writing. GPT-5.5 read Intercom conversations, existing documentation, prior replies, product context, and internal comments, then drafted customer replies that sounded close to how he would write. It picked up the appropriate posture: be direct, be honest, apologize when the bug is ours, do not over-explain, and be clear about the issue.

Its drafts are easier to revise

Katie has used Claude as her writing default for months, but GPT-5.5 was the first OpenAI model in a long time to make her reconsider. Its prose still needed cleanup, but the draft had the thing she cares about most: a clean argumentative spine.

In a Working Overtime introduction test, Katie asked GPT-5.5 and Opus 4.7 to draft the opening for a piece about failing OKRs and building an AI assistant to manage ongoing work. On first read, Opus looked more energetic, with livelier turns of phrase.

But with fresher eyes, GPT-5.5 produced the stronger draft. It moved more patiently from missed goals to the limits of to-do lists and then to the deeper problem of project coordination. It understood the shape of the essay better. The prose still had some AI smell, especially in its tidy correlative constructions and over-smoothed explanatory cadence. But those are easier problems to edit than a draft whose idea progression does not hold.

Turns transcripts into writing without trying too hard

One place GPT-5.5 surprised us was in how well it made dictated text feel like written text. Mike asked it to write in his style from an audio transcript, and it pulled in the right details at the right moments—and didn’t overdo human vocal tics. Claude, by contrast, sometimes shoves in too many “ums” and “ahs.”

GPT-5.5’s restraint helped here. In generating prose, it did not produce the catchiest titles or the best vibe-check quotes, but when the task was to sound like a person without caricaturing them, GPT-5.5 was impressively grounded.

GPT-5.5 is the better model for everyday writing like consulting reports, curricula, agendas, summaries, support replies, and broad-audience prose. It may also be the better first-draft partner for essays when structure matters most. Opus 4.7 still has an edge on punchy framing and catchier titles, but GPT-5.5 gives you cleaner material to work from.

GPT-5.5’s clearest advantage over Opus 4.7 is in practical knowledge work. It excels at tasks where you need to give order to messy inputs, like voice-dictated brainstorming sessions. It’s fast and less prone to overperforming. That makes it especially strong for dashboards, consulting documents, curricula, run-of-show plans, and turning transcripts into usable documentation.

It makes better dashboards

Mike Taylor’s biggest surprise was how well GPT-5.5 produced polished dashboards, with cleaner layouts and stronger visual presentation than Opus 4.7. This was unexpected because Opus 4.7’s launch story leaned heavily on improved vision, and in our testing it still wins on PowerPoint. But for dashboards, GPT-5.5 came out ahead.

Accessible, sometimes at the cost of insight

GPT-5.5’s outputs tend to be easier for broad audiences. On curriculum and planning tasks, it produced reassuringly simple structures that most people would understand quickly. Not every deliverable needs to be clever. Many need to be clear, politic, and easy to adopt.

But Opus 4.7 still finds sharper insights. In one task, Mike noted that Opus did a better job surfacing an audience-segmentation problem—which users the course was ready for and how to target the material to the right audience.

Worse at prompting than Claude

GPT-5.5 was weaker than Claude at generating exercises and prompts for Every consulting workshops. GPT-5.5 is good at making orderly deliverables, but less apt when the job is to create a tool or instruction to give to another model.

That is an important distinction for people who increasingly use models to build workflows. GPT-5.5 can help produce the artifact. Claude is still better at designing the instructions that produce the artifact.

Better for client-safe work

Across consulting tasks, GPT-5.5 felt more dependable. It chose straightforward course titles, simple agendas, and clean run-of-show structures. Opus 4.7 often took bigger swings, but those swings also created rough edges.

Mike’s summary: he would use Opus 4.7 if he wanted to impress a client with wit and had time to micromanage. He would use GPT-5.5 if he needed to get the job done without looking stupid because he was too busy to do the task himself. GPT-5.5 is less showy, but more professionally safe.