“A well-posed problem is half-solved.” With this quote from Henri Bergson, Laurent Uhres opened a coffee talk with our students exploring the challenges of software engineering in the age of AI.
Laurent Uhres is an interdisciplinarian with a background in software engineering, technology innovation, and the arts. Currently VP of Innovation at Webellian, he leads enterprise-level technology initiatives that bridge human insight with engineering rigor. Trained in embedded and real-time systems, Laurent brings decades of industry experience. He is also the author of Creative Convergence, a book exploring the synergies between science, design, and the humanities.
As the role of programmers shifts from simple coding to solving meaningful problems and since Laurent offers a nuanced perspective on a profession that’s often seen in a one-sided way, we asked him what it really means to be future-ready in tech.
The engineering state of mind
First, the question on everyone’s mind: Will AI replace programmers? “It depends on the task,” Laurent remarks. “AI handles simple coding and debugging well, but it still struggles with complex problems – it gets confused and can’t break them down effectively.” AI will likely support programmers by handling routine tasks, freeing humans to focus on creative, complex challenges. But using it well still requires a strong understanding of how systems work.
Does this mean we need a whole new set of skills? Not necessarily. “As a species, we’ve always engineered solutions to survive and shape our environment. Some may have forgotten this or never learned how to apply it, but it’s almost innate,” Laurent reflects.
“It’s not about becoming someone completely different. It’s about developing what I call an engineering state of mind. Whether or not you write code, this mindset will serve you in any field.”
Yet today, the “engineering” part of “software engineering” is increasingly overlooked, he sighs.“Many are skilled technicians and craftsmen, but the true challenge is translating real-world problems into code. Often, the complexity isn’t in the code itself – the real difficulty lies in understanding what to build, why it matters, and how to clearly define the problem.”
He compares this shift to the evolution of bridge-building: “Five hundred years ago, building a bridge was mainly craftsmanship. But as bridges grew larger and had to bear heavier loads, it became an engineering challenge – requiring careful planning and design before construction even begins.”
The power of collaborative learning by doing
If thoughtful engineering is the goal, what kind of learning environment helps us get there? Laurent explains: “The best way to learn is by doing. Collaborative learning like this is essential. Having someone by your side to provide immediate feedback is crucial – without it, it’s easy to get lost or misunderstand best practices.” This approach is very close to us at 42 Warsaw, where hands-on, peer-supported learning forms the core of our educational philosophy.
“There’s also the risk of knowing only one tool – when all you have is a hammer, every problem looks like a nail. A mentor or peer can introduce you to other ‘tools’ you didn’t know existed. This unknown unknown is a major trap,” he adds. “That’s why learning alongside experienced peers is key. They help you improve, think differently, and find better solutions.”
KIS.S and see the beauty behind the code
The engineering mindset also rests on guiding principles. Laurent highlights two as the most important. First: KIS.S – Keep It Simple, Stupid. Complexity is often mistaken for intelligence, but true intelligence lies in simplifying solutions and eliminating the unnecessary. He echoes Saint-Exupéry’s words: “You know something is done not when there’s more to add, but when there’s nothing left to remove.”
The second principle is harder to define, but just as essential: a sense of beauty. “Well-written code has structure, clarity, and flow,” says Laurent. “It often feels elegant without needing to be read line by line. Like a well-designed object or a compelling piece of music, beautiful code has harmony. You can sense when it’s cluttered, forced, or lacking rhythm – even if you can’t point to a single flaw.”
In the end, the most important skill may not be technical at all – it’s the ability to truly understand what another person is asking for. This requires empathy, not just logic. It’s about constantly verifying and validating your work: Have I built the right product – is it what was actually needed? Have I built the product right – is it reliable, safe, and functional?
Have I done the right task? Have I done the task right?
