Giant Robots Smashing Into Other Giant Robots

What causes AI fatigue for engineers and how to ease the strain

2026-10-06T00:00:00+00:00

AI fatigue is hitting some development teams hard. In our original research study, engineering, product and technology leaders from US healthcare companies told us they’re feeling pressured to evaluate a firehose of new AI trends and tools while struggling to navigate AI-generated code alongside legacy systems.

This isn’t entirely new. The industry has gone through waves like this before, from the rise of the internet and the advent of social media to mobile development and every new round of web technology in between. But the rapid progression of LLMs speeds up this cycle, which can leave teams to feel like they’re losing control.

Here’s what our study uncovered about the causes of AI fatigue and some practical ideas for successfully navigating these pain points.

73% feel pressure to evaluate every AI trend

Nearly three-quarters of survey respondents told us they feel significant or moderate pressure to evaluate every new AI trend despite limited bandwidth.

So, what’s a developer or product manager to do when the tenth email this month asks about another new AI tool? Start by looking behind the question. Ask executives what they’re hoping to achieve by adopting an AI trend. Are they looking for speed? Security? Once you know the objective, you can steer the conversation to what your team’s already doing to reach it.

It’s also 100% fine to admit you don’t know a given tool yet. In fact, change your goal from understanding every new tool to keeping a general eye on trends, so you can choose a promising tool to try out later.

59% struggle to evaluate AI technologies consistently

More than half of technology leaders told us they struggle significantly or moderately to evaluate new AI technologies consistently across governance, security, and operational requirements.

This seems like a messy problem to untangle, but the good news is you already know how to do much of this work. Start with the framework you already use to evaluate technology service providers. If you’re giving your whole development team access to Claude or ChatGPT, it means you’re putting data on someone else’s server. Set up and evaluate a data management agreement just as you would with any other Cloud provider.

You’ll also want to consider how strong a given tool’s adoption might be in the marketplace and how likely it is that the tool will be around later. Finally, evaluate whether the company uses trusted business practices and aligns with your industry’s priorities.

When you test out a new AI tool, make it as low risk as possible by setting up a developer sandbox and running short pilot studies that take weeks, not months. Then try basing your experiment around this simple framework: apply the tool to a concrete problem, build a working baseline, and improve iteratively. Stay away from mission-critical systems and use mock or anonymized data to keep personally identifiable information (PII) and protected health information (PHI) out.

Pilots show how a tool behaves, what it costs, and where the trade-offs live. This information all informs later governance decisions. Once you decide to move into production, you’ll want to follow your organization’s usual controls for new technology tools and collaborate with key partners in product and compliance.

62% say engineering fatigue is growing

Nearly two-thirds of survey respondents said engineering fatigue is growing significantly or moderately as teams manage AI-generated code alongside legacy systems.

Reviewing AI-generated code happens along a continuum of approach and time investment:

Pairing with an LLM: It’s a powerful partner but checking every step can be slow.
Reviewing afterward: Going over every piece of AI code can bury developers in work.
Letting AI review AI: This works for catching errors but only up to a point

At the far end of this effort continuum is the largely hands-off dark factory approach. You don’t watch what happens inside the AI code factory. Instead, you define tests and controls that measure success and limit risk.

Take a financial app that recommends trades. Tests might require expected returns between 5% and 20% and block the AI from executing trades. The AI can write code overnight, but it’s never allowed to change the tests. It stops only when it can’t meet the criteria or reaches a judgment call.

Our team sometimes takes what we call a dim factory approach in our agentic coding. Most of the lights are off (we’re not hands-on with the AI coding process), but we can still walk through the factory and see what’s generally happening without reviewing every detail. It reduces the burden on developers while still maintaining additional oversight.

The right approach to AI-generated code depends on your culture, your risk tolerance, and whether you’re prioritizing feature speed or maintainability. Legacy systems also come with legacy cultures, and those need navigating, too.

Emotions loom large

What all these stats hint at but don’t outright state is that there’s a gigantic emotional component to rapid AI change, too. Many developers take pride in crafting code, so naturally, there can be significant grief in turning over this hard-won skill to AI.

One way to re-frame the situation: Focus on the new craft you’re developing as you direct an LLM. As with any emerging technology, you’ll make mistakes, but you’ll also work through them and learn. Focus on personal skill growth vs. letting imposter syndrome creep in.

Another big source of mixed emotions about AI: Decision fatigue. Constantly evaluating output from a dozen agents leaves no room to breathe, especially as AI pushes productivity expectations higher. This volume can leave people feeling burned out. In a recent workplace survey from Lenny’s Letter, 55.7% of tech workers reported significant burnout, up from 44.7% in last year’s survey. There’s no easy answer, but as you’re trying to navigate all the change, focus on the decisions that matter most, set a manageable pace, and accept that everyone has a cognitive load limit.

There’s no one-size-fits-all fix

How your engineering team approaches AI depends on business context and whether you’re defining the team’s overall relationship with AI or simply matching a tool to a problem. Plus, all this context and technology keep changing at a rapid pace.

Want help navigating it? Our AI and machine learning expertise can guide you through governance, focused pilots, and strategies for managing AI-generated code. Let’s talk.

We built an AI product consultant and the free beta is now open

2026-10-02T00:00:00+00:00

For the past several months, we’ve been exploring a question: Can we put some of our product expertise into an AI tool that helps people figure out the right thing to build?

ReadySetGo is now open for anyone to try (fine print: within a daily new user limit).

ReadySetGo helps you turn a rough idea into a build-ready plan by walking you through a product sprint. It guides you through our team’s structured process to pressure-test your idea, challenge your assumptions, and make some of the important decisions that should happen before you start building.

For a limited time during open beta, it’s free to use.

A product expert that doesn’t just agree with you

There are already a lot of powerful AI tools that can help you build software faster. But building faster isn’t an advantage if you’re building the wrong thing.

We’ve spent more than 23 years helping founders and product teams turn back-of-napkin ideas into products worth investing in.

ReadySetGo is an experiment in making more of that expertise available to anyone. We’re baking in the product discovery and shaping practices our teams use every day and have iterated on for years. In the process, our team has been working against one of the biggest blockers for general AI tools to be good product partners: their tendency to agree with you.

ReadySetGo is a strategic sparring partner for you. It asks questions, challenges assumptions, brings in research, and helps you get increasingly specific about the problem, audience, opportunity, and first version of your product.

One of our early alpha testers described it as:

The first AI tool that actually understood my business. It’s a thought partner for product design.

You leave the ReadySetGo sprint with a validated build plan you can hand off to an AI tool like Bubble or a development partner like thoughtbot.

We’ve been building it in public

If you’ve been watching our weekly livestream, AI in Focus, you may have already seen pieces of ReadySetGo come together.

Our founder and CEO, Chad Pytel, along with cohost and Development Team Lead Louis Antonopoulos have been leading the live development of the product alongside many from our team across disciplines. You can continue to tune in to see them work on updates throughout the beta period on our YouTube, Linkedin, and Twitch.

Help us test it

ReadySetGo is now in open beta, and it’s free to use for a limited time.

Bring a rough product idea and try it out. The tool will guide you through 10 steps that you can go through at your own pace. You’ll pressure-test the idea with a process used by product experts and leave with a plan you can build from.

We’re still learning. We want to understand where ReadySetGo is genuinely useful, where it falls short, and whether we’ve succeeded in creating something meaningfully different from opening up a general-purpose AI tool and starting a conversation.

Start a free ReadySetGo sprint

NWRUG's (Manchester, UK) October 2026 meeting — It's time to bin your VCR

2026-10-02T00:00:00+00:00

The next North West Ruby User Group in Manchester, UK is in a fortnight on 15 October at Colony, One Silk Street. Rob Whittaker will take us through one of his hot-takes: VCR does more damage than good, and there are imperfectly better ways to stub your external requests.

Rob Whittaker is Director of Software Development at thoughtbot. He has over two decades of professional web development experience and has worked with Ruby and Rails since 2012. (He’s also the co-organizer of NWRUG!)

We’ll be at the venue for pizza from 6:30pm with the talk starting at 7pm. Afterwards we’ll retire to The Crown & Kettle for a drink. The venue, pizza, and drinks are kindly provided by NWRUG’s sponsors Fatsoma and thoughtbot.

We’re bringing two roundtables to the London CPO Conference

2026-10-01T00:00:00+00:00

On 29 October, thoughtbot Product Leader Bethan Ashley will be hosting two roundtables at the London Chief Product Officer Conference, bringing product leaders together to explore some of the biggest questions shaping the future of the product function.

The topics are different, but they both come back to the same bigger question: what does the Product function need to become next?

Has Product become the bottleneck?

The roundtable will explore what it actually means to become an AI-native product organisation, beyond simply adding AI tools to an existing process.

How should the role of Product change when teams can move faster? Which parts of the traditional product process still help, and which ones might need to be rethought?

There probably isn’t one clean answer, which is exactly why it should make for a good conversation.

Should Product own more of the commercial outcome?

The second roundtable focuses on another shift we’re seeing in product leadership: moving closer to revenue, growth, P&L, and commercial accountability.

So what changes when Product is recognised more explicitly as a revenue-generating function?

That opens up questions around what Product should own, which metrics matter, how product leaders work with commercial teams, and whether greater accountability changes the way priorities get set.

Join the conversation in London

If you’re attending the London Chief Product Officer Conference on 29 October, you can join Bethan for either of the two discussions.

We’ll see you there.