The Best AI Engineers Are Great Communicators

The biggest winners in the AI race are not the people with the deepest technical knowledge. They are the people who communicate the most clearly. If you can describe a problem precisely - the constraints, the data, the failure modes, the shape of a good solution - AI agents will do disproportionately good work for you. If you can’t, no model will save you.

That’s the whole post. Everything below is the argument.

Quality In, Quality Out Is Not a Platitude

LLM output quality is directly coupled to input quality. Everyone repeats this, few act on it.

LLMs are built on natural language. They reason through description. A vague prompt gives the model a huge space of plausible interpretations and it picks one - usually not yours. A precise prompt collapses that space down to the thing you actually want.

This is not prompt hacking or magic phrasing. It is the same skill as writing a good design doc, a good ticket or a good code review comment. Engineers who mastered their own language before AI showed up are quietly collecting the compounding returns now.

Describe the Problem, Not the Code

Here’s the test. You have a system in Java and you want it in C++.

Option one: paste the Java and say “convert this to C++.” The model will do fine. You’ll get a faithful translation, including a faithful translation of every Java-shaped decision that makes no sense in C++.

Option two: describe the underlying problem. What the system processes, at what volume, under what latency constraints. Which algorithms and patterns you’re using and why. How the processing breaks into steps. What must be true when it finishes.

With that spec, the model isn’t translating - it’s solving. It picks idiomatic C++ approaches, flags where the original design fights the new language and can justify each choice. The same spec works for Rust or Go tomorrow, because the spec captures the problem and the problem is language-independent.

Code tells the model what you did. A spec tells it what you need. The second is strictly more information.

Why Non-Engineers Sometimes Out-Prompt Engineers

Here’s an uncomfortable observation: some product managers get shockingly good prototypes out of LLMs. I think the reason is simple - they never learned to think in implementation details, so they describe problems and outcomes by default. That happens to be exactly the input LLMs want.

Engineers are trained in the opposite direction. We think in syntax, idioms and framework specifics, and our prompts inherit that. We hand the model our half-finished implementation thinking instead of the problem itself.

Call this a theory, because it is one. But the direction it points is right: the describing skill is the differentiating skill, and it’s trainable.

This is also why the oldest interview advice - explain your thinking out loud before you write code - aged so well. It was never about the interviewer. Narrating the problem, the approach and the tradeoffs is the exact muscle that prompting exercises. Practicing it makes you a better communicator, and a better communicator is a better engineer with agents.

Technical Depth Still Wins - It Just Isn’t the Bottleneck

None of this means technical knowledge stopped mattering. It matters as much as ever. Depth is how you know the agent’s output is actually sound, how you spot the bad architectural path on turn two instead of in the postmortem and how you name the right pattern instead of vaguely gesturing at one.

The parallel is being an engineering manager. A great EM doesn’t out-code their team, but they need real technical judgment to evaluate work, set direction and know when something smells wrong. Strip the technical depth away and you get a manager who can’t tell good work from confident nonsense.

That’s you with agents. Depth is required. It just stopped being the constraint. The constraint is whether you can get what’s in your head into the agent’s context - because the agents cannot read your mind. Maybe Neuralink fixes that eventually. Until then, you have language.

Delegation Is the Job Now - Communication Is How You Do It

I made the case in The New Problems AI Gave Engineers that the IC track quietly merged into management: run a few agent sessions in parallel and you’re leading a team whether you signed up or not. This post is the follow-up - what being good at that actually requires.

The answer is mostly communication. Every prompt is a spec. Every agent session is delegation. Every review of agent output is a code review of a very fast, very literal teammate. The skills that separate good EMs from bad ones - clear requirements, right-sized tasks, honest feedback loops - are now individual contributor skills.

I’ve written about the mechanics of running agents - skills, hooks, subagents - and about orchestrating them durably with Temporal. But mechanics are the easy part. The hard part is the management thinking that decides what to delegate and how.

Run Your Agents Like a Project, Not a Prompt

Which brings in the other half: project management. You can single-prompt a whole system, and for a toy the result is a fun dopamine hit. For anything with real scope, you should be doing what a senior or principal engineer does before any team writes code.

This isn’t new. Agile teams learned decades ago that clear specs and staged execution beat chaos. The difference now: AI agents execute so fast that bad planning is immediately expensive instead of gradually expensive. The consequences are visible on day one instead of week four.

• Break the work down. What are the actual pieces? What’s small enough to delegate cleanly and verify?
• Map dependencies. What has to exist before what? What goes first?
• Front-load the research. What do you not know yet that would invalidate the design? Answer that before building on the assumption.
• Design for parallelism. If the architecture has clean seams, multiple agents can build features side by side without colliding. If it doesn’t, you’ve built a one-lane road.
• Estimate honestly. What will actually take the longest? That’s where your attention goes, not wherever the agent happens to be working.

Think in terms of a team even when it’s just you and one agent, because the discipline transfers. And hold the line on the boring fundamentals - version control hygiene, tests as gates, small reviewable changes, iterative delivery. Agile practices weren’t invented to slow teams down. They exist because ungated speed produces wreckage, and agents generate speed like nothing before them.

The Single-Prompt Dopamine Trap

The marketing says magic box: idea in, production system out. The models are genuinely impressive and getting more so, but they are not that, and everyone who ships with them knows it.

The trap is that the single prompt feels like it worked. You get running code in minutes. What you don’t get is the architecture that supports the next ten features, the tests that catch the regression or the design decisions anyone can explain later. You find those gaps weeks in, when they’re expensive.

The engineers seeing the biggest real gains are doing solid work themselves: specifying, decomposing, sequencing, reviewing. The agents multiply that work. Multiply zero and you get zero with excellent production values.

Where to Start

Three practices, all free:

1. Write the spec before the prompt. Even five sentences: the problem, the constraints, what done looks like. If you can’t write it, you weren’t ready to delegate it.
2. Explain your thinking out loud - in design reviews, in PR descriptions, to the rubber duck. It’s the same muscle as prompting and it compounds in both directions.
3. Plan agent work like team work. Break it down, order it, define the gates. Then delegate aggressively inside that structure.

The models will keep getting better. The engineers who benefit most from every improvement will keep being the ones who communicate like leads and manage like leads. That skill was always valuable. AI just made it the multiplier on everything else you know.