What I Would Learn If Starting Computer Science Today

If I were starting computer science today, I would not panic.

I would also not pretend the field is the same as it was five years ago.

The honest version is somewhere in the middle: AI has changed the surface area of software work, especially for juniors. But the deeper game is still computer science: understanding systems, modeling problems, debugging reality, evaluating trade-offs, and building things that work when the demo energy wears off.

This article is for the student who feels both excited and behind. You are watching people build agents, apps, automations, research tools, and tiny startups with a laptop and an API key. You may also be hearing that entry-level software jobs are harder to land, that AI can write code, and that your curriculum is moving slowly.

All of that can be true, and you can still have a very good path.

TL;DR

I would learn fundamentals first, but not in isolation. Programming, data structures, databases, operating systems, networks, and debugging still matter more as AI writes more of the code.
I would become AI-literate early. Not “prompt-only” literate, but able to use model APIs, structured outputs, retrieval, evals, and safety checks.
I would build portfolio proof, not collect certificates. Three small projects with tests, README trade-offs, screenshots, source links, and honest failure notes beat ten vague demos.
I would use AI as a coach and reviewer, not a replacement brain. The NUS-Google CS education whitepaper cites evidence that unrestricted GPT-4 access can improve practice performance while hurting later exam performance when AI is removed.
I would optimize for taste. In 2026, code is cheaper. The scarce skill is knowing what to build, what to trust, what to delete, and how to explain the trade-off.

What You Will Learn Here

The 2026 context for students: AI adoption, job-market pressure, and why fundamentals still matter
The learning stack I would follow if I were starting now
How to use AI tools without weakening your problem-solving muscles
A concrete project I would build in my first month
What portfolio proof looks like in an AI-heavy hiring market
What I would delay until later so I could make real progress

The Honest 2026 Context

Here is the source-backed part first.

Stanford’s 2026 AI Index reports that organizational AI adoption reached 88%, that 4 in 5 university students use generative AI, and that performance on SWE-bench Verified rose from 60% to near 100% of the human baseline in a single year. CBS News, summarizing LinkedIn’s 2026 Grad’s Guide, reported that AI engineer was the fastest-growing job title for young workers for the second year in a row, and that LinkedIn added 639,000 AI-related U.S. job postings from 2023 to 2025, including 75,000 AI engineer roles.

That does not mean every student should become a machine learning researcher. It does not mean every company knows what it is doing with AI. It does not mean a chatbot will hand you a career.

My editorial read is simpler: the market is rotating toward people who can combine software fundamentals with AI fluency and product judgment. The person who only prompts is fragile. The person who refuses to use AI is leaving leverage on the table. The person who understands the system and uses AI to move faster is in a strong position.

The Stack I Would Learn

If I were starting today, I would not ask, “What single course should I take?”

I would ask, “What stack of abilities compounds?”

FOUNDATION
  programming, data structures, systems, databases, networks
        |
        v
AI LITERACY
  model APIs, prompting, structured output, retrieval, evals
        |
        v
BUILDING
  web apps, CLIs, APIs, deploys, observability, product loops
        |
        v
PROOF
  shipped projects, tests, READMEs, demos, writeups, trade-offs
        |
        v
TASTE
  judgment, debugging intuition, simplicity, security, ownership

That is the curriculum I would keep in my head. Not because it is perfect, but because it prevents the two common traps:

Going so deep into theory that you never ship anything.
Going so shallow into tools that you can ship a demo you cannot debug.

1. Learn Programming Like You Will Need To Read Bad Code

The first skill is not “Python” or “TypeScript.” The first skill is being able to read a problem, turn it into a precise model, write a small program, and understand why it works.

CS50 describes its goal as teaching problem solving with and without code, with emphasis on correctness, design, and style. That is exactly the right spirit. You are not learning syntax for its own sake. You are learning how to think in constraints.

If I were starting now, I would pick one main language and get boringly competent:

Python if I wanted the easiest path into data, AI APIs, scripting, and notebooks.
TypeScript if I wanted to build web apps, product demos, and full-stack projects.
C or Rust later if I wanted to understand memory, systems, and performance more deeply.

The rule: use AI to explain, quiz, and review, but write enough code by hand that recursion, errors, state, types, and debugging actually become yours.

2. Learn The Durable CS Core

The boring subjects are not boring when you connect them to real projects.

I would learn these in roughly this order:

Area	Why it matters now	Build something small
Data structures and algorithms	AI can suggest code, but you still need to know what is efficient, correct, and appropriate	A search feature with sorting, ranking, and edge-case tests
Databases	Most useful apps are structured memory around a product problem	A notes app with users, tags, full-text search, and migrations
Operating systems	Processes, files, memory, permissions, and concurrency explain many real bugs	A CLI that watches files, runs jobs, and handles failures
Networks	Every AI product is still HTTP, auth, latency, retries, and timeouts	A small API client with retries, rate limits, and logs
Software design	AI makes it easy to add code; design helps you keep the system understandable	Refactor a messy script into modules with tests

Teach Yourself Computer Science recommends programming, computer architecture, algorithms, math, operating systems, networking, databases, languages/compilers, and distributed systems. I would not try to master all of that in one semester. I would treat it as a multi-year map.

The important part is depth over performance theater. Do not just ask AI for the answer to Dijkstra. Implement it. Break it. Visualize it. Explain when you would not use it.

3. Become AI-Literate Without Becoming Prompt-Dependent

AI literacy is now a baseline career skill, but “I know how to ask ChatGPT” is not enough.

I would learn five practical layers:

Prompting: how instructions, context, examples, and constraints shape output.
Structured output: how to force model responses into JSON or typed schemas.
Retrieval: how to answer from documents with citations instead of vibes.
Evaluation: how to test output quality, not just admire a good demo.
Safety and cost: how to handle hallucinations, sensitive data, latency, and runaway spend.

This is where the line between a student project and a serious project starts to show.

A weak project says:

“I built a chatbot.”

A stronger project says:

“I built a study assistant over my course notes. It retrieves relevant chunks, answers only from those chunks, returns citations, validates output with a schema, and logs failures for review.”

Same category. Completely different signal.

4. Use AI Like A Coach, Not A Crutch

The NUS-Google whitepaper is useful because it does not simply say “use AI” or “ban AI.” It says CS education has to shift toward understanding and verifying AI-generated artifacts, while preserving conceptual understanding.

It also cites a randomized controlled trial with nearly 1,000 students where unrestricted GPT-4 access improved practice performance by 48%, but led to a 17% decline in later exam scores when AI was removed. The lesson is not that AI is bad. The lesson is that help without struggle can make you feel fluent before you are fluent.

Here is the rule I would use:

Before AI:
  try, sketch, fail, write what you think is happening

With AI:
  ask for hints, edge cases, explanations, alternate approaches

After AI:
  close the chat, re-implement, test, and explain from memory

Good uses of AI:

“Quiz me on hash tables until I can explain collisions.”
“Review this code for edge cases, but do not rewrite it yet.”
“Give me three ways this database schema could fail.”
“Explain this OS concept with an analogy, then with a precise definition.”
“Generate test cases I probably missed.”

Bad uses of AI:

“Solve my assignment before I struggle.”
“Write the project and README so I can submit it.”
“Explain this error, then paste the fix without understanding it.”
“Make my code look senior even though I cannot debug it.”

You want AI to increase your reps, not replace them.

5. Build Projects That Prove Taste

The job market does not need more portfolios with twelve cloned landing pages and a weather app.

It needs proof that you can take an ambiguous problem, make it smaller, build a working version, test it, and explain the trade-offs.

I would aim for three projects:

Project 1: A useful non-AI app

Build a normal app first. A club budget tracker, personal CRM, study planner, workout logger, open-source issue dashboard, or tiny inventory system.

What it proves: you can build product flows, data models, auth, CRUD, validation, deployment, and basic UX without hiding behind AI magic.

Project 2: An AI feature inside a normal app

Add one AI feature to that app: summarization, classification, extraction, search, recommendations, or a guided assistant.

What it proves: you can integrate AI into software instead of building a floating chatbot.

Project 3: A reliability-focused AI project

Build a small RAG assistant, coding helper, or task agent, but make the evaluation visible.

What it proves: you understand that AI systems fail, and you know how to measure, constrain, and improve them.

For each project, add a README section called What I Tested:

10 example inputs
3 failures you found
what you changed after testing
what the system should not be trusted with
screenshots or a short demo video
setup steps that a stranger can actually run

That kind of honesty is rare. It makes you easier to trust.

A Concrete Build: The Source-Grounded Study Assistant

If I had one month, I would build a study assistant for one real class.

Not a generic chatbot. A tiny system with a contract.

Course notes / PDFs
      |
      v
Chunk documents
      |
      v
Embed chunks
      |
      v
Question -> retrieve top chunks
      |
      v
Model answers only from retrieved chunks
      |
      v
Return answer + citations + missing info
      |
      v
Log result for evaluation

Start with the smallest useful schema:

from pydantic import BaseModel, Field


class StudyAnswer(BaseModel):
    answer: str
    citations: list[str] = Field(description="Source chunk IDs used")
    missing_information: list[str] = Field(default_factory=list)
    confidence: str = Field(description="low, medium, or high")


def validate_answer(raw_json: str) -> StudyAnswer:
    return StudyAnswer.model_validate_json(raw_json)

Then create a tiny eval file:

[
  {
    "question": "What is the difference between a process and a thread?",
    "must_cite": ["os-notes-03"],
    "should_refuse_if_missing": false
  },
  {
    "question": "What did the professor say will be on the final exam?",
    "must_cite": [],
    "should_refuse_if_missing": true
  }
]

That teaches more than it looks like:

file handling
chunking and search
embeddings
API calls
schema validation
hallucination control
testing
product behavior

It also gives you a clean interview story: “I built it, evaluated it, found where it failed, and changed the design.”

Learn The Tools Schools Often Skip

MIT’s Missing Semester exists because many CS programs under-teach the tools you use every day: the shell, editors, Git, debugging, profiling, packaging, and shipping. Its 2026 syllabus even includes agentic coding and AI-enhanced workflows folded into the course.

I would take that seriously.

Learn:

the command line
Git beyond add, commit, and push
debugging with a real debugger
logs and traces
environment variables and secrets
package managers
basic Linux permissions
CI basics
how to deploy a small app

These skills make you faster immediately. They also make AI assistants more useful because you can verify what they are doing.

The Portfolio Bar I Would Aim For

A good junior portfolio in 2026 is not just “here are my repos.”

It should answer five questions quickly:

What problem did you solve?
Who is it for?
What did you build yourself?
How did you test it?
What did you learn or change after it failed?

For each serious project, I would include:

a live demo if possible
a short README with architecture and trade-offs
screenshots or a one-minute video
tests or an eval set
a “known limitations” section
a short writeup explaining one hard decision

This is not just for recruiters. It is for you. Writing the trade-off forces you to understand your own work.

What I Would Not Chase First

Your attention is the budget.

I would not start with:

Training models from scratch. Fascinating, but not needed for most student AI projects.
A new framework every week. Learn one stack deeply enough to finish.
Multi-agent systems before one reliable tool. Make one small loop work before orchestrating five brittle ones.
A giant SaaS idea. Build a tiny useful workflow first.
Only LeetCode. Practice algorithms, yes, but do not let interview prep replace building.
Only vibe coding. It can help you move fast, but you still need to understand, test, and own the result.

Skipping these is not a lack of ambition. It is sequencing.

A First 90-Day Plan

If I were advising a first- or second-year CS student, I would keep the first 90 days small.

Days 1-30:
  Learn one language well enough to build small programs.
  Finish a command-line tool or simple web app.
  Use Git daily.

Days 31-60:
  Add a database, auth, tests, and deployment.
  Write a README with setup instructions and trade-offs.

Days 61-90:
  Add one AI feature with structured output.
  Add a tiny eval set.
  Write what failed and what you changed.

By the end, you should be able to say:

“I built a real app, deployed it, added an AI feature, tested the failure modes, and can explain every major trade-off.”

That sentence is stronger than “I know AI.”

Final Word

If you are starting computer science today, you are not too late. You are starting in a strange, high-leverage moment.

The field is changing fast, but the center is still steady: understand problems deeply, build useful things, test them honestly, and keep learning the layers below your tools.

Use AI. Learn from it. Let it review you, quiz you, and accelerate your projects.

But do not let it steal the struggle that turns information into skill.

The best path is not anti-AI or AI-only. It is deeper than both: become the kind of builder who can use powerful tools because you understand enough to challenge them.

Luis Mori Guerra

Recent Articles

Topics

What I Would Learn If I Were Starting Computer Science Today