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. The source of the 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 working 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 that success in a technology-focused company is a people-centred endeavour, helps teach us how AI tools help, and where they are dead-weight or actively negative influences. The places they can ease our pain, and where they will just increase it. In the last couple of years we’ve integrated more and more AI-first approaches into our ways-of-working. Time enough to see where the impact has been, where things haven’t changed, and some of 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 I have experienced. 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 direct opposite. There is (relatively) good admin that can be done. Project and team rollups that allow the leadership and the broader business to get a view of what is happening across the org 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 works well (with product, and customer showcase sign-off and all those other collaborative things). Its a fun and quick moving way of working. However, I’ve also seen highly architected solutions pre-designed, with project-managed workflows and meetings structures, work. 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, if you’re not a convert by now….

However, 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 thats 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 order we want to do the 20 new features we want to 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 (although, observe how everything slows down around the same time of day/month as people’s tokens run out), 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 effects of all this is firehose development³, we do things without any real ordering, prioritisation, or real 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 the prominent example currently, but similar arguments could be made about business teams, and possibly any other areas within and without technology 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, can you? And, even with adversarial PR reviewing (a pattern of one model planning, one model building, and a different model reviewing tends to work ok), 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 added⁴. Even if you trust your AI to write great code or catch all code or security holes (I’ve tended towards AI review + the usual humans), you are sacrificing a really effective development path for your team. Perhaps this is fine, but what replaces this?

"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 (though, I would recommend Robusta/Holmes here). You’re not sure what the problem is, so you escalate, and pull in the team that wrote the feature that seems to be 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 5-whys (you really should) blameless post-mortem that will give you the todo-list to make sure it never breaks in the same way again.

But, 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’ exactly what was done (or does it?). 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 will be extremely hard to break. 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"

There is a real sense that software engineering, not just writing code, is a trade like any other. One that 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, companies seem to be drifting into 2 short-termist strategies. Either, hollowing out their 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, they are 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. Once we have lost direction, our priorities, and our culture, recovering will be challenging⁶.