What AI coding taught me about micromanagement
About two years ago, developers I respected started landing on opposite sides of AI coding. Some picked up the tools immediately. Others looked at the output and recoiled. Each group found the other one baffling.
I was somewhere in the middle, and for a while I couldn't understand why the disagreement was so sharp. The code explained part of it. Early AI output duplicated logic, ignored established abstractions, and still produced a convincing demo. Experienced engineers had good reasons to be wary.
But our behavior around the tools bothered me more. We had complained for years about managers who prescribed every step, buried teams in documentation, and confused more instructions with better leadership. Then we got an assistant that couldn't push back, and many of us became exactly that manager.
We became the managers we hated
It began with prompts that read like supervision notes. Use this helper. Call that interface. Put the file here. Don't forget the logger. Handle this edge case in exactly this way.
That level of detail was sometimes necessary. Early tools needed more help, and a tightly scoped task still benefits from precise constraints. But the habit remained as models improved. We kept describing the implementation when we could have described the outcome and let the tool inspect the codebase.
Then came the context files. CLAUDE.md, AGENTS.md, system prompts, and rules files grew to hundreds of lines. We filled them with architecture, conventions, preferences, and edge cases. It looked thorough. It also looked a lot like the manager who hands a developer a fifteen-page brief, interrupts with more advice, and leaves no room to think about the problem.
A study on repository context files found that the files didn't generally improve task success rates and raised inference costs by more than 20% on average. The authors found them useful for non-standard practices, but argued that teams should evaluate them rather than assume they improve performance. A separate study on agent skills approached the problem differently and found focused packages with no more than three modules performed better than larger or exhaustive bundles.
The parallel with management is uncomfortable. Extra context can pollute the signal. Old instructions can pull work in the wrong direction. Contradictory rules make the result unpredictable. People have the same problems, although they're better able to question the brief.
Clear goals, the few constraints that matter, and enough room to work tend to produce a better conversation with both people and tools. We already knew that from management. AI exposed how quickly we'd abandon it when the other side couldn't tell us to stop micromanaging.
The old engineering lessons came back too
The same amnesia showed up in the code. Developers who would never copy and paste a utility function accepted the same generated logic in three files because it arrived quickly. We had to tell the tool to use the existing service, respect an interface, combine related code, and stop inlining helpers that were already there.
AI coding tools moved from completing a line to generating functions, classes, and modules. With each jump, the familiar concerns returned: boundaries, duplication, coupling, naming, and tests. The tool changed the pace of production. It didn't remove the reasons those practices existed.
The early divide makes more sense to me through that lens. The skeptics saw genuine damage to maintainability. The people using the tools saw a learning curve and a large increase in what they could produce. Both observations could be true at once.
A brief return to waterfall
Early prompts often looked like specifications handed over a wall. "Create a function called calculateTotal that takes an array of LineItem objects, each with price and quantity fields, and returns the sum of price times quantity for each item." Then came reminders about the logger, error handling, file location, and repository pattern.
That worked reasonably well for small, defined tasks. For broader work, I started seeing better results from prompts such as: "Users need to see their order total update in real time as they change quantities." The model still needs constraints and a definition of done, but the outcome leaves room to inspect the existing system and choose an approach.
People who had spent years trying to replace big upfront specifications with collaboration were recreating the old hand-off in their prompts. I did it too. Exact phrasing and token placement felt like the crucial skill because the earlier models made them crucial. As the models improved, deciding what to ask became more important than polishing every sentence of the request.
The detailed prompt hasn't become useless. Sometimes you know the implementation constraint and need to state it. The problem starts when detailed instructions stand in for a clear understanding of the user's need.
Faster tools still meet old constraints
You can see similar echoes in agent swarms and vibe coding. Splitting work among planning, coding, testing, and review agents introduces coordination and shared-state problems familiar from distributed systems. A prototype assembled in an afternoon can still take a week to untangle when the requirements change. Speed makes both the gain and the mess appear sooner.
I don't think every adopter forgot how to engineer, or that every skeptic failed to see the potential. The tools created a new setting in which familiar judgment had to be applied again. Some of us were too willing to accept generated code. Others were too willing to dismiss a tool while people were still learning how to use it.
The principles held up because they're responses to complexity and limited attention. Keep related things together. Avoid duplicating knowledge. Give clear goals and useful boundaries. Verify that the result works. None of those rules depends on whether a person or a model typed the code.
I'm left wondering which habits I'm still carrying over without noticing. When you work with AI, do you give it the kind of direction you wanted from your best manager, or the kind you once complained about?