//

The New World

AI has changed software development forever - LLM’s are already capable of writing code as well as many software engineers, and we aren’t going to return to the old world of software development. We therefore need to work out what this means for us, as software developers, and understand what our new role is.

The Present

Tools and methodologies have always evolved in our field. Over my long career, I’ve seen them come and go. In many ways, software development today is unrecognizable from when I started in this industry 20 years ago. Part of the job has always been to stay up to date with this evolution and work out how to be most effective with the tooling and mentality of the day. This is never more true than over the last year, when LLM assisted coding has gone from being a sometimes useful autocomplete, to a fully fledged collaborator, capable of large and difficult tasks with minimal assistance.

A large component of our work was translating business requirements into machine executable code - because LLM’s are now capable of translating English into code very well, it seems likely that this part of our role will dwindle away. But we have always had more responsibilities than just coding, and whether we like it or not, we have to find a way to continue providing value in a world with more and more agents developing code alongside us.

This document aims to be my proposal for how we do this. In a world where half the text we read comes straight from an AI, this document is entirely written from my own head. This is because writing is very much like thinking, and one of the most important skills we cannot lose in this transition is how to think. My thoughts have evolved rapidly over the last year, and writing them down is one of the best forcing functions for formulating these thoughts.

The landscape is evolving far faster than we can keep up with processes or guidelines. I think the only way to cope with this rate of change is instead to have an ongoing discussion on how we handle the developments, and be open about how we are using these tools and the tradeoffs therein.

Part of our role as software developers has always been to work out how to incorporate the changes of the ecosystem into our specific context, and to leverage the wider developments to drive the goals of a business forward most effectively. This has not changed. AI is just another tool, and our current biggest challenge is to work out how to leverage it, and in the process, to stay relevant and useful ourselves.

The Past

As a dinosaur, I remember the world of software development 20 years ago when I first started in the industry - tools like git were just starting to become popular over subversion. Engineers would write code and then hand it over to sysadmins who would manually curate it onto the machines that they maintained. Ideas like ‘agile’ and ‘testing’ were new and exciting. There were no clouds, if you wanted to deploy something, you had to build the pieces yourself.

If you took a developer of that era and transported them to the present, they would struggle to understand their role, because so much of the job has changed in that time. Sure, the fundamentals are the same - we are still writing code that runs on a Von Neumann architecture, and we are still using the same network stack. Once they got over the parentheses around a print statement in python, they could probably even write similar code to what they were used to.

But ideas like devops, or platform-as-a-service or continuous-delivery would be alien to them. And if you were to show them an agent, writing software based on a few lines of prompt, then using generated bash to test and deploy it, you would blow their minds. The world changes, and it always has. Despite the fear-mongering, we still need software developers to understand the process of building software, to help translate business requirements into the fractal world of tradeoffs imposed by the underlying reality of software systems.

Some developers have always gravitated towards the code itself, caring about the aesthetics of a codebase, and finding their meaning in writing clean code. Some of these have demanded that their tasks have been well defined for them, so they could focus solely on the transformation of these requirements into code that met their criteria of elegance. These developers will struggle in the new world.

Some developers have never cared about code, they were always willing to do the minimal amount of hackery to get a pragmatic output, and cared less about technical debt than they did about getting to a goal as quickly as possible. Those developers will find today's world thrilling - they can use hordes of agents to deliver as many goals as they can think of. But the technical debt that has always been their weakness will remain and add a tax to long-term development on their codebases.

The rest of us developers live in between them - knowing that there is a natural limit to the size of an edifice you can build without structure and architecture that will support it. Minimizing technical debt has always been a trade-off between short term gain and long term pain. Picking the right tradeoff is context specific and requires understanding the wider business context. LLM’s cannot currently do this.

This is only a single example of the many faceted tradeoffs that have always been our job - knowing what to do has always been as important as how to do it. Knowing how the LLM’s have chosen to do something isn’t enough - we also need to know if that was the appropriate choice for a given context.

I’ll break this out into several topics, which I think we need to consider in more depth.

Ownership

An AI can’t own anything - without pain or pleasure receptors in their architecture, they are unable to be aligned with incentives. As people we live in a far richer context - we are employed under a contract which provides us with pay for the output of our labor. We are intrinsically motivated by “doing a good job”. We have joy and pain. Meetings often cause us pain. We feel shame when our output breaks or causes harm to other people.

Ownership of a codebase aims to link these extrinsic factors to the success of a unit of code. We want a person to have a motivational link to this codebase - we want them to be able to make judgement calls on the feasibility of changes, to understand the success and failure modes of the code, and to be able to correlate pride and blame with outcomes.

When a person is motivated by the idea of career growth when the software under their remit does well (and conversely, fears unemployment should it fail egregiously), we have aligned the business goal of that software component with the intrinsic motivation of a person. This model works well - a person caring about something is the most powerful force in our society. We cannot replicate this with AI.

And just as easily we can lose it by using AI wrongly - if a person who cared about a codebase becomes disillusioned by vibe-slop contributions, or loses their joy in developing that code, then we’ve lost our most valuable incentive.

We need to find a way for people to own code, to tie their reputations and hopes to it, to reward them when it works well, to tie it explicitly to the extrinsic business goals, so the informational business context is incorporated. We cannot do this without people who feel empowered to own that code, and who aren’t competing with AI’s that cannot care.

Management

One analogy for working with agents that I like is that software development has become more like management than individual contribution. At a certain point as a software developer, you become more effective when leveraging more junior developers to implement individual tasks, letting you operate at a higher level of abstraction. This hasn’t changed - software seniority has always been correlated with an ability to leverage a team to perform bigger tasks.

What has changed though, is that everyone has access to a swarm of junior developers now. In fact it’s even better - you have the power of a development team, but none of the downsides of having to keep people happy, which has always been a challenge that developers entering management have faced.

Economic scarcity meant that before, it took a lot of experience and proven success before somebody was entrusted with a team of developers. This gate-keeping had some nice properties - you were forced to hone your skills on smaller projects, learning from skilled managers (or sometimes, learning what not to do from poor ones). By the time you’d earned the reputation to be given management power, you’d become aware of the costs associated with the increased power.

And because your reputation (and thus incentives) were now aligned with the output of that team, rather than just yourself, you were motivated to develop the skills of the people under you, to invest in the team as a whole, and to build the trust in your team to be able to delegate without fear induced micro management.

I’ll return to the topic of skill development, but it’s worth noting that the new abundance of code-writing agents without the gatekeeping of a proven record now gives everyone the opportunity to become a good manager with increased leverage, but also a bad manager, whose output is more voluminous than its merits.

An obvious shortcoming of this model is that, when you had a team of junior developers, some of them would be talented enough to self direct on tasks, identifying problems that you yourself had not anticipated, and fixing them before they became an issue. The truly talented ones would do this to such an extent that they would incorporate business requirements that you hadn’t considered, adding their own initiative to the team. AI cannot yet do this.

Skill Development

We currently live in a world that has plenty of senior developers, each of whom built their skills in a world without AI, and the shortcuts that this allows. There has been a lot of hand-wringing over skill atrophy and loss of ability due to over reliance on LLM’s. It is certainly easier to ask an LLM to do something simple rather than working out how to do it yourself.

I tend not to worry about this too much - just as the invention of the calculator hasn’t stopped people being able to do maths or the invention of the GPS hasn’t stopped people from being able to read maps, I don’t think the lazy option removes our ability to do the hard thing - but it means you’re much less likely to do it. For seniors that isn’t such a problem. The muscle memory of years of doing things won’t atrophy fast.

But for juniors this represents a real problem.

One of the most important growth moments as a junior developer was always when you got stuck and had to bash your head against a problem for a prolonged amount of time. Assistance was always available from senior developers, but it came with the reputational dent of having to ask for help. Bloody minded developers like myself would spend sleepless nights trying to work out why a bug would occur. The tenacity and skills that this process developed was one of the biggest drivers of growth.

Now you can just throw a bunch of AI at any problem and go drink coffee.

Struggle may be a necessary part of growth, and LLM’s remove a lot of struggle. As a junior, if you ask AI every time you have a problem, you are probably damaging your career. In some ways this is also deeply unfair - laziness has always been the hallmark of a good developer - we write scripts to automate things we are too lazy to do. Requiring the will power to avoid an easy solution in order to choose struggle and growth means that we’ll select for less lazy developers, and that might be a problem.

The danger is that LLM’s remove struggle, and that struggle is a necessary component of growth. Without growth, we don’t build new seniors, and eventually, the seniors retire. AI optimists predict that the LLM’s will have replaced engineers completely by then, but it’s still a big source of risk for an institution.

For many decades, humanity couldn’t build a rocket engine after having gone to the moon - the Artemis mission is using refurbished space shuttle engines rather than building new ones, because the people that built them originally have retired, and the skills and knowledge went with them. Humanity can and does dig itself into local-minima holes.

AI cannot mitigate this risk - we need a pipeline of senior developers to avoid a world where we have software that nobody can fix.

Token Economics

For anyone with even a cursory knowledge of silicon valley history, it was obvious for years that the token party would come to an end. It’s been the modus operandi of software startups for years to use venture capital to get your users hooked, then crank up the prices to profit later. You should expect nothing less from an industry that calls its customers “users”.

Civilisation changing amounts of money have been poured into AI, and this is done with the anticipation of future profits. At this point, the only way for that investment to hope to pay back is that almost all users of AI will have their salaries diverted into AI services. The obvious AI investment bubble is out of scope of this document, but one thing is clear - the price of using AI will rise. Whether that is with more expensive tokens, or the need for more of them, AI will become more expensive.

The optimistic worldview says that the increased productivity pays for this outright. For anyone with a brain, it’s more obvious - the costs will be borne by reducing the number of employees. The fact that most of this document discusses the need for developers and the things that developers cannot do, doesn’t detract from the fact that this may not be apparent to upper management, and we can expect a lot of unemployment from investments in AI.

So of course there’s a huge amount of fear - the very incentives we talked about positively earlier are perverted by this. We want to do good work and be paid for it, but our output is conflated with the output of AI, and therefore cost cutting redundancies are facing us. A rational developer might respond to this by refusing to use any AI tools, and by starting a luddite movement to protect their own future. But there will always be people that prefer to use the tools to increase their performance in the short term, leveraging that gain into hopefully more long term benefits.

And some of us just use AI because we are curious about its power, and like to use dangerous tools.

But any discussion of AI in software needs to deal with the fact that there is an implicit promise of joblessness innate within it.

The Future

Predicting the future is a fool's game, so I feel well qualified to have a go. I imagine an AI bubble bursting in the next 6 months, but Pandora has opened the box. AI will be part of software development for the rest of our careers.

Some companies will be led by the hype. They’ll lay off large proportions of their software teams, and after the initial exhilaratory phase of cost reduction, their token bills will rise above the level of their former payroll. They will struggle to understand the software that they have built, and once they hit the wall of tech debt, incomprehensible to anyone at the company, they will invest in more and more contractors to try and explain how it all went wrong. They will have crippled themself and if they rely on that software, those companies will die.

Other, more forward looking companies will think deeper about these developments. They will invest in their juniors, to maintain a skill pipeline, they will provide generous token budgets to their developers to experiment with the tools, but they will track this as an R&D expense - long term usage of LLM’s will have to be justified by quantifiable benefits. They will recognise that software development is more than just writing code.

I hope we are in the latter.

My Proposal for AI Guidelines

I recently posted a version of this as an internal memo, and it received favorable feedback, along with the suggestion that I posted it more widely. So here it is.