AI-Enabled Teams #1: Kicking Off the Series

Notes from the journey of adopting AI inside an engineering team

Hey readers. I can’t believe I haven’t written for more than one and a half years. Life, work, parenting, and sports have all been too consuming. I’ve been thinking about writing, about something, about anything, for a long time, and finally there’s a strong enough gravity to pull me back.

As I’ve been writing documents productively at work through voice-to-text and LLMs (or rather, productively generating tokens), I realise my thoughts are not as clear as they used to be. When my mentees asked for advice, I found it harder to articulate and form my thoughts live. This realisation is immense. I’m now jotting each and every letter on my keyboard again for this post to force myself to think about each of the tokens I’m about to generate from my mind.

Why this series now?

Regaining mental clarity works as the inner force, but the external forces for me to write about this series are even greater. As the industry is moving fast, the force for business leaders to increase the team’s throughput through AI adoption is strong, and I’ve been asked to help with that.

As I go through the journey, I struggle to find content that I find relevant. A lot of the contents are pretty focused on greenfield projects, prototypes, and new LLM models and features. I’ll write about what I can’t easily find, i.e. work experiences and challenges which are grounded in reality.

Is there a value in capturing experiences? I’ve managed to develop injuries on my forearm through ashtanga yoga and badminton. Thanks to a random stranger sharing their experience on Reddit, suggesting me to try Tyler’s Twist exercise, I do feel better now. Before I discovered that post. Feeling irritated that I can’t hold Tolasana and swing my racket without pain, I asked ChatGPT to do deep research, dig up all the bloody anti-fragile science papers it could, and give me the one single thing I should do. No, none of them helped, and yes, I suffer from an episodic scientism now and then.

That Reddit post was about tennis elbow, and even though I do not actually have tennis elbow, the exercise is helping me. That lack of causal relationship is the nature of a complex system, which would also be present in a team setting. A failed experiment in one team could be a successful one in another.

The team’s context

As I write the future posts in this series, understanding the context that I’m operating in is important.

Our codebase is about 2.5 years old, accumulated tech debts through constant change of business priorities. We work in the telecom industry. We’re delivering sustainably, deploying every day.

We are a company of nine engineers, organised into three small outcome-focused teams. We’ve got a good spectrum of juniors and senior+ engineers in the team. We are a remote team, with engineers in the US, the UK, and India.

All of us are in a different phase of AI adoption. Some are a bit more conservative than others. Some are a bit more hype-driven, pushing for multiple agents and switching models as frequently as they can. Some would think that we’ll lose our jobs in 6 months or that junior engineers would cease to exist. I probably write 95% of my code through agents, and some are still at 0% as they’re still using AI chat assistants.

A few of us have been in an indefinite state of experimentation, trying things out for about a year, while some are lagging.

A few of us have used agents, then started to move back to coding by hand.

I’ve reviewed LLM written PRs that have not been reviewed by the authors.

A beautiful mess.

Defining the series

I hope that the term “AI-enabled teams” is self-descriptive.

I originally liked the term AI-assisted engineering, as it’s also used by DORA when they published their AI-assisted software development report last year. However, as I’ve been adopting agents more, I don’t think the word ‘assist’ is fully capturing the evolution of where we are now.

Some used the term Agentic Coding, but this sounds like a specific activity within the umbrella of software engineering. The industry is moving so fast that agents might become obsolete.

AI-native is an interesting term for me, and many are using it. It sounds bold, as it implies that there exist brand new engineering practices could not live without AI. The heuristic being, if you subtract AI from your system now, would it still operate? I found this hard to believe. I believe that all the evergreen engineering practices like TDD and Continuous Delivery will hold regardless of AI, if not becoming more important.

I still don’t like the word AI-enabled, but it’s the least worst option I have.

Teams implies the idea that we have a shared codebase where multiple engineers are working on it together. It’s my belief that this idea would not go away anytime soon. I believe that if you want to build something great, you’ll need to put multiple minds on it.

While there is a lot of excitement around what the tool could do, software development is still software development, and we have to deal with all the anthro-complexity around it.

It did come across my mind, why not let each of the engineer in our team build their own microservices in their own repo, agenting away? Let’s not get there for the time being.

What to expect in the series

The posts would be a mixture of essays, our progress, and some dojos or learning hours that I have organised for the team and some commentaries around that.

This is not a series where I’ll help you replicate our AI adoption journey, in fact, I don’t even know what our outcome would be. My intention is to share our effort and results in the hope that you could help your team, too.