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 during my 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 I learned later the part that counts today for my career path in Software Engineering. 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 (“AI Coding Agents Are Removing Programming Language Barriers”). 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 structured and performant ecosystem becomes clear. The target migration environment is benchmarked based on real life behaviours and problems, like how Uber went from Nodejs to Go language due to technical requirements, which are sometimes difficult to foresee at the beginning of a project.

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 (maybe) if you use it as a motivation coach…

Every job hunt in previous years brought back the same sentence during or after the interview : You do not have X years in Y stack or We are looking for someone with more experience in language Z. After enough rounds you carry it with you.

Job titles do not help neither. They try to put people within boxes that a polyglot programmer and curious engineer’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. This blog titled The Years of Experience Myth blog deserves a read for the sceptical ones.

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.

I also joined early start-up Les Martines as technical co-founder, to develop and maintain the mobile application. The role is perfect for me, as a side project for now, to be constantly learning and innovating with a real impact and purpose the community built within the app.

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 (with a good codebase) or at least a working feature (Context-Augmented Code Generation: How Product Context Improves AI Coding Agent Decision Compliance by 49%). 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 and BDD practices for AI agents, so that every feature is clearly designed and every new piece of code is tested with the right scenarios (How test-driven development amplifies AI success),
  • quality gates as guardrails — unit tests, integration tests, E2E tests, performance tests, code coverage standards… these keep AI agents on track and improve results.

Understanding even the basics of these practices can help you build robust systems. Coding AI agents also perform better under well structured environments. These practices survive every language or stack you’ll ever learn.

The focus today should be understanding how systems interact with each other, systems architecture and protocols, and why one language or stack is best suited to a problem. If every programming language mentionned 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.