I have been in and out of software development since the late 1980s. Somewhere along the way, like many developers, I acquired more responsibility, more meetings, and less time actually building things. You move into management, then executive leadership, and eventually your relationship with code consists largely of asking other people when it will be ready.
It is October 2026, and I am back at it.
This week, instead of settling into Python or C, I spent time getting up to speed with Rust, Go, TypeScript, and the tooling around them. I expected some catching up. What surprised me was how quickly I found myself questioning the purpose of the exercise. How much of each language do I need to master? How much do I need to understand well enough to direct an agent and evaluate what comes back?
Did George Martin need to play guitar, bass, and drums as well as the Beatles to produce their records? The creativity is still there. Some of it has moved up a level, has it not?
If you were once a hands-on developer and woke up Monday wondering what happened to your profession, I suspect you have your own version of that question. Some of our instincts were still useful twelve months ago. Now we get to examine which ones still serve us. I am about as excited as a child on their birthday!
Consider a familiar piece of advice: the best programming language is the one you already know.
That was a reasonable answer when learning another language could consume much of the time available to solve the problem. Your familiarity affected delivery dates, hiring, debugging, and whether anyone could maintain it afterward.
It is becoming a less satisfactory answer when an agent can do much of the implementation in a language you would previously have ruled out.
The old advice has lost its right to end the discussion.
We used to build identities around this. You were the Ruby person or the C# person. And somewhere in the organization was the person who could open gdb, follow the execution into territory nobody else wanted to visit, and explain why the supposedly impossible bug was happening.
I still want that person around. The valuable part was always the ability to investigate a system until its behavior made sense. Knowing how to use the debugger helped, but knowing what to investigate was the real skill.
Photographers have a similar answer when asked about the best camera: the one you have with you. Access matters. A wonderful camera sitting at home cannot take the photograph in front of you.
Agents change which tools we effectively have with us. More languages become practical options. But having access to every camera does not tell you where to point one.
Choosing a language when more languages are available
When you remove much of the manual coding from software development, a surprising amount of the job remains. Someone still has to understand the problem, decide what belongs in the system, establish acceptable behavior, and live with the consequences.
What is new is how much of the implementation we can delegate, and how quickly we can try an idea that might previously have stayed in a notebook. Of course, the same system can misunderstand the assignment and produce a very convincing explanation of its success. We need to know how to tell the difference.
That changes what I want from a language.
I would start with where the software has to run, what it must integrate with, and how it is allowed to fail. A browser application, a small operational script, and a component processing untrusted network traffic have different requirements. The availability of an agent does not make those differences disappear.
Then I would examine the libraries, deployment environment, diagnostics, and people who will own it. An agent may make a new language affordable to try without making a new production ecosystem affordable to maintain. If we already operate a dependable service in Go, generating its replacement in Rust is not, by itself, a reason to migrate.
The interesting change is how I weigh the effort of writing against the effort of establishing correctness. A language that asks for more explicit structure may become more attractive when the agent supplies that structure and the tools check it.
This is where static types get interesting.
A compiler or type checker gives the agent feedback that does not depend on whether its explanation sounds plausible. Define an interface, make the expectations explicit, and certain mistakes can be rejected before the program runs. I expect that feedback to become more valuable as the volume of generated code increases.
Rust adds ownership rules checked by the compiler to govern memory use. That is a concrete property I can consider when choosing a language for a component where memory safety matters. It is more useful than an agent assuring me that it was careful. (Rust’s ownership documentation)
But “typed” is not a synonym for “correct.” TypeScript’s type annotations are erased; they do not validate whatever arrives over the network at runtime. And a perfectly well-typed program can still give one customer another customer’s records. The business rule has to be expressed and checked somewhere. (TypeScript’s documentation)
I would therefore give enforceable constraints more weight, without declaring a universal language winner. A short Python script may remain the most sensible solution. We should be able to explain the choice in terms of the work.
Does the model have a favorite?
Then there is the other participant in this decision. Does the model work better in one language than another?
I would not ask it to settle that question by describing its preferences.
Whether I am using Qwen or another model, I want to know how this particular version performs on the kind of work I need done, with the tools and context I can provide. Familiarity with syntax is only part of that. Can it navigate the repository, use the libraries correctly, interpret failures, and repair its changes without breaking something else?
Cross-language evaluations such as SWE-bench Multilingual are useful evidence, but their results come from particular tasks, repositories, and agent configurations. They do not establish the best language for my next project. (Benchmark description)
I would take a small, representative piece of the actual problem and try the credible options. Include an awkward failure case. Then change a requirement. Watch what happens when the first answer needs work.
Measure the time and cost to reach an acceptable result, including human review and correction. A demo generated in five minutes can create several hours of investigation. That time belongs on the bill.
We are evaluating the combination of model, tools, language, and operating environment. Changing one can change the result. You probably see where I am going with this: we have to think about the system from end to end. That has always mattered, but agents make it much easier to move beyond our individual specialties. Why bring the silos with us?
This also argues against choosing a long-lived architecture around one model’s apparent strengths this month. Models will change. The service still needs an owner.
Who am I hiring now?
That brings me back to the people.
Ten years ago, many interviews asked candidates to demonstrate what they could produce alone, under time pressure, without the tools they would normally use. Language trivia and whiteboard exercises became convenient ways to compare people.
If the job now includes directing agents, we should observe candidates doing that work.
I would give someone an unfamiliar repository, access to an agent, and a bounded change with an incomplete requirement. I would want to see what they clarify before starting, how they establish that the change works, and what they do when the agent offers an attractive but incorrect solution.
Then I would change something. Perhaps the request can arrive twice. Perhaps the caller belongs to another tenant. Perhaps the dependency is unavailable.
Does the candidate understand the implementation well enough to predict the consequences? Can they find evidence? Will they challenge the agent, or simply ask it to reassure them?
Knowing an agent harness matters: its context, permissions, tools, and feedback all affect the work. But I would be wary of replacing “knows framework X” with “knows agent product Y” and calling that a new hiring strategy. We would have exchanged one narrow filter for another.
I still value technical depth. It gives someone a way to recognize when a plausible explanation conflicts with how computers actually behave. I also value the willingness to enter unfamiliar territory and learn enough to take responsibility for it. Those qualities can exist in a veteran developer or someone early in their career. The interview should give both a chance to demonstrate them.
The development lifecycle deserves its own post. For now, I would retire ceremony only where its purpose has disappeared. Generating an implementation faster does not remove the need for requirements, testing, security, or recovery. It does create a need to control what agents can change and to verify outcomes independently of their own reports.
So yes, I am still learning Rust, Go, and TypeScript.
I want enough understanding to make informed choices, read consequential code, and recognize when I need deeper expertise. The agent lets me begin useful work sooner. It also makes it easier to get further than my understanding can support.
That brings me back to George Martin. Producing a record takes musical judgment and imagination. You have to hear what the parts could become together, and know when something needs another take. I see a similar opportunity in software. There is plenty of creativity in deciding what to build and helping all the parts work together.
For those of us returning from years of meetings, there is something wonderfully inviting about this moment. We can build again. Ideas that once waited for staffing or months of study are within reach.
Bring the experience. Reconsider the habits.
And when the agent tells you it is finished, know how you will decide whether it is right.
Mahalo for reading!
Aloha –TK
