Got the roleplay working inside another feature end to end, then spent a long session fixing a fiddly read-only preview.

The problem

Embedding the existing roleplay editor read-only inside a different page surfaced a string of layout bugs: an empty canvas, an expand button that did nothing, panels that felt glued to the canvas, and editable-looking controls in a read-only view.

What I pushed back on

The biggest correction: Claude had built the settings panels inside the editor component; I said they belong to the host page instead, and that one call explained a whole cluster of symptoms. When it kept making confident styling tweaks that did not work, I told it to stop and reassess rather than keep guessing.

What Claude pushed back on

Once I told it to stop guessing, Claude found the real cause of the empty canvas: a height that collapsed to zero when the component was embedded in a different layout. The fix let height flow naturally instead of relying on percentages.

Learning

Decide which component owns a piece of UI before worrying about its layout: a panel that belongs to the host page should live in the host, or you inherit all of the reused child's coupling. And stop guessing, pause, reassess is usually faster than another confident tweak.

Rebuilt how roleplay scenarios are generated, moving from one slow all-at-once AI call to a step-by-step process with live progress and a stop button.

The problem

Generating a whole branching scenario in one AI call timed out after four minutes and left a useless failed state, and meanwhile I just stared at a blank overlay for a minute or two with no sign anything was happening.

What I pushed back on

I turned down a quick 'raise the timeout' band-aid because it would not have shown any progress, and went straight to the proper rebuild. I also insisted on showing the scenario fill in piece by piece, because that is what I had actually asked for.

Learning

A timeout failure and a show me progress request often point at the same fix. Doing the work in smaller pieces both removes the timeout and gives you natural checkpoints to show progress. When two different problems point at the same change, that change is probably worth doing.

A long session spent mostly rescuing the previous day's work, where a batch of changes shipped quickly turned out to be full of small bugs.

The problem

A batch of features Claude had shipped passed its code checks but had never actually been clicked through in the browser. Each click surfaced a different small bug: wrong addresses, buttons that looked like they did nothing, mismatched colours, broken styling.

What I pushed back on

I told Claude bluntly that the previous day's batch was half-baked, too many things rushed at once to do any of them properly. That was accurate. It had been treating a clean code check as a green light, when a feature is not done until you have actually clicked it in the real screen.

Learning

Shipping fast is not the same as shipping more. The work I rushed all had bugs that surfaced the moment anyone used it, and the cleanups took longer than careful first-pass work would have. A passing build is not a finished feature.

Tore down the previous day's image feature in Olympus and rebuilt it as a simpler, clearer version.

The problem

The first version assumed admins already knew the exact wording to type. They do not; they have example images and want the system to work out the style for them. The feature had also taken on work that belonged in a separate shared service, and a few settings were in the wrong place.

What I pushed back on

I kept cutting the feature back to the one job it should do, and pushed the work it should not own onto the shared service. When the part that actually makes the images was not built yet, I asked for a clear 'not ready yet' message rather than faking it with dummy results. And I redesigned the size picker around shapes people recognise ('Square', 'Portrait') instead of platform names.

What Claude pushed back on

Claude pointed out a real limit on the image sizes the model can produce, and added a required field to a table that already had data using a safe, step-by-step approach, so none of the existing rows broke.

Learning

Name things the way people use them, not the way they are built: a picker of shapes beats one of platform names, because the same image ends up everywhere. And when part of a system is not built yet, a clear 'not ready' message is more honest than faking it with dummy data, which tends to hide real problems and stick around too long.

A rapid polish pass on the roleplay builder, comparing the live screen side by side with the design and fixing what did not match.

The problem

The code built cleanly and matched the spec, but in the browser it looked visibly less polished than the design: fuzzy text, a slider stuck at halfway, a menu cropped on one side, connector dots in the wrong place.

What I pushed back on

I treated the broken slider as a real bug rather than a minor visual nit, and kept sending close-up screenshots until each thing actually matched, instead of accepting close enough.

What Claude pushed back on

Claude traced each problem to its real cause rather than papering over it, for example measuring the actual page layout instead of guessing pixel positions, and degrading gracefully when data was missing.

Learning

A green build is not evidence that the screen looks right. Every real bug here was correct in code but visibly broken in the browser. Ship to a real URL early, screenshot it, and compare side by side.

Shipped a batch of platform-hardening work, including tightening how an internal service was exposed to the public internet.

The problem

An internal service was reachable from the public internet and being probed by automated scanners, there was still no per-customer cost record for billing, and trainers had no way to fix one bad day in a plan short of redoing the whole thing.

What I pushed back on

When Claude claimed the scanner noise had dropped to zero, I asked sharper questions; it widened the time window and admitted the quick fix had not actually worked for that scanner. It had also been reading the wrong service's logs until I questioned it.

What Claude pushed back on

Claude argued against putting a heavy web firewall on the new internal-only service. Once you remove the untrusted public surface, that firewall is spend for negligible value, and the right defence at that layer is network rules instead.

Learning

Any public hostname that resolves to your infrastructure ends up on automated target lists within hours. Quick fixes that only block crude scanners do not stop ones that look up your hostname directly. The durable fix is taking the hostname off the public internet.

Made long training-campaign generation reliable, after a big campaign kept failing partway through.

The problem

Generating a 45-day campaign from a 90-page document kept failing. The database ran out of connections, a timeout had no retry, the time estimate was wildly optimistic, and the AI was writing questions about the table of contents instead of the material.

What I pushed back on

Claude proposed a database setting I flagged as risky on shared infrastructure, so I had it audit the real usage data first, and we shipped a far more conservative number. I also corrected its over-optimistic time estimate to a simple rule of thumb that matched reality.

What Claude pushed back on

Claude spotted a fully built cost-tracking service that was never actually being called, meaning there was no per-customer spend record, and flagged it as a launch blocker.

Learning

Changes to shared infrastructure need an audit step before the change, not after. Conservative numbers backed by real usage data beat round numbers picked on intuition every time.

Built a participant feedback form, then chased a mobile video-upload bug where uploads kept silently failing on weak connections.

The problem

Feedback videos were sent through a long chain of servers before reaching storage, giving the upload four places to fail on a flaky mobile network, and when it failed the screen just silently reset so people had no idea what happened.

What I pushed back on

When the proposed fix was to tune one server's settings, I checked whether that file was even the one used in production. It was not, which killed a whole branch of false confidence. I also pushed for a visible progress bar and a clear confirmation rather than a silent state change.

What Claude pushed back on

Claude argued the real fix was structural: upload directly from the browser to storage, removing every middle server as a possible failure point, rather than tuning any single one of them.

Learning

A chain of servers is a chain of places to fail. Sometimes the right debugging move is to delete the chain rather than work out which link is breaking. Once that frame clicked, the fix wrote itself.

Redesigned the roleplay scenario builder around a single clear list of outcomes per turn, replacing a confusing two-part form.

The problem

The old builder split each turn into two overlapping sections, so it was unclear which one meant a wrong answer, and the whole scenario sprawled open at once and became unreadable.

What I pushed back on

I split the work into smaller stages rather than shipping it all in one go, and sent design screenshots even though the written spec looked complete, which caught several missing details before they were built.

What Claude pushed back on

Claude found the cause of a bug that was silently flipping AI-generated scenarios back to manual whenever the author touched anything, and quietly repaired rows that had already been corrupted.

Learning

Shipping in small, independently deployable stages is worth the extra friction, because any one piece can be rolled back on its own. And sending screenshots at planning time costs minutes but saves hours of rework.

Built a shared library of reusable image styles for Olympus, the admin tool behind Frontlyne, that the apps can draw from, and spent most of the session cutting the plan down to what we actually needed.

The problem

There was no shared set of visual styles for the apps to reuse, so each was on its own. We wanted one catalogue everything could pull from. The first plan tried to do far more than that.

What I pushed back on

My main job turned out to be saying 'no, smaller'. I kept cutting the plan back to the one thing that mattered, and insisted that unfinished work stay hidden until it's deliberately published.

What Claude pushed back on

Claude caught a few things I'd have missed, including a warning, right after we shipped, that one button wouldn't work yet because a setting hadn't been switched on in the live system.

Learning

The most useful thing I did all session wasn't writing code. It was deciding what not to build. A good tool will build whatever you let it; the real skill is restraint.