The problem with the future is that it takes too long.
Consider this example: Way back in 2006, Java founder and lead designer James Gosling declared, “The cell phone is tomorrow’s desktop.” He wasn’t wrong, but he’s also not yet right. Despite the ubiquity of cell phones, vendors still shipped 71.6 million desktops and laptops last quarter, according to Gartner. I wish they didn’t exist. I had to take a vacation day last week because of the unplanned hours spent fixing my neighbor’s virus-laden Windows laptop. I can’t wait for Gosling to be correct, but that day hasn’t quite come.
I’ve been known to make bold predictions in my time (open source burying proprietary software, cloud killing on-premises data centers, etc.), but I’m trying to curb that enthusiasm because, as I said, the future takes a long time. I even wrote recently that the cloud is going to take time.
Not everyone supports my newfound caution. “With TuringBots becoming available,” Forrester analysts Diego Lo Giudice, Mike Gualtieri, and Jeffrey Hammond declare, “roles, tools, and technologies on how we build enterprise apps will change forever.” By TuringBots, the writers mean “software bots that help build enterprise software”—things like GitHub’s new Copilot. Yes, it’s possible that such tools will, in fact, forever change the way developers build enterprise apps. But don’t expect that anytime soon.
AI-driven development is here
We’ve been trying to deliver on the promise of no-code/low-code development for decades. As the Forrester analysts call out, we’ve spent years with model-driven architectures and other approaches to simplifying software development (like Rational Software). Although these approaches have helped, software development remains nasty, brutish, and not particularly short, to misquote Thomas Hobbes.
Writing before GitHub Copilot launched, the Forrester analysts were ebullient in their praise of AI’s potential to transform software development:
“Huge innovation is coming in terms of the way we build applications, making AI bots good companions to business analysts, architects, developers, testers, and ops folks during the entire application development life cycle, augmenting their overall analysis, design, development, testing, and deployment intelligence and capabilities. In a nutshell, the era of making development, testing, and deployment of software, as well as the building and deployment of AI models themselves, more autonomous is here and developing rapidly.”
If the authors had been restrained before Copilot, they dropped such restraint after:
“With TuringBots becoming available, roles, tools, and technologies on how we build enterprise apps will change forever.... TuringBots will ‘read’ and ‘learn’ all the above application end-to-end design artifacts and quality requirements, including reference application and infrastructure technology stacks. Together, [application development and delivery] pros and TuringBots will build, change, and refactor applications and scale them orders of magnitude faster than current processes, dramatically reducing costs—all as close as possible to button-pushing agility.”
I know two of these analysts and wouldn’t characterize either as Pollyannaish in their optimism. Still, we may be getting way ahead of ourselves here.
AI-driven development will take time
Copilot is cool, but is it ready for production today? Yes and no. As with AI in general, Copilot isn’t ready to replace human ingenuity in coding. It does seem able to knock out some of the busywork associated with glue code or smaller utilities that would normally need to be rewritten across different applications.
Knowing when to trust Copilot requires a fair amount of human intervention. For example, software consultant John Basile says, “When you are working with it, it will give you 10 items that could be the right fit. Some of them are just flat-out terrible while others are perfect. You really need to sift through the sand to find the diamond.” Or, as InfoWorld writer Simon Bisson stresses, “You shouldn’t expect the code Copilot produces to be correct.” This might be a problem. As he points out, “you’re still going to need to make decisions about the snippets you use and how you use them.”
For a relatively inexperienced developer, Copilot might seem like a savior but ultimately it might prove an inhibitor to learning, with no good way to know when the suggestions are terrible versus perfect. Whether experienced or not, developers may find that it’s easier to not rely on something that is mostly correct, rather than make big bets on it (the same way business users stuck with Microsoft Office instead of open source alternatives like OpenOffice. It simply wasn’t worth betting on “mostly compatible” file format fidelity).
Plus there are a slew of other reasons developers may prefer not to go the no-code or low-code route.
None of this suggests there isn’t real promise in AI-driven software development, or in low-code and no-code options. But it’s going to take time. For an industry that still uses mainframes, it’s wise to bet on the future, but it’s also wise to bet on it taking a bit longer than we might like.