Programming Languages Still Matter -- AI Changes Why

Dev Leader Weekly 160

Oct 11, 2026

TL; DR:

AI reduces friction, not engineering responsibility
Pick languages for the problem you’re solving
Unfamiliar stacks still need credible validation
Join me for the live stream (or watch the recording) on Monday, October 12 at 7:00 PM Pacific!

Are Programming Languages Dead?

I came across a question on the experienced developers subreddit: With AI writing more of our code, does the programming language even matter anymore?

My answer? Yes. But I think the reasons we choose a language are changing.

That is a different conversation from declaring programming languages dead. AI can make an unfamiliar stack more accessible without making every stack interchangeable. It can help you build something without magically removing your responsibility for what you ship.

And honestly, I think that distinction is pretty exciting. We have more options. We still have decisions to make.

You can check out my full thoughts on this in the video below:

The Best Language Is Not Always the Best Decision

Imagine you have eight engineers. Seven are comfortable in one language, and one knows another language that looks like a better technical fit.

Do you automatically choose the technically better fit?

I wouldn’t.

Maybe that language gives you more performance. Great. But if adopting it significantly slows the team down, you have to weigh that against getting the product into people’s hands. A performance advantage does not help much if you never ship anything.

It is the same kind of thinking that makes me question whether a tiny product needs Kubernetes and microservices before it has a single user. You might be optimizing something that isn’t your actual problem.

Historically, team familiarity has been a pretty significant part of that tradeoff. I think it still belongs in the conversation. AI just changes how much friction an unfamiliar language introduces.

It doesn’t reduce that friction to zero. It gives us another way to work through it.

I’ve Built Things in Languages I Don’t Know

C# and .NET are usually my tools of choice. Not because I think they’re the best answer to every problem. I’ve used them for a long time, they’re well suited to a lot of what I build, and I can get things done effectively with them.

But I’ve also used Copilot to build MCP servers in Go. I hadn’t written Go before. I wasn’t purposefully reading Go code either.

Why choose it?

For those little servers, I liked the smaller package and the ability to distribute something that could just run without asking the user to install additional dependencies. Could I bundle dependencies with .NET? Absolutely. Go wasn’t the only viable answer.

The difference was that I could consider it without first deciding to spend a bunch of time learning Go just to build an MCP server.

I’ve also built things in Rust with AI. For those projects, performance and dependency-free distribution were characteristics I wanted to lean into from the beginning. Did the projects absolutely need Rust? No.

AI made the choice accessible. It didn’t make the choice mandatory.

There is an important caveat here: These were side projects, not mission-critical systems with tons of paying customers. A bug in one of those MCP servers is not the same kind of problem as an outage in a service people depend on.

That distinction matters. Building a game with AI still left me responsible for checking what it produced. A different language doesn’t change that relationship.

Actionable Tip: If you want to try an unfamiliar stack, pick a small project where a mistake is recoverable. Be explicit about what you want to learn and what level of risk you’re accepting.

Your Team Still Has to Own the Result

I’ve lived through a team adopting Rust for a new product because its language characteristics were a good fit. The engineers didn’t have prior professional experience with it, and the decision included accepting that development would take longer while they learned.

That was a tradeoff, not an oversight.

With AI, I think a decision like that can become easier to make or rationalize. You have tools that can help engineers navigate unfamiliar syntax and implementation details.

But you still need to ask: How confident are we in the software we’re building?

If your team isn’t comfortable having agents generate code in a stack nobody understands, that is a meaningful constraint. Don’t pretend it disappears because someone says the models are getting better.

If something goes wrong, your customers aren’t going to accept, “Well, the agent wrote it.” Neither is your boss.

You own what you ship.

I’ve talked about deciding what part of software development you keep when AI writes the code. For this conversation, accountability is one part you don’t get to hand away.

Actionable Tip: Before adopting a new stack, answer three questions with your team:

What benefit are we choosing it for?
How will we establish confidence that it works?
Who can diagnose and recover from a failure?

If the answers are vague, generating more code isn’t going to make them clearer.

Syntax Familiarity and Technical Fit Are Different Things

I don’t particularly enjoy reading Rust. That’s my personal preference, not a verdict on Rust as a tool.

With AI doing more of the implementation, I can put less weight on whether I enjoy the syntax and more weight on whether the technology fits what I’m building.

That doesn’t mean software engineering knowledge stops mattering. I’ve been programming for a couple of decades. I’m still defining what I want the product to do, thinking about the architecture, and deciding how systems should integrate.

I’m changing how the code gets written. I’m not abandoning those decisions.

The ecosystem matters too. If you’re building a web application, you might choose TypeScript or JavaScript because the libraries and tooling fit your needs. That isn’t a claim that Rust, Go, or C# can’t do the job. It’s a reason to look beyond the syntax.

Sometimes you don’t need to move your whole application to another stack at all. Connecting a C# application to a separate agent runtime is one example of keeping a familiar application boundary while using another technology where it fits.

And an existing product is a different decision from a greenfield project. AI helping with a port doesn’t automatically make a rewrite worth doing. There still needs to be a reason to incur that cost.

Confidence Needs Something Behind It

When I say you need confidence in how the software is built, I don’t mean you need to feel impressed by the output.

I’ve had an AI model catch useful bugs while review loops expanded the scope and time. Those two things can both be true. A tool can be valuable without every behavior being something you want.

So if you’re using an unfamiliar language, give yourself something concrete to evaluate.

Can you run the result? Can you check the behavior you actually need? What happens when an input is wrong or a dependency fails? Does the packaging advantage you chose the language for actually show up?

For example, testing a processing pipeline means checking faults, cancellation, and cleanup, not just confirming that the happy path returned something. The implementation language might change, but those kinds of engineering questions don’t go away.

Actionable Tip: Build one small, end-to-end slice in the proposed stack. Evaluate the characteristic that motivated the choice, and exercise a failure path. Use that evidence to decide whether to expand the experiment.

Where I Think This Goes

My hypothesis is that knowing a language’s syntax will matter less in our decision to use it as these tools become more capable.

Not that every language becomes equally good at everything. Not that everyone suddenly stops writing code. And definitely not that knowing how to engineer software becomes irrelevant.

I think we get more room to choose based on the problem rather than being boxed in by which syntax we already know.

Could programming languages eventually be designed more around agents than humans? Maybe. I’m curious about that, but I don’t know enough about LLM training to make a strong claim about what would actually work better.

That is a thought experiment, not something I’d use to justify a technology decision for my team.

For now, my position is pretty simple: Programming languages still matter. AI is changing the tradeoffs around choosing them.

Use that flexibility where it helps. Keep the responsibility that comes with it.

Would you trust your team to ship something in a language none of you know well? What would you need to see before you’d be comfortable doing it?

Dev Leader Weekly

Discussion about this post

Ready for more?