AI Will Save Software Development - Flywheel Studio
AI Will Save Software Development
AI Will Save Software Development

AI Will Save Software Development

AI Will Save Software Development

By

Erik Goins

Published on:

AI isn't going to ruin software development. It's going to save it.

I believe this for two reasons.

The world needs more software, not less

We need millions more software applications than we have today. Software should be personal. It should work for users the way they actually want it to work. Instead, we have a handful of broad platforms that require significant customization, at astonishing cost, to do what any one user actually needs.

The result is that most users pay for an entire platform and use a small slice of it. Or worse, no software fits their use case at all, so they're running their business in excel.

Imagine a world with more specific applications, tailored to niche use cases, that feel like they were designed for you. There are thousands of use cases that don't have a real software solution today, and that needs to change.

At the same time, there's a real shortage of software developers. Development isn't an easy trade — it's tedious, specific, and difficult. Most schools and universities don't even teach it. So we have demand climbing and supply constrained. Something has to give.

Most of "software development" isn't software development

This is my biggest frustration with our industry: a huge percentage of what developers do every day isn't actually the creative work of building software. It's mechanical translation. We've accepted this because we've had to, but the constraint is changing.

Here's how we've historically built software at Flywheel Studio.

First, Discovery and Design. This is critical for us. Most agencies will quote whatever a client walks in with. We take a step back and ask whether those are the right requirements in the first place. For our clients this is common sense — let's make sure we're building the right product, with the right features, the right way, before we start. A full D&D takes 1-2 months. Our sprint version takes 1-2 weeks.

The output is high-fidelity Figma designs with technical requirements — everything needed to build the application end to end.

Then we move into development. As the #1 FlutterFlow agency, most of our projects are built in FlutterFlow. Our developers manually recreate the Figma designs in FlutterFlow, set up the database, wire up integrations, and so on.

This is what we call software development. But is it? Is spending six weeks copying Figma designs into FlutterFlow really software development? Or is it a tedious copying process that happens to be performed by a software developer?

Consider the analogy: is manually entering receipts into an expense report "accounting"? Accountants often do it, but it isn't accounting. It's what someone has to do to get to the point where the accounting actually begins.

When we take the manual tasks away, we're not removing development. We're freeing developers up to do the actual work — the thinking, the design, the problem-solving that is creating software. That work isn't going anywhere.

What this means for the future

Three things follow from this.

1. Software is about to get dramatically better.

For over a thousand years, monks copied bibles by hand, one letter at a time. A plain copy took six months to a year. An ornate one could take three years. Then Gutenberg built the printing press.

I wasn't around in 1450, but I doubt anyone seriously thought the press meant the end of books.

AI isn't the end of software. It's the end of hand copying designs into code, hand-writing unit tests, and the thousand other thankless tasks we've accepted as "development." It's the beginning of spending more time actually thinking about software — designing better solutions, challenging assumptions, and making more deliberate choices.

Consider how software budgets actually get allocated. Give a developer 100 hours and ask them to split it between design and development, and the development side always wins — you have to ship something. Design gets squeezed because building is expensive. When AI handles the implementation, that tradeoff changes. Design gets the time it deserves, and better designed software is better software.

2. Software costs have been distorted by scale.

Six months to a year for a plain bible. Six months to a year for a standard app build. The parallel isn't an accident — both are expensive because both require large amounts of skilled manual labor.

The large armies of developers needed to build most applications are going to shrink. We'll build great software with smaller, more agile teams. And smaller teams compound in value: fewer communication channels, less coordination overhead, less gets lost in translation. There's an organizational tax baked into every large engineering team, and most of us underestimate how heavy it is.

3. What this means for you depends on where you sit.

For Flywheel, this is a clear win. I don't want our development team spending their weeks manually copying designs into code. I want them solving hard problems, challenging design assumptions, and architecting systems that actually fit our clients' businesses. That's where they add real value.

For clients, and for anyone who benefits from software, this is also a win. More personalized, niche applications. Less overly complex, piecemealed software cobbled together to approximate what a business actually needs. Faster delivery. Lower cost.

For developers, it's harder.

If your value as a developer is your ability to copy Figma designs into FlutterFlow, or any of a thousand equivalent mechanical tasks, you should be worried. That role is going away, the way the copyist monk's role went away. There's no soft way to say it.

But if you're a developer who thinks critically about software, who designs well, orchestrates AI effectively, and brings judgment to the work, this is one of the best things to happen to the profession in a generation. The tedious work goes away. The room to think, design, and build actual systems expands enormously.

I'm optimistic. This future is better than the past and better than the present. Software development is going to become what it should have always been — about creating software. That's worth celebrating.



AI isn't going to ruin software development. It's going to save it.

I believe this for two reasons.

The world needs more software, not less

We need millions more software applications than we have today. Software should be personal. It should work for users the way they actually want it to work. Instead, we have a handful of broad platforms that require significant customization, at astonishing cost, to do what any one user actually needs.

The result is that most users pay for an entire platform and use a small slice of it. Or worse, no software fits their use case at all, so they're running their business in excel.

Imagine a world with more specific applications, tailored to niche use cases, that feel like they were designed for you. There are thousands of use cases that don't have a real software solution today, and that needs to change.

At the same time, there's a real shortage of software developers. Development isn't an easy trade — it's tedious, specific, and difficult. Most schools and universities don't even teach it. So we have demand climbing and supply constrained. Something has to give.

Most of "software development" isn't software development

This is my biggest frustration with our industry: a huge percentage of what developers do every day isn't actually the creative work of building software. It's mechanical translation. We've accepted this because we've had to, but the constraint is changing.

Here's how we've historically built software at Flywheel Studio.

First, Discovery and Design. This is critical for us. Most agencies will quote whatever a client walks in with. We take a step back and ask whether those are the right requirements in the first place. For our clients this is common sense — let's make sure we're building the right product, with the right features, the right way, before we start. A full D&D takes 1-2 months. Our sprint version takes 1-2 weeks.

The output is high-fidelity Figma designs with technical requirements — everything needed to build the application end to end.

Then we move into development. As the #1 FlutterFlow agency, most of our projects are built in FlutterFlow. Our developers manually recreate the Figma designs in FlutterFlow, set up the database, wire up integrations, and so on.

This is what we call software development. But is it? Is spending six weeks copying Figma designs into FlutterFlow really software development? Or is it a tedious copying process that happens to be performed by a software developer?

Consider the analogy: is manually entering receipts into an expense report "accounting"? Accountants often do it, but it isn't accounting. It's what someone has to do to get to the point where the accounting actually begins.

When we take the manual tasks away, we're not removing development. We're freeing developers up to do the actual work — the thinking, the design, the problem-solving that is creating software. That work isn't going anywhere.

What this means for the future

Three things follow from this.

1. Software is about to get dramatically better.

For over a thousand years, monks copied bibles by hand, one letter at a time. A plain copy took six months to a year. An ornate one could take three years. Then Gutenberg built the printing press.

I wasn't around in 1450, but I doubt anyone seriously thought the press meant the end of books.

AI isn't the end of software. It's the end of hand copying designs into code, hand-writing unit tests, and the thousand other thankless tasks we've accepted as "development." It's the beginning of spending more time actually thinking about software — designing better solutions, challenging assumptions, and making more deliberate choices.

Consider how software budgets actually get allocated. Give a developer 100 hours and ask them to split it between design and development, and the development side always wins — you have to ship something. Design gets squeezed because building is expensive. When AI handles the implementation, that tradeoff changes. Design gets the time it deserves, and better designed software is better software.

2. Software costs have been distorted by scale.

Six months to a year for a plain bible. Six months to a year for a standard app build. The parallel isn't an accident — both are expensive because both require large amounts of skilled manual labor.

The large armies of developers needed to build most applications are going to shrink. We'll build great software with smaller, more agile teams. And smaller teams compound in value: fewer communication channels, less coordination overhead, less gets lost in translation. There's an organizational tax baked into every large engineering team, and most of us underestimate how heavy it is.

3. What this means for you depends on where you sit.

For Flywheel, this is a clear win. I don't want our development team spending their weeks manually copying designs into code. I want them solving hard problems, challenging design assumptions, and architecting systems that actually fit our clients' businesses. That's where they add real value.

For clients, and for anyone who benefits from software, this is also a win. More personalized, niche applications. Less overly complex, piecemealed software cobbled together to approximate what a business actually needs. Faster delivery. Lower cost.

For developers, it's harder.

If your value as a developer is your ability to copy Figma designs into FlutterFlow, or any of a thousand equivalent mechanical tasks, you should be worried. That role is going away, the way the copyist monk's role went away. There's no soft way to say it.

But if you're a developer who thinks critically about software, who designs well, orchestrates AI effectively, and brings judgment to the work, this is one of the best things to happen to the profession in a generation. The tedious work goes away. The room to think, design, and build actual systems expands enormously.

I'm optimistic. This future is better than the past and better than the present. Software development is going to become what it should have always been — about creating software. That's worth celebrating.



Related Articles

Book an introductory call

We'd love to hear about what you're working on…

© 2026 Flywheel

Book an introductory call

We'd love to hear about what you're working on…

Book an introductory call

We'd love to hear about what you're working on…

© 2026 Flywheel

Book an introductory call

We'd love to hear about what you're working on…

© 2026 Flywheel