Cursor, Lovable, Claude Code, v0, Bolt, Figma Make. The AI coding tool category, three years in, has converged on a remarkably consistent shape: take a natural-language description of what someone wants built, return working code. The category does this well. The category is also expanding fast. Every quarter brings a new entrant, a new abstraction, a new pricing model.
What none of these tools do, because it is not what they were designed to do, is help the user arrive at the description of what to build. The description is treated as the input. The tool’s job starts after the description exists.
The result is a category that is structurally indifferent to whether the description it receives is any good. Whatever the user prompts, the tool will build. If the prompt is bad, the build will be a faithful rendering of the bad prompt. The tool is not in a position to know.
The Assumption Baked Into Every Tool
Every AI coding tool ships with an unstated assumption: the user knows what they want. The brief has been written. The audience has been identified. The strategic trade-offs have been made. The architectural choices have been pre-resolved. The tool’s job is to take that pre-resolved input and produce a corresponding output.
Under the right conditions, this works. A senior PM with a thorough brief, working with Cursor, can ship a feature in a fraction of the time it used to take. The tool is not the problem. The brief was already there.
Under the more common conditions, a founder with an idea, a small team with a working hypothesis, a non-PM trying to ship a tool for their own use, the brief is not there. The tool produces output anyway. The output is consistent with the prompt it received, which was an underspecified prompt, which produced an underspecified output, which now sits in production and starts failing in ways neither the user nor the tool can diagnose.
The User As Token Source
From the AI coding tool’s perspective, the user is a source of tokens that get processed into output. The tool optimizes for the quality of that processing: better autocomplete, faster generation, more accurate code, fewer hallucinations. These are real engineering wins. The tool is getting better at the job it was designed to do.
What the tool does not optimize for, because it is not in the tool’s loop, is whether the user is asking the right question. The user’s confusion, vagueness, sycophantic feedback loop with the tool, and the absence of strategic discipline are not bugs the tool’s product team is incentivized to fix. They are conditions the tool’s product team is incentivized to absorb.
The user, from the tool’s perspective, is not a customer who needs strategic clarity. The user is the source of input the tool processes. The strategic-clarity problem is somebody else’s.
The Missing Layer
The category that has not been built yet, and that the AI coding tools structurally cannot build, is the strategic-thinking layer that produces the description. The layer that does the work of audience identification, positioning, trade-off articulation, constraint naming, and brief production. The layer that, under the old building economy, used to live in the head of a senior PM or the hours of a consultancy engagement.
That layer is missing not because nobody has noticed it. It is missing because the existing categories do not reach it. Consultancies are too expensive and too slow for the per-decision use. PMs are scarce and do not scale to the volume of strategic calls a founder makes. The AI coding tools start downstream of where the layer would sit.
The opportunity, in other words, is the layer between the founder’s idea and the coding tool’s input. Not a coding tool. Not a consultancy. The strategic-thinking work that both assume but neither provides.
What This Is Built For
Zynkex is that layer. Not a competitor to Cursor. Not a discount Bain. The upstream strategic-thinking work that the AI coding tools assume exists but do not provide, and that the consultancies provide at a price most teams cannot afford to use repeatedly.
A Zynkex session produces the description the coding tool was waiting for. A Strategy Plan with a prominent Decision Log capturing every call made and why, naming the audience and the position. A Build Brief that translates the strategy into the form Cursor or Lovable or Claude Code can build from. The coding tool then does what it does well: turn a good description into working code.
The thing the AI coding tools never had time to give you is the thing Zynkex was built to give you. You stop being the source of the tool’s problem and start being the source of the tool’s good output.
