Last month I saw a post on HN with 81 points titled "Good Tools Are Invisible." The author argued that good tools should be transparent — when you hammer a nail, you don't think about the hammer's design philosophy, you just care whether the nail went in.
I sat with that for a while. Because it hit me that none of the AI coding tools I use daily actually feel "invisible."
They're getting smarter. They write more complex code. They handle bigger projects. They can fix bugs, run tests, and submit PRs on their own. But the more capable they get, the more I find myself thinking "why is this so damn hard to work with."
This isn't a deep technical analysis. It's just a bunch of thoughts from someone who's been tinkering with AI coding tools for over six months and keeps running into the same frustrations.
A Story About Wasting Two Hours
Last week I was working on a Next.js project and needed to change a page layout. Small project — three components total. I figured ten minutes max.
Turns out it took two hours.
Here's what happened: I told Cursor to "make the sidebar responsive — fixed width on desktop, hamburger menu on mobile." It did change the code, and it looked fine at first glance. But when I ran it, the hamburger menu button didn't work at all.
I checked what it had changed. It updated the UI component but forgot to wire up the click handler. I asked it "why doesn't the hamburger menu work?" and it said "let me check." Changed one line. Still broken. I asked again. Changed another line. Still broken.
On the fourth attempt, I looked at what it actually changed — it was modifying a function that didn't even exist in the codebase.
I fixed it myself in five minutes.
This wasn't the first time this happened. With Claude Code, I've seen it write beautiful code that completely ignores the project's existing conventions. With Copilot, I've gotten wrong import suggestions that passed linting but broke at runtime.
The tools are getting stronger, but the cost of communicating with them is going up too.
What's Actually Going Wrong
I think the core issue is this: AI coding tools are growing in capability faster than their interaction paradigms are improving.
Right now there are roughly three categories of AI coding tools:
The first is inline completion, like GitHub Copilot. You type code and it guesses what comes next. Simple. The interaction model is identical to normal coding — you don't need to learn anything new.
The second is conversational coding, like Cursor's Composer mode or Claude Code's terminal interface. You tell it what you want, and it modifies files or generates code. This is more complex because you have to learn how to communicate with the tool effectively. Good instructions give good results. Vague instructions give you half-finished code that needs manual cleanup.
The third is the agent model — OpenAI Codex, Cline, Aider. You give it a task and it goes off to read code, modify files, run tests, and submit PRs without you touching anything. Sounds amazing. Is currently the least reliable.
I use all three, mostly the third kind because I want to save time. But the time I "save" often isn't enough to cover the time I spend reviewing what it did.
There's a weird phenomenon here: the more powerful the tool becomes, the more effort you have to invest in making it work.
Copilot — open VS Code, done. Near-zero learning curve. Claude Code — you need to learn CLAUDE.md, configure MCP servers, understand context windows. Cline is even worse: Docker setup, API keys, sandbox configuration.
Every tool claims to be "ready out of the box." But once you open the box, you realize you need several hours of configuration, tuning, and rule-writing before it actually becomes useful.
Mistakes I've Made (So You Don't Have To)
Mistake 1: More CLAUDE.md Rules Doesn't Mean Better Results
When I first used Claude Code, I read tutorials saying "write a CLAUDE.md with your project conventions." So I wrote a massive file — code style, directory structure, testing requirements, naming conventions, the works. Probably 300+ lines.
What happened? Claude Code had to read that entire file every time it started, eating up half the context window. It would remember some obscure naming convention but forget the requirement I just gave it in the previous message.
I trimmed it down to twenty lines — just three core rules. Performance improved dramatically.
Lesson learned: rules for AI are a diminishing-return game. Give it a hundred rules and it might follow none of them. Give it three critical ones and it actually gets things right.
Mistake 2: MCP Server Configuration Feels Like Building with LEGO
MCP (Model Context Protocol) is a great concept — let AI tools call external tools. But configuring it is frustrating.
Want Claude Code to access your database? You need to:
- Install an MCP server
- Write a config file
- Point Claude Code's config at that server
- Hope the server stays running
The worst part? Each tool has its own MCP config format. Claude Code uses JSON, Cline uses YAML, Cursor has its own thing. Switch tools, reconfigure everything.
I once spent two hours debugging a custom tool integration. The problem was a missing quote in a config file. Two hours. For a quote.
Mistake 3: Sandboxes Are a Great Idea Poorly Executed
Both OpenAI Codex and Cline support sandbox modes — run AI code in isolation so your local environment doesn't get trashed. Good concept. Rough execution.
The sandbox environment never quite matches your local one. Dependency versions differ, environment variables are missing. Tests pass in the sandbox but fail locally, and vice versa.
And sandboxes are slow to start. You ask the AI to run a test suite and suddenly you're waiting one to two minutes for the environment to spin up. For a tool designed to speed things up, this is ironic.
Mistake 4: High-Quality Code Isn't Correct Code
This was my biggest wake-up call. I once asked Claude Code to build a full CRUD API service. The code was gorgeous — type-safe, proper error handling, logging everywhere. I looked at it and thought "honestly, this is better than what I would have written."
Tests passed. All of them.
Then I actually called the API. The user ID type was wrong — the database expects strings, the generated code used integers. The tests didn't catch it because I created the test data myself, and I used integers too.
I spent ages tracking down this bug. Not because the code was hard to read — quite the opposite, it was too clean, which made me lower my guard.
The takeaway: AI-generated code, no matter how polished, needs line-by-line review. This isn't distrust. It's that the cost of trusting it blindly is too high.
Mistake 5: Bigger Context Windows Aren't Always Better
A lot of people assume bigger context windows are strictly better — more information, right? My experience suggests otherwise.
Put an entire codebase into a 500K token window and the model "sees" everything, but it doesn't necessarily know what matters.
I ran an experiment: same task, small context window (only relevant files) vs. large context window (entire project). The small-window version was actually more accurate — the model's attention wasn't diluted by irrelevant code.
This doesn't apply to every scenario. But for medium and small projects, "precise feeding" beats "throw everything in."
Real Experience Across Different Scenarios
Scenario 1: Writing a New Feature
This is where AI coding tools shine. Give it a clear requirement and it can do most of the work.
I recently built a user permission system. Told it "I need admin, editor, and viewer roles — admin manages users, editor modifies content, viewer only reads." It generated role definitions, permission check functions, middleware, and配套 tests.
Ten minutes of review, fixed a couple of minor issues, deployed. Three to four times faster than writing from scratch.
This is what AI does well — generation. It's good at generating code from specifications.
Scenario 2: Modifying Existing Features
Much rougher territory. Modifying existing features requires understanding the codebase's overall structure, relationships between modules, and the historical reasons behind design decisions. AI doesn't always have this context.
I had a JWT-based login system and wanted to switch to OAuth 2.0. Claude Code changed the authentication code but missed all the dependent modules — caching layer, logging, error handling. I ended up spending twice as long fixing its omissions as it would have taken to do it myself.
Rule of thumb: AI tools are good at generating from scratch, bad at modifying existing code. Small tweaks are fine. Large refactoring? You're probably faster doing it yourself.
Scenario 3: Debugging
This is the most frustrating use case. Sometimes it helps quickly pinpoint issues. Often it gives you completely wrong suggestions.
I had a React component that rendered fine in development but flickered in production. I described the problem to Claude Code. It first suspected a state update issue — changed a few lines. Didn't work. Then it suggested a useEffect dependency problem — changed more lines. Still didn't work.
Turns out the issue was production tree-shaking. I'd marked a utility function as "unused" but it was dynamically referenced.
Claude Code's suggestions weren't wrong — state updates and useEffect dependencies are common React issues. But it didn't know my project structure or that tree-shaking was involved, so the advice was useless to me.
Scenario 4: Writing Tests
Surprisingly good at this. Test writing is inherently a "generation" task — you give it function signatures and inputs/outputs, it generates test cases.
I asked it to write tests for a data processing function. It generated boundary cases, edge cases, normal flows, and concurrency scenarios in one go. Quality was better than what I would have casually written.
One caveat: AI-generated test cases cover more scenarios, but some scenarios might be imaginary — not aligned with actual business requirements. Always review test cases after generation.
Why These Problems Won't Go Away Soon
Honestly, I don't think these are bugs. They're symptoms of being early in the curve.
AI coding tools are in an awkward phase: they can do a lot, but they can't do it reliably enough that you just tell them what to do and walk away.
Several factors contribute to this:
Context management is hard. Even with million-token windows, you can't dump your entire codebase and expect good results. You need filtering, compression, RAG — and deciding what's important takes effort.
Multi-file changes are error-prone. A single function? Fine. A feature touching five files? The model loses track of relationships between files unless you explicitly tell it about every relationship.
Toolchain fragmentation. Every tool has its own config format, protocol, and ecosystem. Cursor has rules, Claude Code has CLAUDE.md, Cline has MCP configs. No portable configuration.
Model non-determinism. Same prompt, different models — wildly different results. Same prompt, same model, two runs — sometimes different results. This unpredictability makes "reliable AI coding" genuinely hard.
These factors combined are why you feel like tools are getting more powerful but harder to use.
Practical Tips From My Experience
Tip 1: Keep CLAUDE.md Minimal
Three rules or fewer. Code style, directory structure, testing requirements — pick the most important ones. Everything else, rely on the model's built-in knowledge. Too many constraints confuse it.
Tip 2: Break Big Changes Into Small Steps
Don't ask the AI to modify ten files at once. Change one, run tests, confirm it works, then continue. Slower, but when something breaks you know exactly which step caused it.
Tip 3: Clean Up MCP Configurations Regularly
How many MCP servers are you actually using? I had seven or eight installed and ended up using two. The rest wasted configuration time and slowed down Claude Code's startup.
Tip 4: Write Comments for the AI
Sounds weird but it works. Add brief comments in your code explaining key design decisions and module relationships. When AI reads your code, those comments help it understand context better.
Tip 5: Accept That AI Isn't Magic
This is the most important one. AI coding tools can improve your efficiency, but they don't replace your thinking. You still need to understand code, architecture, and testing. Otherwise you can't tell if what it produces is right.
Tip 6: Match the Tool to the Task
Copilot for autocomplete, Claude Code for new features, Cline for testing and deployment. Don't expect one tool to solve everything.
Tip 7: Always Commit Before AI Makes Changes
I've been doing this for six months and it has saved me countless times. If the AI breaks something, one git revert fixes it. Don't skip this step.
A Few Mainstream Tools Compared
Different tools have different pain points. Here's my experience with the major players.
Cursor
The biggest advantage is "it's right there in the editor." No switching windows, no opening terminals. It sits on top of VS Code and adds AI. Smooth experience.
Weaknesses: the Composer mode lets you switch between files, but when you need to change a lot, it often modifies things you didn't intend. Once I asked it to change a page's styling and it accidentally modified another page's layout too.
Keyboard shortcut conflicts with VS Code are annoying. Cmd+K and Cmd+L behave differently, and your fingers keep hitting the wrong ones.
Claude Code
Strength: intelligence. Its code comprehension is genuinely better than Copilot. Give it a complex requirement and it usually produces a reasonable solution.
Weakness: configuration is painful. CLAUDE.md writing, MCP server setup, context window management — every step requires experimentation. And configurations aren't permanent: change your project structure and you might need to update everything.
Terminal-based interaction is also not beginner-friendly. You need to be comfortable typing commands in a terminal, which is a barrier for people used to GUI editors.
Cline
Highlight: autonomy. Give it a task and it reads code, modifies files, runs tests, commits to git. Highest level of automation of any tool I've tried.
Cost: you need to spend a lot of time reviewing its work. It changes too many files for line-by-line review. Usually I do a quick scan, deploy, and fix bugs later.
The sandbox feature is a double-edged sword — isolates your environment but causes test reliability issues due to environment mismatches.
GitHub Copilot
Simplest and weakest. Simple enough that you barely need to learn anything. Weak enough that it's basically autocomplete on steroids.
But it's stable. Same context, similar results every time. Unlike Claude Code which can be brilliant one moment and dumb the next, Copilot is consistently mediocre — which is sometimes exactly what you want.
For day-to-day coding, Copilot's completion speed and quality is actually sufficient. You don't need it for architecture design or refactoring. It's a smart autocomplete, and that's fine.
A Slightly Optimistic Outlook
Despite all the problems I've listed, I genuinely think AI coding tools have a good future.
The reason is straightforward: we're early.
Right now, AI coding tools are in the "teach the AI how to work" phase. You write rules, configure environments, tune parameters. This reminds me of early Git — you memorized commands like git reset --hard, git rebase -i, git cherry-pick, each with subtle differences that mattered.
Nobody finds Git hard to use now. Not because Git got simpler, but because the ecosystem around it adapted. VS Code has built-in Git. GitHub added a GUI. Various tools turned command-line operations into buttons.
AI coding tools will go through the same evolution. Maybe not this year, maybe not next, but eventually you'll open your editor and the AI will just be there — no configuration needed, already knowing your project structure, code style, and testing framework.
Then "good tools are invisible" stops being a slogan and becomes reality.
I've also noticed some positive trends. More tools are starting to interoperate. MCP itself was designed to standardize external tool interfaces for AI. The current implementations are rough, but the direction is right. If all AI coding tools eventually share the same configuration format, "out of the box" becomes meaningful.
Some newer tools are also experimenting with progressive disclosure — exposing simple features first and unlocking advanced options as you get comfortable. Good approach. And some tools are offering project templates that auto-generate AI configs based on your tech stack. The quality varies, but the intent is right.
A Quick Meta-Moment
Funny thing — I wrote this article in a plain text editor without any AI assistance. Then I ran it through Claude Code to polish a few sentences. It cleaned up some wordy expressions, but it also "corrected" my intentionally casual phrasing into more formal language. I reverted those changes.
It made me realize that the best state for AI coding tools might not be "doing it for you" but "helping you do it." Suggestions, not substitutions. Automation for repetitive work, not for judgment calls.
That state hasn't arrived yet. But it's coming.
I'm planning to dig into AI coding tool automation workflows next — see if I can simplify the configuration process. Drop a comment if you have thoughts.
FAQ
Q: So do you still use AI coding tools?
Yes. Obviously. I haven't abandoned any of them despite all the complaints above.
My usage pattern changed though. Instead of letting AI do everything, I now treat it more like a "senior assistant" — it handles repetitive work, I make key decisions.
For a new API endpoint, I let AI generate the base code and add business logic myself. For tests, I let AI generate test cases but create test data myself. For debugging, I let AI analyze possible causes but decide the final fix myself.
This balances efficiency with quality.
Q: When will AI coding tools actually become "easy to use"?
Hard to answer. "Easy to use" is subjective — different people have different baselines.
For someone with years of development experience like me, current tools are probably sufficient. For a beginner, they're still too complex.
I'd guess two to three years before toolchains mature, configurations standardize, and models stabilize enough for true "out of the box" experiences.
Q: Any recommended learning path?
Start with Copilot. Lowest barrier to entry — install the extension and you're going.
When Copilot isn't enough, try Cursor or Claude Code. More powerful, more configuration.
Cline and OpenAI Codex are for experienced users who understand sandboxes, MCP, and git workflows.
Don't jump straight to "fully autonomous." Start small — let AI write a function, gauge its quality, then gradually expand.
Q: What about "AI will replace programmers"?
Exaggerated. AI can write code, but it can't understand business requirements, design system architecture, or make technology choices. Those still require humans.
Even if AI writes code, someone has to maintain it. If AI generates a codebase that nobody understands, who fixes bugs?
My take: AI won't replace programmers. But programmers who use AI will replace programmers who don't.
Q: Any specific configuration tips that actually help?
Yes, a few things I've found useful in practice.
First, write a "project readme" — a short document describing the tech stack, directory structure, and known gotchas. Put it in the project root and have the AI tool read it before each conversation.
Here's what my PROJECT.md looks like for a Next.js project:
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
| 12 | |
| 13 | |
| 14 | |
| 15 | |
| 16 | |
| 17 | |
| 18 | |
| 19 | |
With this file, Claude Code understands the project context every time it starts without me repeating myself.
Second, use .gitignore-style exclusions. AI tools sometimes read node_modules, .next, and other build artifacts, wasting context window on useless files. Adding exclusion rules in your config makes an immediate difference.
Third, use git blame. After AI modifies code, check who wrote each line and when. If a section has a "TODO: refactor" note from three months ago, the AI will be more careful when touching related code.
Q: Is this article too pessimistic?
Maybe. I did spend more time on problems than solutions. But I think it's important to show the other side of AI coding tools — not just "what they can do" but "what they still can't do well."
This isn't pessimism. It's pragmatism. Knowing a tool's limitations is the only way to use it effectively.
I also constantly debate whether to let AI handle a task or do it myself. My general rule: if it doesn't involve core business logic, AI does it. If it does, I write the core and let AI handle tests and edge cases.
For example, a user registration page? AI can handle it. Payment flow? I write the core logic and let AI write the tests.
Ultimately, AI coding tools feel less like "assistants" and more like "colleagues who need frequent code review."