When we are so focused on the technology, and the possibilities it gives us, we can easily forget the underlying truth that transcends industries and teams, that organisations are very, very human entities. The source of the creativity, friendships (and complaints!) common amongst people in tech is down to this simple fact.

As seen over many years working with teams and across larger groups, success is largely down to the culture, relationships, personal and between teams, and the positive collaborations that develop. Notably, the common complaints in 1:1s, and the things that impede technical success and the happiness levels of people working within the business, are down to the consequences of bad relationships or inter-personal attitudes.

So, what does any of that have to do with AI? Understanding that success in a technology-centred company is a people-centred endevour, tells us how AI tools help us, and where they are dead-weight, or actively deliterious. Where they can remove the pain, and where they will 10x it, and chances of failure.

“More is more, nothing else”

The ability to generate a site from scratch, a new kernel module, a frontend app, terraform production-grade infrastructure in a few minutes. No longer raking through the documentation of 10 seperate libraries before getting started, or digging through substack for that one answer that will solve your obscrure error message. No more developers, just ideas into reality in the blink of an eye. Well, sort of…

We shouldn’t underestimate even this element by itself, it represents a step-change in the pace we can do things, and cruciall, 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. Its a truly democratising power.

“Finally, no more admin Fridays!”

When I first experienced true 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 seen. 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.

“I have a cunning plan…” - Baldrick

No evangelism here, I’ve seen the customer outcome picked up by a team, broken down into some feature-based definitions of done, and technical implementation left up to individuals/pairing with product, and customer showcase sign-off work well. Its a fun and quick moving way of working. However, I’ve also seen highly architected solutions pre-designed (preferrably in collaboration with the teams involved in implementation!), and 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. Yes, conveying an idea, whether product or technical implementation, to others is one reason. However, and if you’ve ever tried to develop any reseatch ideas academeically you’ll definitely know this one, we write so that we can think through complex problems and soliutions more deeply. The act of writing is there to structure our thoughts, and to unpick flaws in out assumptions.

Now, I’m sure that Claude can write a 20 page doc quicker than I ever could, and devoid of all my spelling mistakes, however, even if I promise myself I will review everything thats been commited to text, the act of structuring your thoughts and reaosning about the whys of the design choices made is lost. Brain plasticity is one of its great strengths, and our own internal adverserial arguments are a key driver of how our neural strucutures will evolve.

What if I have already thought through my idea, and I’m just using an LLM to generate something more polished for external viewers? Then, I suggest you look at your page metrics! A common pattern of a human creating 5 bullet points, to War and Peace document auto-generation, to an AI generating a 5 bullet points summary, is a dangeraous one.

“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 undoubtedly a bias opinion, based on how I see all abstract multi-agent systems, but whose patterns I believe people can and will see within their own organisations as AI adoption increases. Previously, resources were a bottleneck on ideas and tasks. If we dont 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 its from desiginng a new bsuiness process, to if and how (and how much) we do reporting across the business. All these things were contrained, we were forced to make choices, we were forced to simplify so that us human beings could cope with the admin and the meeting-time.

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 peoples tokens run out :) ), we can generate as mch code, plans, designs, processes as we want, often in minutes.This is choice without constraint, we do more, but we have no forced priortisation. The effects of all this is firehose development, we do things without any real ordering or cost to out time or effort resevoir.

“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 avout 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 adverserial 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 wholes (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”

The page goes off, you look at the clock, 2am, again! 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 code-guru that wrote the feature that seems to be breaking….

Ok, not ideal, and no one wants to wake up at 2am, but with the right observability and escalation if needed, you are going to get to the root of the problem. You’ll do a 5-whys (you really should), the blameless post-mortem that will give you the todo-list to make sure it never breaks in the same way again.

But, this time there is no code-guru 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 hard dependency for a business to take. Moving from growing and retaining a skilled group of software engineers in-house, who know the codebase inside out, to a 24/7 instant response required dependency on your favourite commercial AI provider company. Once this depdency is established, it will be extremely hard to break. Hiring engineers to bug fix someone elses code is hard enaough, hiring them to fix an AI’s bugs is likely to be too much to ask. That aside, we wont even mention your token allowance running out, 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

Looking back, I realise how this can look like a laundy list of problems. It really isnt, its an attempt to make sense of what the future looks like. How our businesses, teams, and all the people in them work in an increasingly AI world. These are things I think about, and am constantly working on adapting our ways of working to get all the benefits, new abilities, without the drawbacks. Having been hacking away at code, and leading teams and functions for many years, I can honestly say that AI use has been a breath of fresh air for many of the frictions I’ve experienced in the past. In thinking back on the last year or two, as the longer-term implications and realities of how us humans use these new capabiityies sinks in, I think theres enough evidence there to remind us how human we are, and the way we adopt new tools and adapt as a whole to what they give us, is a very human contruct. Knowing this and planning ahead with this in mind will give us the best of both worlds.