Skip to content

The Factory

What AI-assisted production actually changes

AI changes how much of software production can be drafted and checked, not who answers for the result. What shifts inside the Factory, and what stays human.

From the crew · Software engineering · · 4 min read

In a dark editing suite, a director and a client review a cut on two monitors while an assistant checks the shots against the storyboard.

Two stories are usually told about AI in software production. In the first, AI does the work and people become optional. In the second, AI is a clever autocomplete that changes little. Neither matches what we see when we build enterprise applications every day.

The real change is more specific, and more useful to understand. AI changes the cost of drafting and checking many kinds of work. It does not change who has to understand the operation, who decides what is acceptable, or who answers for the result. Seeing where that line falls is most of what an organization needs in order to use AI well.

What changes: the first draft arrives early

In a traditional project, the first tangible thing a business team sees is often weeks away. Before it, there are interviews, documents and diagrams, all of them abstractions that people have to imagine their way through.

AI changes the economics of the first draft. A recorded conversation can become a structured list of needs the same day. A structured need can become a working prototype that people can click through. Code, tests and documentation can be drafted from agreed decisions rather than typed from nothing.

The important consequence is not speed for its own sake. It is that people react to something concrete much earlier. A finance lead looking at a prototype of an approval flow is likely to spot the missing exception at once, where the same person reading a specification might not. Earlier drafts mean earlier corrections, while they are still cheap to make.

What changes: the shape of the work

When drafting becomes inexpensive, the work reorganizes around what remains difficult. In the Factory, that means roles become more distinct.

  • Shaping turns conversations into needs and prototypes, and checks them with the people who do the work.
  • Building produces the application, with AI carrying much of the drafting and engineers owning the design and the hard parts.
  • Verifying is a separate responsibility. The role that builds is never the role that verifies, and verification works against what was agreed, not against what was produced.

This separation matters more with AI, not less. A system that produces plausible work quickly also produces plausible mistakes quickly. Review is no longer a formality at the end; it is where much of the value sits.

What changes: memory becomes part of production

AI works from what it is given. If the context of an application lives only in the heads of the people who attended the meetings, every new piece of work starts partly blind.

So AI-assisted production pushes teams to write things down in a usable form: the decisions made and why, the constraints that apply, the current state of each change. In the Factory this shared memory is part of the production system itself. It helps the AI draft work that fits, and it helps people too. A new specialist joining the work can read what was decided instead of asking around.

What does not change: understanding the operation

AI can structure a conversation, but it cannot decide which conversation to have. Knowing that the real bottleneck in a purchasing process is the third approval, not the form, comes from talking with the people who live with it, watching the work and asking the next question.

That understanding remains human work, and it remains the foundation. An application built quickly on a misunderstanding is still built on a misunderstanding.

What does not change: judgment and accountability

Some decisions do not belong to a model. What should be built at all. How the system should be designed so that it can be maintained. What is acceptable to release. Anything that touches money, people, security or legal obligations.

In the Factory, those decisions belong to senior people in each discipline, and each decision has someone who answers for it. AI extends what the crew can produce; it does not dilute who is responsible. When a client asks why the system behaves a certain way, there is a person who can explain the decision and a record that shows it.

New risks, managed deliberately

AI-assisted production brings its own risks, and it is better to name them than to hope they stay small.

  • Plausible errors. Generated work can look right and be wrong. The answer is independent verification against agreed needs, and tests that are reviewed as carefully as code.
  • Confident language. Generated documents can sound more certain than the underlying decision. Records should say who decided, and on what basis.
  • Over-trust. When drafts are usually good, people stop reading them closely. Separating the roles of building and verifying keeps attention where it is needed.
  • Data exposure. What is sent to a model, and where it is processed, is a design decision. It is made with the client's constraints in view, not by default.

Questions worth asking a partner

If you are evaluating anyone who uses AI to build software for you, a few questions reveal a lot more than a demonstration.

  • Who verifies the work, and is it a different role from the one that built it?
  • Where do decisions and context live, and could a new person find them?
  • How early will we see something we can test?
  • Which decisions will always be made by a person, and who is that person?
  • What data will be processed by AI, and where?

The answers say more about how a partner works than any claim about how much AI they use.

The short version

AI makes drafts early and checks cheap. That lets a crew spend more of its time where the value always was: understanding the operation, making sound decisions and verifying the result. The Factory is built around that shift. The technology carries much of the production. The people stay accountable for the judgment.

Keep reading

  • A director points to a storyboard whose sketches are linked in a loop, while two people at the table study it.

    Transformation as a function

    Transformation is a function, not a project

    Projects end; the need to change does not. Why organizations that keep evolving treat transformation as a standing function, and what changes day to day.

    September 28, 2026 · 5 min read

  • In an empty industrial hall, a director frames a shot while a colleague holds up photos of possible locations: a hospital corridor, a lobby, a kitchen and a building site.

    Governance by design

    Any language, any cloud: why we stay agnostic

    Why Croo builds with the languages and clouds an organization already relies on, or runs the application itself, and how hosting becomes a design decision.

    September 21, 2026 · 4 min read

All insights

You do not need a finished brief.

Tell us how the business works today. We can start there.

Start a conversation