It Still Has to Float

AI has made it remarkably easy to get software running.

Some projects that would have required a full development team just a few years ago can now be built by one experienced engineer, with support from a tester or two, in a fraction of the time.

But making the build faster doesn't change what the software has to do. An application can look complete and still fail at the job it was built for.

The picture above is from a concrete canoe competition my daughter participated in. The idea sounds a little ridiculous at first. Build a canoe out of concrete, put it in the water, and race it.

Every team knows what a canoe looks like and that it has to float, but the water reveals which teams only got the first part right.

It's more than building the canoe

The canoe has to carry its crew. It has to be light enough to handle, stable enough to paddle, strong enough to survive the race, and maneuverable enough to get around the course and back. Then it has to do all of that better than the other canoes in the water.

A concrete object shaped like a canoe isn't enough.

The engineering lies in translating what the canoe has to do into decisions about the mix, reinforcement, structure, and shape. With one shot at the pour, all of those elements have to work together when the canoe reaches the water.

Software isn't much different.

AI can take a description of what we want and produce something that looks remarkably complete. It can write the code, create the interface, connect the pieces, and get an application running much faster than we could before.

That speed is real, and it has already changed the pace of my own work.

Running isn't the same as working

An application may handle a demonstration but not the real workflow, sample inputs but not real data, or the happy path but not the way people actually use it.

It still has to live somewhere and work with the systems already there. It has to be secure. It has to survive things nobody thought to put in the original description. Someone has to be able to operate it, support it, and change it later.

None of those things is necessarily beyond AI. In fact, AI can already help with many of them.

But that doesn't make them automatic. They still have to be considered, tested, reviewed, and improved.

And that's where I think some of the conversation about AI and software gets ahead of itself.

We're getting very good at making the canoe.

That doesn't mean we've eliminated everything it takes to get four people into it, push away from shore, make the turn, and get them back.

The rest of the job isn't disappearing

AI-assisted development is already changing how software is built. As the tools become better at producing code and completing implementation tasks, getting something built becomes less of the constraint.

That makes the engineering decisions around the build more important: understanding what the software has to do, shaping it for the people who will use it, fitting it into the systems already there, verifying that it works, and making sure it can be operated and improved once people depend on it.

AI can help with those parts of the job too, but it doesn't make them optional. Someone still has to make the decisions, verify the result, and take responsibility for whether it works.

The faster the build becomes, the easier it is to see something that looks finished and assume it will work when people start using it in the real world.

A concrete canoe can look pretty convincing sitting on the beach.

You find out what you really built when you put it in the water.