I remember meeting Gilles for the first time as the investor and him as the entrepreneur, co-founder of Plakar with Julien Mangeard. We spent a long time exploring Plakar’s code base, and although I’m far from fluent in Go, and even less so in cryptography, I was captivated by the clarity of his explanations. I could see he was a true craftsman, passionate and proud of his work yet remarkably humble. I hope readers will discover this side of him and learn a lot from this long-form interview.

TL;DR;

  • Gilles Chehade, co-founder of Plakar with Julien Mangeard, and creator of OpenSMTPD, has spent over two decades building open, reliable systems for Unix environments.

  • He sees software as craft, a balance of logic, elegance, and human understanding, where correctness, simplicity, and security are non-negotiable.

  • Plakar was born from frustration with opaque, over-engineered backup tools. It aims to make data protection transparent, verifiable, and trustworthy.

  • Gilles believes that using open source purely as a marketing strategy is always a bad bet. It demands a philosophy grounded in honesty and accountability.

  • His approach to architecture prioritizes clarity, immutability, and adaptability over trends or frameworks.

  • He views AI as transformative, comparable to the invention of the Internet, but warns of a growing disconnect from foundational skills in programming.

  • For him, success in open source comes from solving real problems and genuinely caring for the community, not from technical edge alone.

  • His guiding principle could be: build systems people can understand, verify, and trust, because trust must is earned through transparency.

The Man Behind the Code

Since this is a portrait and some people might not know you or your work yet, could you start by introducing yourself, specifically as someone working in the technical field?

I’m Gilles Chehade, heading toward 45, and father of a little boy and a baby girl.

I’ve been building software and doing open source for a bit over two decades now, mostly around Unix systems, networks, and storage. My relationship with computers started when I was a kid, somewhere between curiosity and obsession, and it’s been the main thread running through my life ever since.

I’ve spent most of my career writing or fixing things meant to stay up for a long time: mail servers, databases, distributed systems, payment gateways, the kind of invisible software people only notice when it stops working. I care about correctness, simplicity, and security, not as buzzwords but because without them, everything else tends to crumble.

I’m probably best known for OpenSMTPD, a mail server I started within the OpenBSD project. The goal wasn’t to reinvent anything, just to make something reliable and understandable again.

Outside of code, I studied music, hypnosis, and psychology. It may sound unrelated, but it helped me understand systems of a different kind, human ones, and that perspective has influenced how I work and collaborate.

I hold a master’s degree in computer science from Epitech Paris, but most of what I know comes from trying, failing, and building. I just like understanding how things fit together, wherever that takes me.

Please introduce Plakar, your current venture with Julien Mangeard.

Over the years, I’ve used or built enough systems to see how backups turned into something opaque and over-engineered, tools that hide behind abstractions and make you trust them blindly. That always bothered me. They also became complex enough that people procrastinate because they don’t want to deal with them, and even engineers with strong computer science backgrounds often end up getting them wrong.

In 2024, I co-founded Plakar with my longtime friend and collaborator, Julien Mangeard. It wasn’t born as a startup idea. I first prototyped it in 2014 and began working on it seriously around 2019. The company came later, when a close friend encouraged me to take the leap, and the timing happened to align with Julien leaving his previous position. Plakar grew out of years of frustration with how backups had become opaque, over-engineered, and difficult to trust, a problem I just couldn’t let go of.

Our goal is to help set a new standard, not because existing tools are bad, but because none of them have become the standard. In most areas of computing, there’s broad agreement on what a good, dependable choice looks like. You might prefer MySQL over PostgreSQL, or Mercurial over Git, but you’ll still acknowledge that PostgreSQL and Git are solid, trustworthy defaults. That kind of consensus just doesn’t exist for backups.

There are plenty of good tools, rsync, tar, dump, Restic, Veeam, and many others, but the fact that people are still split across so many approaches shows that something’s still missing. Plakar isn’t about replacing them, it’s about addressing what’s been preventing that shared confidence from emerging. The goal is to make backups simple, transparent, and trustworthy enough that people can finally agree this approach makes sense.

Plakar today is the continuation of that long-running idea, but with a proper team and a shared vision. The foundation hasn’t really changed, it’s still about immutability, deduplication, and transparency, but now it’s backed by people I’ve known and respected for years. Almost everyone on the team is someone I’ve known or worked with before, and they chose to join because they believed in what we were trying to do.

The goal is to make backups simple, transparent, and trustworthy enough that people can finally agree this approach makes sense.

We try to build Plakar the same way we want our software to behave, openly and transparently. Most of our work happens in public channels, and many of our meetings are open for anyone to follow. It keeps us honest and grounded, and it reminds us that what we’re building isn’t just for us.

We’re still small, but there’s something special about seeing a team you trust completely collaborate in the open on something that feels necessary and honest. For me, that’s the best part of it all, it’s the kind of place I wish I’d worked at earlier in my career.

Where It All Started

When did you start thinking about pursuing this path? What triggered it for you? Was it a book, a movie, or a piece of software?

When I was six, my father was working abroad and sent us a computer. It came with a few manuals, one of which was for the BASIC programming language. I didn’t have any games, just that manual, so I spent months typing out the examples, tweaking them, and watching what happened. Nothing I did was particularly impressive, but I loved the idea that I could write instructions and see the machine do something new. Each chapter introduced new commands, and I’d mix them together to make small programs I imagined in my head.

I didn’t speak English back then, so the manual didn’t really make sense. My learning was entirely based on trial and error, typing, observing, and guessing what each change would do. That feedback loop became my way of learning, and I think it shaped how I approach problems to this day. What hooked me wasn’t just the creativity, it was the logic of it. When something didn’t work, it was always my fault, and fixing it felt incredibly satisfying. That feeling never really wore off.

By the time I reached high school, I had no idea what I wanted to do with my life. Working with computers didn’t even cross my mind, it felt more like a hobby than something you could build a future around. I was just studying because that’s what you’re supposed to do.

[The good ol’ days, in the “Salle des machines” (Machine’s room)]

I didn’t really understand why we were being taught certain things, and whenever I asked questions that weren’t on topic, teachers would shut them down. School felt more like something to endure than a place to learn, which was hard for me because I was genuinely curious. I wanted to learn a lot of things, just not the ones they were teaching. Over time, I lost interest and mostly felt bored.

Then, everything changed. Around that time, we got our first PC at home, and about a week after setting it up, I stumbled onto the underground hacking scene, a community full of people who truly understood how computers worked. They were all using Linux, so I installed it and fell deep into the world of Unix, programming, and system administration. The more I learned, the more I realized how little I knew, and that was exciting. I’d stay up all night reading tutorials and experimenting until my alarm rang, then drag myself to school half-asleep.

Eventually, my grades collapsed. I failed a year, then another, and got expelled. The school told me I wasn’t fit for studying and should probably look for a manual job instead. At the time, it crushed me. But then it hit me that I was already doing what I loved, I just needed to find a way to make a living from it. I didn’t yet know what that would look like, but I knew it would have to involve computers and programming.

What was your first legitimate piece of code, the first one you could actually be proud of? What was it, and when did it happen?

That’s a tricky question.

I love writing code for the sake of writing code, it’s how I relax. I’ve rarely sat in front of a computer to do something else. Most of the time, I write code because a question pops into my mind and I want to test it, or because I want to learn something new.

I don’t really think in terms of legitimacy, and I rarely take a step back to judge my work that way. Many of the things I’ve written made me proud, not because they were particularly useful, but because I started them not knowing how to do something, struggled for hours, and finished with a better understanding of it. I’m usually more proud of that moment of understanding than of the code itself.

Many of the things I’ve written made me proud, not because they were particularly useful, but because I started them not knowing how to do something, struggled for hours, and finished with a better understanding of it.

If we talk about legitimacy in the external sense, though, that would probably be OpenSMTPD, the mail server I started in 2007, a year after graduating from Epitech. It was committed to OpenBSD in 2008, and it’s still active today. It’s often recognized as one of the simplest and most elegant SMTP servers out there, and that’s something I’m genuinely proud of.

Your career has followed many parallel paths: working as a researcher, engineer, and architect in major successful corporations, while also building and maintaining open-source software in its purest form, with some teaching on the side to pass your knowledge to younger generations. Not to mention Gilles the musician or your love for wordplay only the French audience will catch (Plakar’s container is named Ptar). Music aside, Plakar seems to bring all of this together, can you tell us more about the philosophy behind? How would you define your current comfort zone?

That’s true, I’ve worn a few hats over the years, but they all orbit around the same curiosity, understanding how systems work, whether they’re technical, human, or artistic.

When I was learning psychology, I came to understand that any kind of work can be seen as a form of art, similar to music or writing, where each author has their own style. Their work can be elegant or crude, but if you’re familiar with them, it’s recognizable. This applies just as much to code as it does to any other craft. Some people seek beauty, others seek brevity, it shows in what they create.

[Ptar is an open-source format introduced by Plakar. It is immutable, deduplicated, compressed, encrypted, versioned, browsable and (trans)portable.]

What makes collaboration interesting is that these styles shouldn’t be identical, they should complement each other. A team where everyone thinks the same tends to get stuck, but a team where people have different approaches and still share a common sense of direction can produce something that’s both creative and solid. You need those contrasts, the different tempos and textures, for the result to have depth.

With Plakar, I think I’ve finally found a place where all those paths overlap. It’s a technical project at its core, but it’s also about structure, balance, and clarity, the same principles you find in any good composition. The team behind it is made up mostly of people I’ve worked with or known for years, some for over a decade.

Before they joined, we talked at length about the project’s philosophy and where it was heading, so they already understood the vision, and I knew they would fit. There’s a natural rhythm and trust in the way we collaborate, everyone brings their own voice, but we all share an instinct for where the piece is going, and together it just falls into place.

The philosophy behind Plakar is really about making things people can trust, not because we tell them to, but because they can look, understand, and verify for themselves. It’s the same mindset I’ve always had when teaching or contributing to open source, don’t just hand people a tool, give them the means to reason about it.

I like to think of Plakar as an attempt to bring a bit of order and honesty into a space that’s become overcomplicated. Backups shouldn’t be magic, they should be explainable, verifiable, and transparent.

The philosophy behind Plakar is really about making things people can trust, not because we tell them to, but because they can look, understand, and verify for themselves. It’s the same mindset I’ve always had when teaching or contributing to open source, don’t just hand people a tool, give them the means to reason about it.

As for my comfort zone, I think it’s anywhere I can learn and build at the same time. I’m happiest when I’m deep in something complex but still managing to keep it simple, when I can switch between thinking about design, code, behavior, and meaning all in the same breath. That mix of logic and creation is probably where I feel most at home.

His Philosophy of Openness

You’ve spent your entire career deeply dedicated to open source and its communities. Today, open source has become a broad term with many shades of openness, often used exclusively for go-to-market purposes and interpreted with a lot of flexibility. Do you feel that open source has lost some of its original meaning along the way?

I do think open source has lost some of its original meaning, but mostly because the world around it has changed a lot since the 90s and 2000s. Back then, there was a sharp divide between proprietary and open-source projects. Companies like Microsoft would call Linux a cancer and dismiss its merits, while open-source developers were constantly on the defensive.

Most Windows users didn’t even know open source existed, and very little proprietary software was made to run on Linux because it was seen as a hobbyist system. If you ran Linux or BSD, you didn’t have games, you didn’t have access to most commercial software, and often not even to your own hardware, lack of documentation meant you had to wait until someone reverse-engineered device drivers just to make things work.

At the time, most people who chose open source did it for philosophical reasons. They had strong opinions about what openness meant. It wasn’t about convenience or market share, it was about principles. You picked an open-source system knowing you’d lose access to a lot of software and that parts of your hardware simply wouldn’t work. You made that trade willingly, because the idea of using something open and community-built mattered more than comfort or compatibility.

Over time, that changed. Open-source software like Firefox or VLC became mainstream, even on closed-source systems, and Linux gained massive ground. Today it’s everywhere, even people who’ve never used it know roughly what it is. When someone asks me a Windows question and I admit I have no idea, they often respond, “Oh, you’re on Linux?” Even Microsoft now embraces open source in many ways, and the line between proprietary and open has blurred for much of the community. Most people today are driven less by ideology and more by practicality, they just use what works, regardless of the license.

I don’t think the original meaning of open source has changed, but its audience has broadened. Many people who use open source today don’t necessarily care about the philosophy behind it, they just need the software. The people creating it, though, usually still care deeply about what it stands for.

Using open source as a marketing strategy, if you’re not sincere about it, is a terrible idea. The community can tell. When they feel betrayed, they fork your project, the fork gains traction, and you’re left either backtracking and apologizing or watching your project fade into irrelevance.

As for companies using “open source” as a go-to-market strategy only, I don’t think that fools anyone. The users who don’t care about open source would install it anyway, and the ones who do care are the first to ask, “How do we know you won’t change your mind and go closed source next year?” That’s exactly what we heard when we released Plakar.

Using open source as a marketing strategy, if you’re not sincere about it, is a terrible idea. The community can tell. When they feel betrayed, they fork your project, the fork gains traction, and you’re left either backtracking and apologizing or watching your project fade into irrelevance.

And since this is your first time as an entrepreneur, what is your technical case for openness? Why did you choose it for Plakar?

Depending on whether you’re asking me as an open-source developer or as an entrepreneur, you’ll get two different answers on what’s the technical case for openness.

When I have my open-source hat on, I don’t think in terms of how I’m going to benefit from writing software, or whether it should be open or not. I write code because I like writing code. I publish it so others can learn from it. Sometimes it happens to be useful to companies that use it without giving back, and that’s fine, I’d still rather everyone benefit from the same piece of software than see dozens of slightly different versions appear and create interoperability problems. Many companies made money using OpenSMTPD, and I genuinely don’t care. I gave that code to the public, whoever they are, to better the industry. The fact that they profit from it isn’t really a concern to me. With that hat on, everything can be open, there’s no reason not to.

When I put on my entrepreneurial hat, things have to be more balanced. I still believe open source is the best way to build software, when you work in the open, you can’t hide bad code and hope no one notices. You’re forced to maintain a high standard because your work is visible and judged. At the same time, we have a business to run and wages to pay. We can’t release everything for free, or we’d quickly run out of money, and that would hurt both the company and the open-source project. If that happened, no one would benefit from the work in the long run. The main difference with my other take is that, as entrepreneurs, we need a simple rule, a clear way to decide what stays open and what becomes commercial. It has to be sustainable for us and simple for people to understand, so no one feels betrayed. It’s really about transparency, the rules of the game are known from the start, so the community understands what will be open source and what won’t.

Plakar was already open source, licensed under ISC (Ed. note: A short, permissive open-source license that allows unrestricted use, modification, and distribution, provided attribution is retained), long before we started the company, so we didn’t decide to open source it, it was already the case. What we did decide was how to structure things around it. The idea is simple, Plakar should offer as much as possible to users for free, while allowing us to build extensions aimed at corporate environments, things like compliance, legal requirements, multi-user support, and other enterprise features that most people simply don’t need for personal use.

At home or in small organizations, Plakar is complete and self-sufficient. But once you start facing the kinds of challenges that larger companies deal with, that’s when our commercial extensions come in. This makes the split between open source and proprietary very clear, regular users don’t feel like we’re trying to milk them, and companies that profit from the software contribute back by paying for what they need. In turn, that funding supports the continued development of both the open-source core and the commercial extensions.

When do you think open source is the way, and when it becomes useless? Do you have a framework in mind?

I don’t really think in those terms.

In my opinion, it’s a mistake to go open source as a strategy, unless open source is truly in your DNA and you genuinely believe it will make your project better.

Let me explain.

If you truly believe that open source will improve your project, you’ll embrace the community and try to find the best possible balance for them, even while trying to stay sustainable. That attitude shows. It shows in your decisions, in your interactions, and people pick up on it. They tend to like your company because it values them. It also means you’ll give away things that people might otherwise have paid for, but I think it pays off in the long run. People see what you give, and they understand that when you don’t give something, it’s not out of sheer greed but because it is strategic to your project that it’s not free.

But if you use open source as a strategy, it’s different. You’ll eventually realize you’re spending time producing code you’re not directly making money from. That becomes frustrating, and you start thinking in terms of “what’s the minimum I can give them so I can still sell something.” The community turns from a partner into an obstacle you need to work around. You stop fixing bugs or merging contributions because they might interfere with your business plans, and people sense that, too. The frustration goes both ways.

In my opinion, it’s a mistake to go open source as a strategy, unless open source is truly in your DNA and you genuinely believe it will make your project better.

In addition to that, some projects are naturally better suited to being open source because they rely on users’ trust. In our case, we’re asking people to trust us to preserve long-term archives of their data, protected by strong, state-of-the-art encryption. But would you really trust that promise from a company you’re not already familiar with if everything were closed source? What if we disappeared? What if we were wrong, or even dishonest, about cryptography?

The only real way to inspire confidence is to remove that risk for users. That means making the format open, so that if we ever go down, they can still rebuild the software and maintain it themselves, and so that anyone can audit how the encryption works. It makes people trust us more easily and, in turn, strengthens both the company and the project. Even if only a small number of users actually look into the format or the cryptography, they all know they can, and that makes a big difference.

What, in your view, makes an open-source project succeed while others don’t? How hard is it to stand out from the crowd? Is success mostly driven by a technical edge or breakthrough, or does it come down to the community management that supports the project?

In my opinion, it’s primarily about the problem your project solves, the pain it alleviates, and then how genuinely invested you are in your community.

If your project doesn’t bring anything useful to the table, it won’t attract a community in the first place. That’s the end of the story.

[fion, a static tiling window manager inspired by ion, another Gilles’ project with a tasteful name]

If it does bring something valuable but you don’t care about the people using it, you might still have users, but they won’t be attached to it. They’ll use it while it works for them, but they won’t feel heard. They won’t be patient when problems arise, and if a competing project appears, they’ll switch without hesitation, and stay there if its community feels friendlier.

But if your project is useful and you genuinely care about your community, that’s when real bonds start to form. People feel connected and emotionally invested in the project. They’ll tell you when something is good or bad, they’ll understand when things take time, they’ll still be frustrated by bugs but also grateful when you fix them. And when a competing project comes along, they might try it, but they’ll be more hesitant to leave because they’d rather see you add what’s missing than lose the sense of belonging they already have.

I really believe it all comes down to how genuine you are, and that’s not something you can fake. If you truly care about your community, people notice. They see that you personally spend an hour helping them troubleshoot something instead of passing them to support. That kind of honesty and presence is what keeps them around.

How He Sees Technology and AI Today

What is a technical decision or bet you made early in your career that turned out to be completely wrong?

Having worked in open source and R&D for most of my career, I’ve done a lot of experiments and tested thousands of hypotheses that went wrong or against my intuition. To me, the best way to learn is by testing and failing. You can always somehow make something work, but you only understand how it works when you’ve seen the many ways it can fail. I once told my kid that my job was to fail a lot of things so my coworkers didn’t have to, partly to encourage him to try things instead of fearing failure.

That said, because of my personal history, I’m a very anxious and analytical person, which means I don’t leave much room for risk. I don’t take bets unless they’re highly calculated. For any significant decision, I build a mental decision tree and only move forward if the risk is reasonable, the consequences are low, and I have plans B and C ready on two levels in case things don’t go as expected.

You can always somehow make something work, but you only understand how it works when you’ve seen the many ways it can fail.

I honestly can’t think of anything that went completely wrong, not because I succeed at everything I attempt, far from it, but because I usually only make decisions once I’m confident things will turn out fine one way or another, and I rarely put myself in a position of total risk. I’ll admit it’s mentally exhausting, but I’m still working on improving myself and getting rid of those defense mechanisms. 🙂

My colleagues would probably confirm that one of the words they’ve heard most from me is “de-risk,” as in, “no, I’m not convinced, we need to de-risk this with a PoC before we spend time in that direction.” Sometimes, this is annoying to others as they may themselves have high confidence, but the upside is that when I agree to take a direction it’s generally because I have a very very high confidence that things will eventually work regardless of the challenges found on the way.

In your opinion, what has been the biggest technological breakthrough in recent years, the one in the technical field that truly blew your mind?

In my opinion, AI development in general, and large language models in particular, are the biggest technological breakthroughs since the invention of the Internet.

I could look at it pessimistically and focus on the downsides: we’re burning forests worth of energy to generate funny videos, it’s being used for military purposes, it produces bad code, hallucinates, gives wrong answers with high confidence, and can fail miserably on simple questions.

But I tend to look at it more optimistically. Once the novelty wears off, and we stop using it mainly to generate funny videos and pointless contents, given the mind-blowing rate at which it improves, it has the potential to help solve problems that are otherwise very hard or even impossible to tackle without it. It’s already helping with early cancer detection and has contributed to breakthroughs in several scientific fields, medicine, biology, physics, mathematics, mostly because it can search and correlate our collective knowledge far more efficiently than humans can on their own.

Once the novelty wears off, and we stop using it mainly to generate funny videos and pointless contents, given the mind-blowing rate at which it improves, it has the potential to help solve problems that are otherwise very hard or even impossible to tackle without it. 

As for the ecological cost, unfortunately there’s no going back. The only way forward is to make the technology more efficient and use it in smarter ways, ideally to help find solutions to the very problems it contributes to. Political will probably won’t fix that, better engineering might.

When the field itself changes every few months, how do you make architectural decisions? What is your framework for deciding what is worth building for the long term?

Tech evolves quickly, but most of us aren’t working on problems that require reinventing everything every six months. In my experience, most new challenges are just variations of old ones wrapped in new terminology. The core ideas, isolation, modularity, simplicity, clear data flow, haven’t really changed in decades.

For a concrete example, I’ve worked on very different systems over the years, a mailing system, distributed storage, a database, a payment platform, a proxy for LLM providers, and of course, Plakar. In each of these cases, I had to implement things like a persistence layer, a cache layer, a routing engine, a scheduler, etc. Each time, they had different names, served different purposes, and operated at different scales, but from an abstract perspective, they were all solving the same kind of problem. The technology changed, the details changed, but the core ideas stayed the same. Once you understand the underlying patterns, everything else is just a matter of adapting them to new contexts and constraints. That’s why I try to focus on fundamentals, because the tools and frameworks will keep evolving, but the principles rarely do.

The technology changed, the details changed, but the core ideas stayed the same. Once you understand the underlying patterns, everything else is just a matter of adapting them to new contexts and constraints. 

When I make architectural decisions, I try to think in terms of boundaries and contracts, not implementation details. I design black boxes that take input and produce output, and as long as the interfaces are clear, the internals can evolve freely. That way, when the field shifts, a new database appears, a language gets deprecated, or a framework falls out of fashion, we can swap the internals without rewriting everything.

I also rarely care about designing the full system upfront, because constraints and requirements always change during development. Instead, I focus on making sure that each component’s inputs and outputs are complete and well-defined. That way, I can work confidently on step one without knowing exactly what step ten will look like, because whatever step ten ends up being, the information it needs will already be available, the challenge will just be figuring out how to pass it efficiently.

For long-term decisions, I focus on things that age well, clarity, portability, and simplicity. If a design still makes sense when you explain it on a whiteboard five years later, it’s probably a good one. And if it depends too much on something trendy or too specific, I’ll usually look for a way to decouple it before committing.

In short, the framework is to build systems that can survive change by being simple enough to adapt to it.

Plakar addresses a very deterministic problem, backup. So most of your work right now seems focused on algorithms, compression, and related technical challenges. Has AI had any impact on your work so far? And if not, do you think it will eventually play a role in your company?

To say it had no impact would be a lie, if only because I now tend to ask ChatGPT for documentation instead of going through search engines. That alone saves me a lot of time every day. I also often ask it to suggest rephrasings or remove repetitions in texts I write, yes, including for this interview. 🙂

When we’re tackling a new task, I’ll often ask ChatGPT if it knows of any existing solutions to the problem, just to gather sources and references. But if we have to come up with our own approach, we almost never rely on it, the results are almost never good enough for real use in anything too specialized or new.

AI already plays a role in our company, but mostly in side aspects, not in the core technology. If we lost access to LLMs tomorrow, it would be annoying because we do use them, but it wouldn’t have any real effect on our projects, except that I’d have to do some of the boring administrative tasks manually again, and that would definitely hurt my morale more than our roadmap.

Many argue that software quality is going through a crisis (The Great Software Quality Collapse). AI may not be the only culprit, but it is certainly part of the picture. What are your thoughts on this, and more generally, on the future of the discipline(s)?

While I agree on some aspects, I have a different take on this.

I do think code quality can always be improved, but I don’t agree with the idea that we’re in some kind of crisis. Ever since the 90s, people have been complaining about bloated software eating up RAM, hogging CPU, and freezing machines with blue screens. It’s nothing new. I’m old enough to remember when the entire industry panicked about Y2K because of the brilliant idea of encoding years with two digits. If an entire industry was collectively worried about something that trivial, we can probably agree that high quality wasn’t exactly the norm back then either. If there’s a crisis, then it’s one that’s been going on for more than thirty years.

I’m old enough to remember when the entire industry panicked about Y2K because of the brilliant idea of encoding years with two digits. If an entire industry was collectively worried about something that trivial, we can probably agree that high quality wasn’t exactly the norm back then either. 

As a teenager, I spent nights poking at software bugs with my very limited skills, things I probably couldn’t reproduce as easily today, even with much more experience. The quality of software in the 90s and 2000s was objectively worse. There were fewer developers, less shared knowledge, and far less awareness of secure or maintainable programming practices. Software wasn’t better, it just failed differently. And just like today, certain industries back then still managed to produce high-quality, dependable systems.

That said, I do think software quality has degraded in another sense, not because people have become worse programmers, but because the landscape has changed. The barrier to entry for becoming a developer is much lower than it used to be, while the systems we work with have grown exponentially more complex. That’s not necessarily a bad thing, a lower entry cost means more people are drawn to the field, which is great. But it also means we now have a generation of developers building on abstractions so deep that they rarely see what’s actually happening underneath unless they’re very curious. At the same time, many people now enter the field not out of passion, fighting through the early struggles because they had to understand, but because it’s a reliable career path with good pay. There’s nothing wrong with that, but it does change the relationship people have with the craft.

When I began programming, installing Linux was an achievement in itself. You had to think about swap size, sysctl tuning, and every bit of available memory, because starving a machine with a single CPU and 1 GiB of RAM could happen fast. You didn’t have fast NVMe disks either, so you had to consider the impact of every syscall on I/O and how easily it could bring your performance to a halt. You could also trust the environment to be honest, if you asked how much CPU or RAM was available, you got the real numbers. And on top of that, you wrote code knowing it had to build and run on different systems and architectures, some older and far less efficient than others.

Very few students today can reason comfortably about complexity (...). That doesn’t make them bad developers, they often impress me with how quickly they grasp higher-level concepts that I struggle with. But the low-level understanding that used to ground everything has become fragile.

Today, you install an operating system with a few clicks, everything’s pre-configured, and machines come with dozens of cores, absurd amounts of RAM, and insanely fast disks. You usually write code for just a handful of modern systems, all fairly similar in performance. And when your laptop has 14 cores and 64 GiB of memory, it’s easy to forget why resource management matters. Unsurprisingly, it’s no longer a major focus in computer-science programs.

In my experience, very few students today can reason comfortably about complexity, memory allocation, or concurrency beyond what their frameworks handle for them. That doesn’t make them bad developers, they often impress me with how quickly they grasp higher-level concepts that I struggle with. But the low-level understanding that used to ground everything has become fragile. Add to that how virtualization and containers can lie about available resources, or how modern languages hide complexity behind magic, and the distance between code and the machine keeps growing.

When I first looked at Go, for instance, someone told me, “Just spawn goroutines, they’re cheap, you can have hundreds of thousands, don’t worry, the runtime handles it.” That mindset assumes infinite resources and ignores trade-offs entirely. The tools are more powerful than ever, but the awareness of what they cost has faded.

My only real concern today is with AI giving the illusion of quality. Over the past few years, I’ve seen the same pattern repeat itself, both in classrooms and in professional settings. When I teach programming, I allow students to use ChatGPT, not as a code generator, but as a tool to help them understand their mistakes.

The outcome has been remarkably consistent: most people copy and paste whatever ChatGPT produces, assuming it must be correct because it works. But that “it works” only applies to the optimistic path. The code runs once, under ideal conditions, with no real error handling. Yet it’s often the error handling that defines a good program, the way it behaves not only when everything goes as expected but when things inevitably don’t.

I’ve noticed the same thing in professional contexts. People use AI tools to speed up development, but often take the generated code at face value, trusting that it’s good enough. The results usually work for the happy path but fail spectacularly in edge cases, and debugging AI-generated code that no one fully understands can quickly turn into a nightmare.

It’s something you learn quickly once you stop copy-pasting and start thinking about how your code can fail. But fewer people seem to go through that learning process now, because the tools make it so easy to skip it entirely. The tools are improving fast, but the understanding beneath them is fading just as quickly.

AI didn’t create this problem, people were already copying blindly from Stack Overflow long before it existed. But AI has made it so much easier that it accelerates and amplifies the root issue, a growing disconnect from the foundations. You no longer have to truly understand what you’re doing, because code that appears to do what you want is always just a click away. You never struggle long enough for the light bulb moment, the one where you finally understand why something works.

So to summarize, I don’t think we’re in a crisis yet, but we’re definitely heading toward one. The pool of people who truly understand how to write robust, high-quality code is shrinking. As a result, the data being fed into AI systems is increasingly poor, which will in turn lead AI to generate even worse code. That cycle will eventually produce failures that people can’t reason about, because they’ll lack the fundamental skills to diagnose and fix them.

AI didn’t create this problem, people were already copying blindly from Stack Overflow long before it existed. But AI has made it so much easier that it accelerates and amplifies the root issue, a growing disconnect from the foundations.

The wake-up call will probably be harsh. But humans are resilient, they often need to hit a wall before they change course. My guess is that we’ll see some very bad incidents before the industry realizes we need to bring back the foundations, to teach students, and remind professionals, the skills that actually make software trustworthy.

And to finish on a lighter note, what is your current stack? What do you love using day to day?

It varies from time to time.

Until a couple of years ago, I spent most of my time working on a fairly old laptop running ion3 as my window manager and Emacs as my IDE. I really liked that setup, it never got in the way and stayed exactly the same for almost two decades.

These days, I primarily work on macOS because I’ve been doing more music-related work, and it’s simply better suited for that. But every now and then, I still find myself going back to OpenBSD. Some habits die hard.