The rise of judgement over technical skill

The problem wasn't low paid labor, it was just incompetent labor. You can find competent developers in all these countries offering lower pay, India, Brazil, Romania, Poland, China, Pakistan, its just that they would already be hired by other higher paying companies and what is left for the ones that are looking for the lowest paid possible workers are the incompetent ones.

IMO attempts to make it low paid work will fail, just like almost every STEM profession. But... the number of engineers that we need who operate as "power multipliers" on team will continue to decrease. Many startup and corporate teams already aren't needing junior/mid level engineers any longer.

They just need "drivers", senior/lead/staff engineers that can run independent tracks. AI becomes the "power multiplier" in the teams who amplify the effects of the "driver".

Many people pretend that 10x engineers don't exist. But anyone who has worked on an adequately high performing team at a large (or small) company knows that skill, and quite frankly intelligence, operate on power laws.

The bottom 3 quartiles will be virtually unemployable. Talent in the top quartile will be impossible to find because they're all employed. Not all that unlike today, though which quartile you fall into is largely going to depend on how "great" of an engineer you are AND how effectively you use AI.

As this happens, the tap of new engineers who are learning how to make it into the top quartile, will cutoff for everyone except for those who are passionate/sadistic enough to programming without AI, then learn to program WITH AI.

Meanwhile the number of startups disrupting corporate monopolies will increase as the cost of labor goes down due to lower headcount requirements. Lower head counts will lead to better team communication and in general business efficiency.

At some point the upper quartile will get automated too. And with that, corporate moats evaporate to solo-entrepreneurs and startups. The ship is sinking, but the ocean is about to boil too. When economic formulas start dividing by zero, we can be pretty sure that we can't predict the impact.

Someone told me AI was like having a bunch of junior coders. You have to be very explicit in telling it what to do and have to go through several iterations to get it right. Though it was cheaper.

Agreed on the review burden being frustrating. Two strategies I've found helpful for managing the cognitive load:

1. Tight issue scoping: Making sure each issue is narrowly defined so the resulting PRs are small and focused. Easier to reason about a 50-line change than a 500-line one.

2. Parallel PR workflow: Using git worktrees to have multiple small PRs open simultaneously against the same repo. This lets me break work into digestible chunks while maintaining momentum across different features.

The key insight is that smaller, well-bounded changes are exponentially easier to review thoroughly. When each PR has a single, clear purpose, it's much easier to catch issues and verify correctness.

Im finding these workflow practices help because they force me to engage meaningfully with each small piece rather than rubber-stamping large, complex changes.

Nope, dealing with juniors is way less frustrating because they learn. So overtime, you can increase the complexity of their tasks until they're no longer junior.

This is exactly how to use it and exactly why it’s a huge deal

In my experience so far, the people that aren’t getting value out of LLM code assistants, fundamentally like the process of writing code and using the tooling

All of my senior, staff, principals love it because we can make something faster than having to deal with a junior because it’s trivial to write the spec/requirement for Claude etc…

Indeed.

All this “productivity” has not resulted in one meaningful open source PR or one interesting indie app launch, and I can’t square my own experience with the hype machine.

If it’s not all hat and no cattle, someone should be able to show me some cows.

> Yesterday almost my whole day was wasted because I chose to attack a problem primarily by using Claude 4 Sonnet

I have been extremely cynical about LLMs up until Claude 4. For the specific project I've been using it on, it's done spectacularly well at specific asks - namely, performance and memory optimization in C code used as a Python library.

Honestly, its mind boggling. Am I the worst prompter ever?

I have three python files (~4k LOC total) that I wanted to refactor with help from Claude 4 (Opus and Sonnet) and I followed Reed Harper's LLM workflow...the results are shockingly bad. It produces an okay plan, albeit full of errors, but usable with heavy editing. In the next step though, most of the code it produced was pretty much unusable. It would've been far quicker for me to just do it myself. I've been trying to get LLMs on various tasks to help me be faster but I'm just not seeing it! There is definitely value in it in helping to straighten out ideas in my head and using it as StackOverflow on roids but that's where the utility starts to hit a wall for me.

Who are these people who are "blown away" by the results and declaring an end to programming as we know it? What are they making? Surely there ought to be more detailed demos of a technology that's purported to be this revolutionary!?

I'm going to write a blog post with what I started with, every prompt I wrote to get a task done and responses from LLMs. Its been challenging to find a detailed writeup of implementing a realistic programming project; all I'm finding is small one off scripts (Simon Willison's blog) and CRUD scaffolding so far.

I don’t think AI marks the end of software engineers, but it absolutely can grind out code for well specified, well scoped problem statements in quarter-minutes that would take a human an hour or so.

To me, this makes my exploration workflow vastly different. Instead of stopping at the first thing that isn’t obviously broken, I can now explore nearby “what if it was slightly different in this way?”

I think that gets to a better outcome faster in perhaps 10-25% of software engineering work. That’s huge and today is the least capable these AI assistants will ever be.

Even just the human/social/mind-meld aspects will be meaningful. If it can make a dev team of 7 capable of making the thing that used to take a dev team of 8, that's around 15% less human coordination needed overall to get the product out. (This might even turn out to be half the benefit of productivity enhancing tools.)

> I have to be cynical and believe those shouting about LLMs taking over technical skill must have lots of stock in the AI companies.

I'm far from being a "vibe" LLM supporter/advocate (if anything I'm the opposite, despite using Copilot on a regular basis).

But, have you seen this? Seems to be the only example of someone actually putting their "proompts" where their mouth is, in a manner of speaking. https://news.ycombinator.com/item?id=44159166

It’s interesting that your point about wasting time makes a second point in your favor as well.

If you don’t have the knowledge that begets the skills to do this work then you would never have known you were wasting your time or at least how to stop wasting time.

LLM fanboys don’t want to hear this but you can’t successfully use these tools without also having the skills.

Edit for the parent comment:

> in the end it just could NOT solve the challenge I gave it.

Last week I was like, I might as well vibe code with free Gemini and steal his credit than researching something destined to be horrible as Android Camera2 API, and found out that at least me using this version of Gemini do better if I prompt it in a... casual language.

"ok now i want xyz for pqr using stu can you make code that do" rather than "I'm wondering if...", with lowercase I and zero softening languages. So as far as my experience goes, tiny details in prompting matter and said details can be unexpected ones.

I mean, please someone just downvote and tell me it's MY skill issue.

Just move up an abstraction level and put that flow into planning the features and decomposing them into well defined tasks that can be assigned to agents. Could also write really polished example code to communicate the style and architectural patterns and add full test coverage for it.

I do notice the same lack of flow when using an agent since you have to wait for it to finish but as others have suggested if you set up a few worktrees and have a really good implementation plan you can use that time to get another agent started or review the code of a separate run and that might lend itself to a type of flow where you’re keeping the whole design of the project in your head and rapidly iterating on it.

As a (very good I would say) product manager once told me - the product vision and strategy depends very much on the ability to execute. The market doesn't stand still, and what you _can_ do defines very much what you _should_ do.

What I mean to say here is that not even product management is reduced to just "understand the domain" - so it kinda' feels that your entire prediction leans on overly-simplified assumptions.

>For the first couple years you make stuff, it’s just not that good.

Sadly, that's why I don't start a lot of things that would interest me. You need to get into things when you're a kid and don't realize how junk your work is, because as an adult you just don't have time to dedicate to producing a lot of junk to get good at something. The are shortcuts and more directed learning you can do in a lot of areas to reduce some of the undirected learning you do as a child, but it's till time consuming when time is a rare commodity.

I like to do a good job on small stuff.

It works nicely for me, but doesn't really bring accolades (but a hell of a lot of folks actually rely on stuff I authored; they just don't know it, or care -which is just fine).

>>> But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you.

This is why it's so hard for good classical musicians to learn jazz improvisation, even if they love jazz.

sounds like a containerized workspace. You can do this without a VM.

> You cant learn on nothing, something will be used for it, that something forms the hard knowledge eventually. Typically broad set but shallow hard knowledge.

As a counterpoint though, the way things have gone in the U.K. is to go deep on niche topics without building up appreciation of the broad strokes. To give an example, there’s a GCSE History course for 14-16 year olds where the syllabus is effectively “medicine through time” and “the American West” without ever going near the British Empire, colonialism, the Tudor or Elizabethan periods, the reformation, the Industrial Revolution, Irish home rule and independence, etc. etc. any one of which gives much more insight into the formation of the state and cultural affairs as it stands today.

To my mind it’s too narrow a focus at too young an age when teaching a subject that a lot of children take. It also means there are constantly “we don’t even teach that at school” debates.

High-energy physics?

> In software, we promote good engineers to management

i've not seen this. Infact its the opposite.

It does show an interesting second order downside of publicly using an LLM for anything: it raises everyone else’s suspicion that the rest of your work is LLM generated.

A certain amount of redundancy can be helpful. If you explain the same thing two different ways, one way might make more sense than the other to a particular reader. The judgement comes in because you should not just be doing this by rote or because you were "lead to believe" it was necessary, but in consideration of who you are writing for.

That is the goal post moving, its done by AI optimists that thinks "we just need something that can solve X and it will be as smart as a human expert".

Wasn't true for chess, wasn't true for Go, we will see when its true, but they are constantly moving the goalposts and then arguing its others who are moving it.

Not delegating, just tricking everything I develop out far more than I would have in the past. I'm on yet another hodgepodge project in a looong, decades long series of hodge and podge. AI is letting me begin to answer to my own satisfaction, "what does it look like to do everything to the best of my ability?"

In my current gig, I have an on-prem database and legacy application that is human-powered software, where parts of the business process never touch the computer and a human does the work (mostly support stuff), (and for no good reason other than this system never had real engineering support.) So, I joined the team, and started to wrangle the system.

First thing I was asked to do was get their database code and schema into source control with managed releases. The gold plating process that I never would have entertained in the past led me to get a migration tool installed, get a unit test engine installed in the database and writing new code with tests, figure out even how to refactor the big ball of mud and coming up with patterns there, doing github workflows to run the tests and deploy to multiple environments, linters, Slack alerts.

It's not that I wasn't aware of all these things, I just never would have done all of them _to the extent_ that I did because the time needed to research it all traditionally and spike the solutions would have been too great. And I documented it all!

After the databases were basically under control and I had gained the team's trust, I moved the team to start automating the human-powered parts of the software. We started an admin console webapp project. Again, I was heavy into AI all along the way, even during requirements elicitation. Our data is a rube goldberg machine of cloud and on-prem, but the majority of what we need to get under control is legacy/on-prem. We want the webapp to eventually be hosted in the cloud, but to be close to our databases and not have to fuss with private links, we decided for starters to deploy the webapp on-prem next to them.

So, that meant figuring out how to get our github builds deployed on-prem. There was this huge saga in figuring out how to provision an on-prem GitHub Runner and use Powershell Remoting to fan out our deployments from there to all of the on-prem servers. Never EVER would I have been able to figure out the permissions and powershell provisioning steps needed to pull that off. It's all very gross, Windows is gross, but what we've built works dependably and is secure. I probably would have just used Samba or some other cheesy way to move files around and trigger deployments if I didn't have AI to bounce all these ideas off of.

Another example: we wanted our BFF microservices to eventually deploy as Azure Functions, so gold plating meant we had to figure out how to build and deploy functions on-prem. It ended up being very productive, but again I would have never entertained doing such a thing unless I could bounce my ideas off AI and get credible directions on how to proceed. Instead, I would have written the service as trusty/crusty old Express 4.x and ported the code to Functions once we made the jump to cloud. I am saving future me a ton of work and heartburn!

At every step AI is giving me the latitude to ask, given whatever nasty situation I'm in, what would be the best code/most secure/nicest architecture in that case? It's arduous to continually pepper it with questions and spend many days zeroing in on a final solution with it. But, it beats the guessing game of searching DuckDuckGo, StackOverflow, and software vendors' documentation - those are now the _last_ places I look for answers. (For ill, I'm sure.)

> they solve the communication problem by having on-site managers that can serve as proxies, and they solve the quality floor problem by having the office in countries where the locals have strong expertise.

I think this problem goes deeper: there exist lots of countries where people are strong in programming, but from my work experience, the whole "programming culture" (how to approach problems; how to structure the program; ...) differs quite a bit between countries. So, from other countries you can get great programs, but the style can differ quite a bit from what you are used to.

Worth mentioning here that historically a lot of the famous pop hits have had plenty of interesting technical decisions typically only a mature composer would come up with. Weird short bars, time signature stuff, temporary key changes, weird jazz chords etc. You don't notice them because they're refined choices.

Empirically: by randomly asking N participants to rate pop music made by a celeb and by an indie band and observing if these participants were able to identify the celeb statistically.

Whatever schlock Taylor Swift manufactures next will be a global hit. Doesn’t matter the quality

Ever seen a photoshop expert at work? Every human endeavor has a skill distribution. Hammering in a nail takes skill.

I'm just arguing that there has been no qualitative shift. The skills you need to produce pop music today are different than the skills that you needed before. Now you need to be able to operate a MIDI sequencer or a program like Ableton, which is not necessarily easier in and off itself, than for instance learning how to play a guitar. I think it's the same with AI tools and programming. We're just talking about a different set of skills that you need in order to be competitive. I don't think there has been any real shift from "skill needed" to "judgement needed". I think this relationship remains the same, both for pop music and programming, but also for the example of playing an instrument in a symphony orchestra.

I would go a step further and dont let juniors use LLMs for code generation. The purpose and your role as a junior is to not only work but also to learn. When using genrated code, you miss a lot of opportunities to do so. Of course you could learn of some other methods or stuff from the frameworks you are using but imho thats not that big of an advantage.

Also, judgement alone might not be enough. Judgement can take you to "something is off", but not necessarily further. I mix music as a hobby and it takes a good amount of practice to step up from recognizing the presence of a problem to actually know where and how to fix it. If you don't know where you should look, you just aimlessly try various things, and it is not unusual to make the problem worse.

Eventually you learn to properly recognize the problems, not just their presence, but their actual nature and implications. But this takes practice.

If you see the generated content as "the music that's created with unlicenced samples" that's true.

However, if you see the trained models as "the music that's created with unlicenced samples" it isn't true.