I recently used Claude Code to add browser-framed project screenshots to the portfolio section of this site. The feature itself was straightforward — screenshot each project, wrap it in a CSS-only simulated browser window, drop it into each work card.
It took about an hour. Most of that time was debugging two problems I’d never seen before and wouldn’t have known to look for.
The Setup
My site is built with Astro and uses a global.css file for all styles. CSS is loaded as a static asset via a <link> tag. Simple enough.
The agent wrote the new CSS, added it to the stylesheet, updated the HTML, ran a build — green. Opened the browser: broken. The browser frame rendered as a column of raw text, no flexbox, no screenshot image visible.
Standard debugging instinct: check the CSS. The rules were there in the source file. The HTML looked right. Everything seemed fine.
Bug #1: The Dead Source File
After some digging — inspecting the built output, tracing the <link> tag back to its source — we found it:
There were two global.css files.
src/styles/global.css— imported inBase.astrowithimport "../styles/global.css", except that line was commented outpublic/styles/global.css— the actual file being served, referenced viahref="/styles/global.css"
The agent had been editing src/styles/global.css. The browser was loading public/styles/global.css. Every change had gone into a file the site never reads.
This is not a bug you’d find by reading the code. You’d have to trace the asset pipeline from the HTML <link> tag back to its physical source — something that’s not obvious when the file paths look nearly identical and both files actually exist. I’d set this up at some point (probably during an earlier refactor) and completely forgotten about it.
The fix was to edit the correct file. But finding it required digging into the build output and comparing file sizes between source and compiled output, which is not a debugging path I’d have taken without the agent suggesting it.
Bug #2: The Silent Em Dash
Once we were editing the right file, the layout still wasn’t working. The browser chrome rendered, but with no flexbox — items stacking vertically instead of in a row.
Again: source looked correct. HTML was fine. Built output was the problem.
The agent checked the compiled dist/styles/global.css directly and found the CSS was being truncated — everything after .case-study-section p was dropped. The @playform/compress integration (which minifies CSS via CSSO) was silently stopping mid-file.
The culprit: a comment.
/* Browser frame — GTK/Adwaita dark style */That — is an em dash. A multi-byte UTF-8 character. The CSS minifier choked on it and dropped everything from that point forward — without logging an error, without failing the build, without any indication something had gone wrong. The build reported success. The compression stats showed a reduction. Nothing flagged it.
The fix was one character: replace — with -.
But finding it required:
- Noticing the built CSS file was shorter than expected
- Checking what the last rule in the compiled output was
- Scanning the source CSS for non-ASCII bytes around that boundary
- Connecting a non-printing character in a comment to silent output truncation
That’s a debugging path I have never walked before and would not have known to walk.
What Made These Findable
Neither of these bugs would have surfaced through normal development. The site built cleanly. No errors, no warnings. If I’d been working alone, I’d probably have assumed a browser caching issue, hard-refreshed a few times, and eventually noticed the CSS rules weren’t in the output — but getting from “rules missing from output” to “wrong source file” or “em dash in comment” is not obvious.
What helped:
Systematic output inspection. The agent compared source file size to compiled file size, then compared what rules existed in both. That’s not something I’d do instinctively — I’d start with DevTools and work backwards from the rendered styles.
Checking intermediate artifacts. The build pipeline has multiple stages: Astro compiles, Vite bundles, @playform/compress post-processes. Checking each stage’s output independently is what isolated the CSSO truncation. I’d typically treat the build as a black box unless it throws an error.
Not assuming the obvious path. When the CSS wasn’t working, the first assumption was a browser cache issue (it was, partially). The second was a CSS specificity problem. The agent went straight to “let’s check what’s actually in the built output” — which is the right instinct when you’ve already confirmed the source looks correct.
The Broader Pattern
Working with an AI coding agent doesn’t just change how fast you write code. It changes what problems surface and which debugging paths get explored.
The agent doesn’t have the same cognitive shortcuts I do. It doesn’t assume that because the build succeeded, the output is correct. It doesn’t assume that src/styles/global.css and public/styles/global.css are the same file because they have the same name. It checks the actual artifacts.
That’s useful in a way that’s different from “it writes code faster.” It’s useful because it catches a class of environmental and toolchain problems that humans tend to skip past — because we’ve never been burned by them before and don’t know to look.
I now know to look.