Back to Blog
·3 min read

Building with AI Agents: Lessons from Real-World Projects

What I learned integrating AI coding agents into my daily workflow and how it changed the way I think about software architecture.

AI Dev
AI
agents
development

Building with AI Agents: Lessons from Real-World Projects

I have been using AI coding agents in my daily workflow for the better part of a year now. Not as a novelty, not as a toy -- as a genuine part of how I ship software. Here is what I have actually learned, stripped of the hype.

The Shift in How I Think About Architecture

The biggest change was not in how fast I write code. It was in how I plan it. When you have an agent that can scaffold an entire feature from a well-structured prompt, you start spending more time on architecture decisions and less time on implementation details. That sounds obvious, but the practical effect is real: I now write design documents before I write code, even for small features.

A typical session looks like this. I describe the data flow, the API contract, and the edge cases I care about. Then I let the agent generate the initial implementation.

// I start with a clear interface contract
interface BlogPost {
  slug: string;
  title: string;
  description: string;
  date: string;
  category: "ai-dev" | "personal";
  tags: string[];
  published: boolean;
  content: string;
}
 
// Then I describe the function signature and constraints
// "Parse MDX files from disk, extract frontmatter, sort by date descending"

The agent handles the boilerplate. I handle the decisions.

Prompt Engineering Is Just Good Communication

People overcomplicate prompt engineering. The best results come from the same skills that make you good at writing a Jira ticket or a technical spec: be specific about what you want, state your constraints, and give examples of expected output.

What does not work is vague instructions like "build me an API." What does work is something like: "Create a GET endpoint at /api/posts that returns published blog posts sorted by date. Use the existing getPublishedPosts utility. Return 404 if the content directory is missing."

Where Agents Struggle

They are not great at understanding your codebase conventions unless you tell them. I spent time setting up project-specific context files that describe our patterns -- how we handle errors, where we put shared types, our naming conventions. That upfront investment pays off every single session.

Agents also struggle with multi-step debugging. They can fix a type error, but tracking down a race condition across three services still requires a human staring at logs.

Practical Takeaways

After months of daily use, here is what stuck:

  • Write better specs, not better prompts. If your spec is clear, the prompt almost writes itself.
  • Review everything. I treat agent output like a junior developer's PR. Usually solid, occasionally wrong in subtle ways.
  • Keep context small. Huge files confuse agents. I refactored toward smaller, focused modules partly because it made AI-assisted work more effective.
  • Use agents for the boring parts. Tests, type definitions, data transformations, boilerplate. Save your brain for the interesting problems.

The tools are getting better fast. But the developers who benefit most are the ones who already think clearly about what they want to build. AI agents amplify your engineering skills -- they do not replace them.