Everyone is “doing something with AI.” PRs are shipping faster. Demos look impressive. And quietly, a lot of teams aren’t sure if they’re actually getting better.
In a world where speed is cheap, the engineers who stand out won’t be the fastest or the most prolific. They’ll be the ones with taste.
Taste is what shows up before the code does.
It’s the judgement to:
- Design logic instead of just generating output
- Understand the user well enough to know what not to build
- Look at an AI-generated solution and say, “This technically works – but it’s wrong.”
TL;DR - Top insights on AI Fluency
- AI shifts engineers from writing code to designing logic.
The hard part isn’t producing code anymore, it’s clearly articulating intent, constraints, and system boundaries, and taking responsibility for what ships. - When building becomes cheap, judgement becomes the bottleneck.
Product taste is choosing the right problems and creating real user impact. Speed without judgement leads to bloated products, wasted effort, and missed opportunities. - AI fluency doesn’t scale through individuals, it scales through teams.
It’s not about one “AI wizard” who knows all the tools. What matters is shared standards, visible workflows, and collective judgement that prevent AI from turning into theatre. - AI amplifies fundamentals, it doesn’t replace them.
Output is no longer a reliable signal of competence. Ownership, reasoning, and the ability to explain trade-offs matter more than ever. - Speed is table stakes. Taste is the differentiator.
Everyone can ship faster with AI. The teams that pull ahead are the ones whose judgement compounds in systems, products, and decisions that hold up over time.
What AI fluency really means for engineering teams in 2026
As the conversation unfolded, a clear pattern emerged. Speed wasn’t the debate. Tools weren’t the debate. Taste was. Below are five takeaways, anchored in the taste frameworks redefining how AI is changing engineering work.
1. AI shifts engineers from writing code to designing logic
What we heard: AI has pushed engineers, PMs, and designers closer together to create end-to-end experiences. While coding still matters, more of the value now comes from clearly articulating logic, intent, and constraints and knowing how to guide AI to execute within them.
As Barbara put it:“If you can instruct AI to build clear, elegant systems and take full ownership of what ships and its safety - that’s great design taste.”
Why it matters: Teams that treat AI as a code generator hand over control and hope for the best. Teams that treat it as a system builder they actively supervise end up with software that’s easier to reason about, safer to change, and faster to evolve.
What to do: Invest in logic design skills: system thinking over syntax, architectural clarity over cleverness, and the ability to explain why something is built the way it is – not just how it works.
2. From output to intent, value, and impact
What we heard: AI makes it cheaper and easier to build almost anything. That lowers the cost of experimentation but raises the risk of building the wrong things faster. As Barbara explained, without a strong bias toward impact over output, increased speed just creates a larger backlog of features nobody uses.
“If you understand your users deeply enough to create experiences that genuinely delight them - that’s great product taste.”
Why it matters: When building becomes cheap, judgement becomes the bottleneck. Speed without judgement leads to bloated products, wasted effort, and missed opportunities. Opportunity cost doesn’t disappear just because code is easier to generate, it just becomes easier to ignore.
Teams without product taste optimise for feasibility. Teams with it optimise for meaning.
What to do: Double down on problem selection.
- Make user understanding the gate for what gets built
- Use AI to prototype and validate ideas early, not to justify shipping more
- Treat business impact – not output volume – as the measure of success
3. From knowing tools to shared AI standards
What we heard: The biggest AI risk teams are running into isn’t bad output, it’s knowledge that doesn't travel. One person figures out how to use AI well. They move fast. They ship impressive things. And no one else really knows how it happened.
As Barbara put it: “If you can run quick experiments that help your team recognise good AI output from bad - that’s building shared taste.”
Why it matters: AI fluency doesn’t scale through individual heroics. When prompts, workflows, and decisions live in one person’s head, teams lose:
- consistency
- confidence
- and the ability to reason about risk
That’s how AI turns into theatre: impressive demos, fragile systems, and no shared understanding of what “good” actually looks like.
What to do: Treat AI usage as a team capability, not a personal advantage. Fluency scales through shared mental models. That means:
- sharing workflows, not just outcomes
- making AI decisions visible in PRs, docs, and reviews
- building lightweight team norms like: When did AI help here? When did it hurt?
4. AI amplifies fundamentals, it doesn’t replace them
What we heard: AI increases the surface area of what engineers can produce but it doesn’t change who understands the system. Strong engineers use AI to move faster because they know what to ask for, what to reject, and what to take responsibility for.
As Barbara put it: “AI can make a good developer great, but it can’t make a bad developer good.”
Why it matters: When output becomes cheap, it stops being a reliable signal. A candidate can generate working code, but can they explain why it’s structured that way, where it might break, or what trade-offs were made?
Teams that equate AI-assisted output with competence end up hiring for speed and paying for it later in brittle systems, security gaps, and slow, risky change. Responsibility doesn’t disappear just because the code arrived quickly.
What to do: Shift the bar from can you produce code to can you own a system?
- Ask engineers to read AI-generated code and explain its behaviour, risks, and alternatives
- Evaluate how they reason about edge cases, failure modes, and long-term maintainability
- Develop judgement: knowing when to trust AI, when to push back, and when to rewrite
5. Speed is table stakes, taste is the new differentiator
What we heard: Almost every team is shipping faster with AI but not every team is moving forward. You can see it in how work feels day to day. Some teams move quickly and stay steady. Others ship fast, then slow down immediately after.
Barbara pointed to recent survey data as a signal of tension. While 55% of tech leaders describe AI’s capabilities as overhyped , her reading is that this scepticism isn’t about the tools themselves but about teams still being early in the learning curve, before the real gains start to show.
Why it matters: When everyone can ship faster, speed stops being a competitive advantage. If velocity is the only thing you optimise for, AI just helps you create more output, not better systems. The cost shows up later in brittle code, confused users and teams that hesitate every time something needs to change.
What to do: Stop treating speed as a proxy for excellence. Start defining “great” by questions like:
- Did we solve the right problem?
- Can the whole team explain why this system works the way it does?
- Did this change make life easier for users or just add more surface area?
What is an AI fluent engineer (and what they’re not)
| What this looks like | An AI fluent engineer is ✅ | An AI fluent engineer is not ❌ |
|---|---|---|
| Core mindset | Product-minded, focused on solving the right problems and owning outcomes end-to-end. | Output-driven, focused on shipping tasks or features faster. |
| Relationship with AI | Uses AI as a collaborator to design logic, systems, and workflows. | Uses AI as an autocomplete tool or authority that replaces thinking. |
| Judgement and taste | Applies judgement to guide AI towards clean architecture, good UX, and clear trade-offs. | Equates “it works” with “it’s good enough to ship”. |
| Ownership and responsibility | Takes full responsibility for correctness, safety, and maintainability of AI-assisted output. | Deflects responsibility by blaming “what the AI generated”. |
| Team impact | Builds shared AI standards, workflows, and learning loops across the team. | Acts as a lone “AI power user” whose impact does not scale. |
How should developers communicate AI fluency when job hunting in the AI era?
Developers should communicate AI fluency during job interviews and in their project portfolios by adhering to the AI fluency taste test, not by listing tools or claiming productivity.
Barbara’s point was that AI fluency is hard to see from outputs alone, because AI makes it easy to generate polished results. Instead, developers need to show their taste: how they reason, decide, and take responsibility when working with AI.
She described the taste test as focusing on three things:
- How you use AI
Not prompt engineering or tool breadth, but whether you can explain your workflow. How do you instruct AI? How do you supervise it? Where do you lean on it, and where do you deliberately not? - What you’ve built – and why
Can you show recent examples of things you’ve shipped and explain why they were worth building? What problem did you choose to solve? What impact did it have? Speed alone isn’t the signal – intent and impact are. - Responsible usage and ownership
Can you explain how you thought about safety, risk, correctness, and maintainability? Using AI doesn’t remove responsibility. You still own the output.
Key stats about AI fluency highlighted in the session
- 97% of teams are already using AI in some form: Adoption is effectively universal but usage quality varies widely.
- 55% of tech leaders say AI’s current abilities are overhyped: A strong signal that many teams haven’t yet overcome the learning curve needed to unlock real productivity gains.
- 37% of leaders say it’s harder to get headcount approval: AI is increasing pressure to do more with smaller teams, raising the bar for individual impact.
- 70% of tech leaders say retention keeps them up at night: As “great engineering” becomes harder to define, keeping top talent has become a strategic risk.
Want more data? For more trends, and leadership insights shaping engineering teams today, download the Engineering Leadership Report.
Want the full picture?
If you’re navigating AI adoption and want a grounded, experience-led view of what great engineering looks like now, the full session goes deeper into the trade-offs, tensions, and real team examples behind these insights. 👉 Watch the online event