Why we call them product engineers

On a typical IRLY project, AI writes most of the code. What makes that safe is everything that happens around the code.

Every project is run by senior people we call product engineers. For twenty years the industry has split the work of building software into two roles: the product person, who works out what should exist and why, and the engineer, who works out how to build it. We think that split has stopped making sense, and the way we work is built on the assumption that it has.

Why the split existed

It existed because typing was expensive. When implementing a feature took a team weeks, it made sense to have someone else spend those weeks talking to customers and writing down what the next feature should be. Specialisation was efficient, and so the wall went up: requirements written on one side, thrown over, built on the other.

Every handover across that wall loses something. The product manager knows the customer said "I need to see which invoices are overdue" but not that the real problem is a cash flow crisis every quarter end. The engineer builds an overdue invoices screen, on time, to spec, and it does not solve the problem. Everyone did their job. Nobody was accountable for the outcome.

What changed

When AI does the typing, implementation stops being the expensive part. The constraint moves to judgement: understanding the problem well enough to know what to build, deciding how to build it so it holds up, and telling whether what came back is right.

That is one job now, and a person who has spent the morning with the customer and the afternoon building the fix has no wall to throw anything over. That person is a product engineer.

What a product engineer does

Understands the problem. The problem behind the feature request, that is. They run the discovery, sit with the people who will use the system, and put our AI tooling to work on the documents, data and history around it. By the end they can state the problem in a paragraph the client would put their name to.

Decides what to build, and what to leave out. A client rarely arrives with a specification. They arrive with a problem, some history, and strong opinions about the last system. Turning that into a scope that is small enough to ship and complete enough to matter is a judgement call, and it stays with a person.

Decides how it should be built. Which database, how the data is modelled, where the boundaries fall, what gets logged, how access works. These decisions are cheap to make and expensive to change. AI will happily make them for you, and it will make a reasonable-sounding choice every time.

Checks what matters. Nothing reaches a client's environment unverified. That does not mean a person reads every line. On a project where AI produces thousands of lines a day, that would be theatre. It means the product engineers decide what the code must do, put automated tests around it, and read the parts where the risk lives: the data model, the security boundary, anything that touches money or personal information. Knowing which lines matter is most of the skill.

Knows when the output is wrong. AI is confident when it is right and equally confident when it is not. Spotting the difference quickly needs someone who has shipped this kind of system before and knows what the failure modes look like.

What the AI does

Everything else, and it does it faster than a team of ten could by hand. It drafts the implementation from the plan. It writes the tests. It writes the migration, the seed data, the API client, the documentation. When a product engineer changes their mind about a data model, it reworks every file that touched it while they are still explaining why.

The loop matters more than the volume. A product engineer can try three architectures in an afternoon, with real code and passing tests, and pick the one that holds up. Two years ago that was a fortnight of whiteboard arguments.

Why not hire two people

Because the handover is where the time and the meaning go. A product manager and an engineer, however good, communicate through documents and meetings, and each round trip costs days. A product engineer with AI at their disposal closes that loop in an afternoon, and the person who heard the customer is the person who decides what the software does about it.

It is also why we only put senior people in the role. Handing AI to someone who has never shipped produces code quickly and problems slowly. Handing it to someone who has carried the consequences of their own decisions produces software that holds up.

What this means if you hire us

You get product engineers who know your problem and your system end to end, backed by tooling that lets a small team move at a pace that used to need a large one. You talk to those people directly. When something goes wrong at two in the morning, they are the ones who know why.

It also means we say no to some things. We will not ship a change the product engineers have not verified. We will not skip the tests to hit a date. Those are the parts of the process that make the speed safe, and taking them out would leave you with fast, unreliable software.