Gavin Grant

The fix started with marking up a screenshot.

, a 3D modular home configurator I build on the side, and something at the bottom of the glass doors looked unfinished. A pale strip ran along the floor where the doors stand, and a real house would have a sill there. 

So I took a screenshot, marked the spot in red, and sent Claude Code a short prompt:

A few minutes later, every story's glass had a dark sill at its foot, flush with the finished floor.

That loop of a screenshot, a red mark and one sentence did more of the design work on ModHomes this fall than anything I typed into an editor. This post covers how the loop works, four real examples, and the decision hidden under each one. You don't need to write code to follow along. If you can circle something on a screenshot, you can run this loop.

ModHomes comes out of two jobs I had before I wrote software. From 2004 to 2006, I was a project architect at 

. From 2015 to 2018, I was a sales manager at Connect Homes, where I gave demos to prospective clients and evaluated whether a site could take modules delivered by crane, and whether there was access to get them there. Both companies built homes from steel-framed modules 8 feet wide and 40 feet long.

ModHomes puts that system in a browser. You pick one of eight models, from a single 320-square-foot module up to eight modules across two stories (2,560 square feet), orbit it from outside, change the finishes, and walk through it in first person. The landing page even assembles a home on its steel frame, the way modules come together on site.

I built the first version by hand over several months in 2022 and 2023: 64 commits, homes made of simple boxes, and a color picker. Then it sat untouched for three years. In late October 2026, about six weeks after I wrote about 

, I picked it back up. In four days I shipped 36 commits: a first-person walk-through, an open stair, kitchens and baths, finish pickers, and that assembly animation.

I've made the longer argument for why an architecture background carries over to frontend work in 

Why Architects Make Great Frontend Engineers

. This post is about one habit I brought with me.

Architects have marked up drawings in red for as long as there have been drawings. A redline does two jobs at once: the mark says 

. A drafter can act on it without a meeting.

That turns out to be exactly what an AI coding tool needs. Here's the loop I settled into:

 about what should change, with a dimension if one matters.

Claude Code makes the change and checks its own work.

 It opens the app in its own browser, takes screenshots, and samples pixel colors when color is the point.

The reason it works is that words are bad at 

. "The bottom of the doors" could mean the frame, the glass, the floor or the beam. In a 3D scene seen from an angle, a red mark settles it, which frees the sentence to describe the change.
Not every request needs a red mark, though. Over those four days I ended up with three tools, each for a different kind of request:

: what should change, or what a user should be able to do.

1. A sill that became part of a trim system

The sill wasn't the first dark trim I'd redlined. A day earlier, I'd drawn a red line between the two stories of a two-story home and asked:

So by the time the sill went in, the house had a dark header above the doors, a dark band between the floors and dark sills, all in the same color. Looking at it, I realized the configurator only let people change the siding colors. The frames around the glass were fixed.

This time there was nothing to circle. It was a product decision, so I wrote it as one:

Even here, there was a red mark. I'd put arrows on four colors in a screenshot of 

, a maker of aluminum sliding glass doors, so the options are real frame finishes. "Siding" became "Panels" a few minutes later.

 the panel color sets the overall look of a home. The trim gives people an accent color, which is where much of a modern house's character comes from. To make that one choice, the code needed a new concept. The door frames, the header, the floor bands and the sills had each been colored on their own, and now they're all "trim," set by one swatch.

That's a useful pattern for anyone on a team to recognize. When several things on screen always change together, they're probably one thing that hasn't been named yet.

The two-module homes have a small bath and closet tucked against the glass doors. That left two panes of glass with the back of a bathroom wall right behind them, which no architect would draw. I marked the panes in a screenshot and wrote:

 the easy fix would have been "make panes 4 and 5 wood." Instead, every pane now has an infill, either glass or siding, and a room says which panes it's built against. Any future room that ends up against the glass gets siding automatically.

That's the difference between a patch and a rule. One-off fixes pile up, and rules keep working as the product grows.

3. "Match the wall tile" meant drawing it darker

This is the one where I mostly stepped back. The floor textures were ones I'd picked three years earlier, and I wanted better ones:

Claude found free (CC0) replacements from ambientCG, a warm gray concrete and a neutral loop carpet, and tiled them across the floor instead of stretching one image over 40 feet. Then I asked for tile floors in the kitchens and baths that matched the wall tile.

Matching turned out to be harder than it sounds. The scene lights the floor from above much more strongly than it lights the walls, and the sky reflects in a shiny floor. Using the wall tile's exact color made the floor tile look nearly white next to the backsplash.

How Claude got there is the part I hadn't asked for. It rendered the kitchen, sampled pixel colors from the floor and the wall in its own screenshots, and adjusted until they matched. To 

 like the same tile, the floor tile is drawn at 40% of the wall tile's brightness and made less reflective.

The decision underneath, and the lesson for the whole team:

 a color value in a design spec doesn't survive rendering unchanged. Lighting and reflections sit between the spec and the screen. When something "looks wrong," measure what's on screen instead of re-checking the spec.

4. When a mark isn't enough, give it a number

Some problems don't show up in a screenshot, because the problem 

 where the camera sits. The first-person walk-through felt as if I were crouching. Instead of guessing, I asked for the current number first:

It was 3.95 feet, closer to a seated eye level than a standing one. My reply:

I used the same move on the steel columns: "They look a little thick. Let me know their dimensions then I'll tell you what we should reduce them to." They went to 5 inches square, then 4, with a 2-inch gap between neighboring posts. The stair worked the same way. I asked to "narrow the stair to be 3'-6" wide," add "a 42" high wall around the 3 sides of the stair opening," and later, "Can you move the cables in the stair railings up 1"?" Claude added a test that locks in that new cable height.

 ask for the current number before you give a new one. It turns "this feels off" into a measurable change. Use your field's own vocabulary, too. I asked for a "reveal that's 2" deep and 1" wide" between the floors, and for a "low slope hip roof" whose ridge sits level with the parapets. Words like that mean exactly one thing to an architect, and they meant exactly one thing to Claude. A test then writes the decision down, so that the next change, made by me or by an AI, can't quietly undo it.

Claude's half of the loop, and its limits

The part of the loop I didn't expect was Claude reviewing its own work. Before I looked at a change, it had usually opened the app, taken screenshots and checked the result against what I'd asked for.

That self-review isn't a substitute for mine, though.

 A change Claude made so the model wouldn't reload when you switched floors caused the finishes to render too light some of the time. I caught it and sent a screenshot: "There is a bug now where the floor materials sometimes render too light." It found the cause, a color setting applied too late when textures were preloaded to the graphics card, and fixed it in about ten lines. It also pointed out that its own earlier test screenshot had already shown the pale floor and it had missed it.

 The spinning model previews on the landing page shook up and down when I scrolled on my iPhone, because phones scroll ahead of rendering and the models trailed their cards by a frame. That only showed up on a real device.

 "Colour" and "centre" crept into code comments and commit messages until I asked it to "spell color like color and not colour," and now it's a standing rule.

 It can match a color I describe. It can't tell me which color is right. This will improve over time, but ultimately you are the tastemaker.

In those four days, two commits in the history don't have Claude on them: the footer copy and a lighter weight for the model names on the landing page. Words and type were the things I wanted my own hands on.

The bigger thing that stayed mine was deciding what to mark. Every example in this post started with me noticing something: a missing sill, glass in front of a wall, a floor that read as the wrong material, a camera at seated height. Claude was fast and careful at fixing things. Deciding what needed fixing, and why, was still the job.

You don't need to be an engineer to run this loop, and that's the point. A designer or PM can redline a staging site as easily as I redlined ModHomes.

 Say what a user should be able to do, not just what to change.

Ask for the current number before giving a new one. 

Understand the current conditions, then provide an exact response to that.

 and write the decision down in a test or a commit message.

Redlines were how architects provided feedback to colleagues. AI is now my colleague, and the redline still works. What carries over isn't the drawing tool. It's knowing what to mark.

, and if you'd like more notes like this one, 