Hired to write the requirements. Ended up shipping the code.

The situation

I was hired as a business engineer. Both sides knew I had spent six years as a software engineer first, and that turned out to be the point.

The team is a data hub: we collect and filter the data an external planning partner turns into shelf layouts — which products sit where, in which store, for which assortment. The business users on the other end are the people who need those layouts to be right.

The work has a familiar shape. Requirements arrive as conversations, not documents. The distance between “the business needs something” and “something exists” runs through several people, and every handover is a place where meaning gets lost.

What I actually do

The title says business engineer. In practice I work closer to a founder engineer: find the problem, decide what should exist, build it, and stay with it through support.

The stakeholder half. Weekly sessions across three project scopes, sitting in the business meetings, working out what people actually mean before it becomes a requirement, then turning that into the specifications and test cases the team builds against. I have been the developer receiving vague requirements, which is most of what I know about writing good ones.

The building half. I ship merge requests. When I saw we had no reliable way to check the quality of our own data, I built a sentinel that verifies references hold between data files, so inconsistencies surface where we can see them instead of travelling downstream to someone who trusted them. Nobody assigned that. It came out of noticing a gap while doing something else — which is the whole argument for having the person who spots the problem be the person who can fix it.

The support loop. I take support questions, work out what is actually being asked, and turn the recurring ones into requirements. Support is the cheapest requirements research available, and most teams throw it away.

The AI initiative

I started the team’s internal AI workshop three months ago. It runs weekly: a presentation every second week, and a discussion between groups on the weeks in between, with the topics refreshed as things move.

It was resisted at first. Not everyone wanted it, in the team or more widely in the company — mostly people who did not see the value. That was genuinely strange to me, given what the tools can already do, but it was the actual starting condition and no amount of enthusiasm on my part shortened it.

What changed it was not argument. It was showing the work: proofs of concept, in public, on problems people recognised as theirs.

Three months on, people are building their own agents. Mine are there to be used, but that stopped being the point — the team now writes its own. That is the outcome I would claim from this, and it is a different thing from having built some tools.

What changed

Testing changed the most. I have agents that help write tests, run them, and produce the reports, integrated with the test tooling and with Jira and Xray. The individual pieces are not exotic. What made the difference is that they are joined up, so the path from “we need to test this” to “here is what happened” no longer runs through several manual steps and a person remembering to do each one.

A quieter change: the line between specifying and building moved. Conception tickets here already came alongside implementation tickets. What is different now is that for simple implementations I attach the code changes too — not because a process asked for it, but because producing them stopped costing enough to be worth deferring. When the cost of a step falls far enough, the boundary that existed to protect against that cost stops making sense. That is most of what AI has actually changed about my week, and it is less dramatic and more useful than the way it usually gets described.

I would rather say that plainly than attach numbers I have not measured.

Why this still matters

Most organisations still split this work in two: someone who understands the business writes it down, someone who understands the system builds it. The gap between them is where budget goes to die — not through incompetence, but because meaning does not survive the handover intact.

Closing that gap personally is faster than managing it. And the adoption half is the part people underestimate: the tooling is the easy bit, the resistance is real, and it does not move because someone explains that it should. It moves when a colleague sees their own problem solved in front of them.