The software I build is only as good as the language I use to define it.
Author: James Phoenix | Date: July 2026
Code Starts as a Sentence
The most important language for software engineers is English.
Not Python. Not Rust. Not whatever is trending this week.
When I say English, I do not mean polished prose, perfect grammar, or a native accent. I mean the shared working language that turns an idea into an explicit agreement. The skill is making hidden intent visible to a teammate, an AI model, or my future self.
Many expensive failures begin before code: a vague ticket, a misread requirement, or a conversation where two people agreed on different things. A compiler catches broken syntax, not a beautifully implemented misunderstanding.
Shared understanding is the first compiler in software development. If the input is ambiguous, clean code only makes the wrong interpretation easier to ship.
Ambiguity Is Executable Now
Ambiguity has always been expensive. AI makes it executable at much higher throughput.
A teammate might find a gap and ask a question. A coding agent may choose a plausible interpretation, change several files, write tests around its assumption, and report completion before I notice that it solved the wrong problem.
Every missing decision creates a branch in the solution space. Which users? Which endpoint? Which failure modes? Which target? The model must choose even when I have not.
AI turns ambiguity from a local communication cost into a throughput problem. Vague thinking produces vague prompts, and vague prompts produce technical debt at machine speed.
AI does not remove requirements engineering. It exposes how much of it used to happen implicitly.
Better Prompt or Better Thinking?
Consider a simple request:
Vague: Add caching to make the API faster.
Now compare it with this:
Better: Cache successful GET /products responses in Redis with a
five-minute TTL. Invalidate the matching cache entries after a product
update. Success means p95 latency below 100 ms under the standard API
load test.
The second version names the operation, storage layer, lifetime, invalidation event, and performance target. It still leaves room to choose the code structure.
This is not better prompting. It is clear thinking, written down. The same brief works for an AI agent, a teammate, or me six months later.
More words are not automatically clearer. I include only information that changes the implementation.
Four Questions Make a Problem Ready
I can turn most rough requests into workable briefs by answering four questions:
- Goal: What should exist when this is done? I describe the observable end state, not the activity.
- Context: What does the reader need to know that they cannot see? I include the reason, relevant architecture, known history, and who experiences the problem, not the entire project wiki.
- Constraints: What is off limits or non-negotiable? I name compatibility, security, dependency, performance, and scope boundaries.
- Done: How will I verify it worked? I provide the command, scenario, metric, screenshot, or observable behaviour that turns “finished” into evidence.
Goal describes the outcome. Done describes the proof. Keeping both prevents a task from becoming implementation steps with no connection to purpose.
If I cannot answer all four, I am not ready to request implementation. I may be ready for discovery or a clarifying conversation, but that is a different task and I should name it honestly.
Soft Verbs Hide Hard Decisions
I watch for words that sound active while leaving decisions unresolved: improve, handle, clean up, support, optimize, and make it better.
- “Improve performance” hides the endpoint, baseline, target, and load profile.
- “Handle errors” hides which errors, what the user sees, whether to retry, and what to log.
- “Clean up this module” hides the allowed scope and the behaviour that must stay unchanged.
- “Make the UI better” hides the user journey, accessibility requirement, and visual standard.
A vague verb is usually a hidden decision. I do not need to ban these words. I need to finish them. “Improve p95 latency from 350 ms to below 100 ms at 200 requests per second” gives the word a measurable definition.
Finish the Sentence
The simplest habit I use is to finish one sentence before writing a prompt or ticket:
Success looks like…
For the caching example, success might look like this: repeated product reads stay below the latency target, a product update is visible on the next read, and a Redis outage falls back to the database without returning a 500 response.
Writing that sentence forces me to choose what evidence matters. It reveals when I have an implementation idea without a clear user outcome, or a goal with no practical verification.
Work is not done when code exists. It is done when evidence shows the intended outcome exists. That evidence might be a passing test, a latency measurement, a browser flow, a database row, or a production trace.
Clarity Is Not Micromanagement
Clear English does not mean dictating every function name and loop. I define the destination, relevant terrain, boundaries, and proof, then leave room for judgment.
My test is to write as if I am briefing a capable new hire who does not know the system’s unspoken history. What would prevent a predictable wrong turn? What can they discover safely? Which choices belong to them?
This is the same principle behind declarative constraints. I specify what must be true rather than pretending I already know every implementation step.
Clarity specifies the destination without stealing the route. It makes autonomy safer for both people and AI.
English Is Part of the Technical Interface
Writing is often treated as a soft skill beside the real technical work. I think that distinction is obsolete. Tickets, specifications, tests, and prompts translate intent into action.
As code generation becomes cheaper, deciding and communicating what should be built becomes more valuable. Syntax still matters, but syntax is downstream of intent.
English is now part of the technical interface. An engineer who can turn a fuzzy request into a precise, bounded, verifiable brief will build better software and get more value from every model.
When I catch a lazy requirement, I stop and write what I actually want, as if briefing someone intelligent who cannot read my mind.
If I cannot finish “Success looks like…”, I am not ready to write code. Neither is the AI.
Related
- Upfront Questioning Narrows Search Space – Questions collapse the possible interpretations before implementation begins.
- Prompt Contracts – A formal specification pattern for larger AI coding tasks.
- Highest Leverage Points: Plans and Validation – Why the work before and after code carries the most leverage.
- The Coder Is Obsolete. The Programmer Is Not. – Why understanding and specifying intent remains the programmer’s job.
