> what if the most important professional “developer skill” to learn or improve is how to effectively use coding agents?

Well, it's not. There's a small moat around that right now because the UX is still being ironed out, but in a short while able to use coding agents will be the new able to use Excel.

What will remain are the things that already differentiate a good developer from a bad one:

- Able to review the output of coding agents

- Able to guide the architecture of an application

- Able to guide the architecture of a system

- Able to minimize vulnerabilities

- Able to ensure test quality

- Able to interpret business needs

- Able to communicate with stakeholders

The endgame in programming is reducing complexity before the codebase becomes impossible to reason about. This is not a solved problem, and most codebases the LLMs were trained on are either just before that phase transition or well past it.

Complexity is not just a matter of reducing the complexity of the code, it's also a matter of reducing the complexity of the problem. A programmer can do the former alone with the code, but the latter can only be done during a frank discussion with stakeholders.

A vibe coder using an LLM to generate complexity will not be able to tell which complexity to get rid of, and we don't have enough training data of well-curated complexity for LLMs to figure it out yet.

> This is going to catch some heat, but what if the most important professional “developer skill” to learn or improve is how to effectively use coding agents?

If it does go as far that way as many seem to expect (or, indeed, want), then most people will be able to do it, there will be a dearth of jobs and many people wanting them so it'll be a race to the bottom for all but the lucky few: development will become a minimum wage job or so close to that it'll make no odds. If I'm earning minimum wage it isn't going to be sat on my own doing someone else's prompting, I'll find a job that involves not sitting along in front of a screen and reclaim programming for hobby time (or just stop doing it at all, I have other hobbies to divide my time between). I dislike (effectively) being a remote worker already, but put up with it for the salary, if the salary goes because “AI” turns it into a race-to-the-bottom job then I'm off.

Conversely: if that doesn't happen then I can continue to do what I want, which is program and not instruct someone else (be it a person I manage or an artificial construct) to program. I'm happy to accept the aid of tools for automation and such, I've written a few of my own, but there is a line past which my interest will just vanish.

I also remember a similar wave around 10-15 years ago regarding ML tooling and libraries becoming more accessible, more open source releases etc. People whose value add was knowing MATLAB toolboxes and keeping their code private got very afraid when Python numpy, scikit learn and Theano etc came to the forefront. And people started releasing the code with research papers on github. Anyone could just get that working code and start tweaking the equations put different tools and techniques together even if you didn't work in one of those few companies or didn't do an internship at a lab who were in the know.

Or other people who just kept their research dataset private and milked it for years training incrementally better ML models on the same data. Then similar datasets appeared openly and they threw a hissy fit.

Usually there are a million little tricks and oral culture around how to use various datasets, configurations, hyperparameters etc and papers often only gave the high level ideas and math away. But when the code started to become open it freaked out many who felt they won't be able to keep up and just wanted to keep on until retirement by simply guarding their knowledge and skill from getting too known. Many of them were convinced it's going to go away. "Python is just a silly, free language. Serious engineers use Matlab, after all, that's a serious paid product. All the kiddies stacking layers in Theano will just go away, it's just a fad and we will all go back to SVM which has real math backing it up from VC theory." (The Vapnik-Chervonenkis kind, not the venture capital kind.)

I don't want to be too dismissive though. People build up an identity, like the blacksmith of the village back in the day, and just want to keep doing it and build a life on a skill they learn in their youth and then just do it 9 to 5 and focus on family etc. I get it. But wishing it won't make it so.

Talented, skilled people with good intuition and judgements will be needed for a long time but that will still require adapting to changing tools and workflows. But the bulk of the workforce is not that.

Using a coding agent seems quite low skill to me. It’s hard to see it becoming a differentiator. Just look at the number of people who couldn’t code before and are suddenly churning out work to confirm that.

It absolutely is, but the fundamental misunderstanding around this seems to be that "effectively using coding agents" is a superset of the 2023-era general understanding of "Senior Software Engineer".

At least when you're talking about shipping software customers pay for, or debugging it, etc. Research, narrow specializations, etc may be a different category and some will indeed be obsoleted.

I think your argument is predicated on LLM coding tools providing significant benefit when used effectively. Personally I still think the answer is "not really" if you're doing any kind of interesting work that's not mostly boilerplate code writing all day.

Many of those skills have temporary value before they're incorporated into the models/harnesses

There was a moment we thought JS had won. And then crypto. I personally believed low-level development was done.

Not sure why this would catch heat rationally speaking. It is quite clear in a professional setting effective use of coding agents is the most important skill to develop as an individual developer.

It’s also the most important capability engineering orgs can be working on developing right now.

Software Engineering itself is being disrupted.

I'd offer an edit that the most important skill may be knowing when the agent is wrong.

There's so much hand wringing about people not understanding how LLMs work and not nearly enough hand wringing about people not understanding how computer systems work.

> This is going to catch some heat, but what if the most important professional “developer skill” to learn or improve is how to effectively use coding agents?

Doing so will effectively force a (potentially unwanted) career change for many people and will lead to the end of software engineering (and software as a career), assuming AI continues to improve.

"Effectively" using agents means that you're writing specs and reading code (in batches through change diffs) instead of writing code directly. This requires the ability to write well (or well enough to get what you want from the agent) and clearly communicate intent (in your language of choice, not code; very different IMO).

The way that you read code is different with agents as well. Agents can produce a smattering of tests alongside implementation in a single turn. This is usually a lot of code. Thus, instead of red-green-refactor'ing a single change that you can cumulatively map in your head, you're prompt-build-executing entire features all at once and focusing on the result.

Code itself loses its importance as a result. See also: projects that are moving towards agentic-first development using agents for maintenance and PR review. Some maintainers don't even read their codebases anymore. They have no idea what the software is actually doing. Need security? Have an agent that does nothing but security look at it. DevOps? Use a DevOps agent.

This isn't too far off from what I was doing as a business analyst a little over 20 years ago (and what some technical product managers do now for spikes/prototypes). I wrote FRDs [^0] describing what the software should do. Architects would create TRDs [^1] from those FRDs. These got sent off to developers to get developed, then to QA to get bugs hammered out, then back to my team for UAT.

If agents existed back then, there would've been way fewer developers/QA in the middle. Architects would probably do a lot of what they would've done. I foresee that this is the direction we're heading in, but with agents powered by staff engineers/Enterprise Architects in the middle.

> Edit: as an aside, I have learned plenty from reviewing coding agent generated implementations of various algorithms or methods.

People learn differently. I (and others) learn from doing. Typing code from Stack Overflow/Expertsexchange/etc instead of pasting it, then modifying it is how I learned to code. Some can learn from reading alone.

[^0]: https://www.modernanalyst.com/Resources/Articles/tabid/115/I...

I don’t think it could be the most important skill to have. The most common, and the most standardized one for sure, but if coding agents are doing fundamental R&D or running ops then nobody needs skills anyway.

> As it turns out, neural nets “won”

> The people who scoffed at neural nets and never got up to speed not so much.

I get the feeling you don’t know what you’re talking about. LLMs are impressive but what have they “won” exactly? They require millions of dollars of infrastructure to run coming around a decade after their debut, and we’re really having trouble using them for anything all that serious. Now I’m sure in a few decades’ time this comment will read like a silly cynic but I bet that will only be after those old school machine learning losers come back around and start making improvements again.

I'd say viewing it as most important is pretty unprofessional. But isn't it the point of this extreme AI push? To replace professional skills with dummy parrots.

I've worked for 35ish companies (contract and fulltime), largely on the west coast of the US. I have experienced the lip service, from the vast majority. I have experienced maybe 2 or 3 earnest attempts at growing engineer skills through subsidized admission/travel to talks, tools, or invited instructors.

Every company I worked for didn’t give a shit about my skills. They just wanted to solve the problem in front of them and if they couldn’t then they would hire someone in with the right skills. Improving my skills was seen as a risk as I might leave.

That’s been my experience, too. But now I get a sort of, “I dunno. Maybe don’t use AI on Fridays?”

There doesn’t seem to be a plan for maintaining that culture.

Given the rest of the paragraph, I believe the parent is trying to say that merely improving developer skills is not valuable to the company, not that improving developer skills cannot provide value in terms of improved work product, morale, retention, etc.

You must be lucky then.

The opposite is true in my case - though 1 organization that had a small budget for things like AWS certs. I remember almost everyone who would get those certificates would never really learn anything from it either. They would just take the exams.

Ah, but it's no longer "inexplicably!"

The evidence that software development cannot be automated is we already tried to do it in the 90s with OOP, UML, and outsourcing. It didn’t work out for the same reasons vibe coding isn’t working out — because building the system is the same as specifying it, and that is a creative iterative process.

We are at the point where sure ai can write code, but we could always do that; lack of code writing ability was not what killed the OOP automation efforts. There was plenty ability to code back then as well. The distinction of whether it’s an offshore team in India or Claude writing the code doesn’t change things as far as the larger picture of building the software.

We're witnessing a divergence between Coders and Clauders, with the latter dominating the market at a lower cost of labor + subscription fee to the almighty AI providers. Coders may be called in, hopefully with better renumeration, to review and debug the massive amount of code being generated. Either that or they will also be replaced by specially trained/prompted language models doing the review.

In the future Claude will keep a tight ship on dissenters. If your monthly quota doesn't exceed the 10k worth of tokens your employer will be notified and you will be flagged as a "dissenter". Your lease will be cancelled, because who would trust someone ignorant enough to not use LLMs in their daily life, and you'll be vetoed from the field for life, for clanker companies will proclaim that anyone who doesn't use LLM-assisted coding should be culled and so they'll run a tight ship.

And executives will get millions in bonuses for figuring it out, and the remaining programmers, probably one or two, will raise their necks over who's the best prompter and how everyone else was dumber than them for not figuring it out.

Yeah, the AI productivity gains are a myth in my experience.

> the generated code just annoys me and the agents are too chatty

I’ve eyerolled way less with Codex CLI and the GPT models than with Claude.

There is a deadly game of chicken going on. Junior recruiting already stopped for the most part. Only way this doesn’t end in a catastrophe is if AI becomes genuinely as good as the most skilled developers before we run out of them. Which I doubt very much but don’t find completely impossible.

How many kernel devs does the world need? A dozen or two?

It will be the same with software. AI will be writing and consuming most software. We will be utilizing experiences built on top of that, probably generated in real time for hyper personalization. Every app on your phone will be replaced by one app. (Except maybe games, at least for a short while longer).

Everyone's treating writing code as this reverent thing. No one wrote code 100 years ago. Very few today write assembly. It will become lost because the economic neccesity is gone.

It's the end of an era, but also the beginning of a new one. Building agentic systems is really hard, a hard enough problem that we need a ton of people building those systems. AI hardware devices have barely been registered, we need engineers who can build and integrate all sorts of systems.

Engineering as a discipline will be the last job to be automated, since who do you think is going to build all the worlds automation?

Trust me. All those people do it for the love of doing it, so I don't think they will outsource the jobs to some automation....

I have been coding long before internet and before there were huge demand for software devs..and I would be coding even after there is no demand for the same.

I feel I've upskilled in so many directions (not just "ability to prompt LLMs") since going all in on LLM coding. So many tools, techniques, systems, and new areas of research I'd never have had the time to fully learn in the past.

I have a hard time believing any tenured developer is not actually learning things when using LLMs to build. They make interesting choices that are repeatable (new CLIs I didn't even know existed, writing scripts to churn through tricky data, using specific languages for specific tasks like Go for concurrently working through large numerous tasks, etc.)

Anyone not learning things via LLM coding right now either doesn't care at all about the underlying code/systems, or they had no foundational knowledge or interest in programming to begin with (which is also a valid way to use these tools, but they don't work very well without guidance for too long [yet]).

>But the number will dwindle and we'll ironically be unable to build what our ancestors did, utterly dependent on the AI artifacts to do it for us.

That's only a brief moment in time. We learned it once, we can learn it again if we have to. People will tinker with those things as hobbies and they'll broadcast that out too. Worst case we hobble along until we get better at it. And if we have to hobble along and it's important, someone's going to be paying well for learning all of that stuff from zero, so the motivation will be there.

Why do people worry about a potential, temporary loss of skill?

If a catastrophic failure occurs we will have to return to first principles and re-derive the solutions. Not so bad, probably enlivening even to get to spin up the mind again after a break.

I mean there should be. But there's not. Despite the millions of CS grads produced many people could not reasonably be expected to produce many 'standard' parts of a software stack

I love the perpetual motion machine / thermodynamics analogy.

It kind of feels like companies are being fooled into outsourcing/offshoring their jr. developer level work. Then the companies depend on it because operational inertia is powerful, and will pay as the price keeps going up to cover the perpetual motion lie. Then they look back and realize they're just paying Microsoft for 20 jr. developers but are getting zero benefit from in-house skill development.

This is silly. I can build products in a weekend that would take me a year by myself. I am still necessary 1% of the time for debug, design, and direction and those of not at all a shallow skill. I have some graduate algebra texts on the way my math friend is guiding me through because I have found a publishable result and need to shore up my background before writing the paper...

It's not perpetual motion, it's very real capability, you just have to be able to learn how to use it.