DEV Community: lingxin wang

When AI Learns To Think

lingxin wang — Thu, 16 Apr 2026 00:44:00 +0000

AI's Biggest Advantage Isn't Being Smart

A Counterintuitive Observation

What do you think is AI Agent's biggest advantage?

Most people would say: intelligence. Can write code, understand complex problems, process massive information.

I've been working on an Agent project, and I've noticed something different:

AI Agent's biggest advantage isn't being smart — it's being able to adjust.

Let me explain what I mean.

Two Types of Coaches

Imagine two basketball coaches.

Coach A is a tactical master. Before the game, he creates a detailed playbook: first quarter fast breaks, second quarter slow pace, third quarter focus on defending their #23... all planned out.

Problem is: once the game starts, the opponent plays differently than expected. His playbook becomes useless paper, but he sticks to the original plan.

Coach B also prepares before games, but differently. He adjusts in real-time based on what's happening:

Their #23 is having an off night? Increase offensive pressure
Our point guard's shot is hot? Give them more touches
Down in the third quarter? Call timeout, new strategy

He has a plan but isn't enslaved by it.

AI Agent is more like Coach B.

How Agent "Thinks"

In my project I've been studying Agent thinking patterns. There are mainly two:

Pattern One: Small Fast Steps (ReAct)

This is the "walk and see" mode:

Observe → Think → Act → Observe → Think → Act → ...

Each step is short. Agent gets a bit of information, makes a small decision, sees the result, adjusts.

Like a coach observing from the sideline: ball moved to the right, center is open, yell "post up!" Next possession situation changes, make a new call.

Pattern Two: Plan Then Execute

This is the "draw the roadmap first" mode:

Create plan → Execute step 1 → Execute step 2 → ... → Done

Agent breaks the task into steps, creates a checklist, executes sequentially.

Like pregame tactics: first half focus on defense, second half push offense. A general direction.

In Practice, It's Both

Mature Agent frameworks combine both modes:

Start with Plan mode to break down the task, get general direction
Within each subtask, use ReAct for flexibility
If mid-course you find the plan has problems, re-Plan

That's what great coaches do: have the whiteboard pregame, improvise during play, call timeout to adjust strategy when needed.

Why This Matters for Technical Decisions

From a management perspective, this thinking pattern has important implications:

1. AI Won't Just Barrel Down One Path

Traditional programs are deterministic: input A, always output B. If the logic is wrong, it stays wrong forever.

Agents are different. They adjust strategy based on intermediate results. First step went wrong? See the feedback, second step can correct.

This means: in high-uncertainty scenarios (data analysis, user interaction), Agents might be more reliable than hardcoded logic.

2. Observability Becomes More Important

Precisely because Agents adjust, you need to know why they adjusted that way.

Every round of "think-act" should have logs. Otherwise when things go wrong, you have no idea what it was thinking.

Same reason coaching staffs review game film: you need to see what happened at each decision point.

3. Good "Information Input" Beats Model Optimization

Agent decision quality depends on the information it receives. Give it accurate, timely feedback, it makes better adjustments.

Like coaches needing good data support: player movement heat maps, shooting percentages, opponent tendencies... More accurate information, more precise adjustments.

A Practical Recommendation

If you're considering having your team use Agents:

Start from "observable," not from "smart."

Don't rush to see how complex tasks the Agent can handle. First ensure:

Every round of thinking and acting is logged
You can replay its decision process
When errors occur you know which step went wrong

With these, you can tune. Without them, Agent is a black box.

Personal Reflection

As someone new to this field right out of school, I've learned more than just technology from this project.

The ReAct pattern made me think: small fast steps, rapid iteration. Don't try to do it perfectly once. Take one small step, see feedback.

Plan and Execute made me think: have the big picture in mind, but stay nimble on the ground. Having a plan is good. Being trapped by it isn't.

Combined: set direction first, then adjust based on reality.

That's not just AI strategy. It's a good approach for projects and career planning.

I guess that's the bonus from technical learning — studying Agents, but thinking about broader things.

From Doer To Manager

lingxin wang — Mon, 06 Apr 2026 20:16:32 +0000

I Had It Completely Backwards

When I started working on this AI Agent project, I fell into a trap.

I was thinking: how do I teach AI to write SQL?

I actually started listing rules — "use BETWEEN for dates," "remember JOIN for multi-table queries," "field names use underscores not camelCase"...

Halfway through I realized something was off. This list would be endless. And honestly, my own SQL wasn't that great. How was I supposed to "teach" an AI?

Then my mentor said something that clicked:

"AI doesn't need you to teach it SQL. It already knows. It knows more than you do."

So where was the problem?

The Real Problem

The issue wasn't that AI can't write code. The issue was it didn't know what my database looked like.

It's like a transfer student.

Their math foundation is solid — they know all the theorems and formulas. But give them a word problem and they're stuck — because they don't know the background. The problem says "distance between A and B is 500 km," they don't know what A and B are. It says "Xiaoming's speed is 60 km/h," they don't know who Xiaoming is.

AI is the same way.

You ask it "find all high-risk patients" — it doesn't know what criteria define high-risk. Your database has a risk_level field, it doesn't know. The values are 'high', 'medium', 'low', it doesn't know that either.

Plenty of capability, missing information.

Give It "Background Knowledge" Like a Teacher

Once I understood this, the approach became clear.

I didn't need to teach AI how to write SQL. I needed to tell it what my database looks like.

Just like a good teacher doesn't assume students know everything. They provide background first:

"A is Beijing, B is Shanghai"
"Xiaoming rides a bicycle, relatively slow"
"This problem is about pursuit"

With that background, the student can solve it themselves.

Same with AI. I give it this information:

"Your database has 11 tables"
"Patient info is in the patient table"
"High-risk marking is in ob_profile.risk_level, values are 'high' or 'low'"

With this, it can write correct SQL on its own.

How to Pass Information Efficiently

But there's a problem: database structure information is extensive. 11 tables, dozens of fields, each with types, constraints, relationships... writing it all out is thousands of words.

Give all of it to the AI? You could, but it's wasteful.

It's like teaching a class. You don't read the entire textbook aloud. You highlight key points: these pages matter, this formula will be on the test, this example is important.

The code does the same thing.

Original database definition looks like this:

CREATE TABLE patient (
    patient_id INTEGER NOT NULL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    age INTEGER,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Compressed, it becomes:

patient(patient_id:int*PK, name:str*NN, age:int, created_at:ts)

No information lost, 70% shorter.

This is the trick for giving AI reading comprehension: high information density, minimal fluff, clear priorities.

A Mindset Shift

After this lesson, I had a significant realization:

The core skill for using AI isn't programming — it's information organization.

Before, when I coded, my mindset was "I do it" — I write functions, I call APIs, I debug.

Now with AI, the mindset needs to shift to "I provide information" — I organize the database structure, clarify business rules, spell out constraints.

It's like going from student to teacher.

Students care about "how do I solve this problem." Teachers care about "how do I explain the background so students can solve it themselves."

Using AI means being the AI's teacher.

For People Just Starting Out

If you're also learning AI Agent development, here's what I'd share:

Don't try to "teach" AI how to do things.

AI is smart enough. Most skills it already has. What you need to do:

Figure out what information it's missing
Organize that information into a clear, compact format
Provide it at the right moment

This skill will become increasingly important.

You're not just passing database schema to AI — you'll pass code context, conversation history, business rules. It's all the same thing: efficiently deliver the information AI needs.

What I'm Taking Away

The biggest change from this lesson isn't learning how to extract Schema. It's realizing a role shift:

From "person who does things" to "person who manages information."

I used to think the core programmer skill was writing code.

Now I think the core skill in the AI era might be organizing and transmitting information.

AI can help write code. But how to organize information, when to provide it, how much to give — those judgments still require humans.

That's my early-career perspective on "how to work in the AI era."

Hope it's helpful to others on the same learning path.

When The Window Opened

lingxin wang — Mon, 30 Mar 2026 18:38:34 +0000

How I Got Stuck on Window Functions for Two Hours

Last week a SQL query had me stuck for two hours.

The requirement sounded simple: get the latest vital sign record for each patient.

I knew the data table had multiple records per patient (measured every 4 hours). I just needed the most recent one.

First instinct: GROUP BY.

Wrote it, ran it, didn't work — GROUP BY only returns grouped fields and aggregates. The actual values I wanted — blood pressure, heart rate, fetal heart rate — were gone.

Searched around. Apparently I needed window functions.

Then I saw this line of code:

ROW_NUMBER() OVER (
    PARTITION BY admission_id
    ORDER BY recorded_at DESC
) AS rn

Stared at it for five minutes. More staring, more confusion.

What's OVER? What's PARTITION BY? Why is there an ORDER BY inside parentheses?

I read three tutorials. Every one explained syntax definitions. None of them actually made me understand what was happening.

The Journalist's Verification Method

Then I switched approaches.

A journalist friend once told me about their fact-checking principle: don't just take someone's word for it — verify it yourself.

If a news story says "Company X laid off 50%," you can't just use that. You ask: where's the source? Any internal documents? Can you find an affected employee to confirm?

Every detail needs to be traceable.

I figured learning this SQL was the same. Instead of reading explanations, I should verify.

So I ran an experiment: delete PARTITION BY and see what changes.

One Experiment Solved the Mystery

SQL without PARTITION BY:

SELECT *,
  ROW_NUMBER() OVER (ORDER BY recorded_at DESC) AS rn
FROM vital_signs

Ran it — the entire table's records got numbered sequentially. 1, 2, 3, 4... all the way to the end.

Added PARTITION BY back and ran again:

SELECT *,
  ROW_NUMBER() OVER (
    PARTITION BY admission_id
    ORDER BY recorded_at DESC
  ) AS rn
FROM vital_signs

This time each patient's records were numbered separately. Patient A: 1, 2, 3. Patient B: also 1, 2, 3. Independent.

Comparing the two results, I immediately understood:

PARTITION BY is saying — slice the table into separate windows, number within each window.

Like a journalist fact-checking multiple sources: you don't mix all information together and sort. You group by source, then sort by time within each group.

Why Tutorials Didn't Work

Looking back, why didn't those tutorials help?

Because they were telling me definitions instead of letting me verify.

"PARTITION BY divides the result set into partitions" — syntactically correct, but meaningless to me.

What actually made me understand was: I saw the difference between having and not having PARTITION BY.

It's like fact-checking a story: you can read ten reposts all saying "Company X laid off 50%," but you're still not sure. Until you get the internal memo or interview someone affected, you can't really say "I know."

Verified knowledge is the only knowledge you truly own.

A Useful Learning Pattern

From this experience, I've extracted a learning pattern:

Start with a real problem — not "I want to learn window functions," but "I need to get each patient's latest record"
When stuck, design an experiment — change one variable, see what differs
Verify by comparison — let facts speak, don't just trust explanations
Write conclusions in your own words — not copied from tutorials

This method works beyond SQL. Any technical concept — if you only read without verifying, you stay in the "kind of get it" state forever.

Run it yourself. Change parameters. See results. Ten minutes of experimentation beats an hour of reading tutorials.

For Fellow Engineers

If you're stuck on some technical concept, try this:

Write a minimal example
Delete the part you don't understand, see what changes
Add it back, compare both results
Summarize for yourself: what is this thing actually doing?

Sounds dumb, but it's effective.

Journalists don't fact-check by being clever — they do it with patience and method. Learning tech is the same.

Postscript

I've since used this method to understand several other concepts that were fuzzy before: the difference between OUTER JOIN and INNER JOIN, HAVING vs WHERE, CTEs vs subqueries...

Same pattern every time: minimal example, change one variable, compare results.

Probably the most practical learning technique I've picked up from this project.

Sharing it with fellow engineers still being tortured by various syntax concepts.

One File Eleven Tables

lingxin wang — Mon, 23 Mar 2026 18:30:16 +0000

Live Demo https://obnexus.vercel.app/, GitHub https://github.com/Isaac-aiai/obnexus-project

Organizing Data Like Filing Case Documents

Centuries ago, courts faced a problem: too many case files.

A single case might involve plaintiffs, defendants, witnesses, physical evidence, testimonies, judgments... pile it all together and finding anything takes forever. Eventually people learned to categorize: personnel go in personnel volumes, evidence in evidence volumes, testimonies in testimony volumes. Each category in a standard format, linked by case numbers.

That was the beginning of records management.

When I learned databases today, I realized programmers use the same approach — except we call them "tables" instead of "case volumes."

Databases Turned Out to Be Simple

Before this lesson, my impression of databases was: heavy enterprise stuff. Install servers, configure ports, maybe buy licenses for the serious ones. Something you only use in "real projects."

Then what happened?

My mentor had me run one command:

mise run download-db

A few seconds later, a .sqlite file downloaded to my machine.

Then he said: That's the database.

I blinked. A file? That's it?

No server. No ports. No username/password. One file is a complete database. I could copy it to a USB drive, move to another computer, and it would just work.

I realized: databases aren't as scary as I thought. At their core, they're just organized file management.

Eleven Volumes

Opening this database, I found 11 tables:

Table	What it records
patient	Patient files
provider	Medical staff
room	Room information
bed	Bed status
admission	Admission records
shift	Shift schedules
medical_order	Medical orders
vital_sign	Vital signs
labor_progress	Labor progress
ob_profile	OB profiles
alert	Alert records

This is data from an OB/GYN hospital. Imagine if it were all mixed together.

Picture it: patient info, bed status, doctor schedules, medication records, labor progress, alerts... all in one giant table. Finding a patient's admission time means first filtering out scheduling records. Checking a bed's status means skipping past medical orders.

That's like dumping all case files in one room unsorted. You can find things. But it's exhausting.

Split into 11 tables:

patient only tracks who the patient is
bed only tracks where beds are
admission only tracks who checked in
alert only tracks what's abnormal

Each table is an independent case volume, responsible for one thing.

Need to link information? Use IDs. Just like case files using case numbers to connect different volumes.

Why This Matters for Beginners

As someone new to databases, here's what I've realized: good structure lowers the learning barrier.

If this database were one giant table with dozens of fields mixed together, I wouldn't know where to start.

But split into 11 tables, each with just a few fields, I can explore one by one: first look at patient to understand patient records, then bed to understand how beds are tracked, then admission to see how they connect.

Complex systems decomposed into simple parts.

This decomposition doesn't make things more complicated — it makes learning possible.

Two Layers of Simplicity

Today I saw two kinds of "simple":

First layer: tool simplicity.

SQLite made the database a single file. No servers to install, no networks to configure. Download and use. For beginners, this means focusing on "what does the data look like" rather than "how do I get the database running."

Second layer: design simplicity.

The 11-table structure makes complex business understandable. Like courts categorizing case files — each category answers one question.

These two layers work together. Good tools lower the entry barrier. Good design makes complex problems decomposable.

What I'm Taking Away

I used to think "simple" was a compromise — fewer features, therefore simple.

Today I learned: simple is a capability.

Taking complex things and decomposing them so people can understand step by step — that requires the designer to deeply understand the domain and make deliberate choices.

SQLite's creator chose "one file" as the design, letting everyone worldwide start with zero cost.

This hospital database designer chose "11 tables" as the structure, making complex medical operations orderly.

For anyone starting to learn tech, maybe this is worth remembering:

If something looks complex, it might not be inherently complex — it might just not be well decomposed yet.

Find the right decomposition, and complex becomes simple.

The Gift of Instant Feedback

lingxin wang — Mon, 16 Mar 2026 19:34:53 +0000

Why Developers Are Luckier Than Most

A friend who works in product asked me the other day: "You programmers write code all day — how do you know if what you wrote is correct? Do you have to manually test everything after each change? That sounds exhausting."

I told her: "No manual testing. Just run the tests and you know."

"What are tests?"

"Basically an automatic checking system. After you change code, the system tells you what's right and what's wrong."

"Sounds like a medical checkup report."

That comparison was perfect. What I learned today — coverage testing — is essentially a health checkup for code.

Green and Red

Opening the coverage test HTML report, the screen shows lines of code marked by color:

Green: covered by tests, has been executed
Red: never touched by tests, never run

Just like a doctor reading lab results: normal indicators are green, abnormal ones are red. No guessing. No deduction. One glance and you know where the problems are.

I stared at the screen for a while. Not because I didn't understand — because it was so direct.

You wrote 100 lines. The report tells you: 80 green, 20 red, 80% coverage. Which specific 20 are red? Click in, line by line, all marked.

For someone in product, this precision of feedback is probably hard to imagine.

Most People Don't Get This Kind of Feedback

My friend said: "You programmers are lucky — you know immediately if you got it right."

She's right.

She shipped a new feature. User feedback: "feels off somehow." What's off? Who knows. Is it the interaction flow? The copy? The overall positioning? You can only slowly analyze data, slowly dig through user interviews.

Job interviews are the same way. You bomb it, but you don't know which answer was wrong. Maybe three months later you vaguely guess what you should have said.

At least doctors have lab results. But most things in life? There's no report marking things green and red telling you: this was right, this was wrong.

You rely on intuition, on experience, on trial and error.

Coverage tests just say: these 20 lines of code have never been executed. Not "maybe," not "possibly." Definitely.

This fast, precise, unambiguous feedback is a privilege of this profession.

What Tests Really Are: Daily Rounds

My friend asked: "So what exactly are tests doing? Making sure there are no bugs?"

Yes, but not just that.

I used an analogy: imagine a hospital with one doctor responsible for all patients. When there are few patients, they remember each person's condition. But with more? 100 patients, each with medications, contraindications, allergy histories — impossible to remember everything.

So what do you do? Daily rounds, checking charts.

The medical chart is the test. It records key information for each patient. The doctor doesn't rely purely on memory — one glance at the chart and they know how to proceed.

Code is the same. Small project, you remember what every line does. Big project, 100 files, tens of thousands of lines — change one line, will it break something else? Hard to say.

Run the tests:

All green? Relax, nothing broken
Some red? Read the error message, it tells you what went wrong

Tests are medical charts for code. You don't have to keep all logic in your head. Outsource it to the testing system.

The Wisdom of Layering

There's a deeper truth here that my product friend would understand: good systems are layered.

Human brains have limits. Doctors can't remember 100 patients' conditions, so we invented charts. Programmers can't remember tens of thousands of lines of logic, so we invented tests.

Outsource the "remembering" part. The brain only needs to focus on the small piece currently being handled.

Coverage tests go one step further — they're charts for the charts. They tell you: which code is your testing covering, which isn't.

Tests test code. Coverage tests test tests. Layer by layer, each layer catching what falls through.

A Thought

After this lesson, I understand "feedback" differently.

Building products, designing, doing any creative work — the hardest part often isn't execution. It's not knowing whether you're doing it right.

Programmers are lucky. We have tests, coverage reports. Change code and know the result in seconds.

For anyone building products, I'd say: if you can establish a "fast feedback system" in your domain, that's a huge advantage.

Even if it's not as precise as code testing, anything faster than "find out three months later whether it was right" is worth investing in.

That's probably the insight I'm taking from today's technical learning that transfers to other domains.

Think Big Code Small

lingxin wang — Mon, 09 Mar 2026 21:46:13 +0000

Live Demo https://obnexus.vercel.app/, GitHub https://github.com/Isaac-aiai/obnexus-project

Three Rules for Code That Won't Collapse

When I joined the project, I was told to study code architecture patterns. At first I didn't really get it — if the code runs, isn't that enough? Why bother with these "design patterns"?

Then I saw a codebase that had lost control.

Over 100 files, each importing from who-knows-where. Change one line? First spend two hours tracing dependencies. New team member? Three weeks in and still can't figure out where to start.

It's like an army without a command structure. Every soldier knows their own job, but nobody can see the whole battlefield. Information flows randomly between squads. No central intelligence hub. No clear chain of command.

The code wasn't messy because the programmers were bad. It was messy because there was no command system.

The Three Architecture Rules

Today I learned three patterns — Singleton, Lazy Load, Mixin — and I'm starting to think they're really about establishing a command hierarchy for code.

Rule One: Unified Command (Singleton)

There's a class in this project called One. Need config? Ask it. Need database connection? Ask it. Need AI model? Still ask it.

from obnexus.api import one
one.config    # global config
one.engine    # database connection
one.agent     # AI model

In military terms, there's a principle: unified command. No matter how many battalions or companies you have, operational orders come from one headquarters.

Code works the same way. Doesn't matter how many modules exist underneath — expose one entry point to the outside. New person joins the team, day one they know where to start: ask one. No digging through the whole codebase. No guessing which file does what.

That's what Singleton is for: establishing a unified command entry point.

Rule Two: Intelligence on Demand (Lazy Load)

The traditional approach is to initialize everything when the program starts. It's like an army gathering all possible intelligence before the war even begins — sounds thorough, but it's actually a disaster.

First, resource waste. You might only need the database, but because of how the code is written, the AWS connection gets created too.

Second, and worse, chain reactions. Module A imports B, B imports C, C imports A again — circular dependency, program crashes.

This kind of bug is nasty: everything works fine when the project is small, then explodes as code grows, and it's hell to debug.

Lazy Load's design: intelligence is reported only when needed.

class One:
    @cached_property
    def engine(self):
        return create_engine(...)  # created on access

import one does nothing. You call one.engine, then database initialization triggers. No preloading. No chain reactions. No risk of circular dependencies.

Rule Three: Modular Organization (Mixin)

A mature army is modular: infantry company, artillery company, signals company. Each has their function, and they combine flexibly.

Code should organize the same way.

class One(ConfigMixin, DbMixin, AgentMixin):
    pass

Each Mixin handles one independent capability. Right now there's just ConfigMixin, later we'll add DbMixin, AgentMixin. Add a capability, add a building block. Overall structure stays the same.

The benefit: capabilities can grow while the command structure stays stable.

Why Do This When Code Is Still Simple?

Someone might think: project just started, only a few files, isn't this pattern stuff overkill?

From a technical management perspective, it's exactly the opposite.

The cost of messy code grows exponentially. 10 files with some mess? One hour to clean up. 100 files? Maybe a week. 1000 files needing refactoring? Team might stop for a month.

Architecture debt is scarier than technical debt because you can't fix it by patching a few bugs — you need to redesign the system.

So: when code is simple is exactly when to establish the command structure.

What I'm Taking Away

Before this, my coding style was "get it running first." If it works, ship it. Structure can wait.

But now I understand something:

Think Big, Code Small.

Think Big: stand in the future and look at today. Ask yourself: if code volume increases 10x, will this structure hold?

Code Small: write simple code. Few entry points. Clear dependencies. Each module does one thing.

Good code architecture is like good military command — not assembled during wartime, but trained, exercised, and validated in peacetime.

That's probably the most important lesson I'm taking from this.

Start Big Learn Along The Way

lingxin wang — Mon, 02 Mar 2026 16:00:00 +0000

Live Demo https://obnexus.vercel.app/
GitHub https://github.com/Isaac-aiai/obnexus-project

Not Ready Yet? Good.

I got handed an internship project right out of school: build an AI scheduling assistant for an OB/GYN ward. My immediate reaction was something like panic. I could barely write SQL without looking things up. How was I supposed to build this?

But here's the thing — the scaffolding was already there. Beautiful landing page, complete chat interface, even those little suggested question buttons. It all looked real. Except the AI was fake. Every response was hardcoded.

It was like a team with jerseys printed, stadium rented, fans in the seats — but no players on the field yet.

My job was to make this team actually play.

Why Agent and Not Just a Chatbot

Before writing any code, I had to figure out why we needed an Agent at all. Why not just wire up a chatbot and call it done?

This is actually a critical question for anyone building AI products, and I've been thinking about it a lot.

A chatbot, the way I see it, is like a midfielder who can only pass — never shoot. You tell it to press the opponent, it says "sorry, my configuration is possession-based." You tell it to take a shot, it says "I'm just a passing specialist."

An Agent is different. Agent = brain + legs + the autonomy to decide when to pass and when to shoot.

You say "find me empty beds," and it figures out which table to query, what conditions to use, how to structure the results. It doesn't just understand your intent — it acts on it.

That's the kind of player who can actually score.

For someone like me who wanted to quickly validate whether AI could do something useful, choosing Agent over Chatbot felt like choosing a versatile striker over someone who can only juggle — I needed someone who could put the ball in the net.

The Learning Strategy I'm Betting On

Here's a counterintuitive take: don't wait until you're ready.

The default learning approach is sequential — watch all the tutorials, solve all the exercises, feel "prepared," then finally start building.

It's like an athlete saying "I'll play my first competitive game after my free throw percentage hits 95%."

The problem is — you'll never be ready. The pressure of real competition, the rhythm of actual opponents, the coordination with real teammates — training can't simulate any of that. You only learn where you're weak by actually playing.

I decided on a different strategy:

Find something the 12-months-from-now version of yourself might be able to complete. Start now.

obnexus became my real game:

Complex enough to be worth the effort
Clear milestones where I could see progress
Tech stack I actually wanted to learn (Agents, databases, cloud deployment)
Most importantly — after this game, I'd have game tape to show interviewers

What's Next

I've got the team structure. Now I need to make them actually playable:

Wake up the AI (right now it's just a mannequin)
Connect the database (so it can see real game data)
Implement tool calling (so it can take actions, not just watch)
Deploy to production (so the audience can see the game)

Each step is a small goal. Add them up, you've got a complete match.

A Thought

Here's what I keep coming back to:

You don't become skilled by being fully prepared. You become skilled by repeatedly stepping onto the field.

When I graduated, I thought I needed a few more years of study before I could tackle challenging projects. Now I realize the fastest growth comes from taking on something beyond your current ability — and learning as you go.

The version of me three months from now will definitely be stronger than the current one.

That's why I'm willing to step onto the field now. I don't know exactly how this will go, but I figure that's kind of the point.