We explore the evolving world of generative AI in software engineering and what the future holds for a better way of working.
By Dr Liam Terblanche
Amidst the fanfare and awestruck wonder we’ve all experienced in adopting generative AI into our professional work, the lingering drawback from a software engineering perspective, has always been scope, context, standards and long-term support.
The Current Microservices Lifecycle
We build systems and then maintain them, expand on them, improve them, upgrade them, nurture them, and ten years later, throw them away for a new design on new architecture.
It’s not hyperbole to state that 50% of your development cost gets spent after the initial development cycle, performing code maintenance, reducing technical debt, commenting, and updating underlying SDKs and frameworks. Greasing the wheels to maximise longevity.
But what if that wasn’t the case?
AI Gives Software Engineers a Fresh Opportunity: Nanoservices
Rather than building microservices with 4 or 5, or 15 API endpoints, why not write nanoservices with a single API that does one thing well? Lots and lots of nanoservices.
And if my regression and load testing has sufficient coverage and depth, who cares about design patterns, comments, code quality and standardisation? If it works, it works.
We’re no longer a repair and reuse society. If something breaks, we replace it. Why should software be any different?
And this is where Generative AI can play to its strength. Define your narrowly-scoped service’s inputs, what needs to be done, and what libraries to use, and let ChatGPT or Bard write you your Python code in seconds.
Test it, and ship it.
What to do if the requirements change. If the requirements change, don’t bother modifying your nanoservice. You wisely kept your test plans. Update those with revised test cases, call on your favourite GAI tool to build you a new service and discard the old one.
Invest time building test cases. Rather invest more time building well-defined test cases. Automate your API testing as best you can with frameworks like Mountebank and Karate, track your deployed changes with Scriversi and turn your code into single-use myopic nanoservices that does one thing and does it well.
For me, this was a Eureka moment.
If I have my tests well defined, the lifespan of my code can be reduced to a single version — the one I need right now. And there’s zero technical debt.
There are apparent exceptions, and it would be remiss of me to argue that this approach has no drawbacks. But you cannot deny the allure of this way of thinking about your next project.
Get Scriversi – the free automated technical documentation tool that gives DevOps teams and software engineers freedom to do more
No credit card required. You get full access to our technical writing automation tool built for busy DevOps teams and software engineers who embrace automation.
