English Is the New Code: Why Requirements Engineering Just Became the Highest-Leverage Skill in Software

Software has been getting more abstract for sixty years. Assembly gave way to C. C gave way to Java and Python. Python gave way to JavaScript everywhere. Each step in that progression did the same two things. It opened the field to more participants. And it shifted the leverage from how you wrote the instructions to which instructions were worth writing in the first place. The next step in that progression is here. English is becoming a programming medium. The implication is that the discipline almost everyone in software has historically underrated - capturing what the system is supposed to do, in plain language, with rigour - just became the highest-leverage skill in the field.

This is not a marketing claim. It is the natural consequence of how the abstraction stack works. Each layer of abstraction in software history changed who could participate. C was for systems people. Python opened it to scientists, analysts and hobbyists. JavaScript opened it to anyone with a browser. English opens it to eight billion people. The constraint stops being technical capability and becomes something different - the ability to describe what good looks like, with enough precision that an AI system can act on it without drifting.

The Discipline Everyone Underrated

For most of the modern software era, business analysts have been making one argument and the industry has mostly ignored it. The argument is that the requirements are the work. The code is the cheap part. Get the requirement right and the implementation is straightforward. Get the requirement wrong and you can throw any number of senior engineers at it and produce something fast, expensive, and not what the business actually needed.

The reason the industry ignored this for thirty years is straightforward. The cost of executing on a good requirement was so high that it was not worth the additional time to produce one. A clean spec might save you a month of rework, but if writing it took two weeks and the engineering team was billing through the nose, the spreadsheet said you were better off starting code now and iterating. So the industry built a culture of moving fast and producing requirements as a side effect of building. The artefact you ended up with was the codebase. The reasoning behind the codebase mostly lived in heads, in Slack threads, in the memory of the senior engineer who originally architected it. When she left, the reasoning left with her.

AI changes that arithmetic completely. The cost of executing on a clean requirement is approaching zero. A well-written spec, fed into a system that knows the brand voice, the data shape, the constraints, the audit posture, can produce working software, working content, working operations in hours instead of weeks. The leverage of writing the spec well went up by an order of magnitude overnight. The trade-off that justified skipping it inverted. The discipline that was previously a luxury is now the bottleneck.

Why Most Enterprises Are Not Set Up for This

Walk into a typical large organisation today and ask where the requirements live for the systems that run the business. The answers are familiar. Some of it is in JIRA tickets that are six months stale. Some of it is in Confluence pages no one has updated since the original implementation. Some of it is in PRDs that captured what was wanted at kick-off but not what was actually built. A meaningful chunk of it is in the heads of two or three senior people who can be paged when something breaks. None of these are forms an AI system can reason against. None of them survive a key person leaving. None of them compound when new information arrives.

The capability that AI is unlocking is the ability to operate against living, structured, plain-language descriptions of how the business runs. The cost of producing those descriptions used to be prohibitive. Now it is the work. And most enterprises do not have a function that owns it. The business analyst function, where it exists, is often scoped to project work, not to the standing description of how the operation runs day to day. The technical writing function, where it exists, is documentation-after-the-fact rather than specification-before-the-build. The result is a gap right at the layer that AI deployment depends on.

What Good Requirements Engineering Looks Like in the AI Era

Several patterns separate teams that are getting real leverage from AI from teams that are stuck in pilot land. The first is that they treat requirements as a primary artefact, not a side effect. Specs are written before the build, kept current as the build happens, and audited periodically as a discipline in their own right. The second is that they are written for a dual audience - human and AI. The same document a senior reviewer reads to approve a change is the document the AI uses to generate the change. That forces clarity. Vague specs that humans could fill in from context produce vague AI output that no one can use.

The third pattern is that they capture the why, not just the what. Most engineering specs describe the behaviour required. The high-leverage specs describe the constraints, the principles, the trade-offs that informed the behaviour. When the AI hits an edge case the spec did not anticipate, it can reason from the principles. When a competitor copies the surface behaviour, they cannot copy the reasoning, because the reasoning is what produces the next version. The fourth pattern is that they are versioned and decisioned. Every change to a requirement records who decided it, why, and what the alternatives were. That audit trail becomes the institutional memory the business actually owns.

The Joint Spec Method

The way we approach this with our clients is a pattern we call Joint Spec. The principle is simple. Before any code is written, before any AI system is pointed at a workflow, we sit down with the senior decision-maker on the client side and produce a structured specification together. Not a Discovery deck. Not a workshop output that gets summarised in a slide. A working document that captures the data model, the rules, the edge cases, the constraints, the brand and tone parameters, the audit posture, the failure modes, and what success looks like. Each decision is locked one at a time, written before the next decision is taken up. The output is something the client can read, edit, and own.

This sounds slow. In practice it is dramatically faster than the alternative, because the alternative is building the wrong thing first and discovering it three months in. The Joint Spec is also the asset that compounds. The first project produces a spec. The next project re-uses the relevant pieces and extends them. After a year, the client has a structured, queryable description of how their business runs that did not exist before, and that becomes the input to every AI system they deploy from that point forward.

It also changes who can participate. A Joint Spec session does not require the client to be technical. It requires them to have judgment about how their business should run. The decisions are made in plain language. The translation into deterministic execution happens afterwards, by us. The senior decision-maker sees their own thinking reflected in the spec, can correct it as we go, and ends up with something they can actually defend in front of a board, a regulator, or their own successor.

Why This Disadvantages the Existing Software Industry

There is a structural reason most large software vendors will struggle to make this transition. Their business model is staffed around code production. Engineers, project managers, delivery leads, account managers - the entire operation is calibrated to the assumption that the artefact being delivered is software, that the differentiator is how well it gets built, and that the customer relationship runs through implementation services. When the artefact becomes a clean spec and an AI system that executes against it, the staffing model does not work. You do not need eight people. You need one senior person with judgment and the architecture behind them.

Large consultancies face the same constraint at a higher cost base. The McKinseys and the systems integrators have been selling teams of fifty against problems that, with the right specification and the right execution architecture, can be handled by teams of three. They will protect the existing model for as long as their procurement counterparts let them, because their fee model depends on it. The procurement counterparts will figure it out. They always do, eventually. By the time the realisation lands, the firms that built around the new architecture from day one will have a multi-year head start on the institutional knowledge that compounds inside their platforms.

What This Means If You Are a BA, a PM, or a Senior Operator

The discipline of capturing requirements clearly was undervalued for the entire previous era. People who were good at it spent careers having their work treated as a precursor to the real engineering effort. That is over. The work is now the work. If you have spent ten or twenty years getting good at translating fuzzy business intent into structured specifications, the leverage on that skill just increased by an order of magnitude. The thing you were already good at is the thing the next phase of the industry runs on.

The corollary is that being a good operator is now a more transferable skill into software than being a good engineer. A senior operator who understands their domain in depth, who can articulate the rules and the edge cases, who can sit in a structured spec session and produce a clean description of how the work should run, has all the inputs the AI architecture needs. The thing they used to lack - a path from their description into working software without an eighteen-month implementation project - is what just became cheap. The barrier between deeply understanding a business and shipping software for it is collapsing. The skill that bridges the two is requirements engineering done well.

What This Means If You Are an Executive

The investment that pays back the most over the next three years is not another model or another platform. It is the discipline of capturing how your business actually runs in a form that can be reasoned against. The places to start are the workflows where the institutional knowledge concentrates in two or three people, where the documentation is stale or absent, and where the cost of getting it wrong is large. Those are the highest-leverage spec investments. They reduce key-person risk. They produce an asset that survives staff turnover. They become the input to every AI deployment from that point forward, including ones that have not been invented yet.

The trap to avoid is treating this as a documentation project. Documentation is what you produce after a build to record what was done. Specifications are what you produce before a build to determine what should be done. The distinction sounds semantic. It is not. Documentation is a sunk cost. Specifications are a compounding asset. The teams that produce specifications, version them, decide them carefully, and treat them as primary will be operating on a different curve from the teams that do not.

Where We Sit

ShiftCurve was built on this premise. The Joint Spec method is how we engage. Our delivery architecture is designed around the assumption that the spec is the bottleneck and the execution downstream of it can be made cheap and reliable. Our clients end up with a body of plain-language descriptions of how their business runs that they own, can edit, can hand to a new team member, and can use as the input to whatever AI system we or they deploy next. The technology side of what we do is real and matters, but it is downstream of the language side. We think that is where the industry is heading. We have written this essay because we want our clients, our prospective clients, and the people in their organisations who are about to find their craft re-valued by this shift to see clearly what is happening and act on it before the rest of the market does.