I built a study operating system so AI would stop doing my learning for me

AI disclosure: This article is based on my real study logs and workflow. I used AI to help research DEV's publishing format, organize the draft, and revise the English. The cover image was also AI-generated under my direction. I reviewed every technical claim and made the final editorial decisions.

AI made me faster at producing code. It did not automatically make me better at engineering.

That distinction became obvious when I looked at my GitHub: many repositories, several promising starts, and too few projects I could explain from database constraint to error response without reopening a chat.

So I stopped treating AI as a shortcut generator and designed a small study operating system around one rule:

An output only counts as learning if I can explain, reproduce, and verify the reasoning behind it.

This post describes the workflow as a system you can copy, modify, and run.

The architecture

My daily learning pipeline has four stages:

fundamentals -> academic theory -> market context -> real implementation

In practice:

math -> software engineering degree -> certification -> hiring challenge

Each stage has a specific responsibility.

Stage	Responsibility	Example
Fundamentals	Build the mental model	Sets, relations, Boolean logic, statistics
Academic theory	Name and structure the concept	Normalization, CPU architecture, distributed processing
Certification	Connect theory to industry vocabulary	SQL, cloud, project management, lakehouse
Hiring challenge	Produce evidence under constraints	API, tests, database schema, deployment

The important part is not the list. It is the dependency between stages.

On a database day, for example, I can move from mathematical relations to functional dependencies, from functional dependencies to normalization, and from normalization to constraints in PostgreSQL. One concept crosses four contexts instead of becoming four disconnected study sessions.

The scheduler: minimum, standard, and deep modes

Most study plans assume a constant amount of energy. Humans do not have one.

I use three execution modes:

type StudyMode = {
  duration: string;
  goal: string;
  evidence: string;
};

const modes: Record<"minimum" | "standard" | "deep", StudyMode> = {
  minimum: {
    duration: "10-15 minutes",
    goal: "keep continuity",
    evidence: "one recalled concept or answered question",
  },
  standard: {
    duration: "50-60 minutes",
    goal: "learn, close the source, and retrieve",
    evidence: "an explanation in my own words",
  },
  deep: {
    duration: "90 minutes",
    goal: "implement and integrate",
    evidence: "working code, tests, or deployment",
  },
};

The minimum mode is not a fake version of studying. It is fault tolerance.

If a bad day forces the system from standard to minimum, the process degrades gracefully instead of crashing to zero. Deep work remains important, but continuity protects the next session from the cost of a complete restart.

Tool boundaries: NotebookLM is memory, ChatGPT is dialogue

Using two AI tools without boundaries creates duplicated noise. I assign them different roles.

NotebookLM: source-grounded memory

I use it to organize:

• college material;
• course notes;
• daily study sources;
• summaries of where I stopped;
• questions that still need review.

Its job is context recovery. When I return to a subject, I should not spend the first 20 minutes reconstructing the previous session.

ChatGPT: tutor and reviewer

I use ChatGPT to:

• challenge my explanation;
• generate a small exercise from a specific gap;
• compare two architectural choices;
• review code I already attempted;
• help split an oversized problem;
• identify claims that need documentation or tests.

Its job is interaction, not authority.

The AI protocol

The most useful file in each project may not be part of the application at all:

docs/ai-log.md

This is the template I use:

# AI Learning Log

## Problem
What behavior am I trying to implement or understand?

## My hypothesis before asking
What do I think the solution is? Where am I uncertain?

## AI suggestion
Summarize the proposed approach. Do not paste an entire conversation.

## What was wrong or incomplete?
Missing edge cases, invalid assumptions, outdated APIs, weak architecture, etc.

## Verification
- Documentation consulted:
- Test written:
- Manual experiment:
- Result:

## Retrieval check
Can I explain the solution without reopening the chat?

This changes the interaction. Before asking, I must state a hypothesis. After receiving an answer, I must find a way to falsify it.

The log also creates interview material. Instead of saying “I used AI to build this,” I can explain a concrete decision, a failed suggestion, the evidence that changed my mind, and the final trade-off.

A better prompt lifecycle

My old workflow looked like this:

task -> prompt -> generated code -> commit

The new workflow is:

task
  -> inspect the existing system
  -> write my hypothesis
  -> ask a bounded question
  -> compare the answer with docs
  -> write or adapt the code
  -> test the behavior
  -> explain it from memory
  -> commit

The extra steps feel slower locally. They are faster globally because they reduce copied mistakes, architectural drift, and the need to relearn the same concept.

Weekly routing

I route each weekday to a concept family:

Day	Core theme	Implementation target
Monday	Web and dynamic logic	DOM, events, async APIs
Tuesday	Databases	modeling, constraints, SQL
Wednesday	Computer architecture	memory, processing, I/O
Thursday	Data and distributed systems	batch, streaming, fault tolerance
Friday	Project engineering	scope, risk, estimates, Definition of Done
Saturday	Integration	90-minute build/test/deploy block
Sunday	Recovery	rest plus light weekly planning

The schedule is a routing table, not a prison. If one topic needs another week, it keeps its slot. I do not add a new active project to manufacture the feeling of progress.

One active challenge, explicit Definition of Done

My biggest operational change was freezing secondary projects.

I now work through real hiring challenges in sequence. Each challenge has a concept target and a Definition of Done.

For a menu and promotions API, for example, “done” does not mean that POST /products returned 201 once. It means:

• business rules are explicit;
• invalid input produces intentional errors;
• database constraints protect invariants;
• critical paths have tests;
• setup is reproducible;
• the README explains architecture and limitations;
• I can defend the choices without the AI transcript.

This is where a study project begins to resemble engineering evidence.

Metrics that are harder to fake

Hours are easy to count and weak as a measure of learning. I track:

• days the system stayed online;
• concepts retrieved without the source;
• bugs explained before they were fixed;
• business rules protected by tests;
• completed and deployable projects;
• decisions recorded in the AI log.

Commits still matter, but a commit is an event. Understanding is a capability.

What I am testing next

This system is still an experiment. My current challenge sequence increases complexity deliberately:

1. schema-driven forms and DOM fundamentals;
2. TypeScript API, PostgreSQL, Docker, time-based promotion rules, and handwritten SQL;
3. React/Next.js filtering with URL synchronization;
4. architecture evolved through junior, mid-level, and senior releases;
5. transactions, concurrency, idempotency, and unstable external services.

The hypothesis is simple: if each project reuses old fundamentals while adding one hard constraint, the portfolio becomes evidence of progression instead of a gallery of unrelated demos.

The part AI cannot automate

AI can produce a plausible answer before I have formed a useful question. That is exactly why the workflow needs friction.

The goal is not to avoid AI. The goal is to make its contribution observable, bounded, and testable.

My current rule is:

AI may accelerate the feedback loop.
It may not silently own the reasoning.

If you are also learning with AI, try adding only one thing this week: write your hypothesis before your next prompt. The quality of the question changes, and so does the ownership of the answer.

---

Suggested discussion prompt: What evidence do you use to distinguish “I shipped it” from “I learned it” when AI helped write the code?