This echoes my experience with Claude Code. The bottleneck isn't the code generation itself—it's two critical judgment tasks:
1. Problem decomposition: Taking a vague idea and breaking it down into well-defined, context-bounded issues that I can effectively communicate to the AI
2. Code review: Carefully evaluating the generated code to ensure it meets quality standards and integrates properly
Both of these require deep understanding of the domain, the codebase, and good software engineering principles. Ironically, while I can use AI to help with these tasks too, they remain fundamentally human judgment problems that sit squarely on the critical path to quality software.
The technical skill of writing code has been largely commoditized, but the judgment to know what to build and how to validate it remains as important as ever.
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.
>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
Reminds of me working in IT. One company tried to outsource my job to India five different times before they were mostly successful at it. The companies that are successful aren't the ones that assume it'll cost 1/10th the price, they are the ones that know it'll cost 60+% of the price and still require some handholding.
If you're hiring on price alone, you're already selecting the pool that doesn't contain the most competent labor.
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.
Decomposing a problem so that it is solvable with ease is what I enjoy most about programming and I am fine with no longer having to write as much code myself, but resent having to review so much more.
Now, how do we solve the problem of people blindly accepting what an LLM spat out based on a bad prompt. This applies universally [0] and is not a technological problem.
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.
> The key insight is that smaller, well-bounded changes are exponentially easier to review thoroughly.
I am not sure if that is the real insight. It appears to me that most people prefer small, well-bounded changes, but it's quite tricky to break down large tasks into small but meaningful changes, isn't it? To me, that appears to be the key.
Exactly - and that's where AI becomes really valuable as a thinking partner. I use Claude Code to have conversations with my codebase about how to slice problems down further.
The issue definition itself becomes something you can iterate on and refactor, just like code. Getting that definition tightly bounded is more critical than ever because without clear boundaries, the AI doesn't know when to stop or what constitutes "done."
It's like having a pair programming session focused purely on problem decomposition before any code gets written. The AI can help you explore different ways to break down the work, identify dependencies, and find natural seams in the problem space.
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.
> In my own experience interns are a net drag. New college hires flip positive after 3-6 months.. if they are really good. Many takes upwards of a year.
And mostly their output is not really about incorrect code, but more likely incorrect approaches. By reviewing their code, you find gaps in their knowledge which you can then correct. They're here to learn, not to produce huge amount of code. The tasks are more for practice and evaluation than things you critically need.
I don't want to work with a junior, but I'm more than happy to guide them to be someone I can work with.
I do agree that "unlimited interns who don't improve much" is less practically useful than it might seem at first, but OTOH "never improve much" seems unrealistic, given the insane progress of the field in the last 3ish years (or think back 5 years and tell me who was realistically predicting tools like Claude Code to even exist by 2025).
Also, there's a decently large subset of small startups where there's 1 technical founder and a team of contract labor, trying to build that first MVP or cranking out early features in a huge rush to stay alive, where yeah, cheap unlimited interns might actually be meaningfully useful or economically more attractive than whatever they're doing now. Founders kind of have a perverse incentive, where a CTO doesn't need to solo code the first MVP, and also doesn't need to share/hand-out equity or make early hires quittteee as early, if unlimited interns can scale that CTO's solo productivity for a bit longer than the before-times.
> but OTOH "never improve much" seems unrealistic, given the insane progress of the field in the last 3ish years
The point is that no one should hire an intern or a junior because they think it will improve their team's productivity. You hire interns and juniors because there's a causal link between "I hired an intern and spent money training them" and "they joined my company full time and a year later are now productive, contributing members of the team". It's an investment in the future, not a productivity boost today.
There is no causal link between "I aggressively adopted Claude Code in 2025" and "Claude Code in 2026 functions as a full software engineer without babysitting". If I sit around and wait a year without adopting Claude Code that will have no measurable impact on Claude Code's 2026 performance, so why would I adopt it now if it's still at intern- or junior-level skill?
If we accept that Claude is a junior-level contribution then the rational move is to wait and watch for now and only adopt it in earnest if and when it uplevels.
Precisely - AI getting better or not has nothing to do with my burning cycles using it. My juniors do improve based on my effort. I can free ride on AI getting good enough later (wait) whereas I cannot with my own team of juniors.
> 1 technical founder and a team of contract labor, trying to build that first MVP or cranking out early features in a huge rush
Having worked in environments with a large number of junior contractors... this is generally a recipe for a lot of effort with resulting output that neither works technically nor actually delivers features.
To your last point -- I didn't say large number of junior contractors would write good code or whatever. The change that is happening in the startup scene now, as compared to say 10 years ago, is more about lowering the barrier to MVP and making it easier/cheaper for startups to experiment with finding product market fit, than anything to do with "productivity" or code quality or whatever.
We're probably just talking past each other, because the thing you care about is not the thing I care about. I am saying that, it used to cost some reference benchmark of $X/idea to iterate as a startup and experiment with ideas, but then it became 0.5X because gig workers or overseas contractors became more accessible and easier to work with, and now it's becoming 0.1X because of LLMs and coding agents. I am not making any sort of argument about quality being better/good/equal, nor am I making any sort of conversion chart between 10 interns or 100 LLM agents equals 1 senior engineer or something... Quality is rarely (never?) the deciding factor, when it comes to early pre-seed iteration as a startup tries to gasp and claw for something resembling traction. Cost to iterate as well as benefits of having more iterations, can be improving, even if each iteration's quality level is declining.
I'm simply saying, if I was a founder, and I had $10k to spend to test new ideas with, I can test a helluva lot more ideas today (leveraging AI), vs what I could have done 5 years ago (using contractors), vs what I could have done 10-20 years ago (hiring FTEs, just to test out ideas, is frankly kind of absurd when you think about how expensive that is). I am not saying that $10k worth of Claude Code is going to buy me a production grade super fantastic amazing robust scalable elegant architecture or whatever, but it sure as heck can buy me a good enough working prototype and help me secure a seed round. Reducing that cost of experimentation is the real revolution (and whether interns can learn or will pay off over time is a wholly orthogonal topic that has no bearing to this cost of experimentation revolution).
Yeah in this context I get what you are talking about. I got through your first paragraph and thought of the startup founders using overseas / gig workers a decade ago to test ideas.. which is exactly where you went!
What are you doing to actually keep them at your company? I left a company after they invested a lot in training me. They gave me very little raises and already paid poorly, no guaranteed bonus, bad vacation hours, and no opportunities for promotion. They were shocked when I left, even though I had asked for very modest raises and was way more productive than the "seniors" at the company.
Most companies outside of FAANGs treat their talented juniors like crap, so of course they'll leave.
Which is exactly why no one's hiring juniors anymore. It made sense back when the market for hiring engineers was super competitive and it was easier to gamble on being able to keep a junior than it was to try to snag a senior. But now that there are seniors galore on the market who would bother with a junior?
> Also, there's a decently large subset of small startups where there's 1 technical founder and a team of contract labor, trying to build that first MVP or cranking out early features in a huge rush to stay alive, where yeah, cheap unlimited interns might actually be meaningfully useful or economically more attractive than whatever they're doing now
That's when experienced developers are a huge plus. They know how to cut corners in a way that will not hurt that much in the long term. It's more often intern level that are proposing stuff like next.js, kubernetes, cloud-native,... that will grind you to a halt once the first bugs appear.
A very small team of good engineers will get you much further than any army of intern level coders.
Yeah "actually good engineers" are like a 10:1 ratio with intern/new college hire/junior consultant level.
Not to generalize too much but if you are contracting out to some agency for junior levels, you are generally paying markup on coders who couldn't find better direct hire jobs to start with. At least with mid/senior level you can get into more of a hired-gun deal for someone who is between gigs/working part time/buy a share of their time you couldn't afford full-time.
In fact most junior consultants you are basically paying for the privilege to train other peoples employees who will then be billed at a higher rate back to you when they improve.. if they don't move on otherwise.
Yes, a combination of empire building and "but $X exceeds the $Y cap set by HR for Z role! / we can hire XX juniors for this price!" type of mega corp thinking.
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…
> 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…
How will you make new senior, staff, and principal engineers without "having to deal with a junior"?
> 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…
Hm, interesting. As someone who has found zero joy and value in using LLMs, this rings true to me. Setting aside the numerous glaring errors I get every time I try to use one, even if the tools were perfect, I don't think I would enjoy using them. I enjoy programming, thinking about how to break down a problem and form abstractions and fit those into the tools the language I'm writing in gives me. I enjoy learning and using the suite of Unix tools like grep and sed and vim to think about how to efficiently write and transform code. The end product isn't the fun part, the fun part is making the end product. If software engineering just becomes explaining stuff in English to a machine and having some software pop out... then I think the industry just isn't for me anymore. I don't want to hand the fun part over to a machine.
It's like how I enjoy going to my wood shop to build tables instead of going to Ikea. It would be cheaper and faster and honestly maybe even better quality to go to Ikea, but the joy is in the knowledge and skill it takes to build the table from rough lumber.
"As someone who has found zero joy and value in using LLMs"
I love programming but find zero joy in front-end coding. For me LLM's solved that bit nicely. I'm sure a real webdev would do better, but I can't afford it for my personal projects and the LLM helped me to get it done more than good=enoug for my needs.
I'm not sure I agree that will happen, but if it does, then yeah like I said, it's probably my cue to exit the industry. If the fun goes out of the job, there's other things I'd rather do than sit inside alone and stare at a screen all day.
What the heck, the code generation _is_ absolutely still a bottle-neck.
I dare anyone who making these arguments that LLMs have removed the need for actual programming skill, for example, to share in a virtual pair programming session with me, and I will demonstrate their basic inability to do _any_ moderately complex coding in short order. Yes, I think that's the only way to resolve this controversy. If they have some magic sauce for prompting, they should post a session or chat that can be verified by other (even if not exactly repeatable).
Yesterday almost my whole day was wasted because I chose to attack a problem primarily by using Claude 4 Sonnet. Having to hand hold it every step of the way, continually keep correcting basic type and logic errors (even ones I had corrected previously in the same session), and in the end it just could solve the challenge I gave it.
I have to be cynical and believe those shouting about LLMs taking over technical skill must have lots of stock in the AI companies.
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.
I find it hard to believe the inexperienced would benefit at all. Ai assisted coding requires serious general experience in all matters software to get good value out of it.
I dunno, as an engineer who likes to make side projects, I can say with high certainty that LLMs have helped me compensate for things I'm worse at when coding a product.
I'm good at the engineering side of things, I'm good at UI, I'm good at UX, I'm good at css, I'm just not good at design.
So I tell the LLM to do it for me. It works incredibly well.
I don't know if it's a net increase in productivity for me, but I am absolutely certain that it is a net increase in my ability to ship a more complete product.
> 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 couldn't agree more. This has been my exact experience.
Like you I'll probably write a blog post and show, prompt by prompt, just how shockingly bad Claude frequently is. And it's supposed to be one of the best at AI assisted coding, which mean the others are even worse.
That'll either convince people, match their experiences, or show me up to be the worst prompter ever.
I think you're supposed to let the AI write the bad python code and then do the refactoring yourself. No way I'm letting the AI make changes to 150 files with tons of cross-concerns when I don't even fully understand it all myself unless I dig into the code.
That being said copilot and chatgpt have been a 40% productivity boost at least. I just write types that are as tightly fitting as possible, and segregate code based on what side effects are going to happen, stub a few function heads and let the LLM fill in the gaps. I'm so much faster at coding than I was 2-3 years ago. It's like I'm designing the codebase more than writing it.
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.)
> 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?”
What? Software engineering is about problem solving, not finding the first thing that works and called it a day. More often than not, you have too many solutions and the one that's implemented is the result of a list of decisions you've taken.
> 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.
I credit my understanding of the incredible costs relating to the increased need for coordination and the sharply decreasing return on productivity for additional people to The Mythical Man Month.
I don't take credit for the value of being able to do with 7 what currently takes 8, but rather ascribe it to the ideas of Fred Brooks (and others).
> 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.
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.
I totally just verbalize my inner monologue, swearing and everything. Sometimes I just type "weeeeeeeelllllll" and send it, to get more LLM output or to have it provide alternatives.
It might sound weird but I try to make the LLM comfortable. Because I find you get worse results when you point out mistake after mistake and it goes into apologetic mode. Also because being nice puts me in a better mood and it makes my own programming better.
I want to add something to this which is rarely discussed.
I personally value focus and flow extremely highly when I'm programming. Code assistance often breaks and prevents that in subtle ways. Which is why I've been turning it off much more frequently.
In an ironic way, using assistance more regularly helped me realize little inefficiencies, distractions and bad habits and potential improvements while programming:
I mean that in a very broad sense, including mindset, tooling, taking notes, operationalizing, code navigation, recognizing when to switch from thinking/design to programming/prototyping, code organization... There are many little things that I could improve, practice and streamline.
So I disagree with this statement at a fundamental level:
> The technical skill of writing code has been largely commoditized (...)
In some cases, I find setting yourself up to get into a flow or just high focus state and then writing code very effective, because there's a stronger connection with the program, my inner mental model of how it works in a more intricate manner.
To me there are two important things to learn at the moment: Recognizing what type of approach I should be using when and setting myself up to use each of them more effectively.
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.
> 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
This doesn't work because you still have to read and verify all of the stuff your agents produce
So the new workflow is:
Move up an abstraction level to use an agent to produce code
Then move down an abstraction level to review the code it produces
This sounds like way more cognitive overhead and way harder (and therefore probably slower) to do than just writing the code by hand in a good flow
There's something fundamentally different between writing the program directly that you visualize in your head versus staying one level away and reviewing someone else's code. I'm really talking about the former.
"these require deep understanding of the domain, the codebase, and good software engineering principles" Most of this AI can figure out eventually, except maybe the domain. But essentially software engineering will look a lot like product management in a few years.
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.
pretty big logic leap you made there. I didn't say understanding the domain was the only requirement. But certainly not understanding it will cause you to fail.
That's a narrow view of the issue described in the blog post. You're coming at this from the perspective of a software engineer, which is understandable given the website we're posting on, but the post is really focusing on something higher level - the ability to decide whether the problems you're decomposing and the code you're reviewing is for something "good" or "worthwhile" in the first place. Claude could "decompose problems" and "review code" 10x better than it currently does, but if the thing it's making is useless, awkward, or otherwise bad (because of prompts given by people without the qualities in the blog post), it won't matter.
When the work is equal to the knowledge and judgment of the painter, it is a bad sign; and when it surpasses the judgment, it is still worse, as is the case with those who wonder at having succeeded so well. But when the judgment surpasses the work, it is a perfectly good sign ; and the young painter who possesses that rare disposition, will, no doubt, arrive at great perfection. He will produce few works, but they will be such as to fix the admiration of every beholder.
Leonardo da Vinci, "A Treatise on Painting.", p. 225
> Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase, they quit. Most people I know who do interesting, creative work went through years of this. We know our work doesn’t have this special thing that we want it to have. We all go through this. And if you are just starting out or you are still in this phase, you gotta know its normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions. And I took longer to figure out how to do this than anyone I’ve ever met. It’s gonna take awhile. It’s normal to take awhile. You’ve just gotta fight your way through.
(Ira Glass)
>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.
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).
If your small stuff contributes to a strong foundation for other people, then they should care
It's a shame people lose sight of the ground beneath their feet when reaching to the sky
I'm very guilty of this too, partly because any time I try to look down the people I work with rush in to discourage me from doing that - it's not part of the sprint, after all
Anyways, I am not sure what stuff you build, but thank you for being the sort of person that builds strong foundational stuff that helps other people. We need more people like you. I should try and be more like you
We have built _a lot_ of things on top of shaky foundations. It is one of the tragedies of human society, that we are too resistant to rebuilding parts and accept the status quo too easily. There are network effects at play and probably other effects as well.
Basing our work on solid foundations, we shouldn't need to look towards the ground, when reaching up.
I remember reading a rather silly fantasy book, back in the '90s.
It was obviously written by a UNIX guy, and it featured a software geek that gets transported into a realm where magic works.
He then started to build a foundation of spells, even giving them UNIX names like "Grep," and "Sed."
It was all about how he built a powerful magic system, from scratch, starting with basic components, and combing them, into more ambitious components, and so on.
Most of my published work is components; usually, Swift Package Manager packages. Each one is carefully written and documented, then tested like crazy. It means that I can leverage them, without a second thought, as to Quality, or features.
Here's what I'm working on, now[0]. It still has a long way to go, but it's coming along nicely. It's a "swipeable" tab bar controller, so that iOS apps can behave like Android apps. I have been doing this by hand, in many of my latest apps, and I thought that it was a good candidate for commoditization.
I'll spend a lot of time, testing and documenting it, so it will be a "drop in" module that I'll be able to use for future apps.
I actually don't get what your tool does. I don't use MacOS, so maybe that is why I don't get it. If you could add screenshots of the tool in action, that could be helpful.
One of the things that we learn, as we mature, is that "It Depends" is a mantra for life.
A good filter is the "How Important is It?" filter.
If I'm adding dependencies to an app, a styling dependency is less crucial than an algorithm one. I may just apply some fairly basic checks to a styling dependency, and maybe use injection, to make it easy to swap out. I may also look for free, or low-cost ones.
For the algorithm, which may be my bread and butter, I might be a hell of a lot more demanding, and I may consider using a commercially-backed product.
> It's a shame people lose sight of the ground beneath their feet when reaching to the sky
Shakespeare:
> 'tis a common proof
\ That lowliness is young ambition's ladder,
\ Whereto the climber-upward turns his face;
\ But when he once attains the upmost round,
\ He then unto the ladder turns his back,
\ Looks in the clouds, scorning the base degrees
\ By which he did ascend.
“The reason the gentleman is called worthy is not that he is able to do everything that the most skillful man can do. The reason the gentleman is called wise is not because he knows everything that the wise man knows. When he is called discriminating, this does not mean that he is able to split hairs so exhaustively as the sophists. That he is called an investigator does not mean that he is able to examine exhaustively into everything that an investigator may examine. He has his limit.
In observing high and low lands, in judging whether fields are poor or fertile, and in deciding where the various grains should be planted, the gentleman is not as capable as a farmer. When it is a matter of understanding commodities and determining their quality and value, the gentleman cannot vie with a merchant. As regards skill in the use of the compass, square, plumb line, and other tools, he is less able than an artisan. In disregarding right and wrong, truth and falsehood, but manipulating them so that they seem to change places and shame each other, the gentleman cannot compare with Hui Shih and Teng Hsi.
However, if it is a question of ranking men according to their virtue; if offices are to be bestowed according to ability; if both the worthy and the unworthy are to be put in their proper places… if all things and events are to be dealt with properly; if the charter of Shen Tzu and Mo Tzu are to be suppressed; if Hui Shih and Teng Hsi are not to dare to put forth their arguments; if speech is always to accord with the truth and affairs are always to be properly managed — it is in these matters that the gentleman excels.”
A similar debate has happened in education where people seem to think that having ability to critically analyse texts is more important than knowledge. and to some degree that’s true but personally I think that without building on some decent level of foundational level of knowledge and having a mental model of a subject, you can’t tackle thorny questions because you don’t have enough to draw upon as examples and counterpoints about how to proceed.
My current employer is currently going on a top down driven “one tech” mission and trying to rationalise the technology stacks across diverse product lines. Which is all fine but the judgement is a poor one because the biggest developer bottleneck that comes up in internal developer surveys is the corporate mandated IT things and a relatively hostile setup without even local admin rights, which make sense for general office workers and don’t make sense at all for software developers.
> a relatively hostile setup without even local admin rights
Taking a diversion into this -- how about local admin rights to a virtual VM / sandboxed machine? I imagine that would allow developers to be productive, while protecting everything that IT wants to protect.
Once you do that, I imagine everyone will discover the issue isn't actually _local_ admin rights, but having admin rights to a machine that's on the internal network and can access internal company resources. Which might mean that IT has taken a strategy that once you're inside the local network, you have access to lots of valuable goodies. Which is a scary strategy.
Education itself is supposed to teach us learning, not the mere facts/methods, not just the hard knowledge. Hard knowledge comes with it anyway as some sort of 'side product'. 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.
Ironicly, this is what I feel chipping away in modern collaborative developments. The appreciation of learning capability. In the self interest of the organization (short term self interest, long term is too unpredictable, so does not exists in the practice) specific technical knowledge parcticed individuals are sought out for the purpose of easy replacement: not to be dependent on personnel, have it like a plug and play component. The ability to learn is not valuable while inside the organization. Should be practiced enough for years beforehand and applied intensely after joined. For the sake of claiming evolving organization the teaching may be outsourced in a very limited time to some sort of external enterprise making money on disseminating hard knowledge with made up examples or generic (artificial) applicability, instead of doing it in the actual context of the organization. Be part of the organization. Daily. Application of the new hard knowledge in the specific context of the organization will be casual by the random enthusiast. If they can break through of the company policy and established ways of management. Eventually the policies and practicies must be rigid as well, shouldn't they, so the personnel working in the management could be as easily replacable as the foot soldiers of code. For the sake of the organization. Call this approach the Organization Oriented Development.
> 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.
Reminds me of that concept that I saw pop up in HEP in recent years between "users" and "experts".
This distinction in that case is so dumb I cannot wrap my head around it: You first encounter the code, are unfamiliar with it but very quickly you become expert in order to solve your problem and advance the thing forward.
It does not matter which codebase you start on, what matters is that you understand what the actual stack does and what is involved in there because people are supposed to understand deeply what they are doing.
But this comes from the "corporatisation" of every single entity, where random metrics are used in order to assess performance instead of asking the simple question of "does it work" or "does it need fixing" or "will this thing break".
There is a clear disconnect between the manager type people that are removed from the work and the managers still doing things practically, which understand what the stressors are and where some work of deep understanding and extra contextualisation of the systems, is required, in order to not mess the whole thing up.
This being said, this is coming from a very peculiar perspective and with a very specific tech stack which is and is not industry standard at many levels...
I would argue that this is already true in roles where one supervises the work of another person with skill. Great leaders, for example, were once practitioners. Over time their skills may fade, but their judgment makes them effective and able to the scale their impact.
In software, we promote good engineers to management, effectively accelerating the Peter Principle.
It doesn't have to be that way. Management skills are not an outgrowth of the skills of the managed, but orthogonal to them. This is similar to the lesson many PhD candidates I've known learn: expertise in their field is not pedagogical expertise. Companies who promoted from within used to provide training for new managers.
You've seen good managers promoted to engineers? ;)
I have seen this happening, usually the engineers with the best technical AND people skills are first made lead developer, and eventually "team lead". After team lead they can climb the corporate ladder with titles like "junior vice president" or "senior director".
AI works great for providing you a starting point, and giving a big picture view of how certain things work, and how you should structure them.
Sometimes, even if you're a really seasoned software engineer, you'll encounter something you haven't seen before. Maybe to the point that you don't really even know what to search for to get started. So instead of spending half a day scrounging various forums, e-books, etc. you can ask the model, in somewhat vague terms, what you're looking for - and some of the LLMs are quite good at just that.
Now, the implementation of such things, not quite there yet. My experience has been that the more obscure the problems you deal with, the more obsolete code the model will spit out - with dead and unsupported libraries etc.
A side note to the general point of the article, but I hate how the tech industry uses the word "democratization" to mean "lowering the barrier to entry". These concepts differ from each other but many use the former term because in doing so they justify their actions as driven by some sort of moral imperative when in reality, the development of LLMs is morally neutral, not inherently bad by any stretch, but as much a wealth and power play as any other technology of the last 25 years.
Judgement and technical skill go hand in hand. Technology merely moves the boundary of what is considered judgement, and what is considered technical skill.
I know someone who wrote programs in the punch-card era. Back then, technical skill meant being diligent and thoughtful enough that you avoided most bugs when writing the program. If you screwed this up, you had to wait for another time slot. What does this mean for the complexity of programs you could write? Well, it means you are quite limited. You can't build judgement about things above what is now considered a very basic program.
I learned to program before the AI era that seems to be nascent. Technical skill means things like being able to write programs in python and c++, getting many computers to work together, being able to find hints when something goes wrong, and so on. Judgement now covers things like how a large swarm of programs interact, which was not really in scope for punch-card guy.
Now AI arrives, and it appears that we are free from technical skill problems. Indeed, it does fix a lot of my little syntax issues, but actually it just moves the goalposts. There's soon going to be no excuse for spending time working out the syntax for a lambda function, you'll be expected to generate a much more complicated product, for which you will need an even higher overview to say you are providing judgement.
This blog post shows how not to use AI. The author would have been unlikely to write such a uselessly redundant conclusion if they had to type it themselves.
Edit: I like the post, but it didn't need to be padded with fluff.
We shouldn't be too quick to jump to "AI did it." People write redundant paragraphs and sentences in articles all the time because they're led to believe that every article needs a conclusion that sums up what's already been said. Ironically, including one in this article showed a lack of good judgment, which isn't confined to AIs.
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.
Writing musical notation doesn't strike me as technically difficult but I'm unaware of any musical composers who weren't proficient in at least one instrument.
Good judgement is only accessible to those who've invested considerable time in the rudiments.
And what is that judgement based on? Jobs that an AI can't do yet, like designing a system architecture and drawing boundaries (which features go in the same service), need someone with experience.
We can apply this to all points in the Future of Work section. Even the conclusion "What should you do, and why?" is basically a disguised "What domain-specific knowledge do you have to make an informed opinion on the 'why' anyway?"
This reminds me of Asimov's Jokester story where the same themes are explored - there is an all-knowing computer but someone needs to ask the correct questions.
"Early in the history of Multivac, it had become apparent
that the bottleneck was the questioning procedure. Multivac
could answer the problem of humanity, all the problems, if it
were asked meaningful questions. But as knowledge accumulated
at an ever-faster rate, it became ever more difficult
to locate those meaningful questions.
Reason alone wouldn't do. What was needed was a rare
type of intuition; the same faculty of mind (only much more
intensified) that made a grand master at chess. A mind was
needed of the sort that could see through the quadrillions of
chess patterns to find the one best move, and do it in a matter
of minutes."
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.
CERT advisories are evidence that skill is necessary but insufficient. There’s a lot of code. We get ping ponged between various sections of the code every few weeks. Other people are contributing. There’s a ton of ways code can look like it’s probably correct and not be. There are non obvious bugs everywhere, and there’s an element of luck to whether you’re in the right headspace to catch them all.
AI enables me to gold plate _everything_ I do, which feels exhilarating, if a bit exhausting. Having decent taste and being able to continuously test and verify my work allows me to smooth over the occasional hallucinations and elicit towering, mind-bending solutions.
AI's no replacement for experience; garbage in-garbage out.
When AI gets too good, I figure people will cloister to stop feeding the beast. It can only lead to ignorance and misery, I fear.
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.)
Nothing stopped anyone from hiring 10 to 100 offshore devs for every American software dev for the last 20 years. Yet Google, Amazon, Microsoft, and so on paid top dollar for the Americans.
And American business still pays top dollar. Even more than before. The judgement was always the problem. If the issue was bodies in seats the problem was already solved.
The #1 cause of layoffs in America is offshoring caused by Zoom and other telework tools perfected during COVID. AI is a convenient excuse.
Pop music is mostly not about music quality - hits are always passable - but about celebrity. The rare song that elevates a new artist quickly converts them into celebrity, which converts future songs in their style into further hits 100,000x easier than before. Maybe even 1 billion times easier than before given the amount of songs created every year. Yet AI is supposedly an expert at generating music, and images, and video, and code, and on and on.
I’m not seeing the evidence of layoffs from AI. I’m seeing evidence of better productivity from existing employees, which is the same result of every groundbreaking technology since all time.
The thing that stopped people from hiring 10-100 offshore devs per American dev lead/architect was communication primarily, with quality floor being an additional factor. Plenty of American companies have "hired 10-100 offshore devs" per American lead/architect, but they call it a foreign office, 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.
If AI can solve the communication and quality floor problems (it's pretty close), having 100 agents per dev lead/architect becomes perfectly viable.
> 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.
The Eno quote is good, but the post adds nothing to it! If anything, I think the sections after the quote make the post worse. This shows poor judgment on the part of the author.
Very thin article. The thesis might as well be that technical competence is gone and judgement is all that’s left.
I file this under the category of AI musings on the inevitable massively changed landscape that AI has wrought.[1] I get the feeling that the content itself is secondary (again: the thesis is thin) to the motivation of writing about how AI has supposedly changed everything forever. In this case: now technical competence is dead, hail the king (judgement or whatever).
Music was never an issue of skill. You might have needed skill in order to get to the point where you could use your judgement, but skill was never the deciding factor. So, I don't agree with Brian Eno's point that there has been some kind of seismic shift when it comes to this. Rather, it's just a matter of a shift in the type of skill that you need to have. The same is probably true when it comes to AI tools within the field of programming.
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.
Human judgement is like a house built on sand, it is basically provably feeble [0]. I've literally never in practice seen a human update their beliefs using Bayes' formula. I suspect we'll find that at some point fairly soon AIs will just have better judgement than us because they can be programmed to incorporate formal statistical concepts while humans have to rely on evolving grey goop which we haven't quite mastered. I imagine it'll be almost comical watching human experts going up against a system that can actually intuit the difference between a 60% and 70% chance of something happening in their risk calculations.
Humans will still have a role expressing preferences and subjective questions though. Questions like "how much risk do you want your investments to take?" or "does this look good?" ultimately can't be answered by AIs because they depend on the internal state of a human.
> I've literally never in practice seen a human update their beliefs using Bayes' formula.
Then you've never debugged anything genuinely difficult.
Moving from "Where did I screw up in my code?" to "Is this library broken?" to "Wait, that's not possible. Let's look at the compiler output on Godbolt." to "Are you kidding me? The SPI system returns garbage in the last bit for transactions of 8n+1 bits?" (BTW, Espressif, please fix that in the C6. Kthxbye.) is all about establishing ground truth and adjusting your Bayesian priors as you gather evidence.
If there is one thing AI is currently shockingly bad at, it's updating its assumptions when it is confronted with evidence that they are incorrect. It will tirelessly spin its wheels (seemingly) forever laboring under a false assumption, running into dead end after dead end without ever coming to the conclusion that it should reexamine its assumptions.
Humans may not update like Bayesians, but we read context, shift priorities, and act under pressure. Judgment isn't just math — it's lived experience, intuition, and meaning in motion. That’s still hard to replicate.
Today, if someone uses LLMs for code generation, he/she will probably question the generated code and will put his own judgement above it. I am curious how fast that will change, especially for juniors. When will they start to question their own judgement and just go with the generated code becuase its "more safe"?
At present, when juniors do this at my company, they usually get fired within the month. The onboarding docs now explicitly state that though code review is a joint-responsibility process, you as the submitter are responsible for understanding it, ensuring it all works, and being aware of the broader scope and consequences. Maybe many companies have placed more responsibility on the reviewier to catch problems in the past?
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.
LLMs are very good at sounding right. I’m sure the code generated from them are rarely reviewed by junior developers. Even if they did question it i bet they give the LLM the benefit of the doubt. “Well the computer said this so it must be right otherwise it would be a bug and I bet Anthropic has caught all the bugs…”
I think the reality is that, this notion of "democratising" various technical mediums is used to gloss over that, as countless studies have now evidenced, humans primarily learn and remember well thing by doing things, not merely passively consuming them. Fine-precision decision-making will likely always be the domain of dedicated tooling designed to better correspond with the particular medium or task -- that is, manual testing and experimentation, not relying on logocentric prompt idolatry.
When we get into literature, visual art etc. it becomes more of a problem. You can't get Cormac McCarthies or Mars Voltas from software designed to give you perfect statistical 50% grey, and people who try and hack it without doing the reading, are going to end up writing gibberish. People who actually enjoy and like art, music whatever are going to grow Very bored with the overwhelming majority of work reliant of primarily generative methods, save for those who already have discretion learned through experience of many tools and other means of expression.
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.
I think what and how are so tightly linked, you need to know how to make a thing so you better know what thing to make.
Let's say you want to build worlds fastest car. You can order the pieces and maybe build a car from someones instructions. But to know what makes car fast and how to build it you need to know more and more intricate details. Physics, material science, 3D printing, engineering. How do you measure traction? What shapes increase downforce?
That is how I see AI tools. You can get "off the shelf" ideas on different things, even complete small things, but you really need to be or grow to match the challenge you are facing.
I think, the argument would make more sense if software like Cubase came with unlicenced samples from all songs out of the box. Artists sued and won when someone used their samples without permission.
There's a difference between a sample and something inspired by something but also significantly different. The copyright laws around music are kind of draconian so it's not a good analogy for code anyhow, imagine a world where a fundamental do while loop had 90 year copyright protection, and that's the sort of world we'd be living in if code copyright was like music copyright.
Grok3: "The phrase "There is no royal road to geometry" is attributed to the ancient Greek mathematician Euclid. According to historical accounts, particularly from the philosopher Proclus, Euclid reportedly said this to Ptolemy I Soter, the ruler of Egypt, when the king asked if there was a shorter or easier way to learn geometry. Euclid's response emphasized that geometry, like any rigorous discipline, requires effort and dedication, with no shortcuts even for royalty."
You can use AI as a royal road, but it may or may not prove an effective substitute for the learning required to provide judgement.
Have people noticed the ai-assisted code "creep"? Cursor now by default applies its changes before you've even hit accept, and the tab autocomplete is getting out of control. Sometimes I'll have my cursor resting on some block of code, then suddenly Cursor suggests I delete the whole thing.
This doesn't actually sound encouraging. Judgment is not actually independent of skill, and the sort of music that this approach produces (i.e., nearly everything you hear on the radio these days) is a pretty solid proof of that.
I love these little anecdotes because they always pre-suppose that everyone - the writer, of course, but also the reader - themselves are the people who don't lack judgment, which is a role they relegate to, perhaps, a particularly incompetent co-worker, or even unknown and faceless "drudge".
Which is to say that there's an obvious affliction of narcissism at work that precludes good judgment.
This echoes my experience with Claude Code. The bottleneck isn't the code generation itself—it's two critical judgment tasks:
1. Problem decomposition: Taking a vague idea and breaking it down into well-defined, context-bounded issues that I can effectively communicate to the AI
2. Code review: Carefully evaluating the generated code to ensure it meets quality standards and integrates properly
Both of these require deep understanding of the domain, the codebase, and good software engineering principles. Ironically, while I can use AI to help with these tasks too, they remain fundamentally human judgment problems that sit squarely on the critical path to quality software.
The technical skill of writing code has been largely commoditized, but the judgment to know what to build and how to validate it remains as important as ever.
This would be at least the third time in history we've tried to shunt writing code to low paid labor. We'll see if it's successful this time.
The problem tends to be that small details affect large details which affect small details. If you aren't good at both you're usually shit at both.
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.
>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
Reminds of me working in IT. One company tried to outsource my job to India five different times before they were mostly successful at it. The companies that are successful aren't the ones that assume it'll cost 1/10th the price, they are the ones that know it'll cost 60+% of the price and still require some handholding.
If you're hiring on price alone, you're already selecting the pool that doesn't contain the most competent labor.
"Never buy the cheapest version of something." I don't remember who told me that, but it was good advice. There's always a reason.
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.
Solopreneurs won't be able to effectively lobby govt regulators
i have significantly more faith in school children regulating an insane asylum
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.
That matches my experience.
Decomposing a problem so that it is solvable with ease is what I enjoy most about programming and I am fine with no longer having to write as much code myself, but resent having to review so much more.
Now, how do we solve the problem of people blindly accepting what an LLM spat out based on a bad prompt. This applies universally [0] and is not a technological problem.
0 - https://www.theverge.com/policy/677373/lawyers-chatgpt-hallu...
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.
> The key insight is that smaller, well-bounded changes are exponentially easier to review thoroughly.
I am not sure if that is the real insight. It appears to me that most people prefer small, well-bounded changes, but it's quite tricky to break down large tasks into small but meaningful changes, isn't it? To me, that appears to be the key.
Exactly - and that's where AI becomes really valuable as a thinking partner. I use Claude Code to have conversations with my codebase about how to slice problems down further.
The issue definition itself becomes something you can iterate on and refactor, just like code. Getting that definition tightly bounded is more critical than ever because without clear boundaries, the AI doesn't know when to stop or what constitutes "done."
It's like having a pair programming session focused purely on problem decomposition before any code gets written. The AI can help you explore different ways to break down the work, identify dependencies, and find natural seams in the problem space.
So really the same two skills that a senior engineer needs to delegate tasks to juniors & review the results..
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.
Agreed on that point, and my question for a lot of the AI bros has been "what would you actually do with unlimited interns who never improve much?"
For me, not much! Others may differ.
In my own experience interns are a net drag. New college hires flip positive after 3-6 months.. if they are really good. Many takes upwards of a year.
> In my own experience interns are a net drag. New college hires flip positive after 3-6 months.. if they are really good. Many takes upwards of a year.
And mostly their output is not really about incorrect code, but more likely incorrect approaches. By reviewing their code, you find gaps in their knowledge which you can then correct. They're here to learn, not to produce huge amount of code. The tasks are more for practice and evaluation than things you critically need.
I don't want to work with a junior, but I'm more than happy to guide them to be someone I can work with.
I do agree that "unlimited interns who don't improve much" is less practically useful than it might seem at first, but OTOH "never improve much" seems unrealistic, given the insane progress of the field in the last 3ish years (or think back 5 years and tell me who was realistically predicting tools like Claude Code to even exist by 2025).
Also, there's a decently large subset of small startups where there's 1 technical founder and a team of contract labor, trying to build that first MVP or cranking out early features in a huge rush to stay alive, where yeah, cheap unlimited interns might actually be meaningfully useful or economically more attractive than whatever they're doing now. Founders kind of have a perverse incentive, where a CTO doesn't need to solo code the first MVP, and also doesn't need to share/hand-out equity or make early hires quittteee as early, if unlimited interns can scale that CTO's solo productivity for a bit longer than the before-times.
> but OTOH "never improve much" seems unrealistic, given the insane progress of the field in the last 3ish years
The point is that no one should hire an intern or a junior because they think it will improve their team's productivity. You hire interns and juniors because there's a causal link between "I hired an intern and spent money training them" and "they joined my company full time and a year later are now productive, contributing members of the team". It's an investment in the future, not a productivity boost today.
There is no causal link between "I aggressively adopted Claude Code in 2025" and "Claude Code in 2026 functions as a full software engineer without babysitting". If I sit around and wait a year without adopting Claude Code that will have no measurable impact on Claude Code's 2026 performance, so why would I adopt it now if it's still at intern- or junior-level skill?
If we accept that Claude is a junior-level contribution then the rational move is to wait and watch for now and only adopt it in earnest if and when it uplevels.
Precisely - AI getting better or not has nothing to do with my burning cycles using it. My juniors do improve based on my effort. I can free ride on AI getting good enough later (wait) whereas I cannot with my own team of juniors.
> 1 technical founder and a team of contract labor, trying to build that first MVP or cranking out early features in a huge rush
Having worked in environments with a large number of junior contractors... this is generally a recipe for a lot of effort with resulting output that neither works technically nor actually delivers features.
To your last point -- I didn't say large number of junior contractors would write good code or whatever. The change that is happening in the startup scene now, as compared to say 10 years ago, is more about lowering the barrier to MVP and making it easier/cheaper for startups to experiment with finding product market fit, than anything to do with "productivity" or code quality or whatever.
We're probably just talking past each other, because the thing you care about is not the thing I care about. I am saying that, it used to cost some reference benchmark of $X/idea to iterate as a startup and experiment with ideas, but then it became 0.5X because gig workers or overseas contractors became more accessible and easier to work with, and now it's becoming 0.1X because of LLMs and coding agents. I am not making any sort of argument about quality being better/good/equal, nor am I making any sort of conversion chart between 10 interns or 100 LLM agents equals 1 senior engineer or something... Quality is rarely (never?) the deciding factor, when it comes to early pre-seed iteration as a startup tries to gasp and claw for something resembling traction. Cost to iterate as well as benefits of having more iterations, can be improving, even if each iteration's quality level is declining.
I'm simply saying, if I was a founder, and I had $10k to spend to test new ideas with, I can test a helluva lot more ideas today (leveraging AI), vs what I could have done 5 years ago (using contractors), vs what I could have done 10-20 years ago (hiring FTEs, just to test out ideas, is frankly kind of absurd when you think about how expensive that is). I am not saying that $10k worth of Claude Code is going to buy me a production grade super fantastic amazing robust scalable elegant architecture or whatever, but it sure as heck can buy me a good enough working prototype and help me secure a seed round. Reducing that cost of experimentation is the real revolution (and whether interns can learn or will pay off over time is a wholly orthogonal topic that has no bearing to this cost of experimentation revolution).
Yeah in this context I get what you are talking about. I got through your first paragraph and thought of the startup founders using overseas / gig workers a decade ago to test ideas.. which is exactly where you went!
"hired an intern and spent money training them" and "they joined my company full time and a year later are now productive"
Why would I do that if I can have sombody else pay for the training then poach them when they are ready?
What are you doing to actually keep them at your company? I left a company after they invested a lot in training me. They gave me very little raises and already paid poorly, no guaranteed bonus, bad vacation hours, and no opportunities for promotion. They were shocked when I left, even though I had asked for very modest raises and was way more productive than the "seniors" at the company.
Most companies outside of FAANGs treat their talented juniors like crap, so of course they'll leave.
Which is exactly why no one's hiring juniors anymore. It made sense back when the market for hiring engineers was super competitive and it was easier to gamble on being able to keep a junior than it was to try to snag a senior. But now that there are seniors galore on the market who would bother with a junior?
> Also, there's a decently large subset of small startups where there's 1 technical founder and a team of contract labor, trying to build that first MVP or cranking out early features in a huge rush to stay alive, where yeah, cheap unlimited interns might actually be meaningfully useful or economically more attractive than whatever they're doing now
That's when experienced developers are a huge plus. They know how to cut corners in a way that will not hurt that much in the long term. It's more often intern level that are proposing stuff like next.js, kubernetes, cloud-native,... that will grind you to a halt once the first bugs appear.
A very small team of good engineers will get you much further than any army of intern level coders.
Yeah "actually good engineers" are like a 10:1 ratio with intern/new college hire/junior consultant level.
Not to generalize too much but if you are contracting out to some agency for junior levels, you are generally paying markup on coders who couldn't find better direct hire jobs to start with. At least with mid/senior level you can get into more of a hired-gun deal for someone who is between gigs/working part time/buy a share of their time you couldn't afford full-time.
In fact most junior consultants you are basically paying for the privilege to train other peoples employees who will then be billed at a higher rate back to you when they improve.. if they don't move on otherwise.
Disagree. Some learn, not all and decreasing numbers career to learn
Also most juniors have no idea how to write tests, plan for data scale, know which IPC-RPC combo is best for prototyping vs production
Etc…
90% of software is architecture and juniors don’t architect
> Disagree. Some learn, not all and decreasing numbers career to learn
This is an organizational issue then—someone who is operating at a junior level who demonstrates that they don’t care to learn should be let go.
We’re saying the same thing
The business threshold (willingness to pay for something) for the worst automation will eventually beat the marginal expert.
So there becomes no business differentiation between a junior and a middle engineer
“Architecture” becomes the entry-level job
But they are so cheap, and they increase the headcount on my pfiefdom chart.
Yes, a combination of empire building and "but $X exceeds the $Y cap set by HR for Z role! / we can hire XX juniors for this price!" type of mega corp thinking.
Bingo! Not to mention that "dealing with juniors" is one of the critical ways for a senior engineer to grow.
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…
> 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…
How will you make new senior, staff, and principal engineers without "having to deal with a junior"?
You hire seniors from other companies ofc.
You don’t in the long term
It’s just like “calculator” used to be a manual human job in engineering
Los Alamos, NASA etc… literally had 100s of individual humans running long calculations that computers didn’t have the memory to handle
There are no more human computers
> 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…
Hm, interesting. As someone who has found zero joy and value in using LLMs, this rings true to me. Setting aside the numerous glaring errors I get every time I try to use one, even if the tools were perfect, I don't think I would enjoy using them. I enjoy programming, thinking about how to break down a problem and form abstractions and fit those into the tools the language I'm writing in gives me. I enjoy learning and using the suite of Unix tools like grep and sed and vim to think about how to efficiently write and transform code. The end product isn't the fun part, the fun part is making the end product. If software engineering just becomes explaining stuff in English to a machine and having some software pop out... then I think the industry just isn't for me anymore. I don't want to hand the fun part over to a machine.
It's like how I enjoy going to my wood shop to build tables instead of going to Ikea. It would be cheaper and faster and honestly maybe even better quality to go to Ikea, but the joy is in the knowledge and skill it takes to build the table from rough lumber.
"As someone who has found zero joy and value in using LLMs"
I love programming but find zero joy in front-end coding. For me LLM's solved that bit nicely. I'm sure a real webdev would do better, but I can't afford it for my personal projects and the LLM helped me to get it done more than good=enoug for my needs.
Software at scale is a business function
You’re describing a hobby/artistry process
You can still do all that, the same way that you can still build a table at your house.
But the number of number of handmade table builders is going to drop to effectively zero for the majority of table building going forward
I'm not sure I agree that will happen, but if it does, then yeah like I said, it's probably my cue to exit the industry. If the fun goes out of the job, there's other things I'd rather do than sit inside alone and stare at a screen all day.
What the heck, the code generation _is_ absolutely still a bottle-neck.
I dare anyone who making these arguments that LLMs have removed the need for actual programming skill, for example, to share in a virtual pair programming session with me, and I will demonstrate their basic inability to do _any_ moderately complex coding in short order. Yes, I think that's the only way to resolve this controversy. If they have some magic sauce for prompting, they should post a session or chat that can be verified by other (even if not exactly repeatable).
Yesterday almost my whole day was wasted because I chose to attack a problem primarily by using Claude 4 Sonnet. Having to hand hold it every step of the way, continually keep correcting basic type and logic errors (even ones I had corrected previously in the same session), and in the end it just could solve the challenge I gave it.
I have to be cynical and believe those shouting about LLMs taking over technical skill must have lots of stock in the AI companies.
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.
>I can’t square my own experience with the hype machine.
Me neither. My gut feeling is it's the inexperienced who gain the most from generative AI. That does seem to be confirmed by papers like this:
https://mitsloan.mit.edu/ideas-made-to-matter/workers-less-e...
At most I've found it helps with some of the routine work but saving a few minutes typing doesn't offset the problems it creates.
I find it hard to believe the inexperienced would benefit at all. Ai assisted coding requires serious general experience in all matters software to get good value out of it.
I find this hard to believe- how would you even know if someone used AI in producing a PR or indie product? Are you omniscient?
Further, there are articles here on HN all the time about people using AI for actual serious work. Heres a pretty significant example :
https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-...
I dunno, as an engineer who likes to make side projects, I can say with high certainty that LLMs have helped me compensate for things I'm worse at when coding a product.
I'm good at the engineering side of things, I'm good at UI, I'm good at UX, I'm good at css, I'm just not good at design.
So I tell the LLM to do it for me. It works incredibly well.
I don't know if it's a net increase in productivity for me, but I am absolutely certain that it is a net increase in my ability to ship a more complete product.
That makes perfect sense to me. I’m finding real value in natural language search for code and docs, and “remind me how to do X.”
It’s the extraordinary claims of 10x speed and crazy autopilot that have me looking around for missing cows.
Why do that when they can ignore you and keep living in their bubble?
> 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 couldn't agree more. This has been my exact experience.
Like you I'll probably write a blog post and show, prompt by prompt, just how shockingly bad Claude frequently is. And it's supposed to be one of the best at AI assisted coding, which mean the others are even worse.
That'll either convince people, match their experiences, or show me up to be the worst prompter ever.
I think you're supposed to let the AI write the bad python code and then do the refactoring yourself. No way I'm letting the AI make changes to 150 files with tons of cross-concerns when I don't even fully understand it all myself unless I dig into the code.
That being said copilot and chatgpt have been a 40% productivity boost at least. I just write types that are as tightly fitting as possible, and segregate code based on what side effects are going to happen, stub a few function heads and let the LLM fill in the gaps. I'm so much faster at coding than I was 2-3 years ago. It's like I'm designing the codebase more than writing it.
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.)
> 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?”
What? Software engineering is about problem solving, not finding the first thing that works and called it a day. More often than not, you have too many solutions and the one that's implemented is the result of a list of decisions you've taken.
> 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.
You should really read the mythical man month.
I credit my understanding of the incredible costs relating to the increased need for coordination and the sharply decreasing return on productivity for additional people to The Mythical Man Month.
I don't take credit for the value of being able to do with 7 what currently takes 8, but rather ascribe it to the ideas of Fred Brooks (and others).
> 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.
I totally just verbalize my inner monologue, swearing and everything. Sometimes I just type "weeeeeeeelllllll" and send it, to get more LLM output or to have it provide alternatives.
It might sound weird but I try to make the LLM comfortable. Because I find you get worse results when you point out mistake after mistake and it goes into apologetic mode. Also because being nice puts me in a better mood and it makes my own programming better.
vibe coding as it were :p
I want to add something to this which is rarely discussed.
I personally value focus and flow extremely highly when I'm programming. Code assistance often breaks and prevents that in subtle ways. Which is why I've been turning it off much more frequently.
In an ironic way, using assistance more regularly helped me realize little inefficiencies, distractions and bad habits and potential improvements while programming:
I mean that in a very broad sense, including mindset, tooling, taking notes, operationalizing, code navigation, recognizing when to switch from thinking/design to programming/prototyping, code organization... There are many little things that I could improve, practice and streamline.
So I disagree with this statement at a fundamental level:
> The technical skill of writing code has been largely commoditized (...)
In some cases, I find setting yourself up to get into a flow or just high focus state and then writing code very effective, because there's a stronger connection with the program, my inner mental model of how it works in a more intricate manner.
To me there are two important things to learn at the moment: Recognizing what type of approach I should be using when and setting myself up to use each of them more effectively.
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.
> 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
This doesn't work because you still have to read and verify all of the stuff your agents produce
So the new workflow is: Move up an abstraction level to use an agent to produce code Then move down an abstraction level to review the code it produces
This sounds like way more cognitive overhead and way harder (and therefore probably slower) to do than just writing the code by hand in a good flow
There's something fundamentally different between writing the program directly that you visualize in your head versus staying one level away and reviewing someone else's code. I'm really talking about the former.
"these require deep understanding of the domain, the codebase, and good software engineering principles" Most of this AI can figure out eventually, except maybe the domain. But essentially software engineering will look a lot like product management in a few years.
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.
pretty big logic leap you made there. I didn't say understanding the domain was the only requirement. But certainly not understanding it will cause you to fail.
That's a narrow view of the issue described in the blog post. You're coming at this from the perspective of a software engineer, which is understandable given the website we're posting on, but the post is really focusing on something higher level - the ability to decide whether the problems you're decomposing and the code you're reviewing is for something "good" or "worthwhile" in the first place. Claude could "decompose problems" and "review code" 10x better than it currently does, but if the thing it's making is useless, awkward, or otherwise bad (because of prompts given by people without the qualities in the blog post), it won't matter.
You still need to be able to code to recognize when it's done poorly, and to write the technical specification.
Chap. CCCLXIV. — On the Judgment of Painters.
When the work is equal to the knowledge and judgment of the painter, it is a bad sign; and when it surpasses the judgment, it is still worse, as is the case with those who wonder at having succeeded so well. But when the judgment surpasses the work, it is a perfectly good sign ; and the young painter who possesses that rare disposition, will, no doubt, arrive at great perfection. He will produce few works, but they will be such as to fix the admiration of every beholder.
Leonardo da Vinci, "A Treatise on Painting.", p. 225
https://archive.org/details/davincionpainting00leon/page/224...
> Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase, they quit. Most people I know who do interesting, creative work went through years of this. We know our work doesn’t have this special thing that we want it to have. We all go through this. And if you are just starting out or you are still in this phase, you gotta know its normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions. And I took longer to figure out how to do this than anyone I’ve ever met. It’s gonna take awhile. It’s normal to take awhile. You’ve just gotta fight your way through. (Ira Glass)
>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).
We cannot build great things on poor foundations
If your small stuff contributes to a strong foundation for other people, then they should care
It's a shame people lose sight of the ground beneath their feet when reaching to the sky
I'm very guilty of this too, partly because any time I try to look down the people I work with rush in to discourage me from doing that - it's not part of the sprint, after all
Anyways, I am not sure what stuff you build, but thank you for being the sort of person that builds strong foundational stuff that helps other people. We need more people like you. I should try and be more like you
We have built _a lot_ of things on top of shaky foundations. It is one of the tragedies of human society, that we are too resistant to rebuilding parts and accept the status quo too easily. There are network effects at play and probably other effects as well. Basing our work on solid foundations, we shouldn't need to look towards the ground, when reaching up.
I remember reading a rather silly fantasy book, back in the '90s.
It was obviously written by a UNIX guy, and it featured a software geek that gets transported into a realm where magic works.
He then started to build a foundation of spells, even giving them UNIX names like "Grep," and "Sed."
It was all about how he built a powerful magic system, from scratch, starting with basic components, and combing them, into more ambitious components, and so on.
Most of my published work is components; usually, Swift Package Manager packages. Each one is carefully written and documented, then tested like crazy. It means that I can leverage them, without a second thought, as to Quality, or features.
Here's what I'm working on, now[0]. It still has a long way to go, but it's coming along nicely. It's a "swipeable" tab bar controller, so that iOS apps can behave like Android apps. I have been doing this by hand, in many of my latest apps, and I thought that it was a good candidate for commoditization.
I'll spend a lot of time, testing and documenting it, so it will be a "drop in" module that I'll be able to use for future apps.
[0] https://github.com/LittleGreenViper/SwipeTabController
I actually don't get what your tool does. I don't use MacOS, so maybe that is why I don't get it. If you could add screenshots of the tool in action, that could be helpful.
Oh, it’s still a work in progress.
There will be plenty of stuff soon.
> We have built _a lot_ of things on top of shaky foundations.
[Technical] debt is a choice, and the gene that makes "perfect" the enemy of "good" misses opportunities for inheritance!
As a dev--as an adult!--I still need to learn to relax and embrace shaky foundations--and technical debt!
One of the things that we learn, as we mature, is that "It Depends" is a mantra for life.
A good filter is the "How Important is It?" filter.
If I'm adding dependencies to an app, a styling dependency is less crucial than an algorithm one. I may just apply some fairly basic checks to a styling dependency, and maybe use injection, to make it easy to swap out. I may also look for free, or low-cost ones.
For the algorithm, which may be my bread and butter, I might be a hell of a lot more demanding, and I may consider using a commercially-backed product.
I sort of touch on that, in this posting: https://littlegreenviper.com/concrete-galoshes/
> It's a shame people lose sight of the ground beneath their feet when reaching to the sky
Shakespeare:
> 'tis a common proof \ That lowliness is young ambition's ladder, \ Whereto the climber-upward turns his face; \ But when he once attains the upmost round, \ He then unto the ladder turns his back, \ Looks in the clouds, scorning the base degrees \ By which he did ascend.
(Brutus, of Caesar, Julius Caesar)
No problem!
You can always check my HN account page, for more info. I deliberately tend to be a bit shy about discussing some of that stuff in public forums.
>>> 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.
“The reason the gentleman is called worthy is not that he is able to do everything that the most skillful man can do. The reason the gentleman is called wise is not because he knows everything that the wise man knows. When he is called discriminating, this does not mean that he is able to split hairs so exhaustively as the sophists. That he is called an investigator does not mean that he is able to examine exhaustively into everything that an investigator may examine. He has his limit.
In observing high and low lands, in judging whether fields are poor or fertile, and in deciding where the various grains should be planted, the gentleman is not as capable as a farmer. When it is a matter of understanding commodities and determining their quality and value, the gentleman cannot vie with a merchant. As regards skill in the use of the compass, square, plumb line, and other tools, he is less able than an artisan. In disregarding right and wrong, truth and falsehood, but manipulating them so that they seem to change places and shame each other, the gentleman cannot compare with Hui Shih and Teng Hsi.
However, if it is a question of ranking men according to their virtue; if offices are to be bestowed according to ability; if both the worthy and the unworthy are to be put in their proper places… if all things and events are to be dealt with properly; if the charter of Shen Tzu and Mo Tzu are to be suppressed; if Hui Shih and Teng Hsi are not to dare to put forth their arguments; if speech is always to accord with the truth and affairs are always to be properly managed — it is in these matters that the gentleman excels.”
— Hsun-tzu, Chinese (300–235 B.C.)
To put it simply, "it's easy to do well with tasks that are easy for you."
This is how you make sure to produce good work while simultaneously halting the development of your skills.
A similar debate has happened in education where people seem to think that having ability to critically analyse texts is more important than knowledge. and to some degree that’s true but personally I think that without building on some decent level of foundational level of knowledge and having a mental model of a subject, you can’t tackle thorny questions because you don’t have enough to draw upon as examples and counterpoints about how to proceed.
My current employer is currently going on a top down driven “one tech” mission and trying to rationalise the technology stacks across diverse product lines. Which is all fine but the judgement is a poor one because the biggest developer bottleneck that comes up in internal developer surveys is the corporate mandated IT things and a relatively hostile setup without even local admin rights, which make sense for general office workers and don’t make sense at all for software developers.
> a relatively hostile setup without even local admin rights
Taking a diversion into this -- how about local admin rights to a virtual VM / sandboxed machine? I imagine that would allow developers to be productive, while protecting everything that IT wants to protect.
Once you do that, I imagine everyone will discover the issue isn't actually _local_ admin rights, but having admin rights to a machine that's on the internal network and can access internal company resources. Which might mean that IT has taken a strategy that once you're inside the local network, you have access to lots of valuable goodies. Which is a scary strategy.
sounds like a containerized workspace. You can do this without a VM.
Education itself is supposed to teach us learning, not the mere facts/methods, not just the hard knowledge. Hard knowledge comes with it anyway as some sort of 'side product'. 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.
Ironicly, this is what I feel chipping away in modern collaborative developments. The appreciation of learning capability. In the self interest of the organization (short term self interest, long term is too unpredictable, so does not exists in the practice) specific technical knowledge parcticed individuals are sought out for the purpose of easy replacement: not to be dependent on personnel, have it like a plug and play component. The ability to learn is not valuable while inside the organization. Should be practiced enough for years beforehand and applied intensely after joined. For the sake of claiming evolving organization the teaching may be outsourced in a very limited time to some sort of external enterprise making money on disseminating hard knowledge with made up examples or generic (artificial) applicability, instead of doing it in the actual context of the organization. Be part of the organization. Daily. Application of the new hard knowledge in the specific context of the organization will be casual by the random enthusiast. If they can break through of the company policy and established ways of management. Eventually the policies and practicies must be rigid as well, shouldn't they, so the personnel working in the management could be as easily replacable as the foot soldiers of code. For the sake of the organization. Call this approach the Organization Oriented Development.
> 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.
Reminds me of that concept that I saw pop up in HEP in recent years between "users" and "experts".
This distinction in that case is so dumb I cannot wrap my head around it: You first encounter the code, are unfamiliar with it but very quickly you become expert in order to solve your problem and advance the thing forward.
It does not matter which codebase you start on, what matters is that you understand what the actual stack does and what is involved in there because people are supposed to understand deeply what they are doing.
But this comes from the "corporatisation" of every single entity, where random metrics are used in order to assess performance instead of asking the simple question of "does it work" or "does it need fixing" or "will this thing break".
There is a clear disconnect between the manager type people that are removed from the work and the managers still doing things practically, which understand what the stressors are and where some work of deep understanding and extra contextualisation of the systems, is required, in order to not mess the whole thing up.
This being said, this is coming from a very peculiar perspective and with a very specific tech stack which is and is not industry standard at many levels...
High-energy physics?
Yes, sorry I should not have abbreviated that... Professional deformation...
Pas de problème, merci beaucoup!
I would argue that this is already true in roles where one supervises the work of another person with skill. Great leaders, for example, were once practitioners. Over time their skills may fade, but their judgment makes them effective and able to the scale their impact.
In software, we promote good engineers to management, effectively accelerating the Peter Principle.
It doesn't have to be that way. Management skills are not an outgrowth of the skills of the managed, but orthogonal to them. This is similar to the lesson many PhD candidates I've known learn: expertise in their field is not pedagogical expertise. Companies who promoted from within used to provide training for new managers.
> In software, we promote good engineers to management
i've not seen this. Infact its the opposite.
You've seen good managers promoted to engineers? ;) I have seen this happening, usually the engineers with the best technical AND people skills are first made lead developer, and eventually "team lead". After team lead they can climb the corporate ladder with titles like "junior vice president" or "senior director".
AI works great for providing you a starting point, and giving a big picture view of how certain things work, and how you should structure them.
Sometimes, even if you're a really seasoned software engineer, you'll encounter something you haven't seen before. Maybe to the point that you don't really even know what to search for to get started. So instead of spending half a day scrounging various forums, e-books, etc. you can ask the model, in somewhat vague terms, what you're looking for - and some of the LLMs are quite good at just that.
Now, the implementation of such things, not quite there yet. My experience has been that the more obscure the problems you deal with, the more obsolete code the model will spit out - with dead and unsupported libraries etc.
A side note to the general point of the article, but I hate how the tech industry uses the word "democratization" to mean "lowering the barrier to entry". These concepts differ from each other but many use the former term because in doing so they justify their actions as driven by some sort of moral imperative when in reality, the development of LLMs is morally neutral, not inherently bad by any stretch, but as much a wealth and power play as any other technology of the last 25 years.
I agree with you however I've also not found a better substitute. Any candidates?
Judgement and technical skill go hand in hand. Technology merely moves the boundary of what is considered judgement, and what is considered technical skill.
I know someone who wrote programs in the punch-card era. Back then, technical skill meant being diligent and thoughtful enough that you avoided most bugs when writing the program. If you screwed this up, you had to wait for another time slot. What does this mean for the complexity of programs you could write? Well, it means you are quite limited. You can't build judgement about things above what is now considered a very basic program.
I learned to program before the AI era that seems to be nascent. Technical skill means things like being able to write programs in python and c++, getting many computers to work together, being able to find hints when something goes wrong, and so on. Judgement now covers things like how a large swarm of programs interact, which was not really in scope for punch-card guy.
Now AI arrives, and it appears that we are free from technical skill problems. Indeed, it does fix a lot of my little syntax issues, but actually it just moves the goalposts. There's soon going to be no excuse for spending time working out the syntax for a lambda function, you'll be expected to generate a much more complicated product, for which you will need an even higher overview to say you are providing judgement.
AI can draw blueprints of a house. The house may look aesthetically pleasing, but if it can't hold it's own weight, the design is flawed.
There's a difference between an executed image and a display-only image.
At a certain point, judgment requires technical knowledge.
[dead]
This blog post shows how not to use AI. The author would have been unlikely to write such a uselessly redundant conclusion if they had to type it themselves.
Edit: I like the post, but it didn't need to be padded with fluff.
We shouldn't be too quick to jump to "AI did it." People write redundant paragraphs and sentences in articles all the time because they're led to believe that every article needs a conclusion that sums up what's already been said. Ironically, including one in this article showed a lack of good judgment, which isn't confined to AIs.
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.
Where do you think LLMs learn to write “uselessly redundant conclusion”?
Writing musical notation doesn't strike me as technically difficult but I'm unaware of any musical composers who weren't proficient in at least one instrument.
Good judgement is only accessible to those who've invested considerable time in the rudiments.
And what is that judgement based on? Jobs that an AI can't do yet, like designing a system architecture and drawing boundaries (which features go in the same service), need someone with experience.
We can apply this to all points in the Future of Work section. Even the conclusion "What should you do, and why?" is basically a disguised "What domain-specific knowledge do you have to make an informed opinion on the 'why' anyway?"
This reminds me of Asimov's Jokester story where the same themes are explored - there is an all-knowing computer but someone needs to ask the correct questions.
"Early in the history of Multivac, it had become apparent that the bottleneck was the questioning procedure. Multivac could answer the problem of humanity, all the problems, if it were asked meaningful questions. But as knowledge accumulated at an ever-faster rate, it became ever more difficult to locate those meaningful questions. Reason alone wouldn't do. What was needed was a rare type of intuition; the same faculty of mind (only much more intensified) that made a grand master at chess. A mind was needed of the sort that could see through the quadrillions of chess patterns to find the one best move, and do it in a matter of minutes."
That chess metaphor didn't age well
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.
The problem is - you can't judge if you're not skilled.
So still, get skilled. Learn everything first hand. Try to master it.
That's how our species prevailed in the first place.
CERT advisories are evidence that skill is necessary but insufficient. There’s a lot of code. We get ping ponged between various sections of the code every few weeks. Other people are contributing. There’s a ton of ways code can look like it’s probably correct and not be. There are non obvious bugs everywhere, and there’s an element of luck to whether you’re in the right headspace to catch them all.
When your judgement tells you “this is wrong”, you may need the technical skill to know what instead is right.
The real question is when AI will surpass the average human in both judgement and technical skill.
AI enables me to gold plate _everything_ I do, which feels exhilarating, if a bit exhausting. Having decent taste and being able to continuously test and verify my work allows me to smooth over the occasional hallucinations and elicit towering, mind-bending solutions.
AI's no replacement for experience; garbage in-garbage out.
When AI gets too good, I figure people will cloister to stop feeding the beast. It can only lead to ignorance and misery, I fear.
Can you elaborate? What kinds of things are you doing, maybe something related to programming? What part of the job do you delegate?
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.)
What do you mean by gold-plating? What does not gold-plating look like?
Nothing stopped anyone from hiring 10 to 100 offshore devs for every American software dev for the last 20 years. Yet Google, Amazon, Microsoft, and so on paid top dollar for the Americans.
And American business still pays top dollar. Even more than before. The judgement was always the problem. If the issue was bodies in seats the problem was already solved.
The #1 cause of layoffs in America is offshoring caused by Zoom and other telework tools perfected during COVID. AI is a convenient excuse.
Pop music is mostly not about music quality - hits are always passable - but about celebrity. The rare song that elevates a new artist quickly converts them into celebrity, which converts future songs in their style into further hits 100,000x easier than before. Maybe even 1 billion times easier than before given the amount of songs created every year. Yet AI is supposedly an expert at generating music, and images, and video, and code, and on and on.
I’m not seeing the evidence of layoffs from AI. I’m seeing evidence of better productivity from existing employees, which is the same result of every groundbreaking technology since all time.
The thing that stopped people from hiring 10-100 offshore devs per American dev lead/architect was communication primarily, with quality floor being an additional factor. Plenty of American companies have "hired 10-100 offshore devs" per American lead/architect, but they call it a foreign office, 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.
If AI can solve the communication and quality floor problems (it's pretty close), having 100 agents per dev lead/architect becomes perfectly viable.
> 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.
> Pop music is mostly not about music quality - hits are always passable - but about celebrity.
Interesting and bold statement. How do you distinguish the two?
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
It would be an interesting experiment to have a global music star do a Richard Bachman.
The Eno quote is good, but the post adds nothing to it! If anything, I think the sections after the quote make the post worse. This shows poor judgment on the part of the author.
Very thin article. The thesis might as well be that technical competence is gone and judgement is all that’s left.
I file this under the category of AI musings on the inevitable massively changed landscape that AI has wrought.[1] I get the feeling that the content itself is secondary (again: the thesis is thin) to the motivation of writing about how AI has supposedly changed everything forever. In this case: now technical competence is dead, hail the king (judgement or whatever).
[1] “I’m learning that every topic that people read should be about AI.” : https://news.ycombinator.com/item?id=44082683
As the marginal cost of writing code decreases, the opportunity cost associated with writing the "right" code increases dramatically
Music was never an issue of skill. You might have needed skill in order to get to the point where you could use your judgement, but skill was never the deciding factor. So, I don't agree with Brian Eno's point that there has been some kind of seismic shift when it comes to this. Rather, it's just a matter of a shift in the type of skill that you need to have. The same is probably true when it comes to AI tools within the field of programming.
Getting a seat in a symphony involves skill. Brian Eno didn't just do rock.
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.
Human judgement is like a house built on sand, it is basically provably feeble [0]. I've literally never in practice seen a human update their beliefs using Bayes' formula. I suspect we'll find that at some point fairly soon AIs will just have better judgement than us because they can be programmed to incorporate formal statistical concepts while humans have to rely on evolving grey goop which we haven't quite mastered. I imagine it'll be almost comical watching human experts going up against a system that can actually intuit the difference between a 60% and 70% chance of something happening in their risk calculations.
Humans will still have a role expressing preferences and subjective questions though. Questions like "how much risk do you want your investments to take?" or "does this look good?" ultimately can't be answered by AIs because they depend on the internal state of a human.
[0] See also, the academic field of psychology
> I've literally never in practice seen a human update their beliefs using Bayes' formula.
Then you've never debugged anything genuinely difficult.
Moving from "Where did I screw up in my code?" to "Is this library broken?" to "Wait, that's not possible. Let's look at the compiler output on Godbolt." to "Are you kidding me? The SPI system returns garbage in the last bit for transactions of 8n+1 bits?" (BTW, Espressif, please fix that in the C6. Kthxbye.) is all about establishing ground truth and adjusting your Bayesian priors as you gather evidence.
If there is one thing AI is currently shockingly bad at, it's updating its assumptions when it is confronted with evidence that they are incorrect. It will tirelessly spin its wheels (seemingly) forever laboring under a false assumption, running into dead end after dead end without ever coming to the conclusion that it should reexamine its assumptions.
Humans may not update like Bayesians, but we read context, shift priorities, and act under pressure. Judgment isn't just math — it's lived experience, intuition, and meaning in motion. That’s still hard to replicate.
Today, if someone uses LLMs for code generation, he/she will probably question the generated code and will put his own judgement above it. I am curious how fast that will change, especially for juniors. When will they start to question their own judgement and just go with the generated code becuase its "more safe"?
At present, when juniors do this at my company, they usually get fired within the month. The onboarding docs now explicitly state that though code review is a joint-responsibility process, you as the submitter are responsible for understanding it, ensuring it all works, and being aware of the broader scope and consequences. Maybe many companies have placed more responsibility on the reviewier to catch problems in the past?
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.
LLMs are very good at sounding right. I’m sure the code generated from them are rarely reviewed by junior developers. Even if they did question it i bet they give the LLM the benefit of the doubt. “Well the computer said this so it must be right otherwise it would be a bug and I bet Anthropic has caught all the bugs…”
Probably when the generated code is, on average, better than human-generated code. Somewhere between 1 and 10 years out.
Does the technical skill give you better judgement though? Can a masterchef make better Star Trek replicator meals?
I think the reality is that, this notion of "democratising" various technical mediums is used to gloss over that, as countless studies have now evidenced, humans primarily learn and remember well thing by doing things, not merely passively consuming them. Fine-precision decision-making will likely always be the domain of dedicated tooling designed to better correspond with the particular medium or task -- that is, manual testing and experimentation, not relying on logocentric prompt idolatry.
When we get into literature, visual art etc. it becomes more of a problem. You can't get Cormac McCarthies or Mars Voltas from software designed to give you perfect statistical 50% grey, and people who try and hack it without doing the reading, are going to end up writing gibberish. People who actually enjoy and like art, music whatever are going to grow Very bored with the overwhelming majority of work reliant of primarily generative methods, save for those who already have discretion learned through experience of many tools and other means of expression.
Yes, really good pianist often compose music that is interesting, that other composers don't make ( e.g. Listz, Alkan ).
In jazz, nothing can replace practicing your improv skills.
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.
I think what and how are so tightly linked, you need to know how to make a thing so you better know what thing to make.
Let's say you want to build worlds fastest car. You can order the pieces and maybe build a car from someones instructions. But to know what makes car fast and how to build it you need to know more and more intricate details. Physics, material science, 3D printing, engineering. How do you measure traction? What shapes increase downforce?
That is how I see AI tools. You can get "off the shelf" ideas on different things, even complete small things, but you really need to be or grow to match the challenge you are facing.
I think, the argument would make more sense if software like Cubase came with unlicenced samples from all songs out of the box. Artists sued and won when someone used their samples without permission.
If you use AI to create art, it's like that.
There's a difference between a sample and something inspired by something but also significantly different. The copyright laws around music are kind of draconian so it's not a good analogy for code anyhow, imagine a world where a fundamental do while loop had 90 year copyright protection, and that's the sort of world we'd be living in if code copyright was like music copyright.
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.
Grok3: "The phrase "There is no royal road to geometry" is attributed to the ancient Greek mathematician Euclid. According to historical accounts, particularly from the philosopher Proclus, Euclid reportedly said this to Ptolemy I Soter, the ruler of Egypt, when the king asked if there was a shorter or easier way to learn geometry. Euclid's response emphasized that geometry, like any rigorous discipline, requires effort and dedication, with no shortcuts even for royalty."
You can use AI as a royal road, but it may or may not prove an effective substitute for the learning required to provide judgement.
Have people noticed the ai-assisted code "creep"? Cursor now by default applies its changes before you've even hit accept, and the tab autocomplete is getting out of control. Sometimes I'll have my cursor resting on some block of code, then suddenly Cursor suggests I delete the whole thing.
This doesn't actually sound encouraging. Judgment is not actually independent of skill, and the sort of music that this approach produces (i.e., nearly everything you hear on the radio these days) is a pretty solid proof of that.
I agree with the premise; but the lists sound suspiciously AI-like.
"Understanding what's worth making in the first place": Pretty good
"Evaluating quality": Could be a lot better.
"Anyone with access to AI tools can now produce work that, _at least superficially_, resembles professional output."
Key quote, emphasis mine.
Yeah but, you can't make a judgement in these technical areas without the technical skill... No?
The tooling problem is 90% solved. The new technical bottleneck is human judgment.
It takes skill to see the beauty
I love these little anecdotes because they always pre-suppose that everyone - the writer, of course, but also the reader - themselves are the people who don't lack judgment, which is a role they relegate to, perhaps, a particularly incompetent co-worker, or even unknown and faceless "drudge".
Which is to say that there's an obvious affliction of narcissism at work that precludes good judgment.
[dead]
[dead]
[dead]