Coding Is No Longer My Main Skill

Disclaimer: The following reflects personal opinions based on experimentation outside of work.

My Story (the boring part)

I started coding at 13, first in C and later in x86 Assembly, learning mostly from books and magazines. I almost skipped university, out of naivety and overconfidence. Although I didn't finish my degree, I'm glad I went. In hindsight, the most valuable thing CS studies gave me was not specific knowledge, but a way of thinking: learning how to approach and adapt to very different problems.

Over the years, my professional work took me through many languages and ecosystems: from C, ASP, and VB6, to C#, PHP, JavaScript, Ruby, Python, Java, TypeScript, and others [1]. I've never been attached to a single language or stack. The tools change, but the problem-solving requirement stays.

Until recently, I thought of my role as that of a software gardener. I don't invent entirely new species [2], but I plant systems, maintain them, prune them, and help them grow, so others can use them.

2022: The GitHub Copilot Inflection Point

This might be different for others, but for me, the "Coding revolution" began with the first versions of the GitHub Copilot VS Code extension. Despite being frequently wrong and hallucinating a lot of the responses to technical questions, the first magical sparks were there. I was faster autocompleting the code and I no longer had to search online for the Nth time "In Javascript, should I use contains() or includes() to find sub-strings?".

It got progressively better, other tools came, and you could begin to delegate to the tool (IDE or CLI conversation session) tiny method implementations, or throwaway code still valuable for prototyping.

It was no longer just me doing things, but actually using some LLM help here and there to be more effective.

2025: The Agentic AI Year

Early 2025, I tried the Cursor IDE, and it amazed me how good it was accepting instructions to build non-trivial chunks of code and to analyze a repository. I added it to my tool belt for months, switching back and forth between it and VS Code + Copilot to compare both.

At the same time, all CLI tools (Codex, Claude Code, plus newcomers like Gemini CLI or Copilot CLI) began to quickly improve and adopt any feature that the competition introduced. And people were already experimenting with having multiple terminals with multiple "agents", orchestrating multiple LLMs and the like. So, first Claude Code and now I think everyone, ended up introducing the concept of subagents: You can have multiple specialized roles, and the main agent can spawn one or more subagents, each with their own context memory, and handle communication and coordination.

This apparently small step forward initially sped up the tools: "multiple threads" equals e.g. faster searches, and in general concurrent work whenever possible. But the agents were still faulty, so at least in my experience, delegation of tasks was restricted, always requiring very detailed markdown specs, robust existing tests (or building those with careful guidance). The models already were quite good for example transpiling code from one language to another, but I dreaded the "vibe-coding" trend. The models would still struggle to reach correct solutions, and when they did, you could already see them taking shortcuts to get there: adding lint exclusions, hacking failing tests to make them pass, or claiming to have run tests when they hadn't.

Then, during Q4 Anthropic progressively launched the 4.5 Claude models family, and everything changed.

January 2026: The Present

Some people joke that coding assistants is like having "a brilliant PhD junior developer that at times suffers amnesia". With the 4.5 modes (Sonnet and Opus), the analogy for me is now more like having "a quite proficient developer with massive context and recall, that at times takes hacky shortcuts to finish the task at hand". You still need to review the code that they generate or think about the proposals they make, as they will offer hacks and shortcuts, and by default generate decent-but-not-great code, but it is a significant jump on what they can do. It is no longer a question of if the coding assistant can do a task, but how well will it do it.

I began experimenting already in October, but I spent a non-trivial amount of time during my holidays actively letting AI agents code on my behalf, just based on prompting and technical specs.

Based on my GitHub activity and recent blog posts, you can deduce that these past months I've done a few migrations and plenty of tiny improvements and new features. I also rebuilt a lot of personal little tools, and I have spawned a few pet projects (on early stages yet). The agents still need revision and guidance [3], specially when they begin with a blank state (because they are so damn good at mimicking existing code structure, test patterns and similar), but I now feel like when in the past I would mentor and lead a small team of junior engineers. Given good instructions, they can work on their own, and I review, point out mistakes, and we iterate.

I now 100% think that we are in a career-changing point, for better or worse. This is no longer a shift like when IDEs got autocompletion. This is at minimum a shift from coding in Vim or Emacs (without any plugin) or Notepad, to the advent of IDEs in the late 80s and early 90s. Eventually, it is going to be used everywhere that code is created.

I am on purpose being agnostic with terms like "be used", vs e.g. "become the only way", because I am not yet convinced that it can be fully automated. At the current pace, it might happen, but we could also reach a tipping point soon, and yet end up with an amazingly useful tool that allows to improve a lot a typical development workflow. Even if frontier labs get greedy and expensive, and we need to switch to open-source models, those will eventually match at minimum what we have now in terms of quality. Basically, I don't see any scenario where we really stop and go back to the pre-LLMs era.

The same as some people can still build code using a pure text editor and a compiler, you will be able to keep not using agentic coding assistants. The question is, will you disregard the effectiveness boost that they provide?

I don't know yet whether we'll ever be fully hands-off, but at this point I spend noticeably more time defining specs and prompting than writing code myself.

Conclusion

For me, the joy of software development was never about typing code in one language or another. It has always been about creating and building things. And I'm enjoying learning how to craft and improve agents, while going back to mentoring... tiny little agents 🤖 [4]

Footnotes

[1]: The only languages that seem ever-present in my toolchain since I first used them are Python and JavaScript. And of course SQL for databases.

[2]: Although I've done a thing or two about which I feel quite "technically" proud of.

[3]: Haiku 4.5 is blazing fast, but only recommended for autocompletion-like tasks, as it is too prone to misbehaving after a few interactions/cycles; Sonnet 4.5 is my new default and quite powerful; and Opus 4.5 is a monster, excellent even when given less precise instructions (or debugging non-trivial problems), but slower and expensive.

[4]: In fact, not so tiny. 😄 But tiny regarding "locally" being a small collection of markdowns and scripts.