GenAI Changed the Cost of Coding. Why Are We Still Organizing Work the Same Way?

Everyone is talking about BMAD. Agents. Specifications. How much code they can generate.

Okay. Cool.

But what does that actually change?

If we use these tools to produce more code while keeping the same organizational structure, the same handoffs, and the same feedback cycles, we are missing the more interesting opportunity.

GenAI changes the economics of implementation. Our way of working should change with it.

Here is where I think this is going. Some of it is practical today. Some of it is a prediction. And some of it probably deserves an argument.

The bottleneck is moving

The traditional squad structure made sense under a particular constraint.

One Product Owner. Five to ten developers.

The PO figured out what needed to happen. Developers spent the next sprint or several sprints implementing it. Development was expensive, so we invested heavily in planning before committing to execution.

Now implementation is becoming cheaper.

Not free. Not automatically correct. Certainly not free of integration, security, or operational problems.

But cheap enough that we need to reconsider the balance.

The question is shifting from:

Can we build this?

To:

Should we build this?

And the best way to answer the second question is often to build a small version, put it in front of users, and see what happens.

This is hardly a new idea. It is a core Agile principle.

What is new is how quickly we can act on it.

The constraint increasingly becomes our ability to make good decisions and validate them, rather than our ability to turn a decision into code.

So why would the ratio between business and engineering remain unchanged?

One PO. One engineer. Working on the same problem.

Here is the model I would like to see more teams try:

One Product Owner working directly with one engineer.

Not a PO writing stories for ten developers. Not an engineer receiving requirements over the wall.

Two people working on the same concept, with agents supporting the implementation.

The PO brings business context, customer understanding, and product judgment. The engineer brings architecture, technical constraints, and an understanding of what can be simplified.

Neither person has to pretend to be the other.

I do not think the typical future is one person doing the entire job. Some people can move comfortably across business and engineering. Most have deeper expertise on one side.

That is fine. The point is to connect those strengths, not eliminate them.

The conversation changes from:

Write the requirements. We will show you the result at the end of the sprint.

To:

Is this what you meant? What if we do it this way? Does that change the business outcome? Let's try it.

That is a fundamentally different feedback loop.

An engineer can challenge an unnecessary requirement while it is still an idea. A PO can correct a misunderstanding before it becomes a completed feature.

You do not need to wait for the sprint review to discover that you built the wrong thing.

BMAD is interesting because it connects the workflow

BMAD is interesting to me because its ambition goes beyond code generation.

It connects product exploration, requirements, architecture, epics, stories, implementation, and review.

That matters because the business question and the engineering question should not live in separate universes.

A tool that helps execute a specification is useful.

A workflow that helps us question the specification, identify contradictions, and carry decisions through implementation is more consequential.

It gives the PO and engineer a shared structure to work within.

It does not make their judgment unnecessary. It makes their collaboration more valuable.

Automating the handoff is useful. Removing an unnecessary handoff is better.

A prototype that would previously have been hard to justify

One experiment on my team illustrates why this matters.

We have a complex workflow embedded in a mobile application through a WebView. From the mobile side, it behaves like a black box. The workflow reaches into multiple subsystems, while the application mostly hosts the experience.

Replacing it with a native experience used to look like a substantial coordination problem.

You would need to understand the existing implementation, trace dependencies across repositories, identify the available interfaces, and preserve the business behavior.

Before writing much native code, you already had a discovery project.

One engineer on the team is now exploring that replacement by bringing the relevant repositories into a shared workspace and using BMAD to help reason across them.

This is a prototype, not a claim that the entire migration is finished.

But the change in feasibility is already interesting.

Something we previously struggled to justify as a larger engineering effort is now being explored by one person.

And this particular experiment has a useful constraint: the business behavior should stay the same.

We are changing the implementation, not inventing new business rules.

That does not remove the need for validation. It gives us a clearer target.

What if we stopped assuming every feature must live forever?

There is another consequence of cheaper implementation that I find even more interesting.

We might finally reconsider our habit of continuously adding to existing software.

I remember a presentation from roughly 15 years ago, possibly at a Ruby on Rails conference. The speaker suggested something that sounded impractical:

When you begin the next iteration, reconsider and rewrite what you built in the previous one instead of automatically building on top of it.

You implemented login and registration. Now you understand the problem better. Before adding account settings, implement that foundation again using what you learned.

People were skeptical. Understandably.

Rewriting working software is expensive. Existing behavior is easy to miss. At some point, the product becomes too large for the idea to make sense.

Those objections have not disappeared.

But the economics are changing.

What used to be obviously impractical may now deserve another look, at least within a well-defined boundary.

Not the whole enterprise stack. Not every service before every release.

A workflow. A module. A bounded part of the product.

Instead of asking:

How do we attach another feature to this?

We could ask:

Knowing what we know now, what should this part of the product look like?

Those are very different questions.

Rewrite the implementation. Preserve the knowledge.

There is an important distinction here.

I am not suggesting that we throw away everything we learned and ask an agent to recreate production from a vague prompt.

That would be a great way to rediscover old bugs.

The valuable assets include:

• Business rules.
• Explicit requirements.
• Architectural constraints.
• Tests that capture expected behavior.
• Knowledge of failures and edge cases.

The implementation is one expression of that knowledge.

It does not have to be the permanent expression.

If we can preserve the constraints and validate the behavior, we have more freedom to replace an implementation that no longer fits.

We also have more freedom to remove things.

Cheaper code generation can make feature bloat much worse. It becomes easy to add something and surprisingly difficult to explain why it should remain.

The ability to build more should increase our discipline about what we keep.

Otherwise, we just generate a larger maintenance problem faster.

Community matters more than another internal framework

Another part of this shift is where the workflows themselves come from.

I would rather start with an active, community-driven framework than assume every organization needs to invent its own agent orchestration system.

Internal experiments are useful. Specialized constraints are real.

But maintaining a development framework is a separate product responsibility. Someone has to improve it, test it, adapt it to changing models, and learn from its failures.

A community can create a useful feedback loop:

• People try the workflow.
• They expose weaknesses.
• Improvements become available to other users.
• Those users test it against different problems.

The interesting opportunity is to contribute to that loop, then customize where the actual business constraints require it.

We should spend less time proving that we can invent another framework and more time learning how to use these workflows effectively.

This is an experiment, not a new organizational religion

Large organizations will not suddenly become collections of independent PO-engineer pairs.

Shared platforms, backend dependencies, compliance, and coordinated releases still exist. Faster code generation does not make them disappear.

But those constraints should tell us where to test the model, rather than become a reason never to test it.

Pick a bounded workflow.

Pair a PO with an engineer.

Give them a structured agentic workflow and a short path to feedback.

Then measure how long it takes to answer a useful question:

Did we build something worth keeping?

We can implement more quickly. We can reconsider implementations that once felt too expensive to replace. We can bring business and engineering into the same working conversation.

But only if we change how we work.

Otherwise, we have taken a fundamentally different capability and used it to make the old conveyor belt run faster.