AI beyond coding

We could make AI easier to embrace by giving it more of the work developers would happily give up.

With tools like Claude, we’re speeding up something that often took a lot of time, but was also the part many developers enjoyed most: writing code.

The work around it is still there. Updating tickets, reporting progress, checking changes, preparing releases and making sure everything works once it reaches users.

If writing code takes less time and everything else stays the same, those tasks take up a bigger share of the day. We may be taking the effort out of the work, and some of the pleasure with it.

That seems relevant when we talk about AI adoption. Some developers are enthusiastic, others are cautious. Part of that difference may come from how AI changes their experience of the job.

There’s also an effect on how work moves through the team: Write code → review → test → release → run → monitor.

A faster start can simply mean a longer queue further along. The manual coordination around those stages can be repetitive and offer little gratification.

Looking at Google’s SRE practices and tools from AWS and Datadog, much of this automation is already established. Smaller teams or more traditional organisations may have a different starting point. Even with automation, manual work can remain: gathering context, investigating unexpected results and keeping people informed.

That’s where I’d like to explore working from both ends. Keep helping developers use AI to write code, while building on existing automation to tackle more of the remaining work, starting from production and working backwards.

For monitoring, a developer could ask an agent in the team’s Slack channel to investigate an alert, gather the relevant information and, where reliable, carry out a fix.

For releases, agents could work with existing tools to prepare and run deployments, check the results and reverse changes if needed. We could then look for similar opportunities in testing and review. Along the way, agents could keep tickets and progress updates current.

Fewer interruptions, quicker investigations and less time coordinating releases would be signs that it’s working. That return on investment may show up across the team rather than in one developer’s output.

I’d keep some of that time for learning. If every hour saved becomes another commitment, we leave little room to experiment.

Have you tried approaching adoption from both ends? Has removing tedious work made people more willing to explore what AI can do?

Originally published as a LinkedIn post.