The rate of adoption of AI coding assistants has been astonishing and impressive. This trend speaks to the utility of AI assistants, but it also reveals a huge gap in the evolution of software engineering. AI assistants like Claude and GitHub Copilot, and tools like Cursor and Windsurf, are helping developers “vibecode” entire features in minutes. Even non-developers can prompt them to create a webpage or an infrastructure configuration to host virtual machines, and the tool does the rest. We marvel at this outcome, because it is so simple, but these feats distract us from what engineering leaders should really consider: software development has not evolved with the times. Therefore, leaders must drive modernization of software processes and tooling in their organizations.
Before AI assistants, a cloud engineer who wanted to create infrastructure would start with a blank file and fill it in from their own knowledge, a prior project, a template or copy it from an article on the Internet. To this day, we start with a blank AWS account, or an empty virtual network. If a developer wants to create a web app in Flask, they start with a blank Python file. Even a more capable framework like Django only creates a directory structure. To be sure, we have starter templates, boilerplates, and generators, but none of it has matured into true inter-linkable, reusable components.
The Current State: We Start from Scratch
The current infrastructure and software ecosystem is rich with language frameworks but poor with functional building blocks. There is no AWS option to create an account by selecting the kind of application it will hold and the services it will use. Once Django has created the shell of an application, a developer still has to add a database, wire up authentication, configure local and remote environments and manage secrets.
Ideally, engineers should be able to issue a command or use a simple tool to generate the AWS configuration that they need. Yet many organizations end up creating these building blocks for themselves (I worked at a Vietnamese bank that did this at scale), which represents untold hours of repeated effort. Looking back, open source software projects were a huge boost in productivity, but the industry did not evolve to the next stage. That’s where AI is stepping in.
AI Is Repeating What We’ve Already Done
The current generative AI tools work along the basic principle of predicting the most likely output to a given input, using a neural network model that has been trained upon a huge data set. Coding assistants are resurfacing patterns that have been repeated thousands, perhaps hundreds of thousands, of times. The fact that AI can so accurately generate this code means it has seen the pattern before.
Therefore, when prompted to write the configuration to deploy serverless code in AWS, AI is up to the task. It not only produces the Terraform configuration for a Lambda function, but also the additional configurations that often go with it, such as logging and execution permissions in AWS’s identity and access management framework, because those components are also always present in examples and working code. The output has a high statistical probability. However, since the output is probabilistic, it often is not the same response each time.



Software Systems: Sum of Dozens of Parts
There are literally dozens of foundational tasks that go into creating a production-ready application. Everywhere, there are blank files that need to be filled in. The code is one component, but there are many others. The tasks don’t end with the release. Once the application is live, more components need to be added.
Pre-release Tasks and Components | Post-release Tasks and Components |
source code management | performance monitoring |
configuration parameters | performance testing |
environment variables | load testing |
local development | data backups |
automated testing | vulnerability monitoring |
CICD pipelines | autoscaling |
infrastructure provisioning | load balancing |
network configuration | monitoring and alerts |
application/image versioning and rollback | denial of service prevention |
secrets management | intrusion detection system |
static code analysis and dependency checks | disaster recovery automation |
linting and formatting | secure payment processing |
build artifact lifecycle management | customer support system |
log collection, storage and search | data retention and deletion |
Each of the above tasks becomes a decision point where software creation tools could have standardized the approach. Instead, each one is a potentially distinctive choice, leading to a huge variance from organization to organization. Sometimes, there is no standardization within an organization, or even, in extreme cases, within a project. Therefore, leaders should standardize how engineering decisions (e.g., monitoring, auth, deployment) are made across teams to reduce variance and inconsistency.
AI as a Strategic Tool
While AI assistants offer immediate productivity gains, strategic leaders must recognize their limitations. The reason that we can use AI to perform routine software engineering tasks is the same reason why AI is limited when it comes to cost optimization. Since everyone started with a blank file and filled it in according to their own knowledge, everyone’s system was built slightly differently. Thus AI, which excels at generalizing based on many input samples, can overlook individual differences. Ask it for assistance in optimizing costs and it will mention the usual actions: reduce instance sizes, consolidate services, use spot instances. These are helpful, but it requires reasoning to go beyond the low hanging fruit.
For now, AI tools present a useful option to software engineers for saving time on common tasks. However, in the absence of better tools, as engineering leaders, we should steer teams towards creating building blocks and establishing reusable templates, which are then applied across projects. Even with AI tools, individual developers should not be repeating work that has already been done elsewhere in the organization. This must also not be a one-time activity, as that will lead to obsolete or incomplete components which don’t meet the development needs. Continually revisiting code libraries and upgrading across the entire organization will lead to software development efficiency and improve the ROI or profitability of the application.