init: final_year_cs_student.sh

Build Your Talent Stack.
Be a Good Engineer
by shipping every 48 hours.

Learning by doing. Everyday. Not someday. Pick an idea Friday night. Have a working URL by Sunday. Share it & get feedback. That's the loop.

48 hours One real project Bring: laptop + curiosity
01 / why now

You're graduating into a different industry than 2 years before

Not worse. Different. The job you'll have in 2027 has a description that didn't exist in 2024. The good news: the people hiring you in 2027 are figuring it out at the same speed you are.

Boris Cherny: Can confirm Claude Code is 100% written by Claude Code Team Change

So what's actually different

The skill that mattered most when your CS curriculum was written was writing code. The skill that matters most now is shipping working systems. Those overlap, but they're not the same. AI handles a lot of the typing. It does not handle:

  • Deciding what's worth building in the first place
  • Knowing when the code it produced is wrong
  • Wiring it into something users can actually touch
  • Making it not break at 2 AM
Team Change 1

The students who graduate ready for this don't wait for class to teach them. They build things. On weekends. For nobody. Just to learn by doing.

★ The real reason for this guide

Your CV in 6 months will be judged by exactly two things: your GPA, and what you've shipped. One of those you've already mostly determined. The other, you can change this weekend.

02 / the shift

Three eras in five years.

To know where to aim, look at where the puck is going. Here's the speedrun:

2021

Era 1 — Autocomplete

Copilot suggests one line at a time. You drive every keystroke. AI is a fancy IntelliSense.

2024

Era 2 — Pair programmer

Cursor, Claude, ChatGPT. You describe what you want; it writes the function. You read, edit, run. Conversation, not autocomplete.

2026

Era 3 — Agents

You describe a goal. The AI plans, writes files, runs tests, fixes its own mistakes. You're the architect and the reviewer. The job is to know what good looks like.

jump in shipping speed, per era — if you adapt
Team Change 2

The students who win the next two years aren't the ones who type fastest. They're the ones who can direct the system: pick the right problem, decompose it well, judge the output, and ship.

03 / the recipe

The 48-hour weekend recipe.

One project. From idea to live URL. Friday 6 PM to Sunday 6 PM. Each block is a checkpoint — if you blow past the time, scope down, don't push back.

H 0–2

Pick an idea (small enough to ship)

One feature. One screen. One audience. If you can't describe it in a sentence, scope down. See the idea bank if you're stuck.

H 2–4

Write the PRD with AI

Use the PRD prompt below. Give Claude or ChatGPT your one-sentence idea. Get back a tight one-pager. Push back on anything that feels too big — kill features.

H 4–6

Generate the task breakdown

Feed the PRD into the task-breakdown prompt. You should end with 8–15 numbered tasks, each shippable in under an hour. If a task is fuzzy, split it.

H 6–20

Build with Cursor + Claude Sonnet

Open Cursor. Drop in your .cursorrules file (template below). Work task by task. Read every diff. Commit after each task. Sleep when tired — bad code at 3 AM is the #1 cause of death of weekend projects.

H 20–30

Test it like a user

Open it in a fresh browser. Click everything. Break it on purpose. Have a friend try it. Fix the embarrassing stuff. Leave the small stuff.

H 30–40

Deploy to a real URL

Vercel for Next.js or static. Render or Fly for backends. Free tiers are enough. If deploy takes more than 90 minutes, your project is too complex — simplify and try again.

H 40–48

Tell people

One LinkedIn post. One tweet. One message to three friends. The URL, what it does, what you learned. This is the part most students skip. Don't.

⚠ The single rule

You ship something imperfect on Sunday, or you ship nothing on Sunday. Those are your only two outcomes. Pick the first one.

04 / toolkit

Your weekend stack. Pick one of each. Move on.

The trap of being a final-year CS student is endless tool comparison. There are 40 AI editors. Don't compare them. Pick one. Use it for a weekend. If you hate it, switch next weekend.

The default stack (what to use this weekend)

Editor
Cursor
VS Code with AI baked in. Free tier is enough for a weekend. Student discount if you want more.
Model
Claude Sonnet
Best balance of code quality and speed in late 2025. Use it inside Cursor or in the Claude app for planning.
Frontend
Next.js + Tailwind
One repo, deploys to Vercel in two clicks. Don't overthink it. JavaScript is fine.
Backend / DB
Supabase or SQLite
Supabase if you need auth + DB. SQLite if you need almost nothing. Skip Postgres-from-scratch this weekend.
Deploy
Vercel
Free. Hooks into GitHub. Push to main, your site updates. That's it.
LLM API
Anthropic API
$5 of free credit. Plenty for a weekend project. Use Sonnet from your code.

Skip these (this weekend)

  • Docker, Kubernetes, microservices — you have one user
  • Custom auth from scratch — Supabase or NextAuth, done
  • Tests for everything — write tests for the part most likely to break, ship
  • The "perfect" framework — your first weekend project will be replaced. Pick one and move
  • 15 AI tools — Cursor + Claude is enough
05 / prompts

The prompt library.

Six prompts cover 90% of the weekend. Copy them. Edit the bracketed bits. Read what comes back — don't accept it blindly.

Idea pressure-test

Use this before you commit to a weekend on something. It saves Sunday from being a regret.

prompt — pressure_test.txt
I'm a final-year CS student. I want to build [ONE-SENTENCE IDEA] this weekend (48 hours, solo). Be brutal. Answer: 1. Is this shippable in 48 hours? If no, what's a smaller version that is? 2. What's the ONE feature that proves the idea works? Cut everything else. 3. What's the most likely thing to make me give up by Saturday night? 4. What's a similar thing that already exists, and what would mine do differently? Don't be encouraging. Be useful.

PRD generator

Turns a sentence into a one-page spec. Don't skip this — building without one is how scope eats your weekend.

prompt — prd.txt
Write a one-page PRD for this weekend project: [PRESSURE-TESTED IDEA]. Constraints: - Solo developer, 48 hours, final-year CS student - Stack: Next.js + Tailwind, Anthropic API, deployed on Vercel - One user (me) for now — no auth unless absolutely required Format: 1. Problem (2 sentences max) 2. Target user (1 sentence) 3. The single core flow (numbered steps a user takes) 4. What's IN scope (3 items max) 5. What's explicitly OUT of scope (be ruthless) 6. Definition of done — what does "shipped" mean for v1? Keep the whole thing under 300 words. Be specific, not aspirational.

Task breakdown

Feed your PRD in. Get back a checklist you can actually work through.

prompt — tasks.txt
Here's my PRD: [PASTE PRD] Break this into a numbered task list I can ship in 14 hours of focused work. Rules: - Each task = one Cursor session, max 60 minutes - Tasks must be ordered: nothing depends on a later task - The first task must produce a runnable "hello world" version of the app - The last task must be "deploy to Vercel and test on a real URL" - For each task, write: (a) what to build, (b) how I'll know it's done Aim for 8–15 tasks. If you can't fit it, the PRD is too big — tell me what to cut.

.cursorrules — the file that makes Cursor smarter

Put this in your repo root as .cursorrules. It's the difference between AI that helps and AI that hallucinates.

file — .cursorrules
Project: [ONE-SENTENCE PROJECT DESCRIPTION] Stack: Next.js 14 (App Router), TypeScript, Tailwind, Anthropic SDK Deploy: Vercel Rules for AI assistance: 1. Always read the existing file before editing it. Never invent functions or imports. 2. Match the existing code style. If files use single quotes, use single quotes. 3. When unsure, ask one specific question rather than guess. 4. For new files, propose the file path before writing the code. 5. After writing code, list any new dependencies that need installing. 6. Do not add comments that just restate the code. 7. Prefer fewer, simpler files over many small abstractions. 8. If a request is ambiguous, list the assumptions you're making before coding. Common pitfalls to avoid: - Don't create new components when an existing one can be extended - Don't add libraries that aren't already in package.json without flagging it - Don't write tests unless I ask — this is a weekend prototype

Implementation prompt (per task)

Use this inside Cursor when starting each task. It frames the AI's response so you get diffs you can actually read.

prompt — implement_task.txt
Task: [PASTE TASK FROM YOUR LIST] Before writing any code: 1. List the files you'll touch 2. State any assumptions you're making 3. Flag anything you'd do differently if I gave you more time Then write the code. Keep changes minimal — only what this task needs. After the code: - Tell me what to run to verify it works - Tell me what to expect if it's working

The "explain this back to me" prompt

Use this every 3-4 tasks. The trap is shipping code you can't explain — this prevents that.

prompt — explain_back.txt
Walk me through this code as if I'm interviewing you about it. [PASTE CODE] Cover: 1. What does this code do, in one sentence? 2. What are the 2-3 design decisions you (or I) made here? 3. Where would this break? What input would crash it? 4. If you were code-reviewing this, what's the first thing you'd push back on? Don't be polite. Treat this like a real review.

The debug prompt

When something's broken and you've stared at it for 10 minutes. The structured format is the point.

prompt — debug.txt
I have a bug. Help me find it. What I'm trying to do: [INTENDED BEHAVIOR] What's actually happening: [ACTUAL BEHAVIOR] The error (if any): [PASTE ERROR + STACK TRACE] Relevant code: [PASTE 1-2 FILES, NOT THE WHOLE REPO] What I've already tried: [LIST 2-3 THINGS] Before suggesting a fix: 1. Form a hypothesis about the root cause 2. Tell me what to check to confirm or rule it out 3. THEN suggest the fix If you can't tell from what I sent, ask me for one specific thing — don't guess.
06 / traps

Five traps that kill weekend projects.

These are the predictable ways your Sunday ends with nothing shipped. If you know they're coming, you can dodge them.

trap 01
Asking for "an app" instead of one feature

"Build me a study app" produces 2,000 lines of nothing. "Build me one screen that takes a topic and returns 5 quiz questions" produces something you can ship. Always ask for the smallest possible end-to-end thing first.

trap 02
Not reading the code AI generates

It's tempting to accept every diff. Don't. Read every change before committing. You'll catch hallucinations, security holes, and weird patterns. More importantly: you'll learn. Skipping reading is the fastest way to ship code you can't maintain or explain in an interview.

trap 03
No git commits, no version control

Commit after every task. git commit -am "task 3 done" is fine. When the AI breaks something at hour 18, git reset saves your weekend. The students who've done this before never skip this step.

trap 04
Scope creep on day one

Saturday morning, the AI just shipped a working button, and you think "I should also add..." — STOP. Write the new idea on a sticky note. Keep it for next weekend. The unshipped feature is the one that kills the project.

trap 05
Never actually shipping

The most common failure mode. The project is "almost done" for three weeks, then you forget about it. Deploy on Sunday, ugly bugs and all. A live broken thing teaches you 10× more than a perfect localhost. Plus, only the live version exists.

07 / mindset

What separates a good engineer from a great one in the AI era.

AI can write the code. That used to be the hard part. Now the hard part is everything around the code — and that's the part nobody is going to teach you in a lecture. Here's what to optimize for, starting now.

Reading code > writing code

You're going to spend the next 10 years reading more code than you write. AI just made that ratio worse, in a good way. Train the muscle now: every time AI writes something, read it line by line and ask why. Not whether it works — why it's structured this way and not another way. Engineers who can't read code fast are about to have a hard decade.

Taste is your moat

When everyone has the same AI, the differentiator is judgment. Knowing which solution is cleaner. Which API is better named. Which abstraction is premature. Taste comes from one source: reading a lot of good code, and writing a lot of bad code, and noticing the gap. You build it the same way you build a body — reps, over years.

Systems thinking > syntax memorization

Memorizing the standard library mattered when looking things up was slow. It's not slow anymore. What still matters: knowing how a request travels from a browser to your database and back, where it can fail, and why your latency is 800ms instead of 80ms. That kind of thinking is invisible to AI — it has to come from you.

Ask better questions

The best engineers I know are the best at asking questions. Not just "how do I make this work" but "what am I actually trying to do" and "is there a simpler version of this problem." AI is brilliant at answering questions and useless at asking them. The job — for the rest of your career — is to be the one asking.

★ The shift, in one line

You used to be a code-writer. You're becoming a system-thinker who happens to write code. The weekend project is how you practice that shift before anyone's paying you to do it.

08 / after

What to do Monday morning, and the Monday after that.

One weekend won't change your career. Twelve will. Here's the loop.

  1. Ship one thing per month. Not per weekend — per month. That gives you margin. The goal is consistency, not heroics.
  2. Write about each one. One LinkedIn post or blog. Not a tutorial — your honest take on what worked, what didn't, and what surprised you. This compounds faster than the projects themselves.
  3. Read other people's projects. Find 5 builders you respect. Read their repos and their write-ups. Steal patterns shamelessly.
  4. Build in public. Tweet the broken half-built version on Saturday. Post the live one on Sunday. The audience grows from the process, not the polish.
  5. Aim for harder problems each time. Project 1: a single API call. Project 6: a multi-user app with auth. Project 12: something a stranger pays you for. Don't repeat the same difficulty.
★ The compound interest of this

By the time you've shipped 6 projects, your CV stops looking like every other final-year student's. By 12, you have a portfolio that talks louder than your GPA. By 24, you don't apply for jobs — they apply to you.

09 / ideas

Idea bank — 30 weekend-shippable projects.

Stuck on what to build? Steal one of these. They've all been built before. That's the point — building something that exists is how you learn. Originality is for project 6, not project 1.

For students like you
Chat with your lecture slides — paste a PDF, ask it anything
★ start here
YouTube lecture → timestamped notes — paste URL, never sit through a 3-hour video again
1 day
Past-paper topic ranker — paste your exam, see exactly what repeats
2 days
Job description vs. CV gap analyzer — paste both, get a bullet rewrite plan
2 days
Socratic tutor — explains any concept, keeps asking "do you get it?" until you do
1 day
Cover letter factory — paste job + CV, get a non-cringe draft in seconds
1 day
Dev tools that earn respect
Commit message generator from a git diff
1 day
Unit test generator — paste a function, get test cases
1 day
Code-to-flowchart — paste a code block, get a Mermaid diagram
2 days
Changelog generator — paste git log, get human-readable release notes
half day
API doc chat — paste an OpenAPI spec, ask "how do I authenticate?"
2 days
"Will this pass code review?" — pre-review your own PR before submitting
2 days
The screenshot pipeline (vision API)
Screenshot → working HTML/React — paste a UI mockup, get runnable code
2 days
Error screenshot explainer — paste the red screen, get a fix + root cause
1 day
"Is this a scam?" — paste a suspicious message or screenshot, get a verdict
half day
Whiteboard to diagram — photo of messy whiteboard → clean Mermaid SVG
1 day
Math homework solver — photo → step-by-step solution with explanation
1 day
Terms of Service decoder — paste the legal wall, get what you actually agreed to
1 day
Things nobody asked for (the best ones)
"Roast my GitHub" — analyzes your repos, makes fun of them
1 day
"Senior engineer reviews your code" — ruthless AI persona, maximum savagery
half day
Generates a startup pitch from three random words
1 day
Which programming language matches your personality? (quiz + result)
half day
Your commit history, as a personality type — INTJ or chaotic neutral?
half day
"Is your side project idea original?" — finds existing clones, rates your odds
1 day
Slightly bigger (weekend 2 or 3)
Voice note → meeting minutes + action items (Whisper transcription + Claude)
3 days
"Second brain lite" — save links, auto-summarize them, search by question later
3 days
Group chat TL;DR — paste a Zalo/WhatsApp export, get summary + action items
2 days
Personal finance coach — upload bank CSV, ask "why am I broke this month?"
2 days
One-click portfolio from GitHub — pull your repos, generate a hosted profile page
3 days
"Auto-apply" assistant — feed it job listings + your CV, customizes each application
3 days
⚠ One more thing about ideas

Don't wait for the "perfect" idea. The perfect idea is the one you can ship. Pick a boring one and execute well. Originality is the easiest part of building — taste, finish, and iteration speed are the hard parts.

// closing

The talk ends. The weekend starts.

You don't need permission. You don't need another course. You don't need to wait until you "feel ready" — that feeling never arrives, and the people who shipped didn't have it either.

Pick an idea on the way home. Open Cursor when you get there. Ship by Sunday night.

That's it. That's the whole talk.