The future of software engineering isn't about writing code faster. It's about building the systems that build software.

Let's Talk About Henry Ford

Before talking about AI, let's go back more than a hundred years and talk about Henry Ford.

Yes Henry Ford. Bear with me.

In the early days of the automobile industry cars were largely built by hand. Skilled workers assembled components piece by piece.

It was expensive, slow, and difficult to scale.

Ford didn't invent the automobile or the assembly line. But he helped revolutionize manufacturing by introducing the moving assembly line into automobile production.

His breakthrough wasn't a better car.

It was a better way to build cars.

Instead of relying on craftsmen building individual vehicles, he helped create a system capable of producing cars at scale.

And that changed everything.

Of course, handcrafted cars still exist. Rolls-Royce is famous for its craftsmanship.

And that's perfectly fine.

If you can spend years building a single piece of software and sell it for millions, lucky you, I guess.

But for the rest of us, I think it's time to start building factories.

We've Been Building Cars by Hand for 60 Years

From punch cards and assembly languages to modern frameworks, cloud infrastructure, and automated deployments, software development has evolved enormously.

But fundamentally, developers have always been responsible for producing the software.

We understand requirements, design solutions, write code, test it, and ship it.

We've become better and faster at every step.

But we're still building the car by hand.

AI changes that.

For the first time, we're approaching a world where developers don't necessarily have to implement the software themselves.

We're moving from building software to building systems that build software.

And that's a much bigger revolution than autocomplete on steroids.

I Love Writing Code. That's Becoming a Problem.

I genuinely love programming.

Sometimes I wish I could spend eight hours doing nothing but writing code. Line by line, solving problems, refactoring, making everything beautiful.

At the end of the day, I'd look at what I'd built and feel proud.

But how do I justify it?

Imagine telling my boss:

"Look at this feature! I spent eight hours writing it, and I'm really happy with the code."

And the obvious question would be:

"Why didn't you use AI? Couldn't you have done it in a fraction of the time?"

And honestly, that's a reasonable question.

AI doesn't magically solve every problem in ten minutes. But increasingly, spending hours manually implementing something that AI could help deliver much faster is difficult to justify.

My job isn't to write code.

My job is to solve problems.

And that's a distinction I think many developers will have to confront.

An AI Coding Assistant Is Not a Software Factory

Right now, most developers use AI as a faster pair of hands.

We describe a task. AI writes some code. We review it, adjust it, and move on to the next task.

That's useful.

But we're still the ones driving every step.

A Software Factory is something fundamentally different.

It's an engineering environment where specialized AI agents have the instructions, tools, permissions, and feedback loops necessary to perform development work autonomously.

Instead of prompting an agent to implement a ticket, we build a system that can pick up the ticket, understand it, implement it, test it, and prepare it for release.

Humans define the objectives, constraints, and approval boundaries.

The factory executes the work.

The difference isn't how good the AI is at writing code. It's who is driving the process.

So, How Do We Build One?

I don't think building a Software Factory means throwing ten AI agents into a repository and hoping for the best.

We need to engineer the environment around them.

1. Give AI the right environment

Start with architecture, coding standards, documentation, and reusable instructions.

Expose the tools your team already uses through scripts, APIs, and integrations.

AI should be able to read tickets, understand the codebase, run tests, inspect failures, and interact with your development workflow.

I've been experimenting with AI skills, reusable instructions, and connecting agents to project-management tools.

And the more I work with these systems, the more convinced I become that the environment matters just as much as the model.

A powerful agent in a terrible environment is just a faster way to create terrible software.

2. Build specialized agents

Imagine an engineering team consisting of AI agents.

A Frontend Agent understands your UI components and design system.

A Backend Agent understands your APIs, database, and business logic.

An Architect Agent evaluates technical decisions and architectural consistency.

A QA Agent validates implementations and identifies problems.

Each agent has clear responsibilities, tools, and boundaries.

They don't need to know everything.

They need to be exceptionally effective within their areas of responsibility.

3. Connect them into a production system

Now imagine a product manager creates a feature request.

An agent analyzes the requirements and creates technical tasks.

The Architect Agent evaluates the implementation.

Frontend and Backend Agents build their respective parts.

The QA Agent tests the result.

If something fails, the relevant agent receives feedback, fixes the problem, and tries again.

When the work meets the required standards, the factory prepares a pull request with the implementation and verification results.

A human reviews important decisions and approves the release.

That's the factory.

Not an individual agent writing code, but a coordinated system producing software.

4. Build quality control into the factory

Here's the catch.

AI can produce bad software incredibly quickly.

Without proper controls, you're not building a software factory.

You're building a garbage factory.

Tests, architectural rules, security checks, and observability aren't optional extras.

They're the foundation.

The factory needs to understand what it's building, verify that it works, and explain what happened when something goes wrong.

And when it makes mistakes, we should improve the system rather than endlessly correcting the same problems manually.

The goal isn't to remove humans from every decision.

It's to make human intervention increasingly focused on the decisions that actually matter.

Developers Won't Disappear. They'll Become Factory Engineers.

When generative AI first appeared, people immediately predicted the end of software developers.

AI writes code. Companies need fewer developers. End of story.

But that argument assumes something I fundamentally disagree with.

It assumes the amount of software we need to build is constant.

It isn't.

If a development team becomes ten times more productive, why assume they'll simply build the same things with fewer people?

Why not build more?

Why not tackle problems that were previously too expensive or complicated?

Why not build products we couldn't even consider a few years ago?

AI doesn't just make developers faster.

It expands what developers are capable of building.

Of course, team structures will change. Some roles will disappear, others will emerge, and smaller teams may accomplish what previously required entire departments.

But I believe the most valuable engineers will increasingly become architects and operators of AI-powered development systems.

People who understand how to design, orchestrate, validate, and continuously improve their factories.

Not just people who know how to write code.

Adapt or Get Left Behind

You don't have to like AI.

You can hate the hype. You can question the quality. You can miss spending your days writing code.

Trust me, I understand.

But refusing to adapt won't stop the industry from changing.

And I think developers who insist that writing code manually is what makes them valuable are making a dangerous bet.

Knowing how to write great software will remain important.

But actually typing that software into an editor?

I believe that's becoming one of the least interesting parts of our profession.

The real challenge is building systems capable of producing great software reliably, repeatedly, and at a scale we couldn't achieve before.

Just like Henry Ford didn't eliminate the need for automotive engineers, AI won't eliminate the need for software engineers.

But it will fundamentally change what we engineer.

And the teams that recognize that early will have an enormous advantage.

We spent decades learning how to build software.

Now it's time to learn how to build the factories.