AI
If this were a printed book, I would not write this chapter, for any ink about AI becomes dated when it dries. The capabilities of artificial intelligence tools and the outlook of AI in software engineering changes monthly. No one knows the state to come and those who claim they do have some stake in the outcome.
My biases
I come from Media and Entertainment. Generative images/audio/video have a bad reputation by artists in the industry. The training data copyright infringement, results tend to be uncanny.
I come from version control. We don't really care what you need, we'll build the tools you pay for.
Thirdly, I'm writing a book about software engineering for teams. I only write about methods that have been proven to work, not speculative potential workflows.
Does AI change the way we work. No.
Here's an example of how a typical feature development workflow happens in an enterprise company. Feature request, we write a design doc and list the requirements with all stakeholders. We implement the code. We write tests. We run our tests. We open a Merge Request. Our CI/CD platform runs the tests. We review the code. We merge the code. We ship the code.
The only thing that changed is pace. Where previously our engineer went off to implement the feature for three days, we now generate the source code in 20 mins.
Two types of projects have reported success with AI generated code: green-field projects only starting out, and projects that were already set up for scale.
- Use AI to solve your bottlenecks before adding it to other processes
- Use AI in tandem with other tools and solutions
The software life cycle has not changed, it's just shifted and accelerated. Ultimately we as engineers are still responsible for what we deliver.
Engineers have automated tasks for decades, partly for efficiency, partly because human beings cannot be trusted to reliably complete the same task with the same level of quality. AI introduces an interesting non-determinism in two forms: Firstly, as before, a human generates noise by writing the prompt. Tokens reshuffle depending on the mood that we're in. We add filler words, we forget context, we add typos.
Secondly, the tool's generated output varies. This is new. Outside noise always had a chance to influence the outcome of an automated process, but never to this degree.
Combine the two. I predict a rise of bespoke development tools that deterministically build context and then allow AI-generated source code to fill the given context.
A practical example:
Our team works with strict software guidelines for implementing a feature. The guidelines ensure our software follows a mandated architecture and enables the software code base to scale. To support this, our engineers create the initial file structure using a devtool, let's call it devan.
Historically,devan helped us create file structure, import directives, compile flags, and initialized a new feature with template data: devan create component "MyTest". devan followed strict rules and was not one for distractions. Alas, devan was not what we would spontaneous or flexible.
While experimenting with AI, we set up some local AI agents. While we pseudo-scientifically suffixed our prompt with "please please please just follow the guidelines as instructed. Do not veer beyond your task." This became bothersome rather fast.
The next day we crawled back to devan, but the magic was gone. devan's dull demeanor, while always reliable, felt restricting. And that's when it hit. We do not have to limit aidan, devan can. We build deterministic behavior (And rather perversely, aidan helped us build it into devan).
With devan building the files structure, managing the permissions, and providing comprehensive context, aidan got jiggy with it.