Poll of engineers using AI assistants with production code

I ran a LinkedIn poll asking software developers about their experiences using AI coding assistants with production code. The results were interesting ๐Ÿ‘‡

Why production code? Developers spend most of their time writing it, and AI tools can handle non-critical activities like proof-of-concepts, solo projects, and quick experiments fairly well.

I received 50 responses – not a huge sample, but interesting trends emerged nonetheless. Also, LinkedIn polls arenโ€™t anonymous (which I didnโ€™t know!), so I could see who voted. It allowed me to exclude non-developers and gauge experience levels from LinkedIn profiles and add it to the data.

You can see the results broken down by answer and experience level in the chart attached.

What stood out to me?

– Only one respondent – an apprentice engineer – said they โ€œautomate most things.โ€

– 74% found AI assistants helpful, but 26% felt theyโ€™re more trouble than theyโ€™re worth.

– All who said AI assistants โ€œget in the wayโ€ (24%) had 8+ years of experience.

– 80% of respondents had 8+ years’ experience (I know a few of them, and othersโ€™ profiles suggest theyโ€™re legitimately experienced engineers).

My thoughts? Unless they improve significantly:

1) Theyโ€™re unlikely to shift productivity dramatically. From my experience, โ€œtaskโ€ work takes about 10-30% of a developerโ€™s coding time. So, while helpful, theyโ€™re not game-changing.

2) That a significant portion – especially experienced engineers – find these tools intrusive is concerning.

3) Having heard stories of AI tools introducing subtle bugs, I was surprised not to see more votes for โ€œconsidered harmful.โ€

4) The idea that AI tools might replace software engineers – or that even “conversational programming” is anywhere close – still feels a very long way off.

5) I worry about an apprentice software engineer getting an AI tool to do most of their work. Partly because more experienced developers are a lot more cautious and must have a reason for this, but mainly because they won’t be learning much by doing so.

Creating an Effective Recruitment Process

Hiring is one of the most impactful decisions for any organisation. The wrong person can badly impact the culture and performance of the organisation, absorb time in performance management and be a significant distraction.

Informal recruitment processes are leaving things down to chance.

Inefficient processes consume time and risk losing top candidates who move quickly.

This is why fixing the recruitment process is typically one of my first priorities when working with organisations.

Having interviewed thousands and hired hundreds over the past two decades, here are my top tips:

All candidates should have a positive experience

Whether or not a candidate gets the role, they should leave with a positive impression. A poor experience not only harms your brand but can dissuade other candidates from applying.

  • Being warm, friendly, and engaging throughout the process costs nothing, and it doesnโ€™t prevent you from asking tough questions.
  • Give constructive feedback to unsuccessful candidates so they know where they can improve.

Short Lead Times

Itโ€™s all too common for the time from CV received to decision made to be a very lengthy process, often taking months.

  • Aim for a two week turnaround from CV received to decision made.
  • Much of the following advice is for how you can achieve this ๐Ÿ‘‡

Start with a brief screening call

To make sure a candidate is a basic fit, get eligibility information and to introduce them to your company, and the recruitment process.

  • If youโ€™re working with a recruiter, ideally empower them to handle this stage (if properly briefed).
  • Itโ€™s important this conversation isnโ€™t just a box-ticking exercise. It sets the tone for the rest of the process, so make sure itโ€™s welcoming and informative.

Pre-booked interview slots

So much time is lost in calendar tennis for scheduling interviews. Avoid this by agreeing, and putting in place, pre-booked interview slots upfront in interviewersโ€™ calendars. Whoever is engaging with candidates can then offer them any of the available pre-booked slots. If they canโ€™t do any of them you can always compromise and try and find other times, but make this route one.

Schedule all stages up front

Again, this saves time for both the candidate and your organisation, and gives the candidates clarity on timelines. If youโ€™re doing multiple stages, thereโ€™s no reason why you canโ€™t cancel a further stage if you donโ€™t consider itโ€™s worth proceeding with the candidate, just let them know up-front that you may do this.

Do as many stages as you can in one go

Consolidating interview stages reduces cycle times significantly. While you may end up spending more time with candidates who may not progress, youโ€™ll save more overall by avoiding the delays of additional scheduling and decision-making between stages.

If youโ€™re concerned about wasted effort, you can always tell the candidates up front that you may choose to finish the interview early if itโ€™s clear to you itโ€™s not progressing well.

Structured interviews

Every interview should be structured, with the same scripted questions for all candidates and scoring indicators for responses.

This reduces bias, ensures consistency, and simplifies decision-making. You never use scoring indicators as a pass or fail, they just help inform your decision.

I’ve developed interview templates where each stage has its questions and scoring indicators on the same form.

Two interviewers in each stage

This has several benefits:

  • One can focus on the candidate while the other takes notes.
  • It avoids leaving decisions to a single viewpoint.
  • It provides an opportunity to train future interview leads.
  • It allows candidates to meet more team members.

The second interviewer doesnโ€™t have to be sitting there quietly, they can take part in asking follow up questions and responding to candidate questions.

The interview forms I mentioned previously? Use them as a shared document in e.g. Google or OneDrive and interviewers can see the notes as theyโ€™re typed, and make their own comments and observations.

Same-day candidate debrief

Debrief as quickly as possible after each stage or at the end of all interviews. The structured format, shared notes, and scoring indicators will help you avoid lengthy debate, maintain consistency and make timely decisions.

Who wants an AI toothbrush?

AI toothbrush anyone? Yes this is real, but I don’t want to talk about AI. I want to talk about technology having it’s place. Not everything is best solved by technology.


Iโ€™m a hardcore techie, but when it comes to personal hygiene, I couldn’t be more lo-fi. After years of trial and error, Iโ€™ve settled on a wooden toothbrush, basic Colgate toothpaste, and the same cheap Dove soap for both washing and shaving (with a basic razor and shaving brush).


A ~ยฃ100 “AI-powered” toothbrush solves no problems for me – or anyone, for that matter.


It’s why I challenge early stage startups if they really need to build something yet. It’s why I’m an advocate for practices like Value Stream Mapping and Service Design, and how often the desired outcome is best solved *without* needing to chuck technology at the problem.


It’s why I’m obsessed with process optimisation and systems thinking.


It’s why I loved the recent episode of “The Digital Human” on the potential for AI in the NHS (BBC Radio 4, will share link in comments), where the the eminently sensible Jessica Rose Morley, PhD pointed out thereโ€™s little point in getting carried away when, in reality, it’s still common for three wards to share one outdated PC on wheels, and the data is in such a mess.


Technology is expensive, it comes at a cost. Only when you’ve identified the user need and/or optimised existing processes is it worth investing in.

Don’t tolerate brilliant jerks

I believe it was Reed Hastings, CEO of Netflix who coined the phrase “brilliant jerk.”

Common in tech orgs – smart, technically gifted, and highly productive. They’re seen as the people to go to for solving big problems, and they often save the day in a crisis.

But boy do they ruffle some feathers getting there.

As a leader you can spend a lot of time cleaning up after the mess they create. But you put up with them coz they get stuff done.

“Jerk” is a big bucket of behaviours of course. They can often dominate conversations, dismiss othersโ€™ opinions, and arenโ€™t shy about pointing out whatโ€™s wrong with the org, proudly โ€œtelling it like they see it,” but they’re typically the last to offer any suggestions.

At one organisation I worked, we had a toxic “them and us” culture between Sales and Dev. Interestingly, when one particular person left, it pretty much evaporated.

And don’t forget, “Your culture is defined by the worst behaviour you tolerate”

How to Plan Effectively in the Face of Uncertainty

In a recent post, I explained why weโ€™re inherently bad at estimating, which is a major reason software projects often run late. But that doesnโ€™t mean we canโ€™t plan ahead for the longer term and manage expectations. Here are some techniques Iโ€™ve found effective for longer-term planning, even in the face of uncertainty:

๐—ฃ๐—ฟ๐—ผ๐˜ƒ๐—ถ๐—ฑ๐—ฒ ๐—ฅ๐—ฎ๐—ป๐—ด๐—ฒ๐—ฑ ๐—™๐—ผ๐—ฟ๐—ฒ๐—ฐ๐—ฎ๐˜€๐˜๐˜€ ๐ŸŒฆ, ๐—ก๐—ผ๐˜ ๐—™๐—ถ๐˜…๐—ฒ๐—ฑ ๐—˜๐˜€๐˜๐—ถ๐—บ๐—ฎ๐˜๐—ฒ๐˜€

Over any reasonable period of time, providing likely delivery dates as a range rather than a fixed date is better. Doing so embraces the inherent variability and help stakeholders better appreciate uncertainty. Giving a fixed date, even when you all know itโ€™s just an estimate, sets false expectations.

๐——๐—ผ๐—ปโ€™๐˜ ๐—ท๐˜‚๐˜€๐˜ ๐—ฒ๐˜€๐˜๐—ถ๐—บ๐—ฎ๐˜๐—ฒ ๐˜๐—ถ๐—บ๐—ฒ โฑ, ๐—ฒ๐˜€๐˜๐—ถ๐—บ๐—ฎ๐˜๐—ฒ ๐—ฐ๐—ผ๐—ป๐—ณ๐—ถ๐—ฑ๐—ฒ๐—ป๐—ฐ๐—ฒ ๐Ÿ’ช

Along with estimating how long a task might take, assess how confident you are in that estimate. Is it something weโ€™ve done before and know well? High confidence. Is it new, complex, or something weโ€™ve never tackled before? Medium or Low confidence.Multiply time by confidence. For example, a โ€œSmallโ€ task (e.g. 1-3 days) with “Low” confidence can be re-forecast as 1-7 days.

๐—Ÿ๐—ผ๐—ป๐—ด๐—ฒ๐—ฟ ๐—ง๐—ฒ๐—ฟ๐—บ ๐—ฃ๐—น๐—ฎ๐—ป๐—ป๐—ถ๐—ป๐—ด ๐—ฎ๐˜€ ๐—ฅ๐—ถ๐˜€๐—ธ ๐— ๐—ฎ๐—ป๐—ฎ๐—ด๐—ฒ๐—บ๐—ฒ๐—ป๐˜ ๐Ÿšจ

Effective planning isnโ€™t just about setting expectations on delivery, but managing risks over the project lifecycle. All those estimates which have come in as Large or with Medium-Low confidence? Those are your biggest risks and represent the most uncertainty. Identify risks early, identify potential mitigations, highlight those risks to stakeholders.

๐—”๐—ฐ๐—ฐ๐—ผ๐˜‚๐—ป๐˜ ๐—ณ๐—ผ๐—ฟ ๐—ข๐—ฝ๐˜๐—ถ๐—บ๐—ถ๐˜€๐—บ ๐—•๐—ถ๐—ฎ๐˜€ ๐ŸŒˆ

Whilst you canโ€™t completely mitigate against this, there are things you can do to be a bit less vulnerable. Involve the entire team in estimates, account for full end to end delivery (not just developer time) and factor in holidays, sickness and other factors that could impact delivery.Also, those ranged forecasts which provide a cumulative lowest range for all the work? Highly unlikely due to optimism bias! Itโ€™s probably best not to present the most optimistic forecast for this reason.

๐—ก๐—ผ ๐—ฆ๐—ถ๐—น๐˜ƒ๐—ฒ๐—ฟ ๐—•๐˜‚๐—น๐—น๐—ฒ๐˜, ๐—•๐˜‚๐˜ ๐—ฎ ๐—•๐—ฒ๐˜๐˜๐—ฒ๐—ฟ ๐—”๐—ฝ๐—ฝ๐—ฟ๐—ผ๐—ฎ๐—ฐ๐—ต

These practices wonโ€™t eliminate uncertainty or guarantee perfect outcomes – there’s no silver bullet in longer term planning. However, Iโ€™ve found they help organisations plan more realistically, reducing the stress and frustration that often come with missed deadlines, and enabling more effective, adaptable strategies in the face of uncertainty.

Deal with performance issues quickly

Addressing performance issues is something many shy away from, often putting it off or hoping it will go away.

The sooner you do so, the more likely there’ll be a positive outcome for very everyone.

The longer you wait, the more difficult it becomes.

If itโ€™s clear things aren’t working out then you need to act decisively. Don’t let it drag on.

Itโ€™s not only about the individual; it’s letting the whole team down and sets the standard for the level of performance considered acceptable.

Typing is not the bottleneck

โ€œ๐˜ž๐˜ฆ ๐˜ฏ๐˜ฆ๐˜ฆ๐˜ฅ ๐˜ฐ๐˜ถ๐˜ณ ๐˜ฅ๐˜ฆ๐˜ท๐˜ฆ๐˜ญ๐˜ฐ๐˜ฑ๐˜ฆ๐˜ณ๐˜ด ๐˜ต๐˜ฐ ๐˜ฃ๐˜ฆ ๐˜ฃ๐˜ถ๐˜ด๐˜บ ๐˜ค๐˜ฐ๐˜ฅ๐˜ช๐˜ฏ๐˜จโ€

I still regularly come across this mindset. Not with any ill-intention. Developers arenโ€™t cheap, so naturally you want them to be productive.

Whenever I do, Iโ€™m reminded of this meme (image created by Sebastian Hermida).

So this is a reminder that with software development…

๐—ง๐˜†๐—ฝ๐—ถ๐—ป๐—ด ๐—ถ๐˜€ ๐—ป๐—ผ๐˜ ๐˜๐—ต๐—ฒ ๐—ฏ๐—ผ๐˜๐˜๐—น๐—ฒ๐—ป๐—ฒ๐—ฐ๐—ธ ๐ŸตโŒจ

Development is about a lot more than just being heads down hammering out code – itโ€™s about problem-solving, understanding user needs, designing scalable solutions, and ensuring that whatโ€™s built is truly valuable. Rushing to code without seeing the bigger picture leads to missed requirements & re-work, technical debt and buggy software.

It actually slows things down more than it speeds them up ๐ŸŒ ๐Ÿšง

Developers should be involved in the full end-to-end delivery process, not just the coding bit:

๐Ÿ” Understanding what we need to deliver, and why

๐Ÿงช Quality Assurance (you mean you didnโ€™t test it before you threw it over the wall to QA?)

๐Ÿš€ Shipping! Getting things out to customers before picking up new work

๐Ÿค Collaborating with each other and other disciplines

Collaboration is a key one. When developers pair with each other or folks from other disciplines, it speeds up the process by reducing feedback loops and capturing issues early, and fosters shared understanding and ultimately, better solutions.

Having developers engaged more widely might seem counterintuitive if youโ€™re focused on keeping them โ€œbusyโ€ with coding, but itโ€™s the best way to get the most out of their time.

The estimation trap: why software projects miss deadlines

Why are so many software projects late? Estimation (and how we use it) is often at the heart of it.

Humans are naturally optimistic. We overestimate how well things will go and underestimate the time required. It’s a well documented phenomenon:

๐Ÿคžย Optimism Bias: Our tendency to believe things will go better than they likely will.

๐Ÿ—“๏ธ Planning Fallacy: Underestimating time required, even when past experience tells us otherwise.

Secondly, even with careful planning, we can only account for what we know. As well as software development being inherently complex, as time progresses, unexpected factors always emerge: shifting priorities, new challenges, team changes โ€“ the “known unknowns” as Donald Rumsfeld infamously put it.

๐—–๐—ฎ๐—ป ๐˜†๐—ผ๐˜‚ ๐—ด๐—ฒ๐˜ ๐—ฏ๐—ฒ๐˜๐˜๐—ฒ๐—ฟ ๐—ฎ๐˜ ๐—ฒ๐˜€๐˜๐—ถ๐—บ๐—ฎ๐˜๐—ถ๐—ป๐—ด?
Yes, we can avoid common pitfalls and improve our estimation practices. But they are still likely to be optimistic because of the reasons above.

“It always takes longer than you expect, even when you take into account Hofstadter’s Law.”

– Hofstadter’s Law


๐——๐—ผ๐—ฒ๐˜€ ๐—”๐—ด๐—ถ๐—น๐—ฒ ๐˜€๐—ผ๐—น๐˜ƒ๐—ฒ ๐˜๐—ต๐—ถ๐˜€?
Agile embraces uncertainty, such as breaking down work into the smallest possible pieces and delivering value early and often. But it doesnโ€™t eliminate the challenge of longer-term planning.


๐——๐—ผ๐—ปโ€™๐˜ ๐—ฏ๐—ผ๐˜๐—ต๐—ฒ๐—ฟ ๐—ฝ๐—น๐—ฎ๐—ป๐—ป๐—ถ๐—ป๐—ด ๐˜๐—ต๐—ฒ๐—ป?
Not at all. Organisations need to plan. Without long-term planning, you canโ€™t set realistic budgets, allocate resources & people, or prioritise efforts. The trick is learning how to plan effectively, even in the face of uncertainty.

In my next post, I’ll share how Iโ€™ve approached longer-term planning successfully.

Elavate your change agents

If you’re looking to drive change in your organisation, ๐—ฒ๐—น๐—ฒ๐˜ƒ๐—ฎ๐˜๐—ฒ ๐˜†๐—ผ๐˜‚๐—ฟ ๐—ฐ๐—ต๐—ฎ๐—ป๐—ด๐—ฒ ๐—ฎ๐—ด๐—ฒ๐—ป๐˜๐˜€:

๐Ÿ”Ž Identify them โ€“ look for the people who are most on board with the changes you’re trying to make, the most proactive and unafraid to challenge the status quo.

๐Ÿ’ช Empower them โ€“ give them a seat at the table, involve them in initiatives, elevate their voices. Don’t be afraid to break hierarchy in doing so.

๐Ÿ›ก Support them – protect their time, don’t overload them.

The new leaders in your organisation may already be there

Can UK Tech still rely on the R&D Tax Relief Scheme?

The UKโ€™s Research and development (R&D) tax relief scheme has long been a vital resource for tech companies, offering substantial tax relief. Created to encourage investment in R&D, the scheme allows small companies to claim back a percentage of their expenditure on qualifying activities. However, the recent crackdown on fraudulent claims, tightening of the claims procedure and additional scrutiny on all claims is raising questions about the effectiveness of the scheme, leading to growing frustration in the tech sector and many to question if itโ€™s becoming more trouble than itโ€™s worth.

Fraud and abuse: a growing concern & increased scrutiny

The scheme has been plagued by issues of fraud and abuse. According to a recent BBC article Errors and Fraud have cost the taxpayer ยฃ4.1bn, and another recent article from Dan Neidle at Tax Policy Associates, states R&D Tax Specialist Green Jellyfish are guilty of ยฃ100m fraudulent claims alone.

The has led HMRC to ramp up its efforts to detect and prevent false claims. They tightened their claims procedure in 2023 and have hired an additional 300 inspectors since 2022.

Within my network at least, it’s clear this is having an impact, with many reporting a significant increase in their claims being questioned, delayed and rejected. It’s caught a lot of organisations on the back foot.

While the crackdown is undoubtedly necessary, it’s also exposed the complexity of the scheme and the subjective nature of the schemeโ€™s requirements, and the increased scrutiny has made it more difficult for companies to navigate the claims process.

The issues with the scheme: complexity and subjectivity

One of the significant issues with the R&D tax relief scheme is the subjective nature of its requirements.

According to the UK Government’s R&D tax relief guidelines, to make a successful claim, a company must demonstrate that their project:

  • Looked for an advance in the field.
  • Had to overcome scientific or technological uncertainty.
  • Tried to overcome this uncertainty.
  • Could not be easily worked out by a professional in the field.

What constitutes an “advance in the field”? How significant must the “scientific or technological uncertainty” be? Who qualifies as a “professional in the field”? How hard does something need to be to say it couldn’t be “easily worked out”?

Ah but helpfully, HMRC do have more detailed guidance. Behold CIRD81910, and CIRD81960 for further guidance for software. A quick glance at these documents reveals that they are highly technical and not particularly user-friendly (it appears none of Government Digital Service‘s skilled content designers had a hand in drafting this guidance).

Even with these guidelines, the answer to whether a project qualifies is frequently (as is oft’ the case when you ask a software developer a question), “it depends.” The CIRD81960 guidance for software itself acknowledges these difficulties, and I could write a whole article on the cases for and against the eligibility of software development to be considered R&D, ranging from most of it to very little.

This complexity and subjectivity poses a key risk: differing interpretations between HMRC inspectors, potentially resulting in legitimate claims being unfairly rejected.

Increased burden on companies

Previously, companies could rely heavily on R&D claims specialists to handle much of the work involved in submitting claims. However, with the heightened scrutiny now applied to nearly all submissions, companies are needing to provide far more detailed descriptions of their R&D activities.

While R&D claims specialists can assist with navigating the claims process, they typically lack technical experience and certainly lack the knowledge needed needed to accurately identify which aspects of your software development involve genuine technical uncertainty.

This burden is increasingly falling on the tech teams within organisations, who must now invest significantly more effort into their claims, often resulting in weeks of back-and-forth between technical staff and supporting R&D claims specialists.

Nervously awaiting legal precedents

As many organisations that previously relied on R&D tax relief are finding their claims rejected, it’s pushed some into financial difficulties. Consequently, more are being challenged in court, and these cases are likely to set precedents that will shape future interpretations of what qualifies as R&D.

In the meantime, many other organisations are anxiously awaiting the results of their first claims submitted since rules changed in 2023 and all the new inspectors came on board.

The outcome of these court cases and recent claims could have significant implications, not just for the companies involved but for the entire UK tech sector.

(By the way, previous successful claims are not home and free, HMRC can go back and review claims up to 4 years old and there are recent examples of where organisations have received tax relief and then been asked to give it back).

The need for a rethink

While improving and simplifying the guidance might offer some benefit, the real solution may lie in a complete overhaul of the scheme. Tax incentives that support the creation and growth of innovative new businesses are undoubtedly valuable, but itโ€™s becoming increasingly apparent that this particular scheme may no longer be fit for purpose.

There are certainly at least, questions to ask about the the feasibility of the scheme, given the growing cost and effort required for HMRC to manage it effectively and prevent fraud, the increased burden on organisations to submit detailed claims, and the rising uncertainty over whether those claims will be accepted.

An incentive you canโ€™t rely on?

Despite HMRCโ€™s claim of “making R&D easier for small companies,” recent developments have made the scheme far more difficult to navigate.

With increased scrutiny, a much greater burden for making claims and greater uncertainty as to whether claims will be accepted, many tech companies are finding it increasingly difficult to benefit from the scheme.

If tech companies can no longer rely on the R&D relief scheme, it ceases to be an incentive.