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.
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.
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.
Using two AI tools without boundaries creates duplicated noise. I assign them different roles.
I use it to organize:
Its job is context recovery. When I return to a subject, I should not spend the first 20 minutes reconstructing the previous session.
I use ChatGPT to:
Its job is interaction, not authority.
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:
## 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.
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.
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.
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:
This is where a study project begins to resemble engineering evidence.
Hours are easy to count and weak as a measure of learning. I track:
Commits still matter, but a commit is an event. Understanding is a capability.
This system is still an experiment. My current challenge sequence increases complexity deliberately:
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.
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?