<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Mark Sainty</title><description>Practical AI adoption in regulated organisations</description><link>https://sainty.org.uk/</link><item><title>Moving Back to Individual Contributor in the Age of AI</title><link>https://sainty.org.uk/blog/moving-back-to-ic/</link><guid isPermaLink="true">https://sainty.org.uk/blog/moving-back-to-ic/</guid><description>On returning to hands-on engineering after management, and what AI tooling does and doesn&apos;t change about the transition.</description><pubDate>Thu, 12 Mar 2026 00:00:00 GMT</pubDate><content:encoded>I recently moved from an Engineering Manager role back to an Individual Contributor role.

Over time, management naturally creates distance from the code. That&apos;s part of the role. The work shifts toward alignment, coordination, and decision-making at a higher level.

Moving back into an IC role was about being closer to delivery again. AI tooling has made that transition easier than it would have been even a few years ago.

## Reduced Friction

There&apos;s always a cost to stepping back into hands-on work after time away. APIs change. Frameworks evolve. Patterns shift. Rebuilding fluency takes effort.

AI assistance reduces some of that friction. It handles scaffolding, fills in routine structure, and accelerates first drafts. That doesn&apos;t remove the need for understanding, but it does reduce the time spent reconstructing syntax.

The result is more attention available for design decisions. I spend more time thinking about where system boundaries should sit. What can move from synchronous transactions to asynchronous workflows. What needs to be orchestrated and where.

For someone returning to IC work, that shift is significant.

## What Becomes Visible

From a management perspective, AI conversations often focus on productivity and risk. Those are valid concerns. But the bigger risk — both organisationally and individually — is failing to adapt to changes that are already underway.

Generated code increases output volume. That changes code review dynamics. Reasonable-looking solutions can introduce subtle complexity, and speed can outpace architectural discipline.

AI doesn’t improve judgement. It amplifies whatever baseline already exists.

If engineering practices are strong, the tools increase leverage. If they’re weak, problems surface faster. Being back in the code makes that easier to see.

## Closing

AI has reduced some of the mechanical overhead of returning to hands-on work. The constraint now isn&apos;t &quot;how do we write this?&quot; — it&apos;s &quot;is this the right architectural decision?&quot;

AI doesn’t remove engineering judgement — it increases the need for it</content:encoded></item></channel></rss>