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 and buried teams in documentation. Then we got an assistant that would accept as many instructions as we could write, and we started doing the same thing.
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. Reading them reminded me of the manager who hands a developer a fifteen-page brief, then keeps interrupting with more advice.
A study on repository context files found that generated files tended to lower task success rates, while developer-written files brought a small improvement. Both increased costs. For generated files, the average increase was about 20% or more across the two benchmarks. The authors recommended keeping human-written files to minimal requirements, such as repository-specific tooling.
A separate study on agent skills found that curated skills helped on average, with focused packages of two or three modules outperforming comprehensive documentation. I read both as reasons to be selective about what goes into the brief.
Old or contradictory instructions can pull work in the wrong direction, even when each one once seemed worth including. People can struggle with those instructions too, although a colleague is more likely to question the brief.
With both people and tools, I get a better conversation when I explain the goal and the constraints that matter, then leave room to work. I find it embarrassingly easy to forget that when I can add another instruction without anyone objecting.
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. That meant reviewing larger changes for the same problems we'd always looked for: duplication, poor boundaries, confusing names, and missing tests.
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.
I'm still noticing which habits I carry over without thinking. I want to give these tools the kind of direction I valued from my best managers.