Rebeca Murillo
EN·FR·ES

Hard truths about being a polyglot programmer

· by Rebeca Murillo

Introduction

I learned to program in Caml, COBOL (on AS/400), C and Assembly in the same school years. I actually enjoyed understanding how to speak to a computer at a low level. I enjoyed COBOL and the AS/400 with its no-mouse environment: navigation was complex, but the focus on a single screen was simple at the same time.

What came after is the part that counts today. Java, for highly scalable and typed systems. Kotlin, for modernizing Java. Node.js, for web projects. Python, for data handling and scripting. And PHP… which mainly taught me why Node.js is better for the web (sorry, not sorry).

Nowadays there is a lot of writing about why you should be a polyglot programmer in the age of AI, but there is not enough about its cost. The industry with AI coding will most likely push developers to be polyglot anyway, whether they choose it or not. If this is a path you’d like to pursue, what matters today is to have a strategy for what to learn and explore, instead of focusing on a specific programming language or stack. This is also a way to use AI as a learning tool, instead of letting it think for you.

After almost 3 years, I’m bringing back my learning notes to the blog, starting with some nostalgia after more than 10 years in tech.

#1 The mental load and the context switching

By the end of a working day, the context switching can be exhausting (one of the main bottlenecks with AI development). What I tend to do to avoid this is simply organizing my days per stack and per project — one day, one context. For me it has proven to be more efficient than spreading four projects across five mornings, and it is the change that helped me the most (even before AI).

AI has made this lighter though, since tools like Copilot in the IDE hold the syntax I no longer keep in my head, which leaves room for other concerns.

Another hack is choosing a practical and maintainable stack, and here I got it wrong for a while. Personally, I avoid highly opinionated SSR frameworks like Next or Nuxt; I feel those frameworks make simple websites complex to maintain. I prefer Astro now, since it has a setup feel close to a raw HTML website, which is simpler for the mental load. By the way, this blog runs on it, as I shared in the Astro Starter Blog I18n template post.

#2 The lack of depth

As a generalist, sometimes you learn the depths of a language or a framework when you encounter real problems with it. Performance, caching, security… not from the documentation or from a course, but from a real production incident.

The truth is that I do not go that deep into the technical ecosystem of every language or stack I use. There is not enough time in one career to do it five times over.

I’ve seen teams build an API in Node.js because it is faster to develop, but once it scales and hits large volumes of data and API calls (along with other maintenance issues), the need to migrate to a more stable and performant ecosystem like Java becomes clear.

This is where AI has been the most impactful for me, provided that there is a process and orchestration around it. I use AI as an expert on different domains, for example:

  • to investigate and benchmark solutions,
  • to develop small PoCs to compare performance (sometimes just out of curiosity),
  • to review and challenge my approach,
  • to upgrade an obsolete version of a library or framework (a painful and costly process),
  • and to find edge cases beforehand rather than in production.

Asking an AI model something gets you an answer (sometimes too affirming, depending on your provider); asking it to argue against an idea or plan gets you the depth of expertise you did not have time to build while learning something in the process.

#3 The job search and the impostor syndrome

This is the one AI cannot fix, unless you use it as a motivation coach…

Every job hunt in previous years brought back the same sentence: You do not have X years in Y stack or We are looking for someone with more experience in language Z. It comes up in the interview, and after enough rounds you carry it with you. Impostor syndrome, topped up on a schedule by the market and by recruiters with closed specifications.

Job titles do not help. They try to put people inside boxes that a polyglot programmer’s CV hardly fits.

What I have come to think is that the right role is a match, not a filter. It is a mix of the company’s size (a start-up vs a big company), the product’s life stage (an MVP or new project vs an established one), its goals, and finally the candidate’s skills. When those line up, the years-per-framework question stops being the blocker.

The practical answer is to build something in public: side projects on GitHub, writing, open-source contributions. They will not get you past an automated filter, but they give a person something to read instead of a count. This post is part of that process.

AI as a learning tool, not to think for you

Robert C. Martin has been making the loud version of this argument: that AI out-codes you and you should deal with it, and that you should not read code any more. The Hacker News thread on the second one is worth as much as the post. Whether or not you agree with him, some senior engineers are not writing code any more, and that is a real industry change.

I have been testing and improving agent pipelines, with different frontier models and with open-source ones. The result was not symmetrical. For high-capacity frontier models, a good AGENTS.md file is sometimes enough to deliver good code or at least a working feature. For open-source models, as of September 2026 (Qwen, DeepSeek), the orchestration of the pipeline is the key to good results; in some cases, giving too much context is a killer. The smaller/cheaper the model, the more the structure has to come from an orchestration system around it to get good enough results.

More important than the language or technical stack, a well-structured and documented project gets better results from an agent than a badly structured one. AI can be leveraged to learn and apply high-quality coding best practices that have been proven across the years and across the industry:

  • Clean architecture and clean code practices keep AI agents focused on one layer at a time during TDD,
  • TDD practices for AI agents, so that every new piece of code is tested with the right scenarios,
  • quality gates as guardrails — unit tests, integration tests, E2E tests, performance tests, code coverage standards… these keep AI agents on track and improve results.

What to learn instead of a language

To sum up, a non-exhaustive list:

  • Understanding how systems work.
  • Systems architecture.
  • Clean code / clean hexagonal architecture / SOLID practices…
  • TDD and BDD design practices.

These practices survive every language or stack you’ll learn.

The focus today should be understanding how systems interact with each other, and why one language or stack is best suited to a problem. If every language in this post is forgotten in twenty years (the way Caml and COBOL nearly are), the critical thinking and the high-quality practices will (hopefully) still hold.