Beyond the Hype: What I Actually Learned Using Terminal-Based AI Coding Agents

Six months ago, at 2 AM, I found myself staring at a terminal window, watching an AI agent refactor a 1,200-line authentication module I had written two years earlier and barely understood anymore. It caught three edge cases I had missed in the original implementation, added proper error handling, and wrote better tests than I would have. I felt a strange mixture of relief and existential unease that many developers I know are grappling with right now.

This is not a product review. This is a reflection on what actually happens when you integrate AI coding agents into your daily workflow — the good, the surprising, the genuinely useful, and the parts nobody talks about in marketing pages.

I write this from the perspective of a full-stack developer with twelve years of experience, someone who learned to code when Stack Overflow was the only “AI assistant” we had. What follows is unvarnished and based entirely on my own work across several production projects.

The Day I Stopped Writing Boilerplate

I want to start with a specific moment because it captures something important. In February, I was tasked with building a REST API for a client — nothing exotic, just CRUD endpoints with validation, authentication middleware, rate limiting, and the usual suspects. Normally, this kind of work takes me three or four days when I factor in the thinking, the typing, the testing, and the inevitable back-and-forth with the frontend team.

I decided to experiment. Instead of writing the first endpoint myself, I opened my terminal, pointed the AI agent at my project directory, and typed:

“I need a REST API for a user management module. Express.js, TypeScript, Postgres. Follow the patterns in the existing codebase. Include rate limiting, input validation, and JWT middleware. Write the schema migration too.”

What happened next was not magic, but it was close. The agent read my project structure, examined how I had organized routes in other modules, checked my existing Prisma schema, and proposed a plan. I reviewed it — it had made reasonable architectural choices that matched my preferences because it had context from my AGENTS.md file, a document I had written six weeks earlier describing my coding conventions and project structure.

I approved the plan. The agent generated the router, controller, service layer, validation schemas, tests, and database migration. It took eleven minutes. I spent another two hours reviewing, tweaking, and ensuring I understood every line. What would have been three days became half a day, and I was not rushing.

This is not about speed. It is about what happens to your brain when you stop doing the mechanical parts of coding and focus entirely on architecture, correctness, and edge cases. I caught a subtle race condition in the agent’s initial implementation that I might have missed if I had been exhausted from writing boilerplate for hours. The AI did the typing; I did the thinking.

What Terminal-Based Agents Actually Do Well

After months of daily use, here is what these tools genuinely excel at, separated from the marketing noise.

Understanding Entire Codebases in Seconds

The first time I pointed an agent at a new project — a React and Node.js monorepo with 600 files — and asked “explain how authentication works from frontend to database,” I expected a vague summary. Instead, it traced the login form component, the API call, the middleware chain, the JWT verification logic, the refresh token rotation, and the session cleanup cron job. It noted that the refresh token logic had a potential timing vulnerability and suggested a fix.

For onboarding, this is transformative. I have joined teams where it took three weeks to understand the system well enough to be productive. With an AI agent that can ingest the entire codebase in seconds, the ramp-up time shrinks dramatically. You still need human context — no AI will explain why the original developer chose a specific architectural pattern in 2019 — but the mechanical understanding happens instantly.

Automated Refactoring That Respects Conventions

In March, I migrated a medium-sized codebase from JavaScript to TypeScript. This is the kind of task I normally dread: tedious, error-prone, and requiring strict attention to detail across hundreds of files.

I gave the agent access to one module, asked it to add types while following my existing patterns, and watched. It converted JSDoc comments to TypeScript interfaces, inferred types from runtime usage, and flagged places where the code was ambiguous enough that human judgment was required. Those flags were the key — the agent knew what it did not know.

I reviewed each module after conversion, and the error rate was remarkably low. More importantly, the agent had applied my project’s existing type naming conventions consistently. It had learned from my AGENTS.md that I prefer type over interface for props and that I always export types from barrel files. This contextual awareness is what separates capable AI tools from simple autocomplete.

Debugging Production Issues With Context

Last month, a client reported that their checkout page crashed when a user had items from a previous session in their cart. The error log was vague — a null reference somewhere in the cart merging logic. I pasted the stack trace into the terminal, and the agent traced it through five files, identified that the cart normalizer was not handling stale product IDs after inventory cleanup, and suggested a fix.

What impressed me was not the bug finding — I would have found it eventually — but that the agent also noticed a similar pattern in the wishlist service and flagged it preemptively. It found a bug I had not been looking for.

The Parts Nobody Mentions

Now for the honest part. These tools are not magic, and using them effectively requires developing skills that nobody taught us.

You Still Need to Know What You Are Doing

The biggest misconception I see is that AI agents will let junior developers operate at a senior level. This is dangerously wrong. When the agent generates incorrect code — and it does, regularly — you need enough experience to recognize the problem. I have seen it create subtle SQL injection vectors, misunderstand business logic, and write tests that pass but test nothing meaningful.

Using an AI coding agent without understanding the code it produces is like accepting medical advice from someone who skipped medical school. The tool amplifies your existing ability; it does not replace it.

The Plan-Revision Cycle Takes Practice

I wasted hours early on because I would jump straight into “build mode” and then spend time undoing incorrect implementations. The discipline of reviewing the plan first, challenging assumptions, and refining the prompt feels slower in the moment but is far faster overall. I now spend as much time crafting my initial prompt as I would explaining a task to a colleague — because that is essentially what I am doing.

Context Management Is a Real Skill

The quality of the agent’s output depends almost entirely on the context you give it. My AGENTS.md file is now the most important document in my projects. It describes coding conventions, architectural decisions, testing philosophy, and — crucially — explains why certain choices were made. Without this, the agent defaults to generic patterns that may not fit the project.

I update this file as the project evolves. It is a living document, and treating it as such pays dividends.

Terminal Tools Are Not for Everyone

I work in the terminal because I am comfortable there. Colleagues who prefer graphical IDEs sometimes struggle with terminal-based agents, not because the tools are bad, but because the interface adds a cognitive overhead they do not need. The right tool is the one that fits your workflow, not the one with the most GitHub stars.

What Privacy-Conscious Developers Should Know

This matters to me, and it should matter to you. Many AI coding tools send your code to remote servers for processing. If you work in finance, healthcare, or any domain with compliance requirements, this is a non-starter.

The tools I use are configured to work with local models when needed. I can run an instance of Llama or Mistral through Ollama, point the agent at it, and keep all my code on my machine. For less sensitive work, I use cloud providers with explicit data retention policies that I have actually read. This flexibility — choosing where your code goes — is not a luxury feature; it is a professional requirement for many developers.

I also appreciate tools that do not automatically share conversations or store my code. The default should be private, and sharing should require an explicit action. This aligns with how I think about security: opt-in, not opt-out.

Practical Advice After Six Months

Here is what I would tell my past self, six months ago.

First, write your project context file before you need it. The AGENTS.md or equivalent document is not optional. Spend an hour writing down your conventions, your preferred patterns, your testing philosophy, and your architectural boundaries. Update it when decisions change. This document is the difference between an agent that feels like a colleague and one that feels like a random code generator.

Second, treat the agent like a junior developer you are mentoring. Be specific. Give context. Review its work carefully. When it misunderstands something, explain why. This mindset — collaborative rather than adversarial — produces better results and less frustration.

Third, use the undo feature without hesitation. If the agent goes in the wrong direction, stop it immediately and refine your instructions. Do not try to manually fix a cascade of bad changes. The undo capability is there for a reason.

Fourth, customize the tool to your preferences. Change the theme, configure the keybindings, set up your preferred formatters. The more the tool feels like your environment, the less friction you will experience.

Fifth, and most importantly, stay curious and skeptical. The field is moving fast, and today’s best practice is tomorrow’s outdated advice. Experiment constantly. Question everything — especially claims of revolutionary breakthroughs. The tools that matter are the ones that help you do your actual work, not the ones with the most impressive demos.

Looking Forward

I do not know where this is heading, and anyone who claims they do is probably selling something. What I do know is that the developer who learns to work effectively with AI tools will be dramatically more productive than the one who ignores them — and also more effective than the one who blindly trusts them.

The sweet spot is in the middle: informed, skeptical, and practical. Use the tools. Understand them. Question them. And never stop being the developer who knows why the code works, not just that it appears to work.

That is where I am after six months. Ask me again in another six, and I will probably have changed my mind about half of this. That is the nature of the field, and honestly, I would not have it any other way.

---

The author is a full-stack developer and technical lead who has been building web applications since 2014. He writes about developer tools, software architecture, and the evolving relationship between programmers and AI.