Built for final-year CS students and junior developers who want their first AI engineering role — not just AI hype.
The honest picture
AI-generated code floods every portfolio. Hiring managers can't tell who actually understands anything. The ones who get hired are proving judgment, not just output.
CS programmes train you to build systems where correctness is provable — write code, run tests, deploy, done. Production AI systems are probabilistic. The same input gives different outputs. Quality drifts without any code change. Failures are silent. That is a different engineering problem.
Hiring managers are asking: when the AI gives you wrong code, do you catch it? When your AI feature starts degrading three months after launch, can you diagnose it? Being able to prompt ChatGPT is not what they are hiring for.
You have repos and tutorials. They want proof you catch bad AI output before it ships, diagnose drift months after launch, and build systems that fail loud — not demos that worked once on your laptop.
What the industry needs
The honest picture above is the anxiety. Here is the shift behind it: teams aren't hiring for “can use AI tools.” They're hiring for engineers who can make AI systems reliable in production — and show evidence they've done it before.
Anyone can paste model-generated code. Hiring managers need engineers who know when to reject it, override it, and explain why.
Production AI fails silently — quality drifts, retries double-charge, retrieval misses edge cases. The job is making probabilistic systems observable and bounded.
A GitHub full of green checkmarks isn't enough anymore. They want linked PRs, recorded reasoning, and artifacts they can verify in ten minutes.
That is a specific, learnable skill set — not a personality trait and not something you pick up from a video playlist. Pukkaship is built so you practise it on real broken code and leave with proof.
What Pukkaship teaches
Each skill maps directly to what hiring managers are asking for above — not as theory, but as work you ship. Sixteen modules on one evolving AI service: fix a broken repo, open a PR that passes CI, explain your judgment. Modules 1–8 build the foundation (free); 9–16 add measurement, observability, prompt engineering, RAG, and the capstone (paid).
20 weeks · 12 hours per week · GitHub-based · every merge updates your verified skills profile
Foundation · every module
“Spec first. Test before you read the output. Log every judgment call.”
A professional workflow built for the probabilistic nature of AI: write the specification before you prompt, define the test before you evaluate the output, document every judgment call where the model was wrong and you overrode it. The discipline that separates an engineer who ships from one who pastes.
Topics covered
Modules 1–4 · free
“Your API returned 200. Nothing was saved. Catch that before you add a model.”
Fix code that hides wrong assumptions instead of failing loud. Turn it into a real HTTP service with persistence. Harden external calls with timeouts and bounded retries. Then wire your first LLM — same discipline as any other unreliable network dependency, not a separate magic step.
Modules 5–8 · free
“Validate at the edge. Defend against adversarial input. Queue slow work. Make retries safe.”
Schema validation at every boundary, guardrails against prompt injection and data egress, async decoupling of LLM work from the hot path, and signed idempotent webhook delivery — the foundation arc that makes the system production-grade.
Modules 9–10 · paid
“Replace 'it seems better' with a number you can track. Automate judgment about AI output quality.”
Fixture libraries and a harness that turn classifier output into a measured pass rate. An LLM-as-judge with rubric anchors — and the distinction between a hard gate that blocks release and a soft signal that informs only.
Module 11 · paid
“Quality drifted three months after launch. No code changed. You need to see it before users report it.”
Structured tracing of each hop — prompt, completion, tokens, latency — written so you can debug and evaluate in production what you cannot see from CI alone.
Modules 12–16 · paid
“Navigate unfamiliar code. Stabilise prompts. Budget context. Measure retrieval. Ship the viewer.”
Read and extend a system you did not write, stabilise prompts with regression fixtures, enforce context budgets with token math, measure retrieval per query — then deploy the access-controlled eval-results viewer as the capstone.
Also woven through every module
The credential
Every claim links to a specific PR, a Loom, or a CI run. The areas of growth section is not optional — it is what makes the rest of it credible to a hiring manager.
Alex R. · @alexr
20 weeks complete · Cohort Jun 2026
Technical foundation
Strong
Debugging, reliability & validation all proficient or above across 8 modules
Measurement & evals
Strong
Fixture-first from week 9 · judge correctly separated gates from signals
AI collaboration
Strong
Documented AI rejections in every PR from week 3 · hypothesis before prompt
Prompt & RAG
Developing
Retrieval at 71% vs 80% target · context budgeting mechanical, not design-level
Per-dimension · what the evidence supports
Technical
Measurement & evals
PRs #9, #10, #19 · Loom wk 10
Debugging discipline
Bug journals wks 1–3 · hypothesis in every PR
Reliability engineering
PRs #3, #4 · retry & timeout patterns cited
Boundary validation
PRs #5, #6 · Zod schemas at every edge
Async & systems
PR #7 · pattern applied, rationale thin
Prompt, context & RAG
PRs #13–15 · retrieval at 71% vs 80% target
Behavioural
AI-collaboration judgment
Growth trajectory
Communication (why not what)
Areas of growth · required in every shared profile
Prompt, context & RAG — Developing
“Retrieval fixture pass rate reached 71% (target: 80%). Token budget reasoning was mechanical — included everything that fit rather than choosing what mattered. Recommend more practice before taking on production RAG work independently.”
Detailed findings · linked to artifacts
Measurement & evals
StrongPRs #9, #10, #19 (capstone) · Loom wk 10 ✓
“Fixture-first thinking applied consistently from week 9 onward. Week 10 judge correctly separated hard gates from soft signals without prompting. Capstone eval results viewer deployed, 94% CI pass rate.”
AI-collaboration judgment
Strong“Every PR from week 3 includes a documented AI rejection with stated reasoning. Week 11 Loom shows hypothesis stated before AI consulted in 6 of 7 sessions observed.”
How it works
Each repo is a real production pattern turned into a broken codebase — a type system gap, an async boundary that fails under load, a retrieval pipeline that passes CI but breaks at edge cases. Not puzzles. Real patterns.
Before you open the AI, write your hypothesis. Before you merge, open a PR — CI verifies tests pass — and write why the bug existed, why your fix works, and where your judgment overrode the model. The methodology is the proof.
After each merge, your skills profile updates. You get a personal report — what moved, what to focus on next, with specific guidance.
Pukkaship Weekly Snapshot · Alex R. · Week 10 of 20
This week: pe-10-judge — LLM-as-judge · PR #10 merged ✓
Current standing
Measurement & evals Strong ↑ Proficient
AI-collaboration Strong ↑ Proficient
Debugging discipline Proficient → unchanged
What moved this week
Your journal named the distinction between a hard gate and a soft signal without being prompted. That moved both dimensions.
Focus for pe-11
Evals: Your judge rubric has three criteria but no fixture for when two conflict. Add one before you merge.
AI workflow: Before asking what a function does, write your hypothesis first. Loom should show that sequence.
— Sudi
Built by a practitioner
Not a course creator who learned from courses. Every module reflects real production failures from twenty years of shipping software at scale.
Senior Software Development Manager · Amazon Web Services
GenAI Infrastructure & Applications · IIT Kanpur · Chicago Booth
Clone Module 1. Fix the first bug. Open a PR that passes CI and explain your reasoning. One artifact. Verified. Yours. Nineteen more to go.
Register with GitHub — it's freeRequires a GitHub account · 20 weeks · 12 hrs/week