The Micromanagement of Code

Eighteen Years of IDEs

I want to be clear about something before I make the argument: I loved IDEs. This is not the essay of a person who never learned to use them. I spent eighteen years in them. I have the muscle memory and the opinions to prove it.

It started with Borland. Turbo C++, then Delphi - tools that felt, at the time, like magic. A single environment that compiled, ran, and debugged your code, with an interface that made you feel like a professional even when you were a student writing your first linked list. Borland taught me that the tool shapes the thinking. A good IDE shapes how you conceive of the act of writing code.

Then Eclipse, which I hated and used for years, because the Java ecosystem demanded it. Eclipse was the IDE as bureaucracy: plugin conflicts, memory leaks, configuration files nested inside configuration files. But it worked. It indexed your entire codebase and let you navigate it like a hyperlinked document, which was revolutionary if you were working on anything larger than a toy project.

Then JetBrains, which was a revelation. IntelliJ, WebStorm, PyCharm. Each one felt like having a senior engineer looking over your shoulder, catching your mistakes before you made them, suggesting improvements you had not thought of. The refactoring tools alone were worth the subscription. I could rename a method across a hundred files with a single keystroke and know, with certainty, that nothing would break. That certainty was intoxicating.

I am telling you this because the argument I am about to make (that you might not need an IDE anymore) is not coming from ignorance. It is coming from eighteen years of deep, genuine appreciation for these tools, followed by the gradual and then sudden realisation that I was reaching for them out of habit, not necessity.

The Escape Route Problem

This is the manager who stays late fixing their direct report's work instead of spending thirty minutes explaining what good work looks like. It feels faster. It feels more reliable. And it guarantees that the direct report never improves, because they never have to.

Here is what happens when you use an LLM to write code while keeping your IDE open. The LLM generates something. You paste it in. You read through it, because the IDE makes reading code comfortable and fast, and you spot something. A variable name you do not like. A slightly different approach you would have taken. An edge case the LLM missed.

So you fix it. A quick edit here. A rename there. Maybe you refactor a function because you can see, in the IDE's structure view, that it is doing too much. The code improves. You feel productive. You feel like you are adding value.

But you have just done something insidious. You have taught yourself that your job is to clean up after the LLM. You have established a workflow where the LLM does the rough work and you do the finish work, and this feels natural because it maps onto how you have always worked: rough draft, then revision. The IDE is your revision tool, and it is very good at it.

The problem is that this workflow has a ceiling. You will never get better at instructing the LLM because you never need to. The escape route is always there. Why spend twenty minutes crafting a precise prompt when you can spend five minutes fixing the output? Why invest in better context documents and rules files when you can just eyeball the code and patch it?

The IDE is the escape route. And escape routes, by their nature, prevent you from developing the skills you would need if the escape route did not exist.

What I Do Instead

I closed the IDE. Not as a philosophical statement; as a practical experiment. I wanted to see what would happen if I removed the escape route and forced myself to work through the LLM for everything.

Here is what my workflow looks like now. The only files I edit by hand are Markdown files. Rules documents that tell the LLM how the project is structured. Context files that describe the domain. Prompt templates for recurring tasks. These are the instructions, the equivalent of the briefing document you give a new team member before they start working.

The LLM generates the code. All of it. I do not open the generated files in an editor. I do not read them for style. I do not rename variables or adjust formatting. If the output is wrong, I fix the instruction, not the output. This distinction is the entire point.

Tests verify the code. Not me - the tests. If the tests pass, the code is correct by definition. If the tests fail, I do not open the file to see what went wrong. I tell the LLM what failed, give it the error output, and let it fix its own work. If it cannot fix it, I improve the context: more constraints, clearer specifications, better examples. Then try again.

Version control tracks everything. CI/CD deploys it. GitHub Actions runs the tests on every push. The entire pipeline from instruction to production involves zero manual code editing.

In the past year, I have built entire domain-specific tools this way. Applications running live, handling real users, in production. Not prototypes. Not demos. Working software, built without once opening the source code in an IDE.

The Virtuous Cycle

Something unexpected happens when you remove the escape route. Your instructions get better. Not gradually. Rapidly. Because every failure now costs you real time. You cannot just fix the output. You have to fix the instruction. And fixing the instruction means understanding, precisely, what went wrong in the communication between you and the LLM.

Was the context insufficient? Add more. Was the constraint ambiguous? Make it specific. Did the LLM make an assumption you did not anticipate? Add an explicit rule that prevents it. Each fix to the instruction set is permanent. It applies to every future generation. You are not patching code. You are patching the process that produces code.

This is compound interest applied to prompt engineering. Every improvement makes every subsequent project slightly easier. Your rules files get more precise. Your context documents fill in the gaps the LLM was guessing around. After six months, the LLM produces correct code on the first try more often than not, because your instructions have become good enough that the LLM does not need to guess.

Compare this to the IDE workflow, where every manual fix is a one-time expenditure. You fix the variable name. It stays fixed. But the next project, the LLM will name variables badly again, because you never told it how you want them named. You refactored that function. Good. But the next function will have the same problem, because you fixed the symptom, not the cause.

The constraint (no IDE, no manual edits) is what creates the cycle. It is the forcing function that converts every failure into a permanent improvement. Remove the constraint and you lose the cycle. Keep it and the cycle accelerates.

But I Need to See My Code

This is the objection I hear most often, and it deserves a serious answer. The concern is real, but it stops short.

When developers say they need to "see" their code, they mean they need to understand what the code is doing. Is it structured correctly? Does it handle edge cases? Is the logic sound? These are legitimate needs. The question is whether an IDE is the best tool for satisfying them.

Reading code in an IDE is a human audit. You are visually scanning the code, building a mental model of its behaviour, and checking that mental model against your expectations. This is valuable. It is also unreliable. You miss things. You skim. You make assumptions based on variable names. You see what you expect to see rather than what is actually there. Every experienced developer has missed a bug that was staring at them from a screen they had been looking at for an hour.

Tests are a machine audit. They check behaviour, not appearance. They do not care what the variable is named or how the function is structured. They check that given input X, the output is Y, and they do this every time, with zero fatigue and zero assumptions. If your tests are comprehensive enough, they are a more reliable summary of your codebase than anything you can derive from reading the source.

The real objection, reframed honestly, is: "My tests are not good enough to tell me what my code is doing." And that is a solvable problem. It is a testing problem, not a tooling problem. Fix the tests and the need to visually inspect the code diminishes. Make the tests comprehensive and the need disappears.

I am not saying never read the code. I am saying that if reading the code is the primary way you verify correctness, you have a gap in your process, and the IDE is masking it.

The Shift

I am describing a change in the nature of the work, not merely in tooling. Let me be explicit about what that change is.

For the past fifty years, software development has been fundamentally about writing code. The core skill was translating intent into syntax: taking what you wanted the machine to do and expressing it in a language the machine could execute. Everything else (the IDEs, the debuggers, the linters, the formatters, the version control systems) was infrastructure built to support that core activity.

That core activity is shifting. It is moving from "writing code" to "instructing systems that write code." The translation layer is changing. You are still translating intent, but the target language is no longer Python or JavaScript or Rust. It is natural language, structured as rules and constraints and context, aimed at a system that generates the code for you.

This changes what good looks like. The skills that made someone a great developer in the old model are depreciating. Deep knowledge of syntax, fluency in design patterns, the ability to hold a large codebase in working memory: still useful, but no longer the core of the work. The skills that matter in the new model are different: clear communication of intent, precise specification of constraints, design of verification systems, and the discipline to fix the instruction rather than the output.

The IDE was built for the old skill set. It was a power tool for people who wrote code by hand. If you are still writing code by hand, it is still the best tool for the job. But if you are moving toward the new model (and I believe most developers will, sooner than they expect) the IDE becomes counterproductive. It is the escape route that prevents you from developing the skills the new model demands.

All you need is a text editor, version control, and good tests. The simplicity is not a limitation. It is the point.