A 30-Day Program to Learn Coding with AI

TL;DR

In thirty days, the goal isn’t to become a senior developer or produce a perfect dashboard. The goal is to learn how to evolve the AI’s role: first as a teacher, then as a reviewer, next as a debugging partner, and finally as an executor under supervision. By the end, you should be able to explain, verify, and redo part of what you’ve built.

The mini-dashboard is just a pretext

Claude Code or Codex can generate a mini-dashboard on the first day. A few metrics, React cards, a simulated API call, and tests: all of this is within reach of a good prompt.

But will you be able to evolve it by the thirtieth day?

That’s the question that matters. Because a project only becomes interesting when a piece of data is missing, a test breaks, a business rule changes, or another developer needs to understand what was done. The generated code is just the beginning of the story. The real skill is being able to continue when the story gets messy.

The following program is based on the mini-dashboard from this series: TypeScript, React, and Next.js, a few server metrics, a simulated API, valid or invalid data, and useful tests. If you prefer another topic, just keep the same progression. A task manager, a profile page, or a small business tool can work just as well.

Plan for between forty-five and ninety minutes per day. If you don’t have that time, spread the days out. Consistency is more important than the schedule. Also, keep a very short note after each session: what you tried, what blocked you, the help you asked for, and what you can now explain without reopening the conversation with the AI.

First week: the AI explains, you write

The first week might feel frustrating: the agent is allowed to explain, ask questions, and review, but not take over the keyboard. This is intentional.

Start by writing down the dashboard’s requirements and its limitations. It displays the status of a service, CPU usage, memory, and disk space. It must handle loading, an API error, and invalid data. It doesn’t need real authentication, a database, or real-time graphs. Ask the agent to identify ambiguities. Don’t ask it for the project yet.

Next, initialize Next.js and take the time to understand the created directory structure. What is the app folder for? Where does a component live? What’s the difference between data declared in a type and data actually received from an API? You can verify your answers in the Next.js documentation, then ask the agent to correct only what’s important.

Write your own MetricCard component, powered by simulated data. It doesn’t need to be elegant right away. The important thing is to be able to explain its props, its role, and what would happen if the value were missing. At the end of the week, recreate a small card from scratch, without assistance, then ask the agent to ask you a few questions. The answers you struggle with become the focus for the following week.

Second week: you try, the AI reviews

The second week introduces external data. This is an important moment because a TypeScript type doesn’t magically validate what an API sends at runtime.

Define a nominal response for your metrics, then invent a response where a value is missing and another where it’s impossible. Write the function to fetch the data yourself. Handle the case of an unsuccessful HTTP response. Then, show your attempt to the agent and ask what it actually does before asking for improvements.

Next, work on the interface states. What does the user see while loading? What do you tell them when the service is unavailable? What does an invalid value mean? Don’t silently replace unknown data with zero just to make the screen look cleaner. The interface must remain honest about what it knows and what it doesn’t.

At the end of the week, review the diff of all your changes. You can ask the agent to point out out-of-scope files, mixed responsibilities, and unnecessary duplications. But start by doing your own review. It’s this first pass that turns the tool into a reviewer rather than a judge.

Third week: you drive the changes

The third week is when the agent starts writing more. Not because it’s become more reliable, but because you now have a framework to control what it does.

Before adding a test for the CPU card, write down the expected behavior. A valid value should be displayed with its unit. Zero should remain valid. An out-of-bounds value should be visible as an anomaly, not silently converted. An API error shouldn’t make the whole page disappear. This work prepares the test strategy before the implementation influences it.

You can then assign the agent a limited task, provided it starts with a plan. It should tell you which files are affected, the tests planned, and the validation commands. You approve the scope. Then, you read the final diff and verify that a test fails if you intentionally break the behavior it’s supposed to protect.

Also, introduce a controlled bug. For example, let a null metric slip through to the component. Formulate your hypothesis before asking for help. Observe the raw response, the value after validation, and what’s received by the render. The agent can suggest two probable causes and an experiment to distinguish between them. Keep track of what actually resolved the issue. You’ll learn something more valuable than a fix: a diagnostic method.

End this week with an agent-free session. Add a new metric using the documentation and what you’ve already built. This isn’t a test. It’s a way to check that you can still act without prompts when the context becomes less comfortable.

Fourth week: the agent executes under supervision

The final week isn’t about delegating the entire project. It’s about delegating small parts with clear responsibilities.

Write the stable rules of the repository in AGENTS.md for Codex or CLAUDE.md for Claude Code: the commands that must be run, the architecture to follow, conventions, and key checks. Don’t turn this file into a fifty-page constitution. It should remind you of the decisions you don’t want to repeat in every conversation.

Next, pick a skill that seems relevant and inspect it before using it. See what it does, what it assumes, the scripts it runs, and whether it truly fits your project. The goal isn’t to accumulate skills. The goal is to know how to give the agent useful context without adding conflicting rules.

You can then assign it the task of adding the disk metric or a small, well-defined improvement. Require a plan, approve the affected files, read the diff, and run the validations. You can also ask for two architectural approaches with their trade-offs. Reject an abstraction if the need doesn’t justify it. A more complex solution isn’t automatically a more mature one.

The last few days are for documenting and demonstrating. Write the README yourself: installation, commands, architecture, limitations, and decisions made. Have the agent review it. Then, present your dashboard as if it were a technical review. Explain the data flow, error states, tests, and an architectural trade-off. You don’t need to be perfect. You just need to be able to say what you know, what’s still uncertain, and how you’d verify it.

What you should be able to do by day 30

At the end of the program, the best indicator isn’t the size of your repository or the number of lines generated. It’s your ability to modify a metric without regenerating everything, to explain why data is validated, to read a diff before accepting it, and to turn an error into a testable hypothesis.

You should also be able to distinguish between what’s actually tested and what’s merely assumed. This distinction might seem almost administrative at first. Yet, it’s one of the key differences between getting code and owning software.

You won’t be done learning after thirty days. No one becomes a senior developer in a month, with or without AI. However, you will have changed the nature of your relationship with the tool. You won’t use it just to avoid difficulty. You’ll use it to understand faster, get better feedback, and advance decisions you can still explain.