My interest in programming started with an old computer I inherited from my mother. While other children would probably have used it to play games, I found a BASIC interpreter and decided that writing my own programs was a better way to spend my time. Whether that was a sensible decision is debatable, but it certainly kept me occupied.
Since then, I've worked on everything from IoT infrastructure and autonomous drones to European research projects, multi-agent systems, and AI-driven software development. I've also accumulated a collection of technical projects at home, most of which started with a simple question and ended up taking considerably more time than expected.
I'm Felix, and I've recently joined re:cinq as a Senior Software Engineer. My career hasn't followed a particularly straight path. I tend to follow technical problems that interest me, especially when they're complicated enough to make me question why I started investigating them in the first place.
From IoT infrastructure to autonomous systems#
Earlier in my career, I worked on IoT infrastructure for one of Europe's large energy providers. Software connected to physical infrastructure comes with its own challenges. Hardware doesn't always behave as expected, networks aren't particularly interested in your availability requirements, and failures can have consequences beyond an error message in a log.
I later worked on European research projects involving autonomous logistics and digital data sovereignty, including Gaia-X, data federations, and Verifiable Credentials. One of the highlights was collaborating with a robotics institute and co-authoring a peer-reviewed paper on multi-agent systems. Research wasn't something I'd planned to pursue, but I enjoyed having to demonstrate that our ideas worked rather than simply producing convincing diagrams.
I also worked on autonomous drones, including autopilot firmware in C++ and MAVLink telemetry. Debugging software on a flying device adds a certain urgency to the process. It's one thing to investigate a problem in a development environment. It's another when the hardware running your code is several metres above the ground.
These projects involved different technologies, but I enjoyed the same aspects of each: understanding the architecture, investigating unexpected behaviour, and figuring out how the components interact. Preferably before something expensive stops working.
An early interest in machine learning#
I started experimenting with machine learning well before large language models became the answer to every software problem.
In 2015, I developed a machine learning model to investigate a medical condition I'd been struggling with. The model helped identify the condition and gave the doctors treating me information that helped them reach a diagnosis. It was an unusual personal project, although having a problem worth solving was certainly good motivation.
I've continued exploring AI alongside my engineering work, with much of my recent attention focused on language models and systems where multiple agents collaborate on tasks. That introduces a whole new collection of problems to investigate, which suits me rather well.
Why I joined re:cinq#
I've been using Claude Code and agentic development workflows regularly, and I've spent considerable time experimenting with how agents can contribute to software development.
What attracted me to re:cinq was its focus on the engineering process itself. There are already plenty of discussions about which coding assistant is best or which model performs better on the latest benchmark. I'm more interested in how we organise software development when agents handle a significant share of implementation work.
I'd already been experimenting with this before joining re:cinq. I built a small agent-based software factory that takes development tickets through planning, implementation, testing, and merging. It uses a planning agent, several concurrent worker agents, and a testing agent, with the goal of producing tested, merged code with limited manual involvement.
Building it was an effective way to discover how many things can go wrong when several agents work on the same codebase. Tasks need clear instructions, concurrent changes have to be coordinated, and tests need to catch problems before anything gets merged. Occasionally, the most impressive thing an agent produces is a very convincing explanation of why its incorrect implementation is correct.
Working with agents shifts more of my attention towards designing workflows, defining requirements, and evaluating results. The agents handle much of the implementation, while I focus on giving them enough context and the right checks to complete their tasks.
It's a different kind of engineering, and one I'd like to explore further.
Building software with agents at re:cinq#
I'm still in my first weeks at re:cinq, getting familiar with the existing systems and development practices. My usual approach is to read as much as possible and ask a lot of questions. Some are probably more detailed than necessary, but I prefer understanding why something works before proposing a better way to break it.
I'm particularly interested in how agents coordinate their work, manage dependencies, and avoid conflicts when several of them are modifying the same codebase. There's also the question of how much of the development process can be automated reliably.
Some tasks have clear requirements and straightforward validation criteria. Others involve architectural decisions, business context, or trade-offs that are difficult to express in a specification. Giving agents more autonomy is appealing, but only if the surrounding system can handle the consequences. Otherwise, we risk replacing the time spent writing code with an equally impressive amount of time figuring out what the agents have done.
That's an area I want to focus on at re:cinq: improving coordination, evaluation, and the processes that allow agents to take on more responsibility without making development harder to manage.
Engineering doesn't stop at work#
A considerable amount of my free time also involves computers, which suggests I haven't quite understood the concept of work-life balance.
At home, I run infrastructure based on Proxmox and Unraid, along with several self-hosted language models. I've also experimented with combining an intrusion detection system and an LLM to analyse network traffic. This means my home network can now involve an AI-assisted investigation into whether a smart kettle is behaving suspiciously. I'm sure there are simpler ways to run a household.
I also enjoy electronics and have manufactured my own circuit boards. When I'm not working on computers or hardware, I play drums in a heavy metal band. It's probably the least technical thing I do, although it also involves hitting hardware repeatedly until the desired result is achieved.
What I'm looking forward to#
At re:cinq, I'm looking forward to applying my experience across infrastructure, embedded systems, research, and AI to software factories and multi-agent development.
I'm especially interested in improving how agents coordinate tasks, how their work is evaluated, and how engineering teams manage increasingly automated development processes. I've experimented with some of these ideas independently, and I'm looking forward to developing them further with a team working on the same challenges.
There are still plenty of problems to solve, which is generally how I prefer things.
If you're working on agent-based development, autonomous systems, self-hosted infrastructure, or similarly questionable ways of spending your free time, I'd be happy to exchange ideas.
You can reach me at felix@re-cinq.com.
