I did not land on this coding style by accident. It came from shipping too fast, missing layout bugs, trusting local assumptions, and getting vague feedback that did not map to exact fixes.

The process only started working when I split the work into two loops:

  1. A build loop with a GPT coding agent inside the repo.
  2. A review loop with an outside agent viewing the site through a local portal URL.

That separation measurably improved output quality. The builder optimized for implementation speed. The outside reviewer optimized for user-facing quality and clarity. The result was less guesswork and fewer “looks fine on my machine” mistakes.

Two-agent loop vs. single-agent session

AspectSingle-agent sessionTwo-agent loop (build + review)
PerspectiveOne viewpoint, anchored to author assumptionsBuilder + independent reviewer
Feedback sourceSource-level readingRendered, page-level observation
Blind spotsLayout and narrative issues often missedCaught by outside reviewer
Fix specificityVague (“improve the page”)Scoped (“fix overlap in breakpoint X”)
Regression riskHigher — no external gateLower — quality gate before close

This mirrors the separation of concerns recommended in Gatsby's testing and build workflow documentation and the role-split pattern described in OpenAI's GPT best practices guide.

Why this style works

Most solo development workflows collapse design, implementation, testing, and critique into one person and one perspective. That creates blind spots.

I needed a workflow where:

  • code gets written fast,
  • changes are visible in a real browser environment,
  • feedback comes from a second viewpoint that is not anchored to my assumptions,
  • and each critique translates into concrete edits.

That is why I use a two-agent loop instead of one long coding session.

The architecture of the workflow

Local Repo (Gatsby)
   |
   | 1) GPT coding agent edits code, content, layout
   v
Local Dev Server (localhost:8000)
   |
   | 2) Share read-only tunnel URL (passwordless dev portal)
   v
Outside reviewer agent opens real pages
   |
   | 3) Reviewer reports UX/content issues with specific examples
   v
GPT coding agent applies fixes + verifies build

The key is that the reviewer is not reading source first. It reviews rendered output like a user would. This is the same principle behind browser-based end-to-end testing tools like Cypress and Playwright, which assert against the rendered DOM rather than source files.

The build loop inside the repo

The GPT coding agent handles implementation end to end:

  • update MDX blog posts,
  • adjust CSS and layout,
  • normalize card structure,
  • standardize call-to-actions,
  • run build checks,
  • repeat until behavior is stable.

This works best when requests are concrete. Instead of “improve the page,” I use constraints like:

  • “do not remove words, only improve or add,”
  • “make every project card include a clear problem statement,”
  • “fix overlap in all breakpoints, not just desktop,”
  • “keep dev tooling scripts out of git via .gitignore.”

Those constraints force deterministic edits and reduce drift.

The outside feedback loop through the portal

The external reviewer agent accesses the local site through the shared dev portal URL and reports what is wrong in the rendered UI.

That caught issues local implementation missed, including:

  • card overlaps caused by uneven heights,
  • inconsistent card action buttons,
  • impact statements that read like process notes instead of user outcomes,
  • sections that were technically correct but hard to scan.

Because this feedback came from page-level observation, not source-level assumption, it was much more useful.

The review format that produced real fixes

I stopped asking for generic “thoughts” and asked for structured findings:

  1. What is broken right now.
  2. Where it appears (page + section).
  3. Why it hurts readability or trust.
  4. What specific change would resolve it.

This made the feedback directly actionable.

A good example is layout overlap. “Cards feel messy” is not enough. “Card A spills over Card B when content expands and grid rows do not auto-size” is fixable.

Quality gates before calling a change done

I now require these checks before closing a task:

  • local build passes,
  • key pages render without overlap or clipping,
  • links and buttons are consistent across cards,
  • content intros lead with the user problem, not a stack listing,
  • related-post and internal links are present where relevant,
  • dev-only agent tooling stays ignored in git.

This is not enterprise bureaucracy. It is a lightweight release checklist that prevents repeat regressions. The practice of gating releases behind a checklist is recommended in Google's testing documentation and aligns with the Web.dev quality checklist.

What changed in my output quality

This style improved three things in practice:

  1. Speed with control. Implementation is still fast because the GPT agent handles execution, but quality is gated by external review.
  2. Higher-signal feedback. Outside review exposed issues that code-only review missed, especially layout and narrative clarity.
  3. Better writing tone. Posts and project summaries shifted from generic AI phrasing to clearer first-person, outcome-driven language.

What agents consistently flag

After running this loop across dozens of changes, patterns emerged. The reviewer agent flags the same categories of issues over and over, and they map almost exactly to what a senior human reviewer would catch — but faster and without ego.

Naming. This is the most common flag. The agent catches vague variable and function names that describe the mechanism instead of the intent. A before/after from this very codebase:

const arr = posts.filter(p => p.node.frontmatter.tags.includes(tag))

became:

const postsWithTag = posts.filter(post =>
  post.node.frontmatter.tags.includes(tag)
)

The agent flagged arr as meaningless and p as too short to scan. The fix is trivial, but I would have skipped it in a solo session because the code worked.

Error handling. The agent consistently catches swallowed errors and missing fallbacks. It flagged this pattern in a Netlify function:

try {
  const data = await fetchProfile(id)
  return data
} catch (e) {
  return null
}

and recommended surfacing the error context instead of silently returning null, which made debugging a real outage two weeks later much faster. A human reviewer might have let this slide if they were in a hurry. The agent flags it every single time.

Comments. The agent catches comments that restate the code instead of explaining the why. It flagged // filter posts by tag above a line that literally filters posts by tag. That is noise. It pushed me toward comments that explain decisions — why a fallback exists, why a specific threshold was chosen — and to remove the rest.

How agent feedback differs from human code review

I have run both loops on the same changes, and the differences are consistent.

Human reviewers bring context the agent does not have. A human knows the business reason for a feature, remembers the last outage, and can say "we tried this approach six months ago and it broke the build." The agent has none of that. It evaluates the code in front of it, not the history behind it.

But the agent has advantages humans do not. It is patient. It will check every card on every breakpoint every time. A human reviewer checks the first three cards, assumes the rest are fine, and moves on. The agent flags card number eleven because its action button is misaligned. That is the kind of regression that ships to production when only humans review.

The agent also does not get tired or diplomatic. A human reviewer might soften feedback to avoid friction. The agent says "this heading is generic and does not communicate the value proposition" without worrying about my feelings. That bluntness produces better fixes, faster.

The best results came from using both. The agent catches the mechanical and structural issues. The human catches the strategic ones.

Whether the feedback actually improved the code

Yes, measurably. The most concrete proof is the test suite. Before I started the two-agent loop, the automated verification script had 180 assertions. After three months of build-review cycles, it has 234. Each round of external review surfaced an edge case or a consistency requirement that became a new assertion.

The Lighthouse scores tell the same story. Accessibility sat at 91 before the loop. It is 98 now, and the two-point gap is a single color-contrast warning on a themed demo page that I have not prioritized. Every other accessibility issue the agent flagged got fixed.

The feedback did not just make the code cleaner. It made the code more verifiable. That is the real win.

What to copy if you want the same workflow

If you want this exact style, copy this minimal sequence:

  1. Build locally with a coding agent that can edit files and run checks.
  2. Expose the local page through a safe dev portal URL for outside review.
  3. Ask the reviewer for structured findings, not vague opinions.
  4. Convert each finding into one scoped code or content change.
  5. Re-run checks and repeat until no critical UX issues remain.

The point is not “use more AI.” The point is role separation: one agent builds, another audits from the outside.

Delivery workflow checkpoint illustration for this section.

Closing

This process made my work more verifiable. It reduced hidden UI regressions, improved content readability, and produced cleaner delivery notes I can hand off without losing context.

The workflow is simple: build, expose, review, fix, verify. Repeated enough times, that becomes a coding style instead of a one-off experiment.

Proof this workflow exists

This site is the proof. The workflow described above is exactly how this portfolio was built and maintained:

Keep reading

References