Office Hours — How would you learn AI-assisted development from the ground up?

How would you learn AI-assisted development from the ground up?

Start with one tool, not all of them

Pick a single coding agent and stick with it for two weeks. Use Claude Code, Cursor Agent, or GitHub Copilot with GPT-5.6 Sol. Don’t rotate. The learning curve isn’t about the model, it’s about understanding what context the tool sees, what it forgets between steps, and where it breaks. Switching tools every few days teaches you nothing except frustration.

During those two weeks, work on a real project—not a tutorial. Build something you’d actually use. The reason: AI agents fail differently on real codebases than they do on toy problems. You’ll hit missing context, hallucinated imports, architectural assumptions that don’t match your codebase style. These failures are your curriculum.

The gap between “works in a demo” and “works in production”

After two weeks, you’ll notice the agent succeeds on isolated tasks but struggles with multi-step flows. This is normal and teaches you the fundamental constraint: agents work best when success is verifiable fast. A test suite passing is verifiable. “Does this refactor maintain our architectural decisions” is not.

This means your real learning isn’t about prompt engineering. It’s about designing tasks so the agent has a clear signal of success. Add test coverage to parts of your codebase you want agents to touch. Run linters. Set up CI early. These aren’t nice-to-haves, they’re load-bearing.

Understand token economics and context management

Once your agent workflow is working, you’ll start noticing cost. Claude Opus 5 and GPT-5.6 Sol aren’t cheap at scale. A common pattern: you’ll save 30 minutes per task but the API bill is $50 per task. That’s still worth it for complex refactors. It’s terrible for trivial fixes.

This is where you learn to route. Use Claude Sonnet 5 or Gemini 3.5 Flash for simple completions. Reserve Opus 5 for tasks that actually need reasoning. Read one production cost breakdown—Databricks’ benchmark showing GLM-5.2 matching Opus 4.8 at 34% lower cost is the most useful reference out there right now. Then build a cost model for your own workload.

Context management is harder to learn than you’d think. You’ll write a 5,000 token prompt and the agent will hallucinate a method that doesn’t exist. Then you’ll strip it down to 800 tokens, add structure, and it works. The lesson isn’t “shorter prompts are better.” It’s that irrelevant context creates noise. Learn to frame problems as “here’s what I need done, here’s what succeeded last time, here’s what failed and why.”

Build observability before you need it

At some point you’ll deploy an agent to production and it will do something you didn’t expect. Maybe it generated code that looked correct but had a subtle bug. Maybe it called an API 50 times when it should’ve called it once. You’ll have no idea why because you didn’t log what the agent was thinking.

Start logging early. Every agent interaction should capture: the prompt sent, the response received, any tools called, any errors. Don’t wait until you’re debugging production. Do this in week three of learning. It’s boring but it’s the difference between “agent made a mistake” and “I can explain exactly what decision path led to the mistake.”

One concrete pattern: Claude Code’s trace feature, or OpenAI’s structured logging with agent runs, both show you reasoning steps. Use them. Screenshot them. They’re your documentation.

Learn the actual failure modes

Agents don’t fail because models are dumb. They fail because:

• They don’t understand your codebase structure and generate files in the wrong directory
• They see a function signature in a test file and assume it exists in production
• They hallucinate dependency versions that don’t match your lock file
• They get stuck in a loop calling the same tool with the same arguments
• They’re confident about something completely wrong (the file /app/models/user.py exists when it’s actually at /src/models/user.py)

These aren’t theoretical. Encounter them in order. Each one teaches you a specific thing to structure differently in your next task design.

Know what not to automate yet

Agents fail hard at:

• Tasks where “correct” is ambiguous. If you ask an agent to “improve this code,” it will make changes that compile and pass tests but violate your team’s conventions.
• Anything requiring subjective judgment about safety. An agent can’t tell you if a refactor is safe when your codebase has implicit contracts.
• Long dependency chains where early mistakes compound. If step 3 depends on step 2 succeeding, and step 2 is subtle, the agent will guess and propagate the error through steps 4 and 5.

Keep humans in the loop for these. The productivity gain of autonomous agents is real, but it’s not everywhere. The Remote Labor Index shows agents complete about 16% of real freelance tasks at professional quality. That’s not a bug. That’s the current frontier.

Move from prompt engineering to architecture

After a month, stop tweaking prompts. You’ve probably found 80% of the wins already. The remaining gains come from changing how you structure the problem. Add more tests. Add type hints. Document architectural decisions at the top of files. Use structured output formats.

This is the shift from “AI enthusiast” to “AI-assisted developer.” You’re not trying to trick the model into being smarter. You’re designing your codebase to be easier for agents to understand.

Build a mental model of what your agent actually sees

Here’s where most people get stuck. Your agent doesn’t “understand” your codebase the way you do. It sees whatever context you give it, and nothing more. If you give it a 100-line file without the 5 imports at the top, it will hallucinate those imports.

Spend a week just watching what context the agent is reading. Notice what it ignores. Notice what it misinterprets because it didn’t see the full picture. This intuition is more valuable than any tutorial. You’re learning to think like a context compiler, not a coder.

The curriculum in order

1. Weeks 1-2: Pick one agent, one real project, see what it can do.
2. Weeks 3-4: Add observability. Log everything. See what went wrong.
3. Weeks 5-6: Understand the failure modes. Deliberately trigger them.
4. Weeks 7-8: Stop trying to make agents autonomous. Design tasks they can complete verifiably.
5. Weeks 9-10: Build cost intuition. Use cheaper models where they work.
6. Week 11+: Architect your codebase for agent readability, not human readability.

Avoid the trap of benchmarks

SWE-Bench scores are gamed. OpenAI found 30% of SWE-Bench Pro tasks are broken. Databricks had to benchmark agents on their own million-line codebase because vendor numbers didn’t predict real-world performance. Don’t chase benchmarks. Build evals on your actual work.

Bottom line: Don’t study AI-assisted development in the abstract. Pick a real project, use an agent on it, deploy the result, hit it with real tests, and learn from failure. Your codebase is your curriculum.

Question via Hacker News