Working with AI is a leadership problem, not a coding problem

Allen Bargi, a longtime software engineer, published a short note on 15 August arguing that working with AI feels less like coding and more like leadership. His claim: code gave him certainty, but AI does not. The same request can produce different answers, useful connections, missed points, or surprising approaches. He concludes that the skills that matter are not prompt syntax but context, clarity, and feedback.

The post is two minutes long and links to a Hacker News discussion. It is also one of the more useful framings of the AI coding debate to surface this year, because it moves the conversation away from model benchmarks and toward the actual bottleneck: the human ability to express intent.

Bargi’s central observation is that AI runs on software but does not behave like software. A compiler executes instructions deterministically. An LLM samples from a probability distribution. The same input can produce different outputs, and the difference is not a bug. That is a feature of the architecture, and it changes what the person at the keyboard is actually doing.

Treating AI like a compiler is the wrong mental model. Treating it like a collaborator, Bargi argues, is more productive. He is careful to say AI is not a person. It has no lived experience, accountability, or human judgment. The comparison is about workflow, not consciousness. Good leaders share context, explain desired outcomes, set boundaries, and respond to what comes back. Those habits, he says, improve work with AI more than any prompt trick.

The argument is not entirely new. Anthropic’s prompt engineering documentation has long emphasized providing clear context and examples. OpenAI’s model behavior guidance makes the same point. What Bargi adds is the framing: the limiting factor is not the model’s capability but the operator’s ability to communicate intent. That reframes the entire debate about AI coding tools.

Consider the current state of the market. GitHub Copilot, Cursor, and Claude Code have made LLM-assisted programming mainstream. The discourse around these tools focuses on token limits, context windows, and model quality. Benchmarks like SWE-bench measure whether a model can fix a bug given a clean issue report. Real work is messier. A developer inherits a codebase with undocumented assumptions, ambiguous requirements, and stakeholders who do not know what they want. The model cannot read minds. The developer has to supply the missing context.

That is where Bargi’s leadership analogy bites. A good engineering manager does not just assign tasks. They explain why the work matters, what success looks like, and where judgment is required. They correct course when the work goes sideways. They build shared understanding over time. Bargi argues the same investment pays off with AI: examples, corrections, and reusable instructions reduce misunderstandings, and the system becomes better aligned with how the operator thinks.

The practical implication is that prompt engineering, as a discipline, is less about clever phrasing and more about organizational communication. Writing a good system prompt is like writing a good onboarding document. Defining the desired outcome is like writing a good spec. Giving feedback on a bad output is like running a code review. These are leadership skills, not programming skills.

This has consequences for how AI tools are designed and evaluated. If the bottleneck is human intent, then the tools that win are not necessarily the ones with the best models. They are the ones that make it easiest to establish shared context. Cursor’s ability to reference a repository, Claude Code’s memory features, and Copilot’s workspace indexing are all attempts to solve this problem. They encode context so the operator does not have to repeat it.

The evaluation problem is harder. Benchmarks measure model capability in isolation. They do not measure how well a model performs when the operator is vague, impatient, or unclear. They do not measure how much context a developer needs to supply before the model becomes useful. A model that requires ten minutes of context-setting per task may be less productive than one that needs two minutes, even if the former scores higher on SWE-bench.

Bargi’s framing also explains a common frustration. Developers who treat AI as a compiler get angry when it produces different outputs for the same input. They file it as a bug. But the nondeterminism is not a defect. It is the difference between a machine and a collaborator. A collaborator may misunderstand, but a collaborator may also surprise you with a better approach. You cannot have the second without accepting the first.

The leadership analogy has limits, and Bargi acknowledges them. AI has no accountability. It cannot be promoted, fired, or held responsible for its mistakes. It has no stake in the outcome. A human colleague who misunderstands a task will feel the consequences; an AI system will not. That asymmetry matters in practice. It means the operator bears full responsibility for the output, which is exactly why clarity and feedback matter more, not less.

There is also a risk in the analogy. If working with AI feels like leadership, it is easy to slide into treating AI as a person. Bargi explicitly warns against this. The investment, he says, is not in pretending AI is human. It is in becoming better at expressing intent. That distinction is worth holding onto. The tools are getting more capable, but the human skill ceiling is the same one that has always governed good communication.

The Hacker News discussion Bargi links to reportedly includes agreement, criticism, and divergent experiences. That range is telling. Some developers will find the leadership framing intuitive, especially those who have managed teams. Others will find it overwrought, especially those who work in narrow, well-specified domains where determinism matters. Both experiences are real. The value of Bargi’s note is not that it is universally true. It is that it names a shift that many developers are feeling but have not articulated.

The shift has economic consequences. If the bottleneck in AI-assisted work is human communication skill, then the return on investment in AI tools depends on organizational culture, not just model quality. Companies that invest in documentation, clear specs, and feedback loops will get more from the same models than companies that do not. That is a strange conclusion for a technology story, but it follows from Bargi’s premise.

The technology is new. The leadership skills are not. That sentence, near the end of Bargi’s note, is the takeaway. It suggests that the most valuable AI training is not a course on prompt engineering but practice in explaining why, not just what. For a generation of engineers who spent years learning to tell computers exactly what to do, that is a harder lesson than any API change.