When you should delegate to AI (and when you shouldn’t)

Estimated reading time: 8 minutes

Key takeaways:

• Only delegate work that’s verifiable, low risk, boring, and easy to define as “done.” Everything else needs real human ownership.
• AI-generated work is still your work. Removing yourself from the process costs accuracy, time, and a colleague’s trust.
• Deliberate beats liberal: owning the design, staying critical of AI’s output, and understanding everything before it ships matters more than how much you use it.

---

In the new, ever changing world of working with AI in software engineering, we are all being asked to do more and boost productivity. Every person and organization is figuring out how best to do this.

There is not a one-size-fits-all approach to working with AI. It is a spectrum with “no AI use” at one end and “delegate everything to AI” at the other. As with most things in software engineering, the real answer is a nuanced “it depends” that sits somewhere in the middle, depending on the context.

Let’s explore a high level framework to help understand when, how, and why to delegate tasks to AI… and when it’s crucial that you as the expert human engineer take the lead.

The different types of work 

A software engineer’s day is often a real mix of different types of work:

• A software upgrade to the latest version of ReactJS, handling the breaking changes and their impact on your app.
• A meeting with the product manager to talk through the requirements for your next headline feature.
• Code reviews from your colleagues.
• Triaging incoming bug reports from users and determining the next steps.
• Getting your head down to continue progress on the next change for the big product feature you are owning.

As a senior engineer or technical lead, you are asked to jump through multiple contexts every day. This means it is very tempting to use AI to help make this more efficient.

The criteria for immediate delegation

If a piece of work hits these four criteria, I will immediately delegate it to an agent because I have used them enough to be confident in their ability:

1. It’s verifiable: is the change the AI is making covered extensively by test infrastructure?
2. It’s low risk: is the risk reasonably low if something does get missed?
3. It’s boring: the fix is technically easy and does not require any novel approach or new third party dependency.
4. Requires little context: the work does not need a deep understanding of the codebase or the history of how edge cases work.
5. Done is easily defined: as a piece of work, it’s easy to confirm that it is complete. I can communicate that clearly to the AI and I can easily verify it myself at the end.

If work meets those criteria then I’m very willing to push it onto AI, with a small amount of supervision. Any work will have to go through the usual code review process and the criteria above keep the chances of the AI going “off the rails” in the wrong direction very low. With the newest models, this approach works well the majority of the time for me.

AI can’t think for you

When I first felt the productivity boost from handing off menial tasks to AI, I leant too far into it and ended up using it far more than I should. On more than one occasion I had a scenario that showed me I was being far too lax with my critical thinking and ensuring quality:

1. A co-worker asked me to explain why I took a certain approach in a change. I couldn’t because I had just asked AI and not paid it any attention. This function was a hot path through the application and my change had a huge performance impact I hadn’t considered.
2. On another day I had four bugs I wanted to fix. In the morning I kicked off each one in parallel in a different git worktree and let AI run at them. By the end of the day I had four sub-par changes for review, all with edge cases missed, poor documentation, and improvements I wanted to make. I spent the next day tidying them all up – some manually, some with AI help. In the end it took me far more time than if I had worked methodically through them one by one.
3. With the help of AI I sent a bug fix for an area of the codebase I wasn’t familiar with. The reviewer – the domain expert – pointed out that it was entirely the wrong approach. I believed in the confidence of the AI and didn’t spend the time to validate the approach myself – or ask the domain expert for five minutes to review a plan before diving in. I wasted their time reviewing and my time putting a change together that was flawed before a line of code was written.

These experiences were bad, and I was frustrated with myself for allowing them to happen, but they also brought me clarity on how I was using AI incorrectly and removing myself – an experienced technical lead with 15 years of experience – from the workflow entirely. I realized at this point that I had to be much more deliberate in my use of AI.

When you send a colleague work, that work is yours, regardless of how you generated it. You must ensure you are familiar with it and happy with its quality to make sure your reputation as an engineer is not diminished and you don’t send your colleagues work that you haven’t put the time into.

Use AI deliberately at different stages of the software lifecycle

For prototyping or quick hack projects, where the code is throwaway by definition, I use AI liberally with no real concern for final quality. For the actual software development lifecycle, I’ve come up with a series of rules to keep me on track, ensuring I mix AI’s productivity boost with my own expertise and experience.

One thing at a time

I will never work on more than one thing at once just because I can run AI in two windows. Yes, I might have more than one project on the go at any one time, but if there are features that need working on, I will work on a single one. This lets me give it my full attention and, because the quality is improved as a result, it is quicker than jumping between two features and context switching.

I own the work

I stopped asking AI to define the plan for me and instead asked it to think through potential options. If I’m unsure how to design a new feature I might prompt an agent to “give me multiple options on how this feature could be built, with tradeoffs.” I don’t use these verbatim, but they help get my brain thinking. I am responsible for the final decisions but that does not mean I won’t use AI to get my brain into gear and think through options.

I am eager to ignore AI

AI has spotted edge cases I hadn’t considered numerous times, and it has improved my architecture and code by spotting bugs on many occasions. However, it has also focused on an edge case that is one I know we can dismiss, or hyper-focused on a performance optimization so minute that it warrants no energy. I am purposefully critical of AI suggestions and spend the time to layer its suggestions with my domain knowledge to filter for what is truly important.

I must understand what it produces

I spend a lot of time upfront with AI building an implementation plan before letting it lose on the code. I will think through this plan really carefully and question the AI on what it produces until I am completely satisfied. Once the AI is done with implementation I will go through many rounds of code review. I ask it to walk me through the code and I spend time reviewing it before sending it to a co-worker.

If you would like to see some of my AI skills that I use in my workflow, you can find them online: jackf.io/skills.

Given those guiding rules, I split my work and how I use AI into three distinct sections:

1. Design: I own the design. After some initial thought, I will ask AI to give me suggestions. I deliberately ask it for wide-reaching ideas and want it to think ‘out of the box.” I will use these to help provoke thoughts in my head about how to solve it and think of cases I may have not considered.
2. Implementation planning: once I have a clear design (and have gone through the design doc and approval process if required) I will ask AI to help me take the design and turn it into a plan that can be executed. I will seed the initial state of this plan, but the low-level work I let it own. After it provides a plan, I review it a lot. I like to use sub-agents for this too; give three sub-agents the same plan, with no other context, and ask them to poke holes in it. They will nearly always find something that needs to be added.
3. Implementation: I will let an AI own this. It will write and run tests and work through the code. If needed, I will have adapted its plan to tell it to pause and split the work into multiple PRs if that makes sense and there are no dependencies. After it is done, I will code-review it manually, kick-off some fresh sub-agents to do the same, and apply any feedback – either using AI, or manually if I want to get a feel for the code.

AI is not a silver bullet

AI is a great tool, and it is one of the most impactful tools we have, when used correctly.

When used in the wrong way, it can lead you down rabbit holes, overwhelm you with questionable quality changes, and cause you to slowly disengage and stop being the influential technical lead your team needs.

Take the time to experiment with it, find the flow that works for you, and learn to use it effectively – you will see an impact on your pace and output.

Get articles like this in your inbox

Choose your LeadDev newsletters to subscribe to.