Shifting from Syntax to Natural Language
We’ve spent years getting better at writing code. Cleaner abstractions, better naming, smaller functions. The craft of expressing intent precisely. But always to a machine that does exactly what you tell it — no more, no less.
AI changes that contract.
When you ask an LLM to write code for you, you’re no longer writing for a compiler. You’re writing for something that will interpret what you meant in natural language — and fill in the gaps with its best guess. That guess depends almost entirely on how well you expressed yourself.
This is new territory for most of us. We’re optimised for writing syntax. Natural language was for comments, documentation, PR descriptions that nobody read. It was a formality after the ‘actual’ work, not the work. Now it is.
Here’s what I’ve noticed, though — the developers adapting fastest to these tools aren’t necessarily the most technically skilled ones. They’re the ones who are good at explaining things. They write clear tickets. They document their decisions. They can walk a new teammate through a problem without losing them halfway.
That’s not a coincidence, and it points to something worth thinking about.
Getting better at articulation
We’ve all had prompts go wrong. Let’s think about what usually happens. You ask for something, the LLM produces something adjacent to it, and you’re left kicking yourself and cussing at the AI, wondering why it didn’t do exactly what you imagined it would. Usually, it’s not that the model is incapable. It’s that there’s a gap in your mental model and the AI’s, which meant that it had to make assumptions — and it just made different ones than you.
Then you spend the rest of the context window explaining things, giving some more background, some more dos and don’ts, and try again. This time the result is closer to what you expected. You iterate until it’s right — and the output looks almost exactly like what you’d have written yourself. By this point you’ve spent more time on the prompt than the code would’ve taken. But you’ve also just articulated a set of assumptions you didn’t even know you were carrying.
Here’s what that looks like in practice. Two scenarios, same pattern.
Scenario 1: Adding error handling to a payment form
Without context
Add error handling to the payment form submission.
AI adds a try/catch and shows a generic “Something went wrong” toast.
The error should show the actual reason for failure.
AI surfaces the raw API error string — ERR_CARD_DECLINED — directly in the UI.
That’s not user-readable. Translate it to plain English.
AI adds a hardcoded switch statement with guessed error codes and invented messages.
We have existing error components in the design system — use those.
AI refactors to use a component, but picks the wrong one and doesn’t match the API shape.
Four exchanges in and you’re close, but not quite there. The model wasn’t wrong at any point — it just filled gaps with its own assumptions because you hadn’t given it the ones that mattered.
With context
We want to implement descriptive error handling in payment form submission. On failure, it should display the exact reason for failure using our design system’s error components. Upstream errors from credit card processors should be clear — a CARD_DECLINED error should translate to readable text for users. The API should follow existing conventions described in @src/api/errors
Done, first try. The AI read the relevant files, picked up the API format, the right design component, and the error codes it needed — and did exactly what you wanted.
Scenario 2: Fixing a performance regression
Without context
The UserList component is re-rendering too often and causing the page to lag.
AI wraps UserList in React.memo.
Still slow. Can you check how the parent is passing props down?
AI wraps the callback in useCallback.
Now it’s worse. The callback is closing over stale state.
AI adds the state to the dependency array, which triggers the re-renders again.
Each correction revealed a constraint the model couldn’t have known. You’re debugging the AI’s assumptions instead of the bug.
With context
UserListre-renders on every keystroke in the search input and it’s causing the page to lag — not sure what’s causing it yet. The page has a search input that filters a large list, each item renders a few child components, and we use React Query for data fetching. Can you identify the likely culprits? Note: don’t suggest addingReact.memotoUserList— we’ve left it off intentionally to keep profiling straightforward.
The AI now has enough to work with: it can check for unstable references, unnecessary re-creation of derived values, missing memoization in the right places. And because you mentioned the constraint up front, it won’t waste your time suggesting the first thing that comes to mind.
Both ‘with context’ prompts share the same moves: they lead with intent rather than implementation, point to existing context rather than restating it, name constraints before the model has a chance to assume around them, and are honest about what’s unknown. None of that is eloquence. It’s just thinking out loud in the right direction before you hit send.
Good articulation doesn’t require knowing the answer. It requires sharing what you know — including the things you’ve already ruled out.
Good communicators have always understood this intuitively. When you write for someone who isn’t in your head, you have to make your assumptions explicit. You can’t rely on shared context that only exists on your side of the conversation. You have to say what you mean, precisely enough that the reader — or in this case, the model — can think from your perspective without guessing.
Most of us never had to think about this when writing code. The compiler never guesses. It either understands the instruction or throws an error. There’s no ambiguity. But writing a prompt is much closer to writing a good brief, or a clear design doc, than it is to writing a function.
Every time a prompt comes back wrong, it’s worth asking: what did I leave out? What do I know that it probably doesn’t? That’s not debugging the AI. That’s debugging your own communication — which turns out to be a pretty valuable habit regardless of software.
Getting the articulation right is easier when you’ve got the right mental model of who you’re talking to.
Think teammate, not compiler
A lot of the friction I see developers have with AI tools comes from the wrong mental model. They think of it as a compiler that speaks English, and get frustrated when it doesn’t behave like one. Or they think of it as a search engine that writes code, and are surprised when it needs more from them than a query.
The model that works better, at least for me, is a teammate.
Someone capable and well-read, who works fast and doesn’t get tired. But someone who just joined your team. They don’t know your codebase yet. They don’t know your conventions. They’re smart enough to fill in gaps, but they’ll fill them with their own assumptions if you don’t tell them yours.
You wouldn’t throw a new teammate into a task without context and expect perfect output. The same patience applies here.
When you adopt this model, the soft skills stop feeling optional. Of course you communicate clearly with a new teammate. Of course you share context before diving in. Of course you ensure they kept up with you before you switch your seat and let them drive. That’s just how collaboration works.
The difference is that this particular teammate is available at any hour (unless you’ve run out of tokens), scales to any task, and gets meaningfully better every few months. Worth investing in the relationship.
Being more empathetic
Articulation is about what you say. Empathy is about understanding who you’re saying it to.
By empathy I mean something specific — not the kind you’d feel for a person, but the practical ability to model another agent’s knowledge state. To ask, genuinely: what does this thing know, and what doesn’t it know?
An LLM doesn’t have your codebase in its head. It doesn’t know your team’s naming conventions, your architectural decisions, or why you made a particular tradeoff six months ago. When you prompt without that context, you’re not giving it a chance to succeed. You’re handing it a puzzle with half the pieces missing and expecting a complete picture.
Experienced developers who’ve onboarded teammates know this feeling well. You can hand someone a task and watch them go off in the wrong direction — not because they’re not capable, but because they were missing context you forgot to share. The fix isn’t to find better people. It’s to get better at the handoff.
Working well with AI requires the same thing. Before you write a prompt, it’s worth asking two questions:
What would someone need to know to do this well?
And given what I’ve written, what will they assume I mean?
That moment of thinking from its perspective is the empathy doing the work, and it makes an enormous difference.
It’s a habit, not a talent
Some people come to this naturally — usually because they’ve spent years in situations that forced them to think about what their audience knows. The developers who write clear tickets, document their decisions, and can walk a teammate through a problem without losing them — they’ve already built this habit, often without realising it. They’ve had to write for people who didn’t share their context, and they learned that assumed context is a liability. For everyone else, it’s learnable.
The skill isn’t about being a good writer. The prompts in the examples above aren’t particularly elegant. What they have is information — enough context for the model to work from your perspective instead of guessing. That’s not a writing skill. It’s a thinking habit: pausing before you communicate to ask what does this person need to know that they don’t already have?
Working with AI is an unusually good practice for building the habit — and one we didn’t have until very recently. The feedback loop is immediate and unambiguous. When a prompt comes back wrong, it gives you an idea about the assumptions the model made — which are exactly the assumptions you left implicit. That’s a signal, not a failure. Over time, you get better at catching those gaps before you send the prompt.
It doesn’t matter what role you’re in. What matters is whether you’ve started asking the question.
The unexpected upside
There’s an irony in all of this that I find genuinely interesting. The rise of AI coding tools was supposed to reduce the premium on human skill — automate the repetitive parts, lower the floor, make everyone a bit more productive. And it does some of that.
But it’s also quietly raised the ceiling on a different set of skills. The soft skills we used to treat as nice-to-haves. The ability to communicate clearly, to understand what someone else needs, to share context and perspective in a way that actually lands.
Those skills were always valuable — they’re just load-bearing now.
And here’s the part I find most interesting: working with AI might quietly be training them. Every time you figure out what you left implicit in a prompt, you’re building a reflex that doesn’t stay inside the conversation. It transfers — to the next ticket you write, the next time you walk a teammate through a problem, the next time you explain a decision to someone who wasn’t in the room. The feedback loop that makes you better at prompting makes you better at communicating.
We came here for the productivity. The communication skills are a welcome side effect!