By Caleb Francis, VP of AI Services at DeveloperTown

AI has made it remarkably easy to build software.

That's mostly a good thing.

Developers can move faster. Teams can prototype ideas in days instead of weeks. And people who have never written code before can turn an idea into something that looks surprisingly close to a working application.

But there's a catch: AI can help you build the wrong thing much faster, too.

We're already seeing the consequences.

Recently, our team inherited a project that had been built almost entirely through vibe coding. From the outside, it looked nearly finished. The expectation was that an engineer could come in, make a few adjustments, and get it across the finish line.

Instead, we found foundational decisions that made the existing application essentially unusable.

The result? Roughly a $70,000 rebuild.

The problem wasn't that AI couldn't write code. It had written plenty of it.

The problem was that no one had made the right engineering decisions before the code was written.

The most expensive mistakes happen early

Think about building a house.

If someone hands an experienced builder a bad set of plans, they can often spot the problems before anyone starts pouring concrete or running electrical.

AI is incredibly useful once you know what you're trying to build. But it isn't necessarily going to stop you and say, "These plans don't make sense."

We've seen this happen numerous times where AI had found a technical solution, but it hadn't done the due diligence to determine whether it was the right solution.

That's where experienced engineers become more important.

Their value isn't just their ability to physically write the code. It's knowing which questions need to be answered before anyone starts writing it.

Vibe coding is the new offshore

There's actually a familiar pattern here.

Earlier in my career, I worked at a startup-focused agency where a significant portion of our work involved rescuing software projects that had originally been outsourced offshore.

Some were perfectly salvageable. Others weren't.

We're beginning to see something remarkably similar with AI-built applications.

Some come to us with a solid enough foundation that experienced engineers can take them and run with them. Others might be useful as prototypes or learning tools, but the underlying application can't reasonably become the production system the company needs.

The technology has changed. The underlying problem hasn't.

Someone optimized for getting software built without having enough engineering expertise involved in deciding how it should be built.

AI is a yes man. Good consultants aren't.

There's another reason engineering judgment matters, particularly in consulting.

Sometimes the most valuable thing we can tell a client is no.

No, you shouldn't build that.

No, you shouldn't architect it that way.

No, you don't need a custom system when an off-the-shelf product will solve the problem.

Or: yes, you can build it — but here's what it's actually going to cost you to maintain it over the next five years.

AI is very good at responding to the request you give it. If you ask it how to build something, it will generally help you build it.

A good engineer should also be asking whether you should build it at all.

For enterprise organizations especially, that's often where the real value lies. The question isn't simply, "Can we do this?" It's "What's the risk of doing this? What will it cost to maintain? What dependencies are we creating? And is there a simpler way to accomplish the same outcome?"

Those aren't coding questions.

They're judgment questions.

Discovery matters even more when development gets faster

Ironically, AI's ability to accelerate development has also made upfront discovery more important.

Imagine a development team traditionally works in two-week cycles. Stakeholders have two weeks to answer questions, refine requirements, and make decisions before the next batch of work is ready.

Now imagine AI helps that same team complete the work in four days.

You've accelerated development — but you haven't necessarily accelerated the organization around it.

This is especially noticeable in enterprise environments, where getting an answer to a requirements question may involve multiple stakeholders, approvals, or competing priorities.

The development team reaches the next decision point faster, but the business isn't ready for it.

A strong discovery process changes that.

It allows experienced engineers to identify foundational requirements, evaluate architecture, select appropriate technologies, surface risks, and make key decisions before rapid development begins.

That means fewer interruptions once the build is underway — and a much lower chance of discovering three months later that an early assumption sent the entire project down the wrong path.

The engineer isn't dead. The job is changing.

The conversation about AI and software engineering often gets reduced to one question:

Will AI replace developers?

That's probably the wrong question.

AI is already changing how much code an engineer needs to write manually. That will continue.

But writing code was never the entirety of engineering.

Engineering is also understanding systems. It's recognizing requirements the client doesn't know to articulate. It's evaluating tradeoffs. It's sequencing work correctly. It's anticipating risk. It's understanding what will happen when a prototype becomes a production system serving thousands of users.

And sometimes it's having the experience to look at the plans before construction begins and say:

We shouldn't build it this way.

As AI makes the construction part faster, that judgment becomes more valuable — not less.