I'm a Business Analyst Who Builds, Not Just Specs

Here's why that's becoming the only kind worth hiring.

For ten years my job ran on a quiet, unspoken premise: the business knows what it wants, engineering knows how to build it, and someone in the middle turns one into the other. That someone was me. I wrote the requirements. I drew the process flows. I produced the forty-page document everyone signed off on and nobody read.

I was good at it. I'm telling you it's a dying craft.

Not because requirements stopped mattering — they matter more than ever. But because the document was never the point. It was a workaround. And the workaround is being automated out from under us.

The spec was always a proxy

Be honest about why specs exist. We didn't write them because a Business Requirements Document is a thing of value. We wrote them because we couldn't build the thing ourselves — so we built a description of the thing and prayed it survived the handoff.

It rarely did. A requirement travels like a game of telephone: business → BA → BRD → dev → QA → "that is not what I asked for." Every translation leaks signal. By the time the build comes back, you're three rewrites and two sprints away from where you started, arguing over a paragraph on page 19 that two people interpreted three ways.

A working prototype leaks nothing. It doesn't describe the requirement. It is the requirement, rendered. You can click it, break it, and disagree with it in concrete terms instead of in the abstract poetry of "the system shall."

The document was a bridge we built because we couldn't get to the other side. The tooling now gets you to the other side directly. The bridge is becoming scaffolding nobody needs.

What AI actually commoditized — and what it didn't

Let's be precise, because the lazy version of this argument ("AI changes everything") helps no one.

AI is excellent at turning a clear ask into a tidy artifact. Give it a paragraph of intent and it returns user stories, acceptance criteria, a structured BRD, a sequence diagram. That slice of my old job — the part where I converted plain English into a well-formatted Jira ticket — is now a prompt. It costs the price of a coffee per month.

If that is where your value lives, I have bad news, and it's already arriving.

But notice what the model cannot do. It cannot sit in a room where the head of underwriting and the head of claims both believe they're right, and figure out which problem is actually worth solving first. It cannot tell you that the "simple" change you requested quietly breaks how the reinsurance treaty settles at quarter-end. It cannot hold the messy, contradictory, half-articulated reality of a business in its head and decide what is worth building at all.

The model commoditized the transcription. It didn't touch the judgment. The trouble is, for years we dressed up transcription as judgment and got paid for both. That bill is coming due.

In my world, the requirement doesn't exist until someone sees it

I work in reinsurance. If you've never lived in it: imagine a calculation with layered retentions, sliding-scale commissions, and treaty terms that change behavior depending on a loss event that hasn't happened yet. Now imagine asking a 25-year underwriting veteran to describe the screen they need.

They can't. Not because they don't know — they know it cold. But the knowing lives in their hands, not their words. I have watched brilliant people fail completely to specify what they will recognize in half a second the moment they see it.

And they always say the same thing: "No — not like that."

That sentence is worth more than any signed-off BRD I've ever produced. And you only ever earn it by putting something in front of them. So I stopped asking people to imagine. I started clicking things together — a rough prototype, a flow you can actually walk, a working model of the calculation — and let the ambiguity die on contact with a real object.

You don't extract requirements from a domain expert. You provoke them. A prototype is a provocation.

Building isn't shipping

Here's the objection, and I get it every time: "BAs shouldn't code. You'll make a mess. That's engineering's job."

You're picturing the wrong thing. I am not pushing to production. I am not auditioning to be a developer. I build to think. The prototype is disposable — half of mine die the same afternoon they're born. The understanding they produce is not disposable. That's the whole trade: spend a cheap, ugly, throwaway artifact to buy an expensive, durable insight.

The old loop was: write it up, wait two weeks, review, discover we were wrong, rewrite, repeat. The new loop is: here, I made it, does this feel right? — in the same conversation, while the stakeholder is still in the room and still cares. Engineering then builds the right thing once, instead of the documented thing three times.

I'm not doing engineering's job. I'm making sure engineering never has to do it twice.

The hiring math is brutally simple

Picture two business analysts.

The first hands you a beautiful document. Comprehensive, well-structured, signed off by everyone. You'll find out in eight weeks whether it was right.

The second hands you a clickable draft of the actual thing — wrong in places, but concretely wrong, the kind of wrong you can point at and fix today — and the document too, if you still want it.

One of them de-risks your roadmap this week. One of them de-risks it next quarter, maybe.

The first analyst's core skill is the one a model is racing to zero. The second's skill compounds: deep domain knowledge, plus the ability to make that knowledge tangible fast, plus the judgment to know what's worth making tangible at all. You cannot prompt your way to that combination. You hire it, or you don't have it.

If I'm screening for a role today, the document-only BA isn't a cheaper version of the builder. They're a different, shrinking category — and they're competing with software for the part of the job that software now does better.

So here's the manifesto

A spec describes a future and asks everyone to trust the description.

A builder makes a rough draft of that future you can actually hold, and lets reality argue with it early — while arguing is still cheap.

For a decade I was paid to be a very good describer. The market rewarded it because building was hard and describing was the next best thing. Building isn't hard anymore. Describing isn't enough anymore.

I'm a business analyst who builds. Not because I want to be a developer — because the work was never really about the document. It was always about closing the distance between what a business needs and what gets made. The document was just the longest way to get there.

There's a shorter way now. Take it.

Be the kind that builds.