Product-focused leaders are trying out AI on their own codebases and getting exactly the wrong impression.

Jack uses his orgs codebase with AI: “Wow, this is going so well, I can add features so easily! AI is much better than our engineers”

Nick does the same: “Oh no, AI keeps breaking things – I’m glad we have such great engineers, they are even better than AI”

They are both completely wrong.

Coding agents benefit a lot from, good developer experience, consistent architecture, and particularly from strong testing. They are OK at the moment. If you give them a strong platform, they can build on top of it really well without direction. If you give them a bad platform then they will struggle, just like a new team member would.

Jack had a great experience with AI because his team is so diligent in protecting his orgs ability to innovate. AI is faster than the team because it wants to make Jack happy this session – ideally this message. Jack’s coding agent is mangling his codebase while showing him new features that only look like they work, but he misinterprets his experience in favour of the AI – now brittleness increases every session until he can’t deliver anymore.

Nick had a bad experience because his team is incompetent or rushing. Their software is already brittle, but they can operate in it for now with tribal knowledge. AI can’t – it’s a builder showing up at a home that’s falling apart and being told to add an extra floor. It doesn’t go well and Nick misinterprets his experience in favour of the team. Now he’s stuck with them and they’re stuck with their brittle code. At least refactoring is still possible.

Obviously there is heaps of context to think about, but these are realistic possibilities for product-focused leaders in small orgs.