From user to implementer: My journey understanding coding agents

From user to implementer: My journey understanding coding agents

January 17, 20266 min read0 viewsAI
#user#implementer#journey#understanding#coding

I went from using coding agents as a user to building my own from scratch. Here's what I learned about LLM integration, human-in-the-loop workflows, and why understanding the underlying architecture really matters.

Hey everyone, I wanted to share my experience trying to understand how coding agents actually work over the past few months. It's been kinda frustrating but also really rewarding, going from just using these tools to actually getting how they're built.

The Starting Point: From Confusion to Curiosity

So I started out using Cursor everyday, you know, just like everyone else. Then I heard about Claude Code and thought I'd give it a shot. But the more I used these tools, the more I realized they're basically magic to me. I had no clue what was happening under the hood.

That's when I got really curious. I didn't want to just be another user anymore, I actually wanted to understand the principles behind how coding agents work.

It’s a bit like wondering how the brain works, isn’t it? We use it every second, but the actual mechanics are still largely a mystery. I think that’s what drove me the desire to peek behind the curtain and see the gears turning.

The Learning Path: Struggling Between Two Extremes

So I started looking for resources to learn, and I found this weird gap in what's available. It's like everything is either super basic or ridiculously complex.

On the basic side:

  • I found tutorials like "Building an Agent" (ampcode.com) which were actually pretty good to get started
  • But they're basically just demos, you know? Like they show you the basics but you're still missing the bigger picture
  • After finishing them, I was like ok, but how do you actually build something real with this?"

On the complex side:

  • I dove into open-source projects like reverse-engineered Claude Code, Gemini CLI, Crush, Neovate Code
  • These are the real deal production tools that people actually use
  • But holy crap, the codebases are massive (we're talking tens of thousands of lines) and the architecture is just overwhelming
  • For someone trying to learn, it's almost impossible to figure out what's actually important vs what's just implementation details

I felt really stuck. I wanted to understand how these things actually work, but everything was either too simple to be useful or too complex to learn from.

It was like trying to learn chess by reading the rules versus watching a grandmaster game. One's too simple, the other's impossible to follow without years of experience. There’s gotta be a middle ground, right?

The Turning Point: The Answer Was to Build It Myself

After being stuck for a while, I had this thought what if I just built one myself?

I wasn't trying to create the next big thing or compete with existing tools. I just wanted to:

  • Build something that was complete but not overwhelmingly complex
  • Actually understand what each part does and how they connect
  • Get the core patterns without all the extra production complexity

I figured if I could build a simplified version, I could then reverse engineer the more complex ones. It’s like learning to play badminton before trying to win Wimbledon. You need to master the fundamentals first.

What I Actually Learned from Building It

Honestly, implementing this myself was when things finally clicked for me.

LLM and Tool Integration

  • Figuring out how to actually make LLMs call tools reliably
  • What to do with tool results and how to handle errors
  • When to run things in parallel vs when to do them one by one

Why MCP Actually Matters

  • Before I thought MCP was just more complexity, but then I got why we need standard ways for tools to talk to each other
  • How to make different services work together without going crazy
  • Why extensibility is actually important even in small projects

Human-in-the-Loop Stuff

  • When you actually need to ask the user for input vs when you can just do things automatically
  • How to make confirmation flows that don't annoy people
  • The balance between automation and keeping humans in control

Putting It All Together

  • Configuration management, permissions, sessions all the boring but necessary stuff
  • Error handling (so much error handling...)
  • Making both a CLI and an interactive UI that actually work together

The biggest challenge was definitely error handling. You realize how many things can go wrong when you're orchestrating LLMs and external tools. It's like trying to coordinate a dance with a bunch of unpredictable partners. You need to be ready for anything.

What Actually Clicked for Me

The biggest things I realized:

  1. Complexity comes in layers you can't really understand this stuff until you see all the different levels and why each one exists
  2. Actually building it is way better than reading about it I learned more from a few weeks of coding than months of reading tutorials
  3. The sweet spot is balance you need something complete enough to be real, but simple enough to actually understand

It's a bit like understanding the human brain. You can read all the textbooks you want, but until you start dissecting (metaphorically, in this case!), you don't really grasp the intricate connections.

If You're Trying to Learn This Stuff Too

For anyone else going down this rabbit hole, here's what worked for me:

  • Don't just use the tools try to understand what's actually happening
  • The middle ground is hard to find most stuff is either "hello world" or production-scale complexity
  • Build your own version, even if it's simple you'll learn SO much
  • Focus on the "why" more than the "how" the architectural decisions are more important than the specific code

This whole experience didn't just teach me how coding agents work it actually changed how I think about building complex systems in general. It's made me appreciate the elegance (and sometimes inelegance) of well-designed architecture.

Anyway, if anyone's interested in seeing what a middle-ground implementation looks like, visit curiyashman.com and interact with my persona And if you have any ideas on how to make it even better, I'm all ears!

Comments

Loading comments...