Roles Redefined: AI-first Driven Development
We need to be cognizant of the impact the AI is having on the industry and adapt our classic engineering roles to the new era. Software development engineers will remain irreplaceable for the foreseeable future, but not without major adaptation to the new landscape.
Today was the D-Day, a day when our company lifted the veto on using the AI tools for software engineering work. There were so many reasons put out by the Legal not to use the AI: proprietary IP leaks, customer data concerns, personal info worries, accuracy of the output, and more. C-suite had a single reason to change that: revenue. 😉
Putting aside some early adopters in our crew who may-or-may-not have used the AI tools regardless of the past veto, responsible senior engineers and architects who were dabbling at the code since the 8-bit times were encountering Copilot, Code, Codex and more for the first time in practice and were charging straight ahead at the bulk of our enterprise grade products with mountains of technical debt.
One of the architects was fuming: "This is useless! AI doesn't understand a thing and only messes things up. It used reflection in a function to figure out the call stack and to branch out different behavior based on the origin of the function call. It 'fixed' an issue by using duct tape on a nuclear reactor leak." 😡
About six months have passed since the D-Day and everyone had a chance to try out the new AI tools. Some were more cautions than the others, but no one was left indifferent once they found the right combination of skill markdowns, narrowed down the context, and started thinking with more abstraction.
"G, I cannot imagine ever going back to development without the use of an AI assistant! I mean this isn't a fire-and-forget type of a solution, but it can save so much time when you know exactly what you are doing and manage the expectations early on." - now it was a completely different story coming from that same architect.
Ever improving AI models will be coming out in the future and if we project AI growth based on the historical evidence from the first couple of years of the AI era, we can safely say that there will be no going back to the days of software development in solitude.
However there were still several challenges to tackle before we could say we've fully embraced AI-first Driven Development (ADD) model:
- C-suite put out the expectation of doubling the development output backed by a gut feeling instead of empirical evidence
- Less experienced engineers were trying to vibe code their way to achieve the new expectation
- Experienced engineers assumed they could trust all AI generated code implicitly
- Ensuring production quality with no regressions remained a bottleneck
As #1 couldn't be addressed logically, we moved on to #2 and #3. 😉
Ensuring no regressions in production (#4) is a whole another story.
There isn't a magic wand solution to how the engineers use the AI tools at their disposal. We created guidelines but more importantly we reinforced our mentorship model to evangelize expectations within the new ecosystem:
- Engineer owns the code; each PR bears your own stamp of approval and there should be no lines of code that were implicitly trusted
- Automate the first PR review to use a model different from the one you usually use as an assistant
- As we are working on enterprise grade products, a human review is also mandatory
Realistically we saw 20-25% of improvement in actual PR throughput when working on decades old enterprise grade products. This additional time was balanced out between addressing technical debt and getting new functionalities and bug fixes out to production sooner.
As of the moment of this writing when working with large scale enterprise code bases the AI showed the most promise with:
- Rapid prototyping and new feature development
- Preparing plans for code refactoring or large-scale changes
- Explaining and documenting old code and convoluted product architecture
- Writing unit tests along the way
- All repetitive pattern-based work related to UI, templates, etc.
Depending on the tool and the model used it was also possible to hit the rim on fixing medium complexity issues given proper skill markdowns, focused context and step-by-step guidelines.
A highlight of using the AI is when a junior dev engineer multiplied his productivity by an order of magnitude while writing integration tests for the product just by identifying existing patterns and heavily relying on simpler AI models.
A lowlight was when an unhinged prompt from a senior dev engineer decided to remove an existing architecture of a major product feature written over multiple dev-years and to rewrite it from scratch in order to fix an issue. Good thing we had all the above-mentioned PR checkpoints in place or we'd be flipping burgers right now. 😕
