Guillaume Robin, Head of Software Engineering: "If you reduce the job to writing code, you miss what really matters"

Guillaume Robin, Head of Software Engineering: "If you reduce the job to writing code, you miss what really matters"

Guillaume grew up with a real obsession for understanding how things work. After engineering studies at Epita then Epitech, a double degree in computational intelligence at Kent University, and a stint at the Banque de France and freelancing, he joined Inarix, a deep-tech that turns a phone into a mini-laboratory capable of evaluating the quality of agricultural grains.

We talked about AI "for real," 20,000-euro grain analyzers replaced by a smartphone, technical trade-offs, fully remote work, management, and what AI really changes in the engineer's craft.

First steps in AI

"I did Epita then Epitech, with a double degree in computational intelligence. Today everyone talks about artificial intelligence, but at the time we mostly talked about machine learning."

Very quickly, he got close to the Epitech lab.

"I ended up at the Hub Innovation, in the AI department. I ended up teaching there. That's really where my interest in AI took shape."

What followed was an internship at the Banque de France, then freelance missions. That's where he crossed paths with Inarix.

"They were looking for someone to transform a 'one client, one model' infra into a real multi-client, multi-model platform. The MVP was validated. My role was to take everything that existed and turn it into something that could scale."

Meeting Inarix and the deep-tech click

"When I arrive, there's the CEO, Pierre, a first data scientist, Helmi, Artemis the CTO, and almost at the same time Alexandre, Head of Data Science. He handles the models, I handle software and infrastructure."

What hooked him wasn't only the technique.

"They had already proven something powerful: from a simple photo, a phone could analyze the quality of a grain sample. No need for machines costing tens of thousands of euros. It was fast, concrete, and above all useful."

The team's seriousness mattered just as much.

"Pierre was ultra rigorous on finance. Artemis perfectly mastered the technical vision. You can sense when a team is solid. And then the impact was immediate: better evaluating quality means better paying farmers. I felt it would work, on the condition of working hard."

Context: 2020.

"At the time, few people trained their own models. Clouds weren't yet optimized for inference on GPU, foundation models were barely talked about… stumbling on a team that wanted to do everything in-house was rare. That also convinced me."

Explaining Inarix to a CTO

"In agriculture, everything revolves around grain quality. Three players: producers, collectors, processors. Historically, analysis was done with expensive and slow machines."

Inarix's promise lies in a change of scale.

"What we do is bring this analysis into a phone. The operator takes one or two photos, and we automatically compute the necessary criteria — variety, protein content, etc. It lets them decide in seconds which silo to store in, and avoid mistakes that can cost a lot."

Promise vs field reality

"Today, the promise is delivered. We're deployed in many silos, and the phone's speed has convinced people."

But the transition wasn't easy.

"In a silo, there's often a historical, expensive, and 'official' machine that everyone trusts. Saying that the phone does just as well is a shock. We had to prove the performance."

Systematic comparisons with standards played a decisive role.

"We regularly sent samples to third-party labs. And several times, when our results differed from the machines', we were the ones who were right. That immediately changes the discussion."

Trust was established progressively.

"Today, customers rely heavily on us. It shows we've become central to their process."

First major technical challenges

"When I arrive in January 2020, a freelancer had already laid an infra. It wasn't extensible. We had a web app, a mobile app, servers, model training tools… and everything had to be ready by early June. And I was alone on the software side."

The decision was radical.

"We almost redid everything. We kept part of the web app, but for the rest, we decided to start from scratch. It was a huge technical and organizational challenge, but it was the right decision. Redoing early always costs less than piling on bad foundations."

Then came the topic of inference.

"The next stake was the inference infrastructure. That's what makes the models available to clients. The GPU was expensive, there weren't many, and we didn't have an infinite budget. We needed a solution capable of going to fetch machines from different providers, optimizing costs, all while absorbing the harvest peaks. At the time, very few teams built their own inference system. Many went through off-the-shelf services and just put more money in."

On precision, the bar stays high.

"We never compromised on precision. In agriculture, every percentage point counts. Where we made compromises was on the speed at which we delivered certain things, or on accepting a less elegant solution short-term. On result quality, we always wanted to be at the best of what science allowed."

Technical decisions that changed everything

He cites two founding decisions.

First decision: radically change the architecture of the models.

"Following new developments in the field, Alexandre decided to completely rethink how we built the models. For a year, the new architectures didn't reach the performance of the old models. It was very risky. But from the moment they found the right recipe, we exploded performance. Without that pivot, we probably would never have reached the current level."

Behind it lie modern architectures and a lot of training know-how.

"Today, there's transformer in the story, but it's not just a model. It's a training sauce, data choices, tuning. And this sauce evolves constantly."

Second key decision: the way data is collected in the field.

"From the start, when I rebuilt the mobile app, we decided to make a generic collection system, a bit like an embedded Google Forms. The operator declares what they receive, the variety, the species, and we can ask them other info like humidity or temperature. This system is configurable server-side, to adapt to each client's reality without developing new things every time."

This data-driven vision pays off long-term.

"Because we categorized and structured data from the start, we built in a few years an incredibly rich base. And above all, we could adapt the forms to the business in real time, without breaking the data chain. That saved us months of categorization work later."

Building a team: data, software, QA

The tech organization sharpens over the years.

"On the data side, each data scientist had a topic, sometimes shared, with a very research-oriented logic. On the software side, we progressively structured around infra, mobile, web, backend, data engineering, then QA."

Guillaume stays at the center of backend and management.

"My base is backend. We first hired on infra/DevOps, then mobile, then web, then data engineering, then again backend. Then we added a second data engineer, a second person on infra, a QA team, a mobile lead, a data engineering lead. Me, I kept the backend while steering the whole."

R&D is very clearly on the data side.

"The real R&D is on the model side. We, in software, make all of that usable, stable, industrialized. But we realized we couldn't separate the worlds completely. At some point, we gave the data scientists the ability to deploy to production themselves, so they understood the real constraints and we spoke the same language."

Two engineering cultures to make coexist

"You have a research culture, very fast, very experimental, and a software culture, much slower because there are quality, security, reliability processes. Both are legitimate, but making them coexist isn't trivial."

At the start, each side stays too much in its silo.

"For a while, the data scientists exported a model and after that it was no longer their responsibility. The software team put it in prod. That created opacity, misunderstanding. When there was a problem, it was always: is it the data or the software?"

The solution comes through shared responsibilities.

"The click was opening the prod environment to the data scientists, so they could test in the same conditions as their models in research. And we, on the software side, started testing in their conditions too. When everyone sees the other's world, friction goes down."

Full remote very early, and what it really changes

With Covid, Inarix shifted to full remote when an in-office culture hadn't had time to establish itself.

"It was the best possible decision. The company was young, there weren't yet very ingrained office habits. But you have to accept that remote isn't 'the same thing but at a distance.' You need a culture of written communication."

The rules that emerge are simple but demanding.

"When you have an oral meeting, someone has to take notes and share them. When you say 'let's hop on a call' in a Slack thread, you have to make a summary afterwards. Otherwise, those who weren't there are lost. Remotely, if it isn't written, it doesn't exist."

Remote also opens the borders.

"It let us hire all over France, then abroad. We had an intern who didn't speak French, who was hired on a permanent contract. We switched all communication to English. That opened access to profiles we never could have hired otherwise."

But not everyone is built for full remote.

"We saw people realize after three months that they felt alone, that this way of working wasn't for them. There are 'scars' from in-office that take time to disappear. For example, asking for a half-day to go to the doctor. We had to repeat: you block your calendar, you go, and as long as the work is done, it's fine. It's a mindset shift."

Recruiting remote on hard topics

The hardest role to recruit: infra/DevOps.

"It took us a year and a half to find. Many profiles were either too junior, or very experienced but on proprietary environments that didn't fit our needs. And we also had to filter the ability to work remotely."

Juniors are excluded by the context.

"In full remote, with a small team and very tough stakes, we can't afford to take very junior profiles. You need autonomy, discipline. It's not the ideal model for a first job."

There's no magic recipe to detect someone "remote compatible."

"Having previous remote experience helps. But beyond that, it's a lot of feel: how the person writes, how they structure their answers, how they behave on video. And then there's only one real test: the trial period."

What distinguishes a great engineer

"I don't like micromanagement. I hire people who don't wait to be told what to do. They have to be able to go after the need, take initiative, understand the broad directions."

Product and business vision becomes central.

"With AIs that code, the difference won't be made on writing code. It'll be made on understanding the business problem. A good engineer must understand why, for a given model, we don't need perfection right away. That a 'good enough' model already brings a lot of value, and that the company needs to sell, to survive."

Knowing how to say no is part of the job.

"In a startup, everyone charges ahead. You need people capable of looking up, saying no, and arguing to protect the company from technical decisions it'll pay for later. Even if, in the end, we don't always follow their recommendations, at least no one can say no one warned us."

Learning to be a manager

"I didn't really choose to be a manager. I accepted. We had agreed with the CTO: if I didn't like it, we'd have to find another solution. In the end, I loved it, but in a precise frame."

First lesson: delegate.

"Like many people who arrived early, I had to accept others touching what I had built. On mobile or front, no problem. On backend, it took me longer, because I know it's the heart. But if you don't delegate, you block everyone."

Then comes the management of individual differences.

"You don't manage everyone the same way. Some never lose confidence, they go to the front all the time, sometimes too quickly. Others doubt a lot, you have to support them until they gain confidence. Some take direct feedback very well, others need more nuance. You have to adjust."

Conflict resolution is often simpler than you'd think.

"Remotely, many conflicts are born from a misinterpreted message. Putting the two people in the same call, getting them to talk, solves 90% of problems in five minutes."

Finally, he sees the manager's role as a buffer.

"I've always seen myself as a filter. My job is to absorb, filter requests, and only pass on to the team what has real impact. Development requires long stretches of concentration. Sending a message directly to the developer for every idea destroys that. So yes, you take a bit more load, but that's the role."

Future of Inarix, future elsewhere

On the Inarix side, a new product was launched around traceability in the supply chain.

"The idea is to map storage sites, including silos, and know in real time what's in them, in quantity and quality. With the development of on-farm storage, cooperatives are renting more and more capacity from farmers. They have to keep clear visibility on silos that are no longer physically with them."

The challenge is as much product as human.

"It's a complex product, on a topic where many have broken their teeth. And in parallel, the team has given a lot over the years. There's fatigue, restructurings, departures. Restarting in a 'back to the beginning, new promise, new market' logic requires enormous energy."

For Guillaume, the next chapter will be elsewhere.

"Inarix is at a moment where market-fit no longer needs to be proven on the first products, but you have to stabilize, aim for profitability, clarify whether the goal is to become a beautiful profitable SMB or to restart on a more aggressive trajectory on new products. Me, I wanted to see the next stage: a company that has already found its product market fit, that goes from 30 to 80 or 100 people, that launches a second product, that really structures at scale."

He's joining another company more advanced in its trajectory, to take the lead on a new product.

Having done AI "for real"

"The big advantage for me is having worked on internally trained models, not just APIs. At the time, those who really trained their models were Google, Facebook, and a few labs. Today, many companies 'do AI' by calling a third-party API. It works, but it's not the same experience."

This experience gives him a different view of the current market.

"I see many companies doing AI-assisted legal, writing, business copilots. Technically, they're very dependent on a vendor. They don't always have the in-house skills to understand the model's limits, biases, costs, security. The risk is to undergo the technology rather than master it."

Still, not everyone needs to train their own models.

"When you talk about LLMs or VLMs, training costs are enormous. You don't recreate in five years what companies built in ten with hundreds of millions of budget. You have to choose your battles. Sometimes paying an API remains the best option. What matters is doing it knowingly."

Will AI replace developers?

"I think AI will mostly raise the average level. It'll be very good at producing 'correct' code, average code. Those below that average will suffer. Those above, who understand the business, the architecture, the constraints, will be augmented."

For him, the key is to distinguish developer and software engineer.

"I've long made the distinction between developer and software engineer. Developers love code. Software engineers love understanding the system, the business problem, the science behind it. It's not the same mindset."

Profiles only attracted by code risk more frequently colliding with AI.

"If you don't particularly like the business behind it, if you don't seek to understand how it works, and you see code as an end in itself, you find yourself head-on with models that, themselves, generate code all day. Those who'll use LLMs the most to code will often be those who don't really like code. It's a bit paradoxical."

He doesn't see AI as a replacement, but as a revealer.

"If you love understanding the business, taking apart the pen to see how it's made, looking for an elegant solution to a complex problem, AI will take away part of the painful work. It'll generate boilerplate, repetitive endpoints, first drafts. But it won't replace what you put into design, into choices, into trade-offs. Not right away anyway."

What he'd say to a young person who wants to start

"We sold the developer profession a lot by saying you could make it in six months. You can learn to code fast, yes. But computer science is a science with decades of history. You don't ingest it in a bootcamp."

For him, the question to ask is simple.

"Do you really want to spend your days understanding systems, businesses, constraints, and not just learning a trendy language? If the answer is yes, you have a place. If it's just for the money, or because someone told you 'there's work in tech,' it'll be very hard to keep up the pace."

And he reassures those already in the craft.

"AI won't replace good engineers overnight. It'll make the craft more demanding. You'll have to stay ahead of the average, keep learning, keep understanding what you do. But if you don't reduce your work to typing code, you still have room."