Clare Sudbery on Human-Centered Software Development and Keeping Humans in the Loop

Blog

iSAQB Software Architecture Gathering 2025

Clare Sudbery

Independent Technical Coach

Published on October 2, 2025

Higher-Level Principles: Clare Sudbery on Asking Simple Questions and Keeping Humans in the Loop

An interview with Clare Sudbery

In anticipation of Clare Sudbery's workshop "How Can You Combine AI With Test Driven Development?" and her session "Let’s Stop Making Each Other Feel Stupid", Richard Wallintin (WPS - Workplace Solutions) asked her several questions about fostering learning, psychological safety, and human-centered practices while keeping humans in the loop alongside AI.

What was the most "embarrassing" knowledge gap you had to admit? How did you deal with it, and would you feel differently about it today?

This is a really hard question to answer because it's such a long time since I got embarrassed about such things! Years ago, I used to be embarrassed about the fact that I wasn't used to working on the command line - I preferred to use tools that had more user-friendly interfaces. So whenever people gave instructions that involved the command line, I would have to ask them to explain what they meant in very simple terms, or I simply couldn't make sense of what they were talking about. After a while I got a bit more experienced in using the command line, but also stopped being embarrassed about it. After all, computers are supposed to make our lives easier, not harder! And that's nothing to be embarrassed about.

Why is it such a common behaviour to associate shame with not knowing something? Is that a historic/cultural thing?

I believe that it's both historic and cultural. We've historically tended to associate knowledge with status, and that has led to a culture of shame if you don't know something. I think it's connected with the way our education systems work, with their emphasis on tests and exams that rely purely on facts. We're expected to memorise things and then churn the results out on an exam paper.

This brings us to associate prestige with knowledge: In order to get a job in a knowledge industry such as ours, you're supposed to know a lot of stuff. But being good at building software is not about memorising a bunch of details. It's about understanding how to think logically, analytically and strategically, how to ask the right questions and collaborate well with other team members.

Do you have some basic behavioural "tricks" up your sleeve to improve psychological safety and encourage learning in a team? Is that all it takes?

Nothing is ever as simple as a handful of tricks. Human beings are complex creatures operating in complex socio-technical systems. There are a LOT of things we can do to improve psychological safety and encourage learning. I go through a lot of them in my talk.

I can't list them all here, but my favourite one is to ask simple questions confidently. Don't be embarrassed about it, and don't hide it. Be explicit about it. Explain why it's important and why it's helpful. Encourage one another to both ask and answer questions. Never judge anybody for asking questions. Make sure that people at all levels understand: If they don't know about something, there is no shame in asking.

It's especially powerful when senior people do this. It's definitely not just for inexperienced colleagues. And when we ask questions openly and confidently, everybody benefits from the answers, including the people answering the questions.

Why is TDD still not simply the default way of working for software developers? (I know for most technical coaches, TDD is a core technique - but most developers learn it late in their career or never.)

I think TDD (Test Driven Development) is much harder to do well than people realise. It takes time to learn how to use it effectively, and it isn't prioritised by most educational institutions or workplaces. It's also practised ineffectively in a lot of places, so people have bad experiences that make them believe they've tried TDD and it was slow and ineffective, so they don't want to do it again.

Until you've learnt to do it effectively, it feels like it's slowing you down and preventing you from making progress. When people face deadlines and constant pressure to move faster, unless the whole team is on board with doing TDD and doing it well, it's horribly easy to just slide out of the habit. And then once it stops being the normal team culture, it's very hard to push against the tide. It's hard to persuade your colleagues that even though it can feel like it slows you down short term, it will speed you up - and make you more effective - long term.

Which aspects of the software development trade can truly benefit from LLM-based Coding Assistants? What role does TDD (test-first) play when using them?

Writing code from scratch can benefit from using LLM-based coding assistants, but it's very easy to get caught in a trap where you start fast and end up slow. Because LLMs can produce large quantities of code very quickly, it's very tempting to just ask them to build an app and let them do it all in one go. And typically what they produce is so problematic that you then spend a huge amount of time trying to tweak it to do what you want.

But if you include good tests at the very beginning and throughout the process, it's a lot easier to make progress. There are other related principles that are also helpful, such as making progress in small steps instead of changing everything at once, and regularly throwing all the code away and starting from scratch.

It's harder to do good refactoring with LLMs. There are ways in which they can help, but they can also easily make things worse.

As a coach, do you see these "AI" assistants as a great chance to improve skills or do the risks outweigh the benefits?

I think we have to be really careful. We need to emphasise the "human in the loop". When using an LLM to build software, we need to keep querying the direction it's moving and why. We need to think very carefully about what we're building and how we'll know if it's fit for purpose. How can we maximise the benefit of the potentially very-fast feedback loop? How can we recognise when it's time to throw it away and start again? What are the rules we want the LLM to follow? How are we defining and measuring value? What guardrails do we have in place to make sure deployment is safe and well protected?

All the higher-level principles of software development become especially important as our focus moves away from the generation of each line of code. With the right approach, this can be a benefit. But there are many risks. Whether those risks outweigh the benefits, only time will tell.

But we'll always need well built, robust functioning software. I don't think we'll ever be able to do that without human intervention. So we'll have to develop the skills we need, and keep the skills we already have. But there will be ructions along the way as we learn to get the balance right.

More from the speaker

Let’s Stop Making Each Other Feel Stupid (Session by Clare Sudbery)

How Can You Combine AI With Test Driven Development? (Workshop by Clare Sudbery)

TEAM DISCOUNT: ✓ Save 10% until conference starts, ✓ 15% CPSA Discount