AI Isn’t The Answer

If AI isn’t the answer, what is? Before you can say what the answer is, you need to be clear what the question is. If the question is “How can I get more code written faster?”, then AI might be the right answer. On the other hand, if the question is “How can I provide more value to the user faster?”, then AI probably isn’t the answer. At least not in any meaningful way. And not with what we call AI¹ today.

Let’s be clear. One thing today’s AI can do, and do quickly, is churn out code. It will probably compile. And might even do something close to what you want. That’s probably OK as a proof of concept. It’s fast, and not completely wrong. If that’s your goal, then go for it.

On the other hand, if you’re trying to do something that hasn’t been done, deal with your specific constraints, or work with a complex, deeply interconnected system (think legacy code), typing speed is not what’s holding you back.

Consider this

Learning to program has no more to do with designing interactive software than learning to touch type has to do with writing poetry. – Ted Nelson

Yes, programming is a part of what we do as software engineers. We do eventually need to write things down in a way the computer can understand them (after translation by the compiler). But just as important as the code we do write is the way the code we write is organized. In functions, files, libraries, executables, and services (to name a few). It needs to be written is a way to make it easy to modify. As we learn more about what the code is supposed to do and what we need from it, we need the code, and it’s related tests) to be easy to update.

Also, just as important is how we organize our data. Both at rest (in memory, on disk, or in a database) and in motion (method arguments, cache layout, network messages, and more). It needs to support our use cases. It needs to be hard to get the data into a bad state. How your data is arranged can impact what your program can do in the future even more than the code itself.

Even more important than the code that gets written is the code you don’t write. Some abstraction, but not so much that it hides your meaning. Your code needs the ability to handle incorrect inputs, but you don’t want to go to far. You need to expect things to change. If you’re writing a tool to sort things, you probably want to be able to sort on multiple parts of your data structure, or at least know how that fits into your system. But you shouldn’t also build it to handle language translation. If that becomes necessary, so be it, but don’t build that in at first.

Because what you’re doing is software engineering. Making the engineering tradeoffs that fit your exact situation. Not someone else’s exact situation. Of course, It Depends, but figuring out what it depends on takes judgement. It takes awareness. It takes larger contexts. It takes intelligence. Which is exactly what AI doesn’t have. Which is why AI isn’t the answer. There are lots of ways AI can help², but it’s not ready to help with the thinking parts yet.