Field notes · 2026Engineering intern · N5

The way I work
with an AI agent.
From ticket to backend.

I am an intern. The agent is fast. I am the judgement. This is the flow we share.

Tools in play
CursorClaude CodeFigma MCPJira MCPRepoMocks
01Wire the tools

Plug Figma and Jira straight into the editor.

Before a single line of code, the agent gets eyes and a memory. Figma MCP and Jira MCP load into Cursor or Claude Code. The model now reads tickets and frames the same way I do.

Figma MCPJira MCPCursorClaude Code
MCP · Connected
Figma● Live
Jira● Live
Repo● Live
Browser○ Idle
$ cursor mcp add figma --token=•••
$ cursor mcp add jira --site=n5.atlassian.net
→ 2 servers connected.
02Read the ticket. Read the code.

Fetch the ticket. Map it to what already exists.

I point the agent at the Jira ID and the repo. It pulls the ticket, walks the codebase, and tells me what is already in place and what is genuinely missing.

Prompt to agent
“Fetch JIRA-482. Cross-reference the current implementation in /apps/web. Tell me what is done, what is partial, what is absent.”
Jira MCPRepo
Jira · JIRA-482
In progress
StorySprint 14 · 5 pts
Account screen — wire profile and billing tabs
·Tabs: Profile · Billing · Sessions
·Re-use existing Form, Button, Card components
·No new API endpoints — use existing /account
!Agent flagged: Sessions list already shipped on dev.
03Audit the ask

Question the ticket. Ask for the dev URL.

Tickets drift. The agent reviews the request against reality and flags inconsistencies. I ask for the live dev URL so I can see the current state with my own eyes — not just through a model.

Prompt to agent
“Is this ticket still accurate given what we found? List anything already shipped on the dev URL that the ticket assumes is missing.”
Jira MCPBrowser
Audit · ticket vs reality
ShipSessions list — already on dev/staging.
BuildProfile form — fields incomplete.
BuildBilling tab — empty placeholder only.
VerifyNeed dev URL to confirm Sessions parity.
04Decompose the design

Hand over the Figma. Find the parts already built.

I send the frame. The agent identifies the screen, breaks it into components, and matches each one against the design system. Reuse first. New parts second. Nothing duplicated.

Prompt to agent
“This Figma frame is the Account screen. Decompose it. For each component, tell me whether it exists in /components, partially exists, or is new.”
Figma MCPRepo
Figma · Account.frame
ReuseHeader
ReuseTabs
ReuseForm
ReuseCard
NewBillingRow
NewPlanCTA
4 reused · 2 new67% reuse
05Plan before code

Generate the build plan. On paper. First.

No keystrokes yet. The agent produces a step-by-step plan — files, components, props, states. Cheap to read, cheap to throw away.

Claude Code
Build plan · v1
  1. 01Scaffold AccountPage with three tabs.
  2. 02Mount Profile form. Bind to fixtures.
  3. 03Drop Billing tab. Static plan card + history rows.
  4. 04Confirm Sessions list still passes (existing).
  5. 05Add empty + loading + error states.
  6. 06Add unit tests against fixtures.
06Cross-check

Diff the plan against the ticket. Read it myself.

The agent compares its own plan to the original ticket and lists gaps. Then I review. The model is fast. I am the judgement.

Jira MCPReviewer — me
Plan ↔ Ticket · diff
— Ticket asks: tabs, form, billing, sessions
— Plan covers: tabs, form, billing
+ Plan adds: empty/loading/error states
~ Sessions list omitted on purpose (already shipped)
Reviewer: approved with notes.
07Build, with handcuffs

Frontend only. Mock data only. No backend yet.

I tell the agent exactly what it cannot touch. It builds the full design against fixtures, so I can validate the surface before anything talks to a server.

Prompt to agent
“Build the screen end-to-end. Use mock data only. Do not modify the API layer. Do not call backend.”
Claude CodeMocks
Cursor · AccountPage.tsx
// mock data only — no backend touched
export function AccountPage() {
  const { profile, billing } = fixtures.account;
  return (
    <Tabs items={["Profile","Billing","Sessions"]}>
      <ProfileForm value={profile} />
      <BillingPanel data={billing} />
      <SessionsList /> {/* existing */}
    </Tabs>
  );
}
● mockno backend touched
08Wire the backend

Replace the mocks. One step. Then the next.

Frontend done. Now the agent lays out the backend swap as a checklist — endpoint by endpoint, hook by hook. I review each step. I test each step. The flow ends where the product begins.

Prompt to agent
“List the steps to replace each mock with the real backend. One commit per step. I will review and test before you move on.”
Claude CodeBackendReviewer — me
Backend swap · checklist
GET /api/account/profile
Tested
PATCH /api/account/profile
Review
GET /api/account/billing
Queued
POST /api/account/billing/portal
Queued
Six rules the flow runs on

The agent is fast.
I am the judgement.

01

Context first

The model sees what I see. Figma, Jira, the repo.

02

Question the brief

Tickets get stale. Verify before you build.

03

Plan before keystrokes

A wrong plan caught early costs nothing.

04

Build with handcuffs

Constrain scope. Mock data first. Backend second.

05

Step by step at the seams

Frontend → backend transitions get tested one swap at a time.

06

I am the judgement

The agent is fast. I am responsible.

Eight steps.
One loop.
No keystrokes wasted.

This is not a hack. It is a discipline. The agent reads, plans and writes. I question, review and ship. The flow stays the same whether the ticket is a bug or a feature.