Of Masons and AI

The Christmas Party and the Trigger

Recently we had our Christmas party, and as with every team event, we started with an activity that involved the whole team: This time we met at "Weißer Hirsch" and arranged to play a series of games in the "Hall of Game".x For three hours, we played nine different games in three teams – fully engaging as a company with analog Rocket League and Nerf-gun shooting, activities that were part of our company's daily routine about seven years ago.

Caught up in the competitive spirit, all three teams fought a close head-to-head race that was only decided at the finish line. It was exciting, entertaining, and overall highly recommended! But what stuck with me since then was what the game master told us at the end: "I had a group of masons here recently, and I didn't have to explain the rules much – they just wanted to play. But with you: I almost had to put the brakes on explaining the rules because you asked so many questions!" At first glance, this might sound quite boring when people are more enthusiastic about the rules than the actual game. But it also shows quite well how we operate as a company: we want to know and understand all the parameters first, instead of just starting to develop without proper planning. Now, I don't want to imply that masons simply build walls haphazardly. But something seems to differentiate our approaches.

On Building Walls and Software Development

A wall is a wall, regardless of whether the owner, tenant, visitor, or neighbor stands in front of it. Software, however, behaves differently when an administrator uses it compared to a regular user, yet this behavior must be defined – deterministic. Anyone implementing an "if-then" should also consider the "else," otherwise it won't work. A wall, on the other hand, presents a fairly clear expectation of what needs to be done. Software is generally more complex than a wall and may need to undergo more adaptations during its lifetime – it needs to be and remain flexible. While a mason handles refinements with skill and experience when building a wall, measuring with a spirit level and adjusting if necessary, software rarely forgives course corrections halfway through. With software, it should be considered from the beginning that the last component fits the first. With a wall, bluntly put, it's simpler: the first and last components are the same: a brick.

This may be an oversimplified view of the differences, especially since I admittedly don't understand much about the mason's profession. But it was enough to explain why the masons simply started playing and having fun (or building a wall that fully meets customer expectations), while we need an extra round of rules before we can get started (or want to clarify many questions first to avoid boxing ourselves in with the foundation). So far, so good, even if up to this point it might just be self-assurance of our own raison d'être.

The Omnipresent AI

The second question that immediately arose was one that accompanies me in almost all areas at the moment: How does AI change this perspective? The mason probably rarely needs AI support to do his job - that's still genuine craftsmanship, and AI-controlled craftsman robots probably need a few more years before I wrack my brain about them. But with software? We always start requirements gathering with questions. An AI can probably handle that pretty well too. AI can already capture customer goals quite well today, I have no doubt about that. There are countless success stories from Vibe Coding that are based precisely on this! And already, one's own reason for existence begins to crumble. Or does it?

All of us at esveo have integrated AI into our daily work and are testing various use cases and strategies for where and how AI functionality can be integrated into our workflow: What proves successful, what doesn't, where is there currently still a gap until AI fills this void? And behold: As diverse as this range of applications is, we're also still far from AI completely taking away our reason for existence. But what do I mean by that?

What Distinguishes Us from AI

Instead of just asking how we should implement an existing idea – which an AI certainly does excellently – we consider our customers' ideas in the context of other aspects, because software development is generally a non-linear optimization problem, making determining an optimal solution not trivially possible, and the first idea not necessarily the best. An AI could certainly ask questions in these directions too, but it mostly only asks what it's told to ask. It's very polite by nature; contradicting is not one of its strengths. However, to find a good solution to a problem, critical questioning of the first solution ideas is needed. I have collected the aspects that belong to this questioning in the form of four clusters and a series of example questions:

• Goal: Ensure we're betting on the right horse through critical questioning & challenging
  • What do you want to achieve with your idea?
  • Why do you want to achieve this goal?
  • Is there another goal behind your direct goal?
  • Is your current idea really best suited for this or are there other approaches?
  • What other goals are you pursuing?
  • How does the current topic fit into the overall theme landscape; is it really to be prioritized so highly or are there other issues that would provide more benefit?
• Environment: How does the idea fit with the rest of the company?
  • What interfaces and exchange frequencies with other (IT) systems do I need?
  • Are these interfaces easily accessible?
  • What solutions already exist and can possibly be integrated through minor adjustments?
  • How likely is possible further development?
  • Which stakeholders need to be involved and do they want to have a say in the conception?
  • What needs to be considered to successfully deploy the solution to end users?
• Effort: Careful use of time and cost budgets instead of wasteful resource consumption
  • Are there any low-hanging fruits in the mix; approaches where effort can be minimized while maximizing benefit?
  • Do you need a quick & dirty one-time solution, a proof of concept, a solid first round, or the robust long-term solution?
  • How quickly do you need which functional scope of the envisioned total solution?
  • How large can the cost risk be to react to unforeseen circumstances?
  • Requirements are relative: A feature for €500 can be a clear must-have, while the same feature becomes a nice-to-have at higher development costs.
• Human Factor:
  • How to decide in case of doubt? While the principle of question-and-answer between customer and AI or between customer and service provider sounds technically-practically simple, giving the answer is not always clear and easy. What customer would choose a simple laying hen when offered a golden goose at the same time? Often it takes consultation to find the right answers, and since self-recognition is often not possible, it ultimately comes down to experience-based recommendations: a nudge from the consultant to get closer to finding a solution.
  • Are you sure? Individual senses are more strongly used in human 1:1: While AI only sees (reads) or hears requirements, human consultants see nuances, sense uncertainties in the customer that we perceive as hesitation, eye movements, or indecisive pronunciation, allowing us to proactively follow up when a customer is uncertain and hesitates.
  • More senses in use: We are faster at capturing a broader context, developing a feel for the customer's values, as we absorb impressions not only by reading (seeing) or hearing, but also by sitting with the customer and smelling their environment (fresh coffee beans), feeling (nice office furniture) and even tasting (the cookie with coffee). This contextual knowledge often provides a good gut feeling for the customer's values and sometimes helps to make the decisive difference in individual decisions.
  • How to create acceptance for a new solution? Things developed one-on-one with AI may be viewed more skeptically from the outside and potentially have a harder time finding acceptance. Something created together is team-building & creates broader identification. Creating positive changes together is fun and creates multipliers. It often feels safer to implement new projects with experienced partners and make decisions through (human) exchange.

Conclusion

Smaller tools with narrowly limited functionality, trivial logic, and a small user base can be perfectly vibe-coded, but the more complex the system and the logic to be mapped, the greater the probability that a good solution still requires real specification and developer craftsmanship. This requires many questions to be asked and answers weighed, framework parameters such as technology selection, time and money budgets to be considered, and that's where we consultants and developers from esveo are suddenly quite close to the mason, making things intuitively more correct with a lot of experience and intuition than an AI that (still) lacks this experiential knowledge and competence. Last but not least, in a 1:1 with the customer, we also recognize when body language indicates that a customer doesn't actually want to make a certain decision the way they say they do - we work with more senses and (still) derive a competitive advantage from this compared to AI, which certainly surpasses us in pure knowledge questions. Not to be underestimated is our consulting competence: AI can ask many questions, perhaps even critically follow up, but really contradicting, challenging ideas, expressing concerns, completely turning the perspective, and sometimes advising against entire aspects - AI (still) lacks the experience for this or is usually simply too polite. All in all, as of today, AI is a pretty excellent junior developer and sparring partner for individual questions, but currently not just a whole step away from the senior developer, but also far from the senior consultant / product owner / requirements engineer. We probably don't need to worry about being replaced soon, even as we keep an eye on the breathtaking development in amazement – reason for existence (still) secure for now.