How to find the sweet spot between AI-first and traditional ways of working

Introduction Introduction

Let’s assume you’ve made it past the title and want to read another piece on AI-first working. Then don’t stop reading now. Because we know everyone is talking about how AI is making work more efficient and how their company has a unique AI-first approach.

But let’s be honest—most of these unique approaches usually boil down to isolated experiments, quick wins, and surface-level tweaks. The way a project is run hasn’t fundamentally changed. There was just some AI sprinkled on top of it.

So what happens if we stop treating AI as an add-on and start designing with it at the core, right from day one? Does that spark your interest? Then keep reading.

Working AI-first is exactly what we set out to do in our strategic technology partnership with Tilia, born out of Van der Linde Texel. Their innovative fleet management platform, Tilia Rental Software, transforms rental operations for leading hospitality brands like Landal, Europarcs, and RCN Holiday Parks. Bike rentals, boats, tools, even golf course management—you name it, it runs through Tilia. Founder Martijn van der Linde had the software developed in-house, which opens up endless possibilities.

Of course, innovation like this takes two to tango. And we were in luck with a partner like Tilia. Right from the very beginning, we made a deliberate choice together: every aspect of the project should be optimized with AI.

Both of us accepted it wouldn’t be perfect from the start and that trial and error would be part of the process. But that’s the tradeoff when you’re among the first to push boundaries. The goal? To experiment, to challenge assumptions, and to unlock more value from AI than ever before.

We spoke with Kostas van Ruitenbeek, Backend Architect at Hypersolid, about how our partnership with Tilia is giving him the opportunity to go all-out on AI and about the many challenges he is allowed to encounter during that journey.

InterviewInterview

Q: You agreed on an AI-first way of working with the client. How did you start?

As soon as we got access to the codebase, we put words into action. Usually, figuring out the outlines and scope of such a large project takes a huge amount of time. You need to understand the setup, the code structure, the database… often spread across multiple codebases with minimal documentation.

Step by step, AI gave us contextualized breakdowns of the codebase. We could quickly reconstruct parts, test them, and understand how they worked. Manually, this would have taken much longer, especially with poor documentation.

Even better, we used AI to generate relationship graphs. They showed how different components interacted and where the complexity lay. The system rated complexity on a scale from 1 to 10, highlighting where to focus within the architecture.

This doesn’t give you 100% certainty about what you will encounter later in the project, but it gives you the key outlines fast. That freed me up to spend more time thinking deeply about the truly complex parts. And honestly, the AI’s complexity predictions turned out to be pretty accurate. In the end, though, it is still human judgment that makes the call.

It wasn’t just about generating documentation either. I used the AI as a conversation partner. I would often look at a section and think: this might be more involved than it looks. Then I would ask the AI to challenge or confirm that. Could this already be modeled like XYZ? Could it be simplified?

You are not just accepting the system. You are already evaluating and questioning the architecture. You are thinking in solutions while still in orientation mode. Every insight gets you one step further.

By the time we entered the scoping meeting, I was far better prepared than I would have been if I had been working in the traditional way. This allowed me to engage with the stakeholders with confidence, ask sharper questions, and bring ideas to the table. That made a big difference, especially since Tilia was preparing for a full rebuild of its rental platform. Early clarity about how to proceed helps everyone massively to align faster.

Q: How did that scoping meeting go?

We built a full JIRA board straight from the AI insights. Because I had a better overview of the codebase, I could define initiatives, epics, and features, and break them down into stories.

It was surprisingly smooth. I had just enough understanding to present the whole thing like a debrief. That is something really rare for me in legacy projects. Usually, you start in the dark and uncover things slowly. Now, I was able to make realistic estimates from the start, across the entire codebase, not just parts of it. That is powerful.

We also began identifying known unknowns earlier than usual. Things like cancellation flows or integrations with systems like Mollie. We might not have the full picture yet, but we could already flag them as key initiatives. That makes it easier to tell the client: “This is something we have not explored deeply yet, but we know it matters.”

Normally, issues like that only surface deep into the development process. By spotting them early, we could mark them, prioritize them, and avoid surprises.

Q: And what was it like once you started building?

Using AI to actually scope a project was something new for me, and this already made a massive difference time-wise. Although using AI in the building part is something we are more accustomed to, the kind of “reverse-engineering” part turned out to be really interesting, too.

I am not originally from a .NET background, but I have been programming in it for six years now, so I feel comfortable with it. Still, some of the syntax or language-specific quirks take me longer because I often have to look them up.

That is where AI gave me a serious boost. I no longer had to get bogged down by language details. I know what I want to build, and I understand backend architecture inside and out. AI just helped me bridge the gap between my intent and the implementation, making me much more proficient in, for instance, .NET and speeding this process up a lot.

I love building things, seeing how they work, laying out the rough structure first, just input and output, and then restructuring it to make it cleaner, faster, and more optimized. AI was able to speed up that entire process dramatically.

I made the conscious choice to put extra time into designing the data models, thinking carefully about how everything should interact. Once I have mapped that out, I let AI handle the actual building. Normally, that would take ages.

Things like CRUD endpoints (create, read, update, and delete) are necessary but tedious. In this new way of working, AI handles that in about 30 minutes. Then I can test it, see how it fits, and if it does not work, I can quickly rework it.

Sometimes I would build a small tool, just a quick front-end mockup using AI, to simulate how the backend interacts in practice. Especially if I had not received a UI from the designer yet. It helped me get a better feel for how the data model behaves in the real world, how the entities connect. That ability to spin up and tear down tiny prototypes on the fly is a game-changer.

There is this sweet spot developers always talk about. You want to automate things to work faster, but often, building the automation takes longer than doing it manually. That is why you hesitate. You do not want to waste three days building something that was supposed to save time.

But now I can automate things without blowing past that sweet spot. I will have an idea, quickly build a little helper tool in a couple of hours, use it during development, and then throw it away when I am done. It speeds up my entire workflow and, more importantly, it allows me to get to the sweet spot of developing the best solution.

Q: Do you have an estimate of how much more efficient this has made you?

Roughly, yes. I would say I work about 30% more efficiently on average. Some days it is much higher, 70 to 80% faster when everything clicks. Other times, you hit a bump, the AI gives you the wrong suggestion, and you lose time redoing things, maybe 20% slower in those moments.

But overall, the difference is huge. The ability to iterate so quickly is the real gain. That is what lets me move fast, test things, throw them away, and rebuild without losing momentum. And keep in mind: this was my first time using AI in such a fundamental way; the more I get accustomed to it, the more efficient the process will become. Especially given the rate at which AI is developing.

And the biggest win is not only in raw speed, it is in how I spend my time. I can focus on the hard problems and help the rest of the team more because I am not stuck doing repetitive work anymore. This makes my life nicer and also has a huge impact on the quality of the work we are able to deliver.

Q: What’s it like working with a client that’s AI-first-minded?

Tilia is pretty unique in that sense. They are ahead of the curve in how they approach things. They experiment a lot, take bold risks, and constantly adopt new tools. Many other clients are also exploring AI, but they tend to be far more cautious.

You can see the difference in something as simple as their briefings. Instead of a traditional call or a written document, we will often get a fully iterated AI-generated prototype or design of the desired outcome. They will iterate on that for an evening and then send it over. For us, that instantly sets the direction. This is where we need to go. This is roughly what it should be.

Of course, there is complexity in that. Rebuilding something “better” is not as simple as it might look from the outside. But I really enjoy working this way. It creates a very dynamic collaboration. We get aligned much faster, communication is clearer, and we do not waste time arguing over assumptions.

Q: You are clearly positive about working AI-first, but you have also mentioned it is still complex and far from perfect. So how do you find the sweet spot between AI-first and traditional ways of working?

I think it is all about iteration, just doing a lot. That sweet spot? You find it by feeling your way through it. It is no coincidence that people call it vibe coding. Although personally, I prefer the term “intent engineering” as a tongue-in-cheek distinction. Vibe coding has taken on a bit of a fuzzy reputation and has too many negative connotations. There is a big difference in being in a tech lead role, orchestrating sustainable LLM output, compared to a non-technical person creating quick prototypes and proof of concepts. Both are very useful, but with a different purpose.

The most important thing with an intent engineering approach is that you have to experiment to figure out how to best convey your intentions in the right structure to the AI. Sometimes you even need to use one LLM to help you write better prompts for another. If you cannot quite get it right, ask an LLM: “Here is what I want, can you formulate this properly so another model can interpret it?” That is when you start to understand what structure it needs to generate good results.

The biggest limitation right now is context. LLMs still have limited context windows. You need to summarize, structure, and communicate very clearly so that it can apply your instructions across a larger codebase. That takes practice, just like writing good documentation. Everyone starts with messy walls of text, but over time, you learn to use bullet points and structure things better, and the same goes for AI. Small tip: give the LLM an overview of your directory structure and configure default context info on your project. That already makes a huge difference.

One of the harder parts is managing expectations. A client might quickly generate something with AI, throw it over the wall, and think it is done, or think it should be simple for us to implement because they made it fast. But setting up a robust, secure, and scalable architecture still takes time, even with AI.

That is where clear communication becomes crucial. We spend a lot of time aligning expectations, taking what the client has built, and transforming it into something sustainable. And to maintain speed, we also use AI ourselves in that process. I see it as a sort of funnel. The client produces a quick draft, and we refine it with AI and our expertise into something production-ready.

Even if you can move fast on your own, professional oversight is crucial. Our value lies in deep knowledge, technical expertise, and the ability to scale. We make sure everything is built sustainably, securely, and with long-term quality in mind. We guide the process, set the right structure, and keep an eye on what will matter months or even years from now.

Curious about going AI-first yourself? Let’s talk and explore how it could transform the way you work.