AI in software engineering is no longer a future trend, it’s reshaping how engineers work, how teams are structured, and how hiring managers should assess technical talent. At Zebra Talks Tech on 3rd June at Old Street Roundabout, we brought together engineering leaders and hiring experts to discuss what’s actually changing on the ground. Here are the key takeaways.
“One thing that resonated, and that we’re already seeing reflected in the market, is that AI isn’t replacing engineers; it’s redefining what makes them valuable. The engineers who thrive will be those who can judge the quality of solutions, think in product terms, and use AI with critical judgment. Hiring processes need to evolve to recognise that.”
– Adam, Zebra People
The event focused on a major shift: AI is making it less valuable to test whether someone can simply write code, and more important to test whether they can understand problems, make good decisions, and use AI effectively.
The speakers argued that engineers are moving up a level of abstraction. Just as modern engineers no longer need to write compilers or servers from scratch, future engineers may not need to hand-code as much. Instead, their value will come from knowing what should be built, why it should be built, whether the AI-generated solution is good, and what trade-offs are being made.
Coding is becoming less of the main differentiator
The group repeatedly discussed that AI can now generate code, refactor code, and help with implementation. Because of that, simply producing working code is no longer enough to prove someone is a strong engineer.
The new differentiator is whether someone can:
- Understand the actual problem
- Define what good looks like
- Evaluate AI output
- Spot flaws in design or architecture
- Reason through alternatives
- Explain trade-offs clearly
The message was not “engineers are no longer needed.” It was more: the engineer’s role is changing from code producer to problem-solver, reviewer, architect, and AI supervisor.
How to run technical interviews in the age of AI tools
A major topic was technical hiring. Traditional coding tests, take-home assignments, and live coding tasks are becoming weaker signals because candidates can use AI tools to produce polished answers.
Rather than trying to ban AI entirely, the speakers seemed to favour interviews where AI use is allowed or expected, but the candidate is assessed on how they use it.
Better interview questions now include:
- Why did you choose this solution?
- What alternatives did you consider?
- What are the risks?
- How would this scale?
- Is this secure?
- What would you change if requirements shifted?
- What did the AI get wrong?
- Can you defend or improve the design?
The point is to test whether the candidate understands the work, not whether they can hide their AI usage.
Engineering judgement and ‘taste’: what AI can’t replace
One of the strongest themes was that AI tools can produce plausible code, but they do not reliably have taste.
In this context, “taste” means the ability to look at a solution and judge:
- Is this clean?
- Is it maintainable?
- Is it overcomplicated?
- Are related things grouped sensibly?
- Will this become a mess later?
- Is it secure?
- Is it scalable?
- Does it fit the wider product direction?
The speakers suggested this is what separates stronger engineers from people who can merely prompt AI to generate code.
Engineers now need Product thinking not just technical skill
There was a strong point raised about engineers needing to understand the business and product context, not just the implementation.
There was discussion around asking:
- What does the user need before they reach this page or feature?
- What problem are they trying to solve?
- What should the product experience be?
- How does this feature connect to future expansion?
- How does the technical design support the business direction?
This suggests the ideal engineer is becoming more like a technical product thinker: someone who can bridge user needs, business goals, and technical implementation.
The rise of the Technical Product Manager: blurring engineering roles
The conversation included an interesting planning example: historically, a 50-person product team might have had roughly 40 engineers and 5 product managers, but future planning may flip some of that balance, with far more product-oriented roles and fewer traditional engineers.
The speakers discussed the idea that many product managers may need to become more technical, and many software engineers may need to become more product-minded. The phrase “technical product manager” came up as a likely growth area.
The implication: people who can bridge engineering and product will become especially valuable.
Some engineers may struggle if they only want to code
A more challenging point was that not all software engineers will want to cross into product, strategy, or broader problem-solving. The speakers seemed concerned about what happens to engineers who are strong at implementation but less interested in product ownership, ambiguity, or business context.
The likely winners are engineers who are:
- Curious
- Ownership-driven
- Comfortable with ambiguity
- Willing to learn product thinking
- Able to use AI as part of their workflow
- Able to communicate and defend decisions
The risk group is engineers who only want to receive clear tickets and implement them without engaging with the wider problem.
AI agents in engineering teams could change how they operate
There was discussion of teams using AI agents in tools like Slack or development workflows, where individual engineers might each have agents carrying out tasks such as refactoring, code review, or implementation support.
This raises bigger team-design questions:
- How many engineers are needed if each engineer can control multiple agents?
- What work should humans do versus agents?
- How do teams review AI-generated work?
- How do you maintain quality when output volume increases?
- What does management look like when engineers are also directing AI systems?
The speakers seemed to think this will make team planning harder, because old assumptions about headcount and productivity may no longer hold.
What happens to Junior Engineers when AI does the beginner work?
The discussion touched on a difficult issue: if AI handles a lot of simpler engineering work, then the traditional route for junior engineers to learn by doing basic tasks may weaken.
There was concern about how future engineers build depth if everyone is using AI from the start. However, one speaker compared this to previous abstraction shifts: engineers once needed to understand compilers or servers much more deeply, but the profession evolved as tools improved.
So the question is not just whether junior roles disappear, but how juniors learn judgement, fundamentals, and taste in an AI-heavy environment.
Senior engineers and principal engineers remain very important
There was clear suggestion that companies may still need strong senior/principal engineers as the “backstop” against bad AI-generated decisions.
These senior people are needed to:
- Review architecture
- Define quality standards
- Catch security/scalability issues
- Coach others
- Protect the system from accumulating poor decisions
- Understand deep trade-offs
In other words, AI may reduce some implementation burden, but it may increase the need for people who can judge whether the implementation is actually right.
Curiosity and ownership may matter as much as technical skill
Near the end, the discussion moved towards personality and mindset. The speakers suggested that hiring should test whether someone is genuinely curious, takes ownership, and wants to understand the problem.
The ideal person is not just someone who says, “Give me a task and I’ll complete it.” It is someone who asks:
- Why are we doing this?
- Is this the right solution?
- What is the user really trying to do?
- What could go wrong?
- How does this fit into the wider system?
The biggest takeaway is: AI is not removing the need for engineers, but it is changing what makes engineers valuable
The future engineer needs to be less of a pure coder and more of a problem-framer, product thinker, AI operator, technical reviewer, and decision-maker.
The people who will thrive are those who can combine:
- Technical depth
- Product understanding
- Good judgement
- Curiosity
- Communication
- Ownership
- Ability to use AI without blindly trusting it
The event’s underlying warning is that people who only know how to produce code may become less differentiated, while people who know how to decide what should be built and whether it is any good will become more valuable.
AI is changing what great engineering looks like — and what it takes to hire for it. Whether you’re reviewing how you assess candidates, building a team with the right mix of technical depth and product thinking, or just want to stay close to where the industry is heading, we’re here to help.
