From Brisbane to Bedrock: Why Your Code Might Be Your Biggest Liability

It's somewhere in the previous decade; with the financial crisis in the rearview mirror and the pandemic far over the horizon. I, a mid twenty something enthusiastic technologist, am coming to the end of his masters degree in computer science and weighing up what to do next.

Offers locally in Ireland are on the table, but like many an Irish man before I decided to up sticks, and move to the other side of the world. The land down under.

I could spin this as some rags to riches story - and when does an Irish man let the truth get in the way of a good story. However, I'll leave embellishment for another time.

Instead my girlfriend had arrived in Australia for work 10 weeks previous and done all the hard work of finding us a place to live. A great new build apartment overlooking the city scape of Brisbane. All I had to do was find some work. Worst case scenario - I would be a kept man.

Somewhere in the second week I arose from bed overlooking the city with its 8th floor view, and after a dip in the pool, I got ready for a day of coffees with some connections I had set up ahead of time.

With a fresh shirt on - which had been meticulously ironed by mother and traveled for 24 hours across the globe - I set out on the job hunt. By 5pm that day I was in employment.

I would learn a lot during my time in Australia. I had landed a role working with the finance team and the CFO. Helping collate data from disparate sources and answer underlying business questions. Nothing my young enthusiast self wasn't up for, and I was utilizing every one of my hard skills that I had honed for 10 years. It was a baptism of fire - but I loved every minute of it.

Getting exposure to board level and learning constantly was a major plus. I couldn't get enough. Understanding commercials, how business value could be unlocked, and how to run a large enterprise.

But, there was one lesson that would stick with me for life. You see, being a young tech enthusiast I was of the mindset there's nothing lines of computer code can't solve.

One day, several weeks in I was pulled into a meeting with a couple of the c-suite and they complimented my work, and were about to embark on a build vs buy exercise for an expensive piece of enterprise software.

I of course was in the mindset of build, build, build!

However, it was the CFO that imparted the words of wisdom I live by to this day.

Every line of code a business owns is a liability - not an asset

But, what? This wasn't what I was told at university. Surely this can't be the case?

Well after another decade I can tell you, this is more the case than ever.

A piece of code has to be paid for at least three times during its lifetime. Once when it is designed, again when it is implemented, and then again when it is maintained.

In business you want to add value to the market whilst keeping your costs as low as possible. The difference is your margin - or more colloquially known as profit.

Whilst code helps you add value, by the very fact it is an expense to the business you can view it as a liability. And this got me thinking.

For the last several decades in software development we have been creating tiered apps which effectively have some sort of user interface, and underlying data repository. These two layers are tied together by some sort of code usually APIs.

These APIs contain the underlying business logic and rules required to answer users questions about the data.

Ultimately, this business logic and API layer needs to be maintained… and we end up with 100s-1000s of APIs per application with the majority of system diagrams looking like this in a simplified view.

But, does it have to be this way?

Well the answer as of today is no - it does not have to be the way.

The latest developments in GenAI have led us to the promised world of agents. Agents can perform tasks and carry out actions using Foundational Models (FM). This means that moving forward the business logic layers, and the subsequent APIs will disappear and instead be replaced by this agentic layer.

In the example above we are using Amazon Bedrock Agents to implement the business logic required to interact with the data later. The agent now handles the query generation and is able to use its pre-existing capabilities with the specific domain knowledge provided by the user.

This domain knowledge is in the form of instructions which can be used to inform the agent of what its tasks and boundaries. Prompts can then be sent to the agent from the user to elicit information for the underlying data repositories.

So, why does this matter?

Today, and for the majority of computer history, we have had to maintain - or in some cases not maintained - a layer of code which knits the data to the user. This is often a complex task with developers, architects and everyone else inside the org constantly battling the need for innovation with complexity of the code base.

The agentic experience removes this. No longer are we maintaining this complexity. The liability of a code base is now replaced by a GenAI foundational modal which can be instructed through natural language by domain experts to return the data as needed to unlock business value.

And we can go a step even further, agents can then be used to visualize this data, bring insights, and even create UIs on demand to reflect the business need.

It is promising, and we are not there yet - but it does raise these questions; What does the future hold for development? We can't lose this expertise as it will always be required to help guide and sense check any GenAI outputs, but if agents do end up replacing junior to mid level developers in the next 5 years then we must think carefully about the skills gap this will lead to.