Why Programmers and Process are More Important Than Ever in the AI Era

Festina lente. (Make haste slowly.)

— Augustus, quoted by Suetonius, The Twelve Caesars

To start this conversation I first want to address any reader assumptions. I am not anti-AI. In fact I use it in my development process quite frequently for both planning, coding, as a key element in several cyber analysis/intel applications I have built, and in my personal life (it’s great at clarifying complex tabletop game rules!).

AI can be a serious force multiplier for software devs, speeding up development significantly in some cases. But what I want to discuss is when there is the illusion of speed, and the resulting mess programmers have to clean up after.

Maybe this story sounds familiar to some. An app is developed by someone who is a subject matter expert in their field and knows just enough python to be dangerous. They also have access to a frontier model, and in a weekend build a full fledged technical application by prompting their new artificial friend.

Now this black box has numerous claims made about it and all its capabilities. Management is thrilled by the sudden and rapid progress. Everything is going swimmingly, right up until a software architect gets involved, and some software devs start testing the code.

While the architect attempts to untangle the spaghetti code and bugs keep arising in testing, six new pull requests pop, none tied to issues, because why would anyone want to be bothered by any type of development process, that would just slow things down! Meanwhile its discovered all the shiny new AI generated features were built on a branch 8 merges past.

Four hours later the merge conflicts are mostly resolved by two developers and we are ready to move forward……right? Not so fast, management wants speed, and the SME is the expert, and we can’t let “process hinder progress.”

And herein lies the issue. AI is allowing non-programmers to build large scale applications at speed. Unfortunately, while AI is surprisingly good at writing code, feeding it a massive prompt to build an entire application shows its shortcomings. In addition when done by someone who is not a coder by trade, design choices and architecture can be short term successes. The code may work under very certain conditions, but not when faced with more real world applications.

So now you have a large codebase that needs to be rearchitected to fit coding standards for a project of this size, you have an experienced software architect, and you have dedicated software developers (distributed geographically), but no software development process. On top of that you have rapid development by SMEs pushing code at a rapid base without pulling the latest and greatest branch.

I think you can see where I am going here. Poorly architected code, and no process resulting in complex merge conflicts, and development at a rate only achievable with AI. Two options arise out of this situation. One, we put on the brakes, and nail down the process, stop relying AI to continuously write features without a knowledgeable programmer to guide it and build something great, or two, we accept the garbage that has been produced and push forward to meet an unrealistic deadline with something that just works enough to impress the customer, disregarding any future pain trying to get a fully operable product. Not even considering something the team can stand by with pride.

Can we have rapid development with process? Or is process the enemy of progress. Maybe both answers are right? I will address that in the next post, because who doesn’t love a cliffhanger?