§ 00 / Philosophy

How engineers work with AI in 2026.

In 2025, software engineering hiring changed permanently. Companies no longer expect you to write code from scratch — they expect you to ship features using AI assistants, and they're evaluating how well you do it. Junior is the new mid-level. The bar moved, and AI fluency is what closed the gap.

The Sage Owl

“Plan before you prompt. Read every diff. The tool isn't magic — you are.”

§ 01 / Why this page exists

Most candidates use AI assistants like a smarter Stack Overflow — paste a question, copy an answer, modify it, run it. That worked in college. It fails in interviews and on the job.

One OwlHub student failed an interview last month because they used Claude Code as a chat assistant — typing prompts one at a time, letting it code without a spec, without a plan, without reviewing each task — when the interviewer expected them to use it as a code assistant: writing the spec, decomposing the work, reviewing each diff. Same tool. Completely different skill.

SPARC is the workflow OwlHub teaches to close that gap. It's how senior engineers actually work with AI assistants, named so you can articulate it in interviews and applied so you build the muscle memory before you need it.

The Promise

When a hiring manager asks how you work with AI, you should be able to answer cleanly, in your own words, without hand-waving.

§ 02 / What SPARC stands for
iterate until review passesonce per featureper taskSSpecPPlanAActRReviewCCommit

Each phase produces an artifact. The artifacts are how you prove — to yourself, to your reviewer, to a future interviewer — that you actually did the work, instead of letting an AI sprawl through your codebase unsupervised.

Inspired by AWS's AI Development Life Cycle (AI-DLC) — the methodology Amazon teaches its engineers for AI-assisted development.

§ 03 / The five phases, in detail
S
Phase 01
Spec
req.md

Define what you're building before you build it.

Capture what, why, in-scope, out-of-scope, assumptions, success criteria. Use the assistant in plan mode here — push back when its suggestions go beyond what you actually need. You are the architect; it is the sounding board. Create a req.md file in your repo's sparc/ folder.

Doing it well

A spec someone else could read and ship the feature from, without asking you questions.

Doing it wrong

A two-line description that hides assumptions. You'll discover them during Act, when they're expensive to fix.

P
Phase 02
Plan
tasks.md

Decompose the work into reviewable tasks.

Take req.md and produce tasks.md. Each task: small enough to review in one sitting, independently testable, dependency-aware, with explicit acceptance criteria. Let the assistant decompose; you validate. Create a tasks.md file in your repo's sparc/ folder.

Doing it well

A tasks.md you could hand to another developer and they could ship the feature.

Doing it wrong

One giant task labeled “implement the feature” — you didn't plan, you renamed the spec.

A
Phase 03
Act
code + tests

Implement one task at a time, in code-assistant mode.

Instruct the assistant to implement THAT task only. Be explicit about scope. The assistant edits files directly, runs tests, iterates on failures — and stops when the task is complete. No “while I'm at it”.

Doing it well

The task's diff is focused, the assistant stayed in scope, tests are passing.

Doing it wrong

The diff touches unrelated files, tests were rewritten to make them pass, or you're not sure exactly what changed.

R
Phase 04
Review & Verify
feedback-task-N.md

Read the diff. Run the tests. Manually verify.

This is the phase that separates code-assistant-fluent engineers from chat-assistant-stuck ones. Read the diff (don't skim). Run the tests yourself. Probe edges the tests don't cover. Loop back to Act with specific, scoped feedback until the task is genuinely done. Create a feedback-task-N.md file in your repo's sparc/ folder for each task you complete.

Doing it well

Specific findings. Real issues caught. The assistant got better feedback because of your review.

Doing it wrong

“LGTM, tests pass.” That's a rubber stamp — reviewers spot it instantly.

C
Phase 05
Commit
git log

Mark the task done. Commit cleanly. Move on.

Meaningful commit message describing what changed and why. Update tasks.md. Each commit is a checkpoint where the work is genuinely done — no batched commits, no “I'll review at the end”.

Doing it well

Commit history reads like a story — someone could git log and understand how the feature was built.

Doing it wrong

One commit at the end called “implemented feature”. Reviewers can't tell what was reviewed and what was rushed.

§ 04 / What your GitHub repo should look like when you submit

Every hunt from Hunt 1 onward expects a sparc/ folder at the root of your repo, containing your workflow artifacts. These files live at the root because you should be proud of them — your AI Sherpa reviewer reads them as part of your hunt submission.

your-hunt-repo/
├── sparc/
    ├── req.md              # Spec phase output
    ├── tasks.md            # Plan phase output
    ├── feedback-task-1.md  # Review of task 1
    ├── feedback-task-2.md
    └── feedback-task-N.md
├── src/                    # your code
└── tests/                  # your tests

The numbering of feedback-task-N.md matches the task numbers in tasks.md exactly. Tasks 1, 2, 3 → feedback files 1, 2, 3.

What a real one looks like

Here's a real req.md from a Hunt 10 student adding a health-check endpoint to the clinic API. Roughly 10 minutes of thinking. Look how much it saves you downstream.

sparc/req.mdHunt 10 · clinic-api
# /health endpoint

## What
Add a GET /health endpoint that returns service status.

## Why
The ECS load balancer needs it to decide if instances are healthy.
Right now it's defaulting to "always pass" — masking real outages.

## In scope
- Returns { status: "ok", timestamp: ISO-8601 }
- 200 on success, 503 if the Postgres connection is unreachable
- No authentication required

## Out of scope
- Detailed dependency checks (downstream services, Redis, etc)
- Spring Boot Actuator — overkill for this hunt, ~3MB of deps

## Assumptions
- DataSource bean is already wired (Hunt 8)
- The endpoint won't be rate-limited (not a hot path)

## Success criteria
- curl /health returns the expected JSON
- During a simulated Postgres outage, returns 503 within 2s
- One JUnit test per success/failure path
§ 05 / Code-assistant vs chat-assistant mode

Read this twice. It's the most common failure pattern we see.

Chat-assistant mode · the wrong way

Ask. Code. Ask. Code. Repeat.

  • · No spec. No plan. Just prompts.
  • · One change, then the next, then the next.
  • · Sprawling diffs. Files touched that didn't need to be.
  • · Tokens burned. Tests reviewed by no one.
Code-assistant mode · the right way

Spec. Plan. Task. Review. Commit.

  • · You write the spec. The assistant validates it.
  • · You decompose into tasks. The assistant ships one at a time.
  • · You read every diff before the next task starts.
  • · Focused changes. Fewer tokens. Code you can defend.

The difference shows up in interviews instantly. An interviewer who watches you fire off prompt after prompt with no plan and no review has already made up their mind. An interviewer who watches you write the spec, decompose the work, and read every diff before moving on is watching a senior engineer work — regardless of your years of experience.

§ 06 / When SPARC applies — and when it doesn't
Default

Every hunt from Hunt 1 onward

Full SPARC. Artifacts in sparc/. The reviewer reads them.

Compress

Tiny edits, bug fixes with clear root cause

Spec might be one sentence. Plan might be one task. Review still matters.

Compress

Exploratory prototyping

Lighter spec, looser plan, more iteration — as long as you know you're prototyping.

Knowing when to compress phases is a higher-order skill. For now, run full SPARC on every hunt — that's how the muscle memory builds.

§ 07 / Self-check before Hunt 1

Answer these for yourself. Not on a form. In your own head, or in a notebook. If you can answer them clearly, you're ready for Hunt 1.

  1. 01

    In your own words, why is reviewing the diff yourself more important than the assistant saying “tests pass”?

  2. 02

    What's the actual difference between using an AI as a chat assistant vs. a code assistant?

  3. 03

    When would you compress the Spec phase to a single paragraph? When would you write a full document?

  4. 04

    Why is 100% code coverage the bar at companies like AWS — and what does hitting it actually require?

  5. 05

    If you only had time to do one phase of SPARC well, which would it be? Why?

End of document

SPARC maps closely onto AWS's AI-DLC methodology, Kiro's spec-driven mode, and how the Claude Code team recommends working with their own tool. We've named it and given it five phases so you can articulate it cleanly in an interview without hand-waving.

Now go write your req.md.