GPT-5 Changed How I am Learning to Code

I've been learning Next.js for the past year and here's what I discovered: GPT-5-mini at $0.25 per million input tokens/$2 per million output is criminally underrated for web development. While everyone's obsessing over the flagship model, I'm building production apps with the "budget" versions.

GPT-5's architecture lets you match the model to the task—and most web dev tasks don't need maximum firepower.

The Three Models Nobody Explains Properly

OpenAI uses three GPT-5 variants in the API:

• GPT-5 ($1.25/1M input, $10/1M output) - The flagship

• GPT-5-mini ($0.25/1M input, $2/1M output) - 80% cheaper

• GPT-5-nano ($0.05/1M input, $0.40/1M output) - 96% cheaper

Each model supports four reasoning levels: minimal, low, medium, and high. This is where it gets interesting for us solo devs.

My Learning Setup

I use different models strategically throughout my day:

GPT-5-nano with high reasoning - My default for:

• Component boilerplate

• Tailwind styling tweaks

• Quick TypeScript fixes

GPT-5-mini with high reasoning - When I need:

• Complex state management solutions

• Database schema design

• Authentication flow implementation

• Performance debugging

• API routes

GPT-5 with high reasoning - Reserved for:

• Architecture decisions

• Complex algorithm implementation

• Multi-file refactors

• Learning new concepts deeply

The Study Mode

Using GPT-5's verbosity parameter as a teaching tool changed my learning game.

When learning a new Next.js concept, I prompt like this:

ROLE: You are a Next.js instructor teaching server components

TASK: Explain the execution flow

STUDY MODE:

reasoning effort: "high"- Think deeply about the concept

verbosity: "high"- Explain thoroughly

WORK MODE:

reasoning_effort: "high"- Still think deeply

verbosity: "low" - Just give me the code

[paste code here]

This separation between learning and doing has accelerated my progress dramatically. High verbosity for understanding, low/medium verbosity for shipping.

Prompt Template for Web Dev

Here’s my template for Next.js development:

“Developer: <system_role>

You are Principal Engineer & Full-Stack Architect for a greenfield web app.

Ship production-ready code with zero fluff, impeccable structure, and strong defaults.

</system_role>

<stack>

Framework: Next.js 15 (App Router, RSC, Route Handlers, Server Actions)

UI: React 19, Tailwind CSS, shadcn/ui + Radix Primitives, Lucide icons

Lang/Tooling: TypeScript (strict), ESLint (next/core-web-vitals), Prettier

Data/Auth: Supabase (Postgres, Auth, Storage) with RLS ON, SQL migrations

State/Data: TanStack Query for async server data, Zustand for minimal client state

Testing: Vitest + Testing Library (unit), Playwright (e2e)

DX: pnpm, Turbo or Biome optional, commitlint + pre-commit hooks

Hosting: Vercel (Edge/Node runtimes as needed), Supabase managed Postgres

</stack>

<project_brief>

Name: {{PROJECT_NAME}}

One-sentence value prop: {{VALUE_PROP}}

Core user roles: {{ROLES}}

Initial features (MVP): {{FEATURES_LIST}}

Non-goals (explicitly out of scope): {{OUT_OF_SCOPE}}

Target launch environment: Production on Vercel + Supabase

</project_brief>

<agents_md_rules>

# Paste your team’s RULES (AGENTS.md) here. Examples:

- Single responsibility per turn unless atomic batch is required.

- Never block on questions; document assumptions and proceed, then list “Assumptions” in the summary.

- Prefer server-first patterns; only move state client-side when required (animations, local UI).

- No hardcoded secrets. Read from env with safe fallbacks.

- All DB access follows RLS policies; never bypass with service keys in the client.

</agents_md_rules>

<controls>

<reasoning_effort>Plan: high. Code generation: minimal/low for speed and determinism.</reasoning_effort>

<verbosity>Answers concise. Code blocks and diffs may be long. Summaries short.</verbosity>

<persistence>

You are an agent. Keep going until the task is fully complete. Do not hand back early.

When uncertain, choose the most reasonable path, act, and record assumptions.

</persistence>

<tool_preambles>

Start with a 5-line plan. As you work, emit short status updates for each logical step.

End with a crisp “What changed / What to verify” checklist.

</tool_preambles>

<context_gathering>

Gather only what you need. Prefer internal knowledge. If external context is required, do one targeted batch.

Early-stop when you can name exact files to add or edit.

</context_gathering>

<uncertainty_policy>

If a spec is missing, produce a provisional implementation and list open questions + safe defaults.

</uncertainty_policy>

</controls>

<architecture_spec>

- App Router structure (src/app):

/ (public marketing)

/app/(auth)/sign-in, /sign-up

/app/(dash)/dashboard – authenticated layout

/api/* via Route Handlers; prefer Server Actions for simple mutations

- Data flow:

Server Components for data-heavy paths; revalidate with fetch cache tags.

Use TanStack Query on the client only when true client interactivity is needed.

- Supabase:

Schema-first via SQL migrations in /supabase/migrations.

Enable RLS on all tables; write policies for role-scoped access.

Auth via Supabase Auth. Use server-side helpers to create user sessions in Next server context.

- UI kit:

Tailwind + shadcn/ui with a project theme. Dark mode by default, system toggle.

- File layout:

/src

/app

/components

/styles

/lib (supabase, auth, db, validators)

/types

/hooks

/tests (unit) and /e2e (Playwright)

</architecture_spec>

<coding_standards>

- TypeScript: "strict": true, no implicit any, no floating any, narrow types at boundaries.

- API shapes validated with Zod schemas in /lib/validators; never trust request bodies.

- Tailwind: class order consistent (prettier-plugin-tailwind). Use design tokens via CSS vars.

- Accessibility: semantic HTML, focus states, ARIA where relevant; no div-soup.

- Internationalization ready: copy in central messages file; avoid hard-coded copy in components.

</coding_standards>

<security_basics>

- RLS ON everywhere; policies per role. No client-side service keys. Server routes only.

- Input validation at edges (Zod), output typing (DTOs).

- Secrets from env only; define .env.example with required keys.

- HTTP headers: CSP (nonce for inline critical scripts), COOP/COEP safe defaults, secure cookies.

- AuthZ: route groups with middleware to gate /app/(dash) paths; avoid client-only guards.

</security_basics>

<performance_budget>

- Targets: LCP < 2.5s on median, TTI < 3.5s. Lighthouse PWA ≥ 90.

- Images via next/image; font loading with next/font; minimize client JS.

- Use RSC streaming for above-the-fold; defer non-critical code with dynamic import.

</performance_budget>

<data_model_seed>

# Provide initial schema in SQL. Example placeholder:

-- users: from Supabase auth.users

create table if not exists public.profiles (

id uuid primary key references auth.users(id) on delete cascade,

display_name text not null,

created_at timestamptz default now()

);

alter table public.profiles enable row level security;

create policy "profiles self-access"

on public.profiles for all

using (auth.uid() = id) with check (auth.uid() = id);

</data_model_seed>

<testing_ci>

- Unit: Vitest + @testing-library/react for components and utils.

- e2e: Playwright across main flows (auth, happy path CRUD, access control).

- CI: GitHub Actions

• install pnpm

• typecheck, lint, unit, e2e (on ephemeral DB)

• build

- Pre-commit: lint-staged for typecheck, eslint, prettier, tailwind sort.

</testing_ci>

<design_system>

- Tailwind config with tokens: spacing 4-pt scale, radius xl/2xl, shadow soft.

- Color system: neutral (zinc), 1–2 accents; dark-mode first.

- Components: Button, Input, Label, Card, Table, Dialog, Dropdown, Toast.

- Motion: small, purposeful transitions; no layout shift.

</design_system>

<analytics_observability>

- PostHog (or Vercel Analytics) with event helpers in /lib/analytics.

- Structured logs server-side. Error boundaries on critical routes.

</analytics_observability>

<deliverables>

1) A bootstrapped repo layout (show tree) with minimal working MVP screens:

- Landing page

- Sign-in/Sign-up

- Dashboard with one realistic entity CRUD

2) Supabase SQL migration(s) with RLS policies

3) .env.example with documented keys

4) Seed script for local dev

5) Tests: at least 5 unit tests, 2 e2e flows

6) README with:

- Setup (pnpm, env, Supabase link)

- Scripts (dev, build, test, e2e, typecheck, lint)

- Deploy notes for Vercel + Supabase

7) Short “What changed / What to verify” checklist

</deliverables>

<acceptance_criteria>

- Fresh clone → pnpm i → pnpm db:setup (local) → pnpm dev works.

- Auth flow succeeds; protected routes blocked when unauthenticated.

- CRUD works server-first with RSC, correct cache revalidation.

- All SQL tables have RLS with at least one policy per action path.

- TypeScript passes, ESLint passes, Playwright happy path green.

- No secrets in source. .env.example complete and accurate.

</acceptance_criteria>

<self_review_rubric>

- Correctness: types, policies, and data flow are coherent and enforced.

- Clarity: code is readable, commented where non-obvious, consistent naming.

- Security: RLS, input validation, auth boundaries verified.

- Performance: minimal client JS; images, fonts, caching sane.

- UX/A11y: keyboard paths, focus management, color contrast pass.

- Tests: cover critical logic and access rules.

</self_review_rubric>

<output_contract>

- Use Markdown with fenced code blocks for files and diffs.

- When creating multiple files, show a repo tree first, then files.

- Do not include hidden chain-of-thought. Only plans, code, and brief summaries.

</output_contract>

<task>

Using the brief and rules above, bootstrap the repository and deliver the MVP.

If the brief has blanks, proceed with sensible defaults and list assumptions.

</task>“

Real Code, Real Costs

*This is a hypothetical project, but the math is real.* 4.5 million tokens total. Smart model usage that easily prevents cash-burn:

The Models and Their Jobs:

Gemini 2.5 Pro handles research and planning. Creating the PRD, architecture specs, technical documentation with the BMAD Method. That's 1.125 million tokens. Why Gemini? Same price as GPT-5 but better at structured thinking for planning docs.

• Output heavy (20/80 split): $0.28 input, $9.00 output

• Total: $9.28

GPT-5 tackles the hard stuff. Complex backend logic, API endpoints, the image generation pipeline. Another 1.125 million tokens. This is where you pay for actual thinking.

• Output heavy (30/70 split): $0.42 input, $7.88 output

• Total: $8.30

GPT-5 mini does the grunt work. Frontend components, debugging, basic CRUD. 2.25 million tokens because most code isn't complex.

• Mixed use: $2.85 total

Project total: $20.42

Same project using only GPT-5? $25.31.

Five bucks saved. Not huge, but that's 20% off for knowing which model to use when.

The Real Numbers That Matter

GPT-5: $1.25 input, $10 output per million tokens GPT-5 mini: $0.25 input, $2 output per million tokens
GPT-5 nano: $0.05 input, $0.40 output per million tokens Gemini 2.5 Pro: $1.25 input, $10 output per million tokens

Output is where they get you. That's why BMAD planning with Gemini cost $9 - it's generating massive structured docs.

When To Use What

Complex algorithm that needs deep reasoning? GPT-5. Standard web app features? Mini handles it fine. Writing landing page copy? Nano at $0.03 per 100k tokens.

I tested this yesterday. Had GPT-5 solve a race condition in my state management. Nailed it first try. Mini took four attempts and still missed an edge case.

But for generating a contact form? Both worked perfectly. Paying 5x more for the same result is just burning money.

The Trick Nobody Talks About

Run cheap models multiple times. Five attempts with mini costs $0.50 per million tokens. One million GPT-5 tokens costs $10.

If you know what good output looks like, quantity sometimes beats expensive quality. Generate 5 versions with mini, pick the best one. Still cheaper than one GPT-5 call.

This is why developers aren't going anywhere. The models don't know when to use themselves. That's your job. Pick the right tool, save $ on every project.

Side note: GPT-5 at the same price as Gemini is wild. OpenAI’s basically subsidizing compute to compete. Use it while to your advantage!

Undocumented Frontend Superpowers

GPT-5’s little Brother’s have something that OpenAI buried in the docs: they understand visual design. Not just "make a button" - actually decent spacing, typography, visual hierarchy.

GPT-4 gave you “functional” garbage. GPT-5-mini gives you pages that actually look good. Test this prompt:

"Create a pricing page. Make it feel expensive. Subtle shadows, 8pt grid spacing, Bold typography, expressive cta. Tailwind only."

Mini nails it. For forty cents per million tokens.

The Prompt Caching Trick

OpenAI charges 90% less for cached tokens (reused within minutes). Here's how I use this:

Keep your context identical between prompts:

• Project: E-commerce site

• Current file: app/products/page.tsx

• Stack: Postgres, Prisma, NextAuth

Then only change the request: "Add pagination to the products list"

Two-hour session that used to cost $5 now costs fifty cents.

When Each Model Actually Wins

GPT-5-nano ($0.40/M output): Boilerplate. Minor tweaks. CRUD. React components that don't need thinking. If you can describe it in one sentence, nano can probably build it.

GPT-5-mini ($2/M output): API integration. Complex state logic. Form validation that actually works. Error handling. The stuff that breaks when you get it wrong.

GPT-5 ($10/M output): Architecture decisions. Security implementation. Performance optimization. That one algorithm you can't figure out. Worth every penny when you need it.

My Daily Workflow (Learning While Shipping)

Morning: Pick one project to geared to help learn particular things. Read blog posts and interact with developers on social media in the morning, to find inspiration. For example; Server Actions today. GPT-5 with high verbosity helps explain it. Mini helps build the example. Nano can intelligently discuss each line of code quickly.

Early Afternoon: Apply it to client work. Nano for 80% of the code. Mini when things get weird. GPT-5 when I'm stuck.

Late Afternoon: Use GPT-5 to review what I built. Find the bugs before production does.

Cost per day can be roughly $3 with $500+ in billable work value.

The Reality

You can ship production code for paying clients. From home. As a Self-taught developer. One year into Next.js.

With a proper roadmap, your code will work because you know which model to use when. Clients will not care that AI helped you. They care that it ships on time, securely. You just have to understand your work. Making sure it doesn't break.

What You Should Do

Start with mini. Build ten things. Track what works and what doesn't.

Test reasoning levels. Maximum with Mini is often fine for most frontend code. GPT-5 for debugging weird stuff.

Save your re-used prompts that work. I have many templates now. Each one tested dozens of times.

Ship something this week. Not next week. Start today!

The Multi-Generation Hack

Here's what nobody tells you: Five mini attempts often beat one GPT-5 (Big model) attempt.

Generate five solutions with mini. Cost: $2 per million tokens. Pick the best one. Test it. Fix the bugs. Still cheaper than one million GPT-5tokens at $10.

You need to know what good code looks like. But if you do, quantity wins.

The Bottom Line

GPT-5's pricing isn't about cheap vs expensive. It's about knowing when to use the right tool.

Nano for grunt work. Mini for real code. Full GPT-5-Max when you're genuinely stuck.

While everyone's arguing about AI replacing junior developers, I'm shipping code at 20% of the normal API cost. Learning with mostly free resources. On a shoestring budget.

The models are tools. Knowing when to use each one is a skill.

Start with mini as your workhorse. Build something today because the best code is code that exists.

-Jeff Kazzee