You can own a state-of-the-art IDE and still use it like Notepad. The tool does not make you fluent; how you use it does. I see this often: a developer runs a fully-featured editor and writes code the same way they did in a plain text editor several years ago. The features are there, but they were never learned. The keyboard shortcuts sit unused, the refactor menu is unexplored, and the code-analysis warnings scroll past like background noise. The machine is waiting to help, but the human has not asked.
The first thing I do when I commit to an IDE is spend real time learning it. One month I focus on the main shortcuts: navigation, rename, extract method, run tests. The next month I look at one feature I have ignored. I search YouTube for a feature I never knew existed, or I open the documentation for a keybinding. Almost every time I find something that has been under my nose for years. That discipline pays back more than any new language because the tool amplifies everything else I learn.
The IDE also taught me C# again. I left .NET for several years to work in Ruby on Rails. When I came back, I had missed three major versions of C#. I wrote code the way I remembered it, and the IDE kept suggesting newer syntax. Pattern matching was one of those features. I was still thinking in nested if-statements and property checks: car, red, expensive. The tool offered a cleaner shape, and I accepted it. I did not memorize the syntax first; I learned it by letting the tool rewrite my old habit and then reading what it produced.
This is where the “Code Fluent” idea becomes practical. I am not fluent because I know every keyword. I am fluent because I can express an idea and let the tool handle the translation. The language becomes a detail. And that’s how I use AI tools, too.
When I pick up a new language or framework, the first thing I learn is how to write tests in it. In Ruby on Rails it was RSpec. In React it was Jest. The syntax changed, but the process did not. I describe behavior in English first, in given-when-then form, and then I figure out how to make the test pass. Once the test is green, I ask a colleague to look at the implementation. The test gives us a safety net while we restructure the code into something idiomatic. The tool lets me move fast; the test keeps me honest.
The same approach works with AI. I use it as a collaborator, not as a replacement for thinking. This is the arrangement I wrote about in AI in Your Loop Not You in Theirs: the machine helps with syntax while I own the intent. Last year I had to replace Fluent Assertions with a different assertion library in a codebase with almost 3,000 tests. Porting by hand would have taken weeks. With the tests already describing intent, and with AI helping rewrite the calls, the work took about six hours. The tests were the process. The AI was the accelerator.
There was one missing method in the new library. I knew how to write it by hand in C#, but that was not the best use of my time. I gave the AI the input, the output I wanted, and the intent. It returned an approach I had not considered, one that was simpler and faster than what I would have written. I still owned the decision. I still defined the goal. The machine found a path.
That balance is what Don Norman described in The Design of Everyday Things: a weak human plus a machine plus a better process beats a strong human plus a machine plus a bad process. The process in our work is the test, the clear name, the conversation with the user. The machine is the IDE and the AI. The human is the one who decides what problem is worth solving.
My current IDE is Devin Desktop. But the point is not the brand; in the last two years, I’ve gone through JetBrains Rider, Cursor, Windsurf, Claude Code, Devin Desktop. All of them have the same opportunity. Pick one, learn it, and let it teach you. Use AI to express intent faster, but own the intent. A hammer does not make you a carpenter, and an IDE does not make you fluent. The tool matters only when the human knows what to build. The tool exists to build something, not to be admired.
When the tool stops being the bottleneck, the people around you become the next curriculum. That is the subject of the next post.
Further reading
- A Workflow for Building Features with AI in the Loop
- AI in Your Loop Not You in Theirs
- AI Starts With Average – You Take It From There
- When Tools Cost Money and When They Cost Time
Leave a Reply