title: "Your First Hour" last_updated: 2026-03-21 status: proven difficulty: beginner prerequisites: [00-what-is-agentic-dev]
Your First Hour
Going from install to productive in 60 minutes.
The First-Hour Framework
Your first hour with an agentic coding tool follows a natural arc. Resist the urge to skip ahead. Each phase builds on the previous one, and rushing through them creates bad habits that compound over weeks and months.
The framework has five phases:
- Install (~5 minutes) — Get the tool running. This is the easy part.
- Orient (~10 minutes) — Let the agent explore your codebase. Watch what it does.
- Configure (~5 minutes) — Write a minimal configuration file. Three to four lines is enough.
- Build (~30 minutes) — Complete a real but low-risk task with the agent's help.
- Reflect (~10 minutes) — Review what happened. Adjust your mental model.
This is not a rigid schedule. Some phases will take longer, some shorter. The point is that all five phases happen, in order, during your first session. Skip any one of them and you will form incomplete mental models that slow you down later.
Why the First Hour Matters
The first hour is not about productivity. It is about calibration.
During this hour, you are building an internal sense of what the agent is good at, where it struggles, how fast it works, and what it costs. These impressions will shape every decision you make with the tool going forward — which tasks you delegate, how much context you provide, how carefully you review output.
Get this calibration wrong and you will either over-trust the agent (leading to subtle bugs you don't catch) or under-trust it (leading to micromanagement that defeats the purpose of using it). Both failure modes are common, and both originate in a poorly structured first session.
Habits form fast. If your first interaction is typing vague prompts and accepting output without review, that becomes your default. If your first interaction is thoughtful, structured, and review-oriented, that becomes your default instead. Choose deliberately.
The Critical Mistake: Toy Projects
Most people start with a toy project. They create a fresh directory, ask the agent to build a to-do app or a calculator, and marvel at the output. This feels productive. It is not.
Toy projects tell you almost nothing about how the agent will perform on your actual work. They are too simple, too well-represented in training data, and too far removed from the messy reality of production codebases. An agent that writes a perfect calculator from scratch may flounder when asked to add a feature to your 50,000-line monorepo with custom conventions, unusual architecture, and undocumented edge cases.
Worse, toy projects give you a distorted sense of the agent's capabilities. You walk away thinking "this thing is amazing" or "this thing is useless" based on evidence that does not transfer to your real work.
Use your real project from minute one. Pick a codebase you already understand — something you work on daily or weekly. The agent's output will be more meaningful because you can instantly evaluate whether it is correct. You will spot hallucinations, incorrect assumptions, and style violations because you know what right looks like. This is exactly the kind of feedback loop that builds accurate calibration.
The Orient Phase
Before asking the agent to change anything, ask it to read.
Give the agent a broad exploratory prompt: "Read this project and summarize the architecture" or "Explain how this codebase is organized." Then watch what happens. Pay attention to which files it reads, which ones it skips, and whether its summary matches your understanding.
This phase serves two purposes. First, it gives the agent context. Agentic tools work dramatically better when they have oriented themselves in the codebase before attempting modifications. Second, it gives you context — about the agent. You learn how it navigates code, what it pays attention to, and where its understanding diverges from yours.
If the agent's summary is wildly off, that tells you something important: either the codebase is unusual enough to need more guidance, or you need to provide better orientation hints. Both are valuable signals before you ask it to write code.
Do not skip this phase. The ten minutes you spend here save you thirty minutes of confused debugging later.
The Configure Phase
Agentic coding tools look for project-level configuration files — CLAUDE.md for Claude Code, AGENTS.md for Codex CLI. These files give the agent persistent context about your project: what language you use, what conventions you follow, how to build and test.
Many people skip this step entirely, planning to "set it up properly later." Others go overboard, writing pages of detailed instructions before they have any experience with what the agent actually needs to know.
Both approaches are wrong. Start with a minimal configuration — three to four lines that cover the absolute basics:
- What the project is (one sentence)
- What language and framework it uses
- One or two critical conventions (e.g., "use tabs not spaces" or "all functions must have docstrings")
That is it. You will expand this file over time as you discover what the agent gets wrong without guidance. But you need something in place from the start, because even a minimal configuration file measurably improves output quality. The agent stops guessing about basics and focuses its reasoning on the actual problem.
Think of it as a two-line README for your AI collaborator. You would not onboard a new teammate without any context. Do not onboard your agent without any either.
The Build Phase
Now you build something. But choose your task carefully.
The ideal first task has these properties:
- Real: It comes from your actual backlog, not a contrived exercise. A real bug to fix, a real test to add, a real function to document.
- Low-risk: If the agent gets it wrong, nothing catastrophic happens. Adding a test is low-risk. Refactoring your authentication system is not.
- Verifiable: You can check the result quickly. A test either passes or it doesn't. A bug fix either resolves the issue or it doesn't.
- Small: It should take the agent 5-15 minutes, not 45. You want time to iterate and reflect.
Good first tasks include:
- Add a unit test for an existing function
- Fix a small, well-understood bug
- Add type hints or docstrings to a module
- Implement a simple utility function that is on your to-do list
Bad first tasks include:
- Build an entire new feature
- Refactor a critical system
- Migrate to a new framework
- Anything involving secrets, credentials, or production data
During this phase, pay attention to the agent's process, not just its output. How does it break the problem down? What files does it read before making changes? Does it ask clarifying questions or charge ahead? Does it test its own work? These observations are more valuable than the code it produces.
The Reflect Phase
When the task is done — or when you have decided to stop — take ten minutes to reflect. This is where calibration actually happens.
Review every change the agent made. Use git diff to see exactly what was modified. Ask yourself:
- Correctness: Is the code right? Not just "does it run" but "would I approve this in a code review?"
- Style: Does it match your project's conventions? Did the agent pick up on patterns in your existing code?
- Scope: Did the agent do what you asked, or did it do more? Scope creep from agents is common and sometimes subtle.
- Process: How much back-and-forth did it take? Did you have to correct the agent, and if so, about what?
Write down your observations. Not a formal document — a few bullet points in a scratch file is fine. What worked well? What surprised you? What would you do differently next time? What should you add to your configuration file?
This reflection is not optional busywork. It is the mechanism by which your first hour converts from an experience into a skill. Without it, you will repeat the same mistakes in your second hour.
Cost Awareness
Your first hour will cost roughly $1-5 in API tokens. This is normal.
The orient phase is the most expensive part because the agent reads many files. The build phase varies depending on the complexity of your task and how many iterations it takes. Configuration and reflection cost almost nothing.
Do not optimize for cost during your first hour. The goal is calibration, not efficiency. Once you have a clear sense of what works, you will naturally become more cost-effective — providing better prompts, catching issues earlier, choosing tasks that play to the agent's strengths. Premature cost optimization leads to under-utilizing the tool, which is far more expensive than a few extra dollars in tokens.
That said, develop an awareness of cost from the start. Most tools show token usage or cost estimates somewhere in their interface. Glance at these numbers periodically. You are building an intuition for what "expensive" and "cheap" interactions look like, and that intuition will serve you well as you scale up your usage.
Key Takeaways
- Follow the five-phase framework: install, orient, configure, build, reflect.
- Use your real project from the very first session. Toy projects teach you nothing transferable.
- Let the agent read before it writes. Orientation dramatically improves output quality.
- Start with a minimal configuration file. Three lines now beats thirty lines next month.
- Choose a real, low-risk, verifiable, small task for your first build.
- Review every change with
git diff. This is where you calibrate trust. - Your first hour costs $1-5 in tokens. That is the price of calibration, and it is worth it.
- Write down what you learned. Reflection converts experience into skill.