When focusing on technology and its ever more advanced possibilities, it’s easy to forget that organisations, and the way they work and function, are still very human. Creativity, and what is created, is driven by the friendships and frictions between people. Over many years working with teams and across larger functions I’ve seen how success is down to the culture and relationships, and the positive collaborations that develop. The common complaints I’ve heard in 1:1s, and what impedes technical progress and the happiness levels of people within the business, are the result of bad relationships and inter-team attitudes.

So, what does any of that have to do with AI? Understanding success in a technology-focused company is a people-centred endeavour helps teach us how AI will help, and where it is immaterial or actively negative. In the last couple of years we’ve integrated more and more AI-first approaches into our ways-of-working. Time enough to see the impact, what things haven’t been affected, and the second-order effects of this step-change.

"More is more, nothing else"

The ability to generate a site from scratch, a new kernel module, a frontend application, terraform production-grade infrastructure in a few minutes is a relatively new one. Perhaps even a year ago, I wouldn’t have had much faith in what was produced. These days triggering an agent flow on autopilot and leaving it to completion is common, and when using the latest models, generally successful. No more combing through the documentation of a dozen separate libraries before even knowing where to start, or hunting through substack for that one answer that will solve your obscure error message. So, no more coders required? Anyone can turn ideas into reality in the blink of an eye. Well, sort of…

We shouldn’t underestimate this change, it represents a complete overhaul of the pace we can do things, and who can do them. Anyone with an idea can code something, working production software, no longer reliant on convincing 3 other teams its a good idea, or that they must drop all the other work to get it up and running. It’s a truly democratising power. Anything that removes project management meetings must be a good thing surely.

"Finally, no more admin Fridays!"

When I first enjoyed working in truly Agile development 10+ years ago, there were a few key tenets that ‘just worked’. The manifesto still holds true, and is the most productive (and fun) way of working. In many ways AI strengthens just how true those manifesto commitments are, but in reality, as organisations are very human, it is often used to do the complete opposite. There is good admin¹ that can be done. Project and team rollups that give people across the broader business (as well as senior leadership) a view of what is happening is a useful way of keeping coherence and giving the business a more unified character and understanding. Engineers are not always the most enthused at generating human-readable posts on what’s going on in their area after all. But, throwing an AI at summarising everything is both simple, and surprisingly effective. It doesn’t need to be Shakespeare, just an easy-to-read version of the epics and initiatives that have been done this month. You can even get a few nice pictures automatically thrown in.

However, unnecessary documentation, reports, and miscellaneous admin tasks are notorious for eating away at productive time, and reducing things down to the valuable and needed is often one of the key tasks when looking to accelerate development. The pattern of AI introduction is not always to ease creation of needed admin, it can also make the creation of more admin processes instantaneous. But response to these new processes is not, it takes time. People need to engage with them, meetings are generated. Having AI generated process and AI responses to them is neither always feasible, nor a healthy goal. Making processes minimal and efficient still must be the primary drive.

"I have a cunning plan..." - Baldrick

There are many ways of breaking down goals that work, in different ways, with different strengths and weaknesses. Customer outcomes picked up by a teams, broken down into some feature-based definitions of done, and technical implementation left up to individuals or small groups of engineers just works², the more autonomous we can be, the better. Its a fun and quick moving way of working. However, highly architected solutions with project-managed workflows and meetings structures, work also, and depending on a companies structure and industry, may be a necessity. I still believe that the latter way of working has some serious drawbacks in reality, sunk-cost mentality and inflexible design before discovery being real issues, but, not going to rehash any Agile arguments here.

In any case, there are reasons to write things down, whiteboards or docs. Conveying an idea, whether product or technical implementation to others is one reason. However, and if you’ve ever tried to develop any research ideas academically you’ll definitely know this one, we write so that we can think through complex problems more deeply. The act of writing is there to clarify our thinking and structure our ideas, and to unpick flaws in our assumptions.

Claude can write a 20 page doc quicker than I ever will, and missing all my spelling mistakes, however, even if I promise myself I will review and understand everything that’s generated, the mental act of reasoning about the whys of the design choices made is lost, why choices are made, why some things are discarded, and when and where compromises were chosen. Brain plasticity is one of its great strengths, and our own internal adversarial arguments are a key driver of how our neural patterns evolve.

Maybe it’s useful to use AI when I have already thought through my idea? Just using an LLM to generate something more polished for external viewers. If you think that, I suggest you look at your Confluence page metrics! There really is no observable benefit in a human creating 5 bullet points, giving it to an AI to auto-generate 20 pages, and another human giving it to another AI to auto-generate a 5 bullet point summary.

"Learning to choose is hard. Learning to choose well is harder" - Barry Schwartz

A bold statement (maybe someone should do a PhD on this topic :*) ). This is a biased opinion no doubt, based on how I see abstracted multi-agent systems³. But these patterns can be seen within most organisations with significant AI adoption. Previously, resources were a bottleneck on ideas and tasks. We don’t have infinite developer time, then we need to choose which, and which order we want to do the 100 new features we could build. This can be said for all areas, whether designing new business initiatives, or how (and how much) we do reporting and knowledge sharing. All these things were constrained, we were forced to make choices, we were forced to simplify so that us human beings could fit things in to our time and energy budgets for the day⁴.

AI removes this cost. We have no constraints on dev time⁵, we can generate as much code, plans, designs, processes as we want, in minutes. This is choice without constraint, we do more, but we have no forced prioritisation. The effect of this is firehose development⁶, we do things without any real ordering, prioritisation, or consideration of purpose or value. Would creating 1000 products not be more valuable than creating 10 though⁷? Certainly if your customers are human, this doesn’t hold up in reality⁸.

"Success is stumbling from failure to failure with no loss of enthusiasm." - Winston Churchill

The generation of code is an obvious example, but similar arguments could be made about business teams, and many areas within companies. So, why is this bad? Well, its not, but its not good either. A rapid stream of PRs is great for rapid development, but, the cost in human reviewing is substantial, and in reality is often impossible. An AI may be able to review a 1000 line change reliably, or claim to do so, but could you verify such a change? Even with adversarial PR reviewing⁹, does that actually achieve what we want? PR reviewing has always proven one of the best ways for people on teams to learn, and for counter-arguments on implementation to be suggested¹⁰. Even if you trust your AI to write great code or catch all security flaws, it is sacrificing an effective development path for your team.

"Creation without understanding makes for unsupportable realities"

Your phone pages at 2am in the morning, and you flip open the laptop and start rifling through logs¹¹. You’re not sure what the problem is, so you escalate, and pull in the team that wrote the feature that is breaking…. While not ideal, no one wants to wake up at 2am, but with the right observability and escalation, you are likely going to get to the root of the problem. Following on to a blameless post-mortem that will give you the todo-list to make sure it doesn’t break in the same way again.

What if there is no code-guru or committed team to reach out to, there is only AI. It wrote the 10,000 line code dump that went into production yesterday, and its the only one that ‘understands’ what was done. This is a single and highly-critical dependency for a business to take on. From growing and retaining a skilled group of software engineers in-house, who know the codebase inside out, to a 24/7 instant response dependency on your favourite commercial AI provider company. Once this dependency is established, it is self-reinforcing, and is extremely hard to break. A knowledge gap like this is very easy to introduce, and very hard to close. Hiring experienced engineers to bug fix someone else’s code is hard enough, hiring them to fix an AI’s bugs is likely to be too much to ask. We won’t even think about what happens when the token allowance runs out when its urgently needed, or inference timeouts as your provider gets overloaded.

"Put one foot in front of the other, as long as there’s something to stand on"

Software engineering is a trade like any other, not just writing code. Learning it takes time, from apprenticing through to wizard-like knowledge and skills. We learn how to write better code through working with others, we learn how to run robust and performant software through experiencing the failure modes and lessons running live software teaches us. As AI code generation becomes more and more capable, its easy to drift towards short-term strategies. Either, hollowing out entry-level or junior engineer roles, as the AI is skilled enough at this level (this is more nuanced than it seems however), giving their more experienced staff a high workload that they can offload many of the tasks onto an agent¹². Or, hiring early-career, less expensive engineers, who can do more complex tasks than their lack of experience limits them to because, they have a highly skilled copilot (or full autopilot) in their AI, capable of taking on increasingly advanced design and build.

Outside of the ‘who do you call’ problem above, there is an obvious longer-term one. When we have taken out the lower-experienced jobs, we have no one that will grow into a more senior and knowledgeable engineer. There is no pathway, no mistakes to make and lessons to learn that will grow someones engineering skills. If we hollow out the experience, we have even more of an immediate danger. The software we create is entirely dependent on the skills of a 3rd party AI providers model. The business now rests on this dependency and its availability, and cost, for the foreseeable future. In fact, with no progression or interesting work available to enthusiastic coders, why would you take on this job at all?

"It is not clear that intelligence has any long-term survival value" - Stephen Hawking

How our businesses, teams, and all the people in them work in an increasingly AI world is an adaptation that is fully underway. Being able to instantly generate huge amounts of complex code is a new and powerful tool at our disposal. What it means to the way we work, interact, and how our organisations evolve is something we are all trying to figure out. Short-term benefits such as increased output and rapid innovation are clear to see already, as are some of the risks of firehose development and the knowledge gap between whats written, and what we understand. Longer-term risks and benefits are more unclear, but now is the time to think about them. Once we’re committed down a path of certain skillsets being valued or not within a business, it can be difficult to reorientate if it proves problematic.

Some of the observations above may help develop some more practical actions. Encouraging learning when its no longer baked into the day-to-day through ‘hand-code days’, where no AI is allowed, or ensuring people have dedicated time for side projects, where immediacy can be sacrificed for more gradual code development. This not only maintains human skill levels, but also can increase the enjoyment of coding for many. Manufacturing constraints to replace previously inherent ones can ensure some element of prioritisation, where new projects can be created only when the success metrics for the current ones are hit, or the services removed. Forcing a maximum PR length for changes. Solutions are not easy, and it will take time to find the methods that work, but now is the the right moment to be trying things out and getting new ways-of-working that give us the best of the AI and human development worlds. Once we have lost direction, our priorities, and our culture, recovery will be challenging¹³.