International Olympiad in Informatics (IOI) Gold Medalist here. I too did competitive programming for years. I pride myself on writing beautiful code that is succinct, effective, and efficient.
Yet I find myself using AI coding agents more and more. In this day and age, your choice is to either use them, or be stomped into the ground by programmers who do.
AI still can't write code at my level of quality, but it can do so at adequate quality now; and sadly, that is "good enough" for the real world.
I've made many friends and acquaintances over the years who are top notch, some world class, programmers.
I'd say that 90% of them are very excited about using LLMs for coding. They have nothing to prove to anyone and can easily steer AI to reach "godly" productivity (please note these guys were 10x programmers already).
I also know some weak programmers and most of them tend to be critical of AI and want to get rid of it.
Lastly, a couple of people I know are against AI for moral/ideological reasons without denying it can bring productivity increases.
This is purely anecdotal but I'm starting to notice this pattern everywhere I look.
All I want is an explanation of how you're all reliably getting good enough (or better) results from LLMs. Surely us AI critics are doing something wrong, something much more specific than needing to "prompt harder", if we accept the framing that 90% of world class programmings are achieving that, while the rest of us are not. There simply has to be some specific, repeatable, and yes, teachable thing we're missing. So what is it?
Try requesting a feature from Opus 5.5 high that would take you a day or two to implement and test well. It'll work for 20-30 minutes or so. Then ask it to review the changes with a sub agent of itself and with Codex Sol 6.1 high. Then let it address the findings and iterate the review/fix cycle until the reviewers are happy.
Anecdotally, for small tools and projects, it can crank out functional tools that would take me days or weeks to remember how to do manually. Every time I ask LLM to write something, it also writes tests and validates its code against known values. I additionally spot-check the LLM's code against my own known values in prod, and have had to correct it on some functions. The code I write is mainly analysis of logs and configurations, and they seem well trained on the products that I am using.
Testing. It's all about having unit tests, and known outcomes that the LLM can check against every time it makes changes. For my work, that is good enough. For safety-critical systems I would demand more rigor in the testing and the human review and creation of tests.
Most senior developers that steered juniors or interns in the past, are able to work with LLM's.
Sure, LLM's are unreliable. So are juniors.
Sure, LLM's code quality is not always great. Well, so is the juniors code.
The benefit of LLM's is that they can work super fast and have a vast amount of knowledge. The benefit of juniors is that they actually learn from their mistakes and get better over time. LLM's stay at intern/junior level, even with the correct context.
So for me, I see each LLM session as a new intern coming in. You hand them the right context, give them the correct instruction, and off they go. Then they come back, and you will have to judge how detailed you want to review what they produced. Or in other words, can you get away with some bad code? And for the next session, it's a new intern that starts from 0.
But it is also highly dependent on the project you are working on. If it's a big complex codebase, LLM's will struggle, and they can only do simple tasks (however, they can help with testing a lot!)
So the teachable thing is unfortunately experience:
- Know where quality matters, and where it doesn't
- Know what kind of mistakes could be made and should be checked for
- Know which things can be duck-taped together, because they live at the edge, and which things need a proper foundation, because the rest builts on it.
So in the end, I think it all comes down to making the right trade-offs and the right decisions (which LLM's are terrible at, by the way). And unfortunately that is gained by the slow process of experience.
I think it's very tough for junior developers right now, because they either go fast by letting the LLM's do the work, but then they learn nothing. Or they go slow by asking the LLM's what's going on, and then do learn.
A senior developer never understood the full code-base, and never reviewed every line of code. That's just impossible. And now every developer needs to be a senior developer that is able to steer these new "interns".
And just like with juniors and interns, you have to put a lot of effort into it, and it's not always clear in the end if you gained or lost time :D.
One thing that stood out in that comment: You said "you like" the act of programming elegantly and understanding the problem.
There's nothing wrong with that. Many of us do (or did) like programming and the problem-solving itch it scratched for us. But getting work done for pay is more than what we like. If an LLM can reliably solve a problem for me in a day that would have taken a project, a team of several people, and close to a month of work to build out manually, then I go with the tool that works.
And that "if" is the reality I live in. About a decade ago, I wrote a program to do analysis of config files for a product our team uses. It took me weeks of side-work to implement the idea of passing boolean python functions as checks for the configuration. Such an elegant way of creating new checks on our system! It was company work, and when I left to a new place, I didn't have that code, just the idea. Fast forward five years and I want to write the same thing at a new place. I asked an LLM to do the same task, and it wrote exactly my solution immediately. It just worked. It shocked me. In the last few months, I've had it write analysis tools against this product that would have taken me days or weeks. I am admittedly not a comp-sci level programmer.
There is no denying that LLMs are powerful coding tools. That can be true at the same time that we lament the end of manual-coding-for-pay, the death of programming education as we know it, and the worries about employment and society.
I don't claim LLM's and juniors are the same. I claim that working with LLM's and juniors are similar. If you are able to work with juniors, you are probably able to work with LLM's.
To comment on the post you linked:
I agree that people can be thought. But on the other hand, I also had juniors that reached their limit pretty fast, which can also be frustrating. The best way to "teach" LLM's is the context, but I agree it has limits and is not really teaching anything, just steering them in the right direction every time (like a checklist).
Your comment basically states that running LLM's is a gamble, but according to my experience, most of the time it delivers what I ask. Maybe in a different way that how I would do it, but I want results, and am not interested in micro-managing.
Are you working on a project that requires high quality code? Or is it your preference to work in such a codebase? For me, I was always ok with "good enough" code. And sometimes "good enough" needs to be good, and other times you can get away with some really bad code.
I feel like code quality is important when humans have to reason about. However if the future is machines managing the code then all that matters is AI understanding it.
The only danger is losing grasp of internal components of the system, but maybe there'll be a "management" layer eventually for humans.
I don't know what the future of programming will look like but I don't see us rolling back the clock to 2021..
Who cares about the theory? The fact is that the world is now worse due to LLM use.
And it's not just restricted to software. Everything I care about is getting worse.
Dribbling about how it could theoretically be better doesn't help undo the damage. "Imagine how much fun we could have playing baseball", says the man with the baseball bat, as he kneecaps you.
A phrase I've been toying with is eyes free vs hands free coding.
The distinction is important. While I too hardly write code these days, I do continue to make smaller changes and look at what's being done. This is as opposed to the group who has decided vibing mega commits is a good idea.
I am not doing small changes though, I add large features or refactors daily, which involve changing hundreds of files and thousands of lines, even if I wanted I couldn't review everything by hand.
I have done this too, for side projects, but I see the limits. Discovering what happens when we do this was one of my intentions and why I hold my opinions.
For these projects I make regular time to look through the code and do cleanup phases.
So you're saying simultaneously, the code is "higher quality than ever", but you also haven't even looked at the code to see its quality. Classic. I think you're mistaking quantity for quality.
AI is a hammer, problems are the nails. At the end of the day, you still need someone to swing the hammer. Aside from the occasional overstretch of scope and “reining it in”, the real bottleneck is humans.
We have more freedom than ever to build whatever we dream of, you still need a dreamer. And that’s why the profession of coding isn’t going away, you still need people to turn ideas into reality. I find AI soulless, it’s great at mimicking but is incapable of coming up with an original idea that wasn’t yours regurgitated.
When am I (as a user of a lot of software) going to start seeing any results of this unprecedented productivity gain?
This thread is full of 100x supercharged programmers, so why is it that I can't name a single useful feature added in the last 5 years in e.g. macOS, Windows, Firefox, Chrome, YouTube, VS Code, YouTube, Slack, Photoshop, Word or any of the other 5 programs currently on my taskbar?
The productivity gain is invisible using your metric.
What I have seen is that, with LLMs, an entire class of process brokenness disappeared in the in-house codebase. Before, there were many trivial tickets that, in the end, required a 5-line bugfix sitting in the queue for months. Now, such tickets are resolved instantly, and the backlog is shrinking.
Because the code is and almost never was the problem. Product design and business involves a lot more than code.
Personally, I did see a lot of entry-level products having a lot higher quality and better UX. At the same time, most companies go for fast iterations and are profit-focused, do product quality is not really a target for many.
I insist on reviewing every line of code. But in the last few weeks I realized that LLMs are simply better than me at reviewing code too and I'm just finding excuses to not do the real work, which is to write more prompts.
I have been asking LLMs to review/edit prompts since GPT4o era, so I really don't know what the point of this snarky comment is.
Since GPT4o, I have been convinced that most of the digital work would be done by AI and humans' job is to "move the chairs around to not block AI's way." It's a given to me. I'm just debating whether reading the code makes me a better chair-remover.
Don’t think it was snarky. My guess is op is just suggesting that you could automate further, but you are ratcheting toward it one step at a time while op is suggesting to allow the ai more autonomy.
Here is something I found this week: copies the entire db to memory, inserts a single row into in-memory db, deletes everything from real db, writes everything back. Sentence that caused this is "do XXX in one transaction".
All tests pass, everything seemed to work. Would not have noticed of I didn't read through the code. Amount of other stupid shit I found is crazy.
These anecdotes mean little without knowing context, model, harness, prompt. The technology has moved a lot in the past year, and does require some adjustment.
My very first experience with OpenCode led to a `rm -rf /` within minutes, which I caught by chance watching the output stream in. Yet 99% of my code is currently written through an agent.
A performance benchmark would have easily caught this though, ask the LLM to create and run benchmarks and see how those change after each new feature/major change.
Also to make it clear, I am not saying the code itself is better, but the end-product and what the user sees and gets. Like that saying "if it's stupid, but it works, then it's not stupid"
Because the exact same processes that create it faster, are also now generating large comprehensive test suites, and data-validation suites based around the actual business requirements and data/edge cases.
In essence, it is writing the code faster (great), but then also writing the code that was often previously never written due to budget/time limitations (comprehensive testing/validation).
So, how do you know the code is the highest quality ever? Because we have test result data that PROVES it to be the case. It isn't "trust but verify" it is "Don't trust. Verify."
This is my observation as well. I thought I was good at testing (I wanted to be good at testing), but the models are just better at it. Testing in particular rewards a tireless cataloging of the tiny and the tedious and in this respect LLMs are unmatched.
Single data point, my Sentry notifications across more than a half dozen client projects when from 2-4 a month to basically 0. That's while shipping 20x _more_ code.
Yeah but you don't test for stuff you don't know you have to test for. All tests can pass and internally its still done in a braindead way that will explode at some point.
Absolutely, and this is exactly why humans are weaker than LLMs. We consider what is likely, they consider what the data/logic shows is possible. So you get edge cases tests/flagged, that wouldn't even be something a real person would know to look for.
You must have replied to the wrong comment, since the one you did replied to never claimed that the test and validation suites were "never looked at." They are reviewed, and the test/data results are reviewed.
> Because we have test result data that PROVES it to be the case.
pgrust thought this too, but then another human discovered claude had hardcoded benchmark query plans.
Now pgrust has a "test" [1] to make sure the Ai doesn't do this again (unless it decides this test is bad for the current goal)
I have a growing list of these, another notable one is OpenCode having a security regression [2] because the Ai redesigned configuration loading for v2.
Real verification seems beyond transformer capabilities.
Very little code written in the world day to day ever has to justify its 'quality' or long term value. A lot it is just one off tools, bits and bobs to make a teams life easier or whatever.
I used to work in Web agency for sizeable brands and not a single site I built lasted over a year because the companies changed concept regularly. The next agency would come in and tell them it was built wrong and couldn't be reused etc etc. We did the same, it was irrelevant how it was built and we didn't even look. This is the nature of most code. The problem is that very few people will ever be in a position to be writing verifiable important code, but every developer likes to cosplay that they are.
Most code is ultimately an, annoyance businesses need to meet a goal that will always be a cost. It's often worth treating it as such and writing things that are easy to spin up and teardown.
The people most vexed by AI dev appear to be the ones who think writing code is a pinnacle role, it's not even though over our lives the salaries would sometime suggest otherwise. That's ultimately going to be a short term blip in the landscape and most code will be one seen as the cost it is.
A programmer's output was never code. It's was just what we had to do to get computers to work for us. Now I just ask a genie to do what I did and check the results.
> I haven't touched a line of code in over 6 months, didn't even look at it, but the work I do is faster and higher quality than ever.
Well that doesn't make sense if you are writing code that is going to be used on critical infrastructure.
Imagine a disaster were to happen and you said to the auditors that "I don't know what I am doing nor did I look at the code" and you cost the company tens of millions of dollars.
Sure if your building toys, that's fine, otherwise, why take the risk in being liable for not looking at what the code does and then believing it is high quality?
Indeed, I am just building apps people use, they are not "critical infrastructure" and the world won't end if there's a small bug, I don't vibe code self driving cars, defense systems or medical devices. A
If there is a bug, it will be fixed quickly anyway, so only a few users might ever see it, or see it only for a brief time.
Even when manually coding, projects still have issues and bugs, I don't think much changes in that aspect now, if anything, there are fewer bugs now in most high quality apps than before, due to AI catching more issues. See all the vulnerabilities found in old core code and libraries nowadays, that humans didn't find.
LLMs write better code than humans with fewer bugs. They also do it much much faster so you can spend all the remaining time testing. Tests are written faster too so not only you have more time for testing but also you can use it better.
>>Sure if your building toys, that's fine, otherwise, why take the risk in being liable for not looking at what the code does and then believing it is high quality?
>>Don't you see the contraction you just did there?
I wouldn't trust anyone who refuse to use LLMs for programming. Their code is worse, they test it less and it takes longer to write. For me "no LLMs" attitude is a sign of incompetence. Good for hobbyist trying to keep their brain active but that's about it.
That is even more so for critical infrastructure. Just look at the mess human coding is when it comes to security. LLMs are fixing it at the pace we couldn't even imagine a year or so ago.
> LLMs write better code than humans with fewer bugs. They also do it much much faster so you can spend all the remaining time testing.
So does that mean you should never look at its code?
If a fault in the software occurs even after testing and there was an investigation, will you admit in the postmortem report that you did not look at the code at all and blame the agent for the error?
> I wouldn't trust anyone who refuse to use LLMs for programming.
Did I say I refuse to use LLMs for programming? I am telling you to check the agent's work.
I would not trust anyone who DOES NOT check the changes of an agent's code when using them for programming in highly regulated industries or in critical systems. For most companies in the Fortune 500, it is irresponsible to not check.
> That is even more so for critical infrastructure. Just look at the mess human coding is when it comes to security. LLMs are fixing it at the pace we couldn't even imagine a year or so ago.
No-one argued against that and it does not mean that you do not check with the agent at all even if the agent believes that they "fixed it".
This is akin to sticking to hand tools after the development of the electric motor.
There is no going back to writing code the old way. I don't see that happening in the industry, ever.
The grievances listed here are 100% real, but not fundamental - with some practice you can prompt an LLM to great effect without it taking the reins from you. If you let it write the code, it does become a management job more than an engineering job. That said, I do believe that there must be a way to structure your workflow such that the LLM becomes your read-only pair programmer/rubber duck while you yourself get to do the fun parts of coding.
> If you let it write the code, it does become a management job more than an engineering job.
I disagree. It remains an engineering job. Us software engineers got confused about what the engineering part always was. The engineering part of chemical engineering isn’t cutting piping, welding shit, or rolling metal. The engineering in civil engineering isn’t pouring the concrete, or grading the site.
Yet somehow it’s a prevailing idea that the engineering part of software engineering was typing on keys and naming variables.
Writing high-level code was never as mechanical as “cutting piping.” That’s absurd. If that’s how you thought about writing code, you were simply a bad programmer. (Or working on some incredibly boring code.)
The typing absolutely was mechanical. The thinking what you need to type is what's never been mechanical, and there's plenty of that to do LLM or not.
We took advantage of the typing time to also think, and in many ways typing code served a similar purpose to drafting your thoughts on paper. With an LLM you still think a lot and those thoughts turn into specs, prompts, plans, or whatever workflow you prefer.
I guess it's because throughout the lifetime of this profession, we have not witnessed a development like this. We went from punchcards to assembly to compilers to javascript, but at no point was it a process that would just "keep going" until you turned it off, much like a motorized machine.
I would disagree that "the grievances" are not fundemantel. The _profession_ of the programmer is about to cease to exist, much like the human computer. Sure, you can still compute without a computer and perhaps enjoy it, but you will not find anyone to pay you to do it. Whatever you think "babysitting an LLM" is, it's not programming, even if presumably programmers are fairly well suited for it.
Which is why none of us have or want job titles with "programmer" in them; even juniors are junior software engineers. As long as a human is needed to design and implement good software, they will be software engineers. The temporal affordances aren't nearly as unique as you imply, either: generated code and unit test results are two good examples of things that "keep going... much like a motorized machine".
That is, unless you treat the agents as if they were people and thus the true engineers, of course. I think that's a fascinating philosophical topic despite ultimately disagreeing, but to say the least it's incredibly controversial to even consider the personhood of agents, much less endorse it.
This is all moot anyway, so apologies if I'm rude or overly dismissive of your comment that I agree with the general thrust of. No point starting fights over deck chairs...
I have a hard time believing this. The businesses employing us and the businesses competing with them will view handwritten code as an evasion of financial responsibility. That does not mean inevitability is positive or worth welcoming with open arms. But it is so inevitable at this point.
> The businesses employing us and the businesses competing with them will view handwritten code as an evasion of financial responsibility.
If this were true, then we wouldn't be seeing the correction to reasonable limits. While I generally agree not using LLMs is irresponsible and not viable any more, I have real doubts transformers will live up to the hype projections and the end of the profession. On the other side (with too much Ai coding), there are market penalties from the users (because of Ai mistakes).
There are frequent news stories about companies that want to go capture an asteroid for mining, because it's worth "trillions" in rare metals. The companies don't seem to grasp the fact that flooding the market with a new supply said metals will diminish those metals' value dramatically. They can pump billions of dollars chasing that dream, and if they succeed, their reward will be to flood the market, and diminish the market.
LLMs feel like the same thing. They're spending billions of dollars on these machines that can flood the market with something once rare and valuable--human creativity. If they succeed, they'll just be ruining creativity and diminishing what humanity values.
I have a hard time understanding that position when it comes to programming. What is "human" about typing instructions for the computer into a terminal? Was perforating paper more human? And I say this as a programmer with 20 years of experience. The human part is the thinking and intention behind it, not the typing.
When it comes to generative art, yes, that's a much more significant issue.
Not OP, but all the choices made along the way are the human part. The understanding and creativity to solve the complex challenges that arise in an efficient way that fits into the structure of the greater program.
Programming never has had one right way to accomplish a task, and that is disappearing with agents. Why would pick Ruby for a project because it’s nice for the programmer, when the agent is the one coding? In fact, Why would anyone ask an LLM to write a new program in almost anything other than JavaScript and Rust?
Have you ever solved a problem with code? If you have, you will know why it hurts so bad to lose that ah-ha moment at that level. It's something special spending a long time on something, learning as you do it. I do understand you can get this through possibly an LLM, just different. Take a mathematician spending years on a problem. Seeing a computer do it in a matter of a second or "11 days", is devastating in a way.
Yeah, I used to get a kick out of building a perfect, performant, keyboard-accessible, a11y compliant and well-designed dropdown menu. Building my own rendering libraries. Making things run at 60fps. Optimizing server code, HTTP performance. Watch a full fleet of servers running my code in action. It was great.
Now I get the same feeling out of building an entire component library in an afternoon, running my code in a Nintendo Wii with twenty minutes of effort, hacking a LED display that I bought for €5, writing a tool to update my keyboard that only supported Windows, or building projects that would take a team of twenty engineers in the past.
We just got a power upgrade, the magic is still there.
> But there again, nobody is forcing you to use LLMs.
In the sense that I can quit my job at any time, sure. But my employer certainly requires LLM use, and even if I found another position that doesn't, I have no reason to believe that will last.
This is the commercial kitchen part of the analogy. Either you work in someone else kitchen based on their rules. Or start your own kitchen and you set the rules.
I am not denying the lack of freedom when working for someone else, or that it sucks when they impose rules on you. But that’s always been the way it goes.
The comment I replied to was about home projects and home cooking. Nothing there has to change.
If we're going with cooking analogies - I really enjoy it, yet a good rice cooker was one of the best purchases I've ever made. That's a better parallel to me.
I know right? Yet, what I said is true, and you can ask anyone who owns one for japanese/korean/chinese cooking. It reduces effort to near zero while giving 100% consistent results.
The point though, is that I don’t feel “sad” about not having controlled the temperature and time myself. It’s a tool.
I thought the same thing until I got a rice cooker. It makes cooking a little less stressful while you make the rest of your meal. I eat rice once every 1-2 weeks and I still love it.
assuming you yourself had programmed pre-LLM i completely fail to relate to your lived experience. what a devastatingly sad way of viewing the world
setting aside the craft and mastery or satisfaction in goal accomplishment: to me the main thing is a sense of actualization, of the codebase or thing you were working on being better because you were there.
have you ever put up a shelf? did it feel good after?
Putting a shelf up is not fun. Designing, building the shelf from scratch with my own vision feels way better ;). It's a lot more of a hassle but you will always look at it and be like I did that, heck you might have even learn a whole bunch doing that as well. It's easy to go to the store, buy something and assemble it (automation).
I think this perspective comes from assuming that the LLM is doing the thinking for you. And that is not the right approach IMO. The code is still mine - I chose how to write it, reviewed changes, suggested improvements, picked the architecture, directed refactoring and benchmarking efforts, tooling, scope of tests, and so on. It feels quite similar to being a project lead.
As an illustrator/animator who codes as a hobby and to produce games that are mostly just making that art interactive. I feel like AI is taking over my humanity when it’s doing any visual art or design work. But when it does code. I care much less and am just happy that I reach my goals faster.
This is very personal and I completely understand that if coding is your main thing, code by genAI feels worse.
I do fear for the future…
At least coders have been able to save some money. Visual artists are mostly broke.
I feel like LLMs are akin to a performance enhancing drug that's gained mainstream acceptance.
Everyone can run a 5 minute mile now without training. I used to like training to be able to do that, but now that it's accepted everyone can do it for free (and people don't care if you did it the hard way) the joy has been sucked out of it a bit.
Except performance enhancing drugs are banned from sports because that’s how they want it to be played (it has nothing to do with safety, look at non drugs like the LZR Racer swim suit).
If you wish to make software engineering your job then it stops being a game where we ban things simply because they provide an “unfair” advantage.
If you wish to play at programming “the way it used to be done” then by all means go ahead. But mixing methapors between sports and work is not helpful.
I guess I don’t understand the motivation you have for perusing your hobbies.
To me, the effort part only feels pointless if you want to accept LLM-derived code as comparable. Any marathon run is pointless, you go in a loop and we have cars. The point is to do the run yourself unaided.
That a computer can play a virtual instrument better than me (and continuously better than anyone) has little bearing on whether or not I continue practicing on my piano.
It's more like they are being carried in the arms of a big robot who is doing the running for them, but everyone has somehow agreed to say that the human "ran" a five-minute mile because they ordered the robot where to run.
Oh I'm fine but people around me aren't and that's from accountants, to writers, to artists(music, drawing, animating), look around you. I'm the kind of person who doesn't buy bread, I bake everything from scratch, AI won't take a lot away from me, I'm a lover and creator. I do worry though, it may take everything in a way eventually, that's the sad part if you think far enough into the future.
I'm curious, is your database work all hand-coded? Tidesdb is extremely impressive in any case, and I just saw Turborel which looks interesting. Your commit rate is pretty intense -- speaking as a hand-coding dinosaur myself, if this is all by hand too I'm now even more impressed (and a bit jealous for your level of productivity!)
I'd say they took the inhumane parts of being a programmer away and people who spend 30 years turning themselves into robots don't know what to do with themselves now.
Programmers were just the first shoe to drop. The same is now coming for the entry-level engineers as agents learn cad programming which has the same complexity barrier to entry.
We will soon trade that complexity barrier over to the agents and we won’t know how it is done, because the agents always did it for us.
> models can write code better than the average engineer
If you're not interested in "average", volume isn't going to make up for quality. I'm certainly not perfectly satisfied with LLM output quality, but even the best programmer in the world will undeniably be helped by LLM tooling, even if only for having it write tests, benchmarks, run experiments, create research summaries, and so on.
Even if you have a hard line against using LLMs to write code, for whatever reason, they are undoubtedly extremely useful for reviewing code and finding bugs. Why would you not take advantage of this?
Do I write less and less code myself? Yes. Do I read less and less code? Maybe. Does it always matter? No. Sometimes, the agent writes code in a project or section of code that is sensitive and deserves a thorough review. Sometimes, it's in a tool that you would never have had the time to write if you didn't have an agent. Or it can be in a project that is so well covered by TDD that you can be confident that it won't break. There could be performance regressions or duplication / code creep, but once you realize it, you can ask an agent to simplify the code and find ways to prevent that from happening again.
There are cleanup / technical-debt-reduction tasks that I thought would never be done in my lifetime due to lack of time and other priorities. But now, I'm blasting through them with Claude. I cannot imagine the lack of productivity I would suffer if deprived from an agent.
That said, I agree with most points the author makes. It becomes harder to grok the code, just as it becomes hard to navigate without GPS navigation once you are used to it. It is maybe necessary to force oneself to do a development task once in a while without the help of an agent in order to stay sharp.
But stop using LLMs? that sounds counterproductive.
Retired after 4 decades of programming for a living… To that end I am now a "hobbyist" programmer and not affiliated with a Corporation™ when I "ship" code. Perhaps I would feel differently if I still were.
As a hobbyist though, I find that LLMs are allowing me to tackle projects that I would not have tackled at all but for the existence of the LLM.
It's an important point to make (to me).
Many of these projects are rather tedious. (Other coders though might enjoy what this one-man calls "tedious".) I have found that liberating.
I've been suggesting my junior colleagues recently the following mindset:
for the last 5 years you have been milking cows, that was your job, and you were great at it.
But this job ceased to exist [somewhere around August this year when Opus 5 appeared]
You have a new job: you are a barista now [and you are going to serve oat milk]
You can still manually type code, it can be a great hobby, but it is unlikely that someone will pay you a full time salary for doing it
Except your job as a software engineer has never been to write code, it has always been to produce software. Whether you do this by using AI or by rolling your head on the keyboard doesn't matter, and nobody cares.
Yes, people care. Part of the job of management is not just to define what is to be done, but how it is to be done. Let's put to bed this notion of "nobody cares how you do the job as long as it gets done" because it's hogwash.
In the early 20th century, Frederick Winslow Taylor came up with scientific management, a set of principles for determining the most efficient way to perform work tasks using systematic observation and measurement rather than tradition and "rule of thumb". The problem Taylor was trying to solve was that of soldiering, or as we call it more euphemistically today, "quiet quitting"—doing the bare minimum of work necessary to keep your job. If the best way of performing a particular task were known to management, soldiering workers could be held to account for not performing as much work as they could, effectively stealing from their employers. So since that time, business has had a vested interest in understanding the best way to perform all business tasks and making that the institutional standard.
You might think "But that doesn't apply to us in software engineering/IT. We use our smarts to solve problems." You couldn't be more wrong. Milt Bryce's insight was that the exact same management principles that applied to the manufacturing and construction industries applied to information systems as well, and treating a software shop like an industrial factory would save the company time, money, and effort.
Today, it is known that, when properly prompted, LLMs write better code than humans, much faster than humans can, and test it much more thoroughly as well. So yes, your employer absolutely cares whether you use an LLM or not. What rational person wouldn't, especially if they don't want to waste time or money? Furthermore, now that LLM use has been standardized as best practice because they are vastly more efficient, if you refuse to use LLMs on the job, you are stealing from your employer. Your boss has every right to fire you, and they'd be right to do so.
Except usage of AI is not only about writing code, it produces software very often from very small intent, shallow context and few bread crumbs. And you don't need to play Planning Poker with it
- Try to prove the concept early on. When you start spinning in circles, then it might be time for a different approach
- I’ve had a lot of success with projects that have not started out as LLM codebases. And adding features one by one and testing really carefully by hand
- UI generated by LLMs are overly verbose. The key lies in the iteration. What you can cut, move or approach differently. But you have to have taste.
> "LLMs expose the literacy gap between great and mediocre coders. If you can't see how bad the generated code is, LLMs will only make you not see it faster."
I wholeheartedly believe that if the general trend in SWE goes without hiring new grads/self-taught people (who can still use AI-assistance in their work), we're gonna be seeing huge outsourcing to AIaaS companies and generally become tremendously dependent on them when existing pool of seasoned programmers goes extinct and the work doesn't intrigue training new people.
Although there is cheap, open source models running locally or available at scale on reasonable prices without compromising programmer integrity.
Genuine question: Will you also reject the results and fixes regarding the current PHP CVEs until there are handcrafted versions? And - a question from another perspective - would you be open to using Mistral in a self hosted environment?
I work on what should be pretty simple things (3D models of projects for CNC machines) and based on flet.dev recently announcing 1.0 and a quick test one-shotting a convincing protototype of a drawing program description which heretofore every such system had failed at miserably, decided to proceed with it.
I got a quick prototype of a rabbet box generator:
but the geometry was all wrong and ultimately required that I describe the calculation of the position and dimensions of each element in exhaustive detail in order to get a usable DXF (the wireframe preview is still all messed up) which eventually worked to make a box:
I was also drawing the design up in an interactive CAD/CAM program, and modeling it in BlockSCAD/OpenSCAD (and dropping into BelfrySCAD to figure out rotation):
(and speaking of rotation, at this time, the sliding and hinged lid options open on opposite sides in the preview...)
Since then, I've made a very simple generator which simple does a box decorated with lines, arcs, and circles on each side --- my intention is to dis-assemble that and use it to write a Domain Specific Language implementation for creating such designs and previewing them and writing out DXFs --- which is a long-winded way of saying I've been finding this tooling frustrating to use, but potentially useful to make rough drafts of programming templates which can then be used as a starting point for more traditional coding.
I’m not disagreeing with the author, but if you look at his dealbreakers: most of them will be resolved over time (quality, maintainability, environmental impact & even politics), they are not so much against LLMs as they are against the current versions of them.
The only arguments against AI itself are about cognitive decline and “I like coding”
While there is nothing wrong with those preferences, it’s akin to saying “I like building furniture with only hand tools, and not doing it by hand leads to decline in your ability.”
It could be the case that the environmental and ethical issues with LLMs are resolved, but that's about a projected future, not the present reality. Wouldn't you say that until such a time, the only ethical choice is to refuse to use LLMs?
I've struck the balance of using it at work but not at home.
At work I still read through every line in the diff (unless it's a personal util/non-production facing/critical etc). Even with this I feel less 'in touch' with my work code than I do with my home code.
The post sounds more like a programmer at heart, and that's totally fine.
To me, being an entrepreneur is more about building products, solving problems, and creating business value. LLMs help to deliver bug fixes, new features, and entirely new products faster.
I'm not writing a blog post just for this, but the man is right. For me, the only thing I expecte from a LLM is a StackOverflow/Google that actually works and maybe some static code analysis.
Disclaimer: I use LLMs for support and deep dives into existing code, not for creating new substantial code that I intend to publish.
Quoting from the article:
> With these subsidized token prices currently, I bet we're seeing less and less AI usage encouragement in companies in the future.
I see a different trend, and for a different reason. Employees are encouraged to use open-weight LLMs hosted on-premise, or, at least, in the "correct" geographical area, in preference to models from big providers. The motivation is mostly compliance with GDPR and NDAs. And when this happens, complaints like this get ignored:
> Your local model wrote a wrong root cause analysis for the customer ticket. It's a broken tool, worse than nothing. Claude did it right. We really need either access to frontier models or, alternatively, reasonable expectations on your side about what is doable with the tools you provide.
I see LLM usage as more of a spectrum than a binary decision. For the most critical parts of my day job, I still don't commit anything from an LLM that I haven't checked myself. My brain has never felt busier and more engaged on that stuff. But then I also produce absolute mountains of code (side projects, internal tooling) that I don't have time to review and frankly it doesn't really matter what the code looks like. You can choose how much to engage your brain. Every project is different.
The brittle slop happens when you tack feature on top of feature because it’s fast and easy now.
The higher quality stuff happens when you dive into the details of what you/the agent implemented (looking at code, with agent, or not) trying to make the current feature set work better.
IMO there will be outsized competitive advantage to the latter. Features are now cheap. But quality remains rare.
> I feel that LLMs and their overtly verbose output trick less knowledgeable programmers of the quality of their output. When Claude spits out refactored code with tons of comments, documenting each method and variable, and tests for everything as well, it looks impressive, at a first glance. But if you dig deeper, it's sometimes just complete bullshit.
This is pretty spot on. But it's important to note that the resulting code, is still often significantly better than what those developers used to produce. Especially under tight deadlines and pressure to complete CRUD like interfaces. We simply can't afford spending a whole day tweaking a sortable table on the web anymore.
I agree that it produces code that is better than many of my colleagues. I have spent the last 14 years honing my ability to build code in a scalable way that works for basically any domain. I still produce better output than the LLM. But the incentive to encourage my colleagues to reach that kind of level is just gone, and that's what frustrates me. As humans, we could have been so much more efficient, but instead LLMs came in and are steering us towards the median of slop code. Slop by my standards anyways.
I guess nobody cares about, if some one use LLM or hand written code. They all care if you are hired and deliver the output comparable to others with all their requirement fulfilled. I still remember how wordpress developers were against elementor during its early days and look how pagebuilders became default choice now for wordpress.
It is perhaps confirmation bias, but I feel like I see fewer and fewer of these posts on HN. All respect to the author, life is too short to force yourself to do something you don’t like. But, these post seem more like a goodbye to the train that has already pulled out of the station.
The quibble I would make is with the “code is not that good” and the implication that they are so much better at coding while those who have adopted AI are “mediocre”. It’s certainly possible this is right. I would be the first to call myself a middling programmer. I am still waiting to be inducted into the Real Developer (TM) society. (Is it a card? Or does someone teach you a handshake?). But my question is, why, if you’re an ace programmer, can you not get good results out of an LLM? These things are endlessly configurable. They are begging to be tested and, dare I say, engineered to your system and way of doing things. So, why are your results still bad?
The author's not wrong that left completely to their own devices, and especially if your working on something that's not well represented in their training data, LLMs will make a mess of things. But a Real Programmer (TM) isn't doing that. (Or so I assume. like I said, I haven't gotten the pin. Or is it a medal? A certificate perhaps?).
Not to be a jerk, but what if I told you there was a raging debate about widgets vs wodgets in the last 6 months and, although it seems pretty clear that widgets were being adopted across the industry at large, there was an ever growing sentiment that wodgets were actually preferred and the market was going to reverse itself, any day now?
I can’t really point to any evidence of this because the wodget people have stopped posting about it and every month the cost of widgets keeps going down while they simultaneously get better and there’s so much capital and talent being thrown at widgets that it’s impossible to think a wholesale reversal could even be possible. Would you tell me that, “trust me, bro” is not really an argument?
* Programmers can now generate (and are now expected to generate) massive amounts of code
* This massive productivity boost is, oddly enough, not reflected in consumer products at all
* In fact, most of this newfound productivity seems to be aimed at making AI widgets or infrastructure for maintaining AI widgets
* LLM use seems to hamper software development at its current level of complexity (because AI is incapable of independent abstraction and simplification)
* Programmers are deskilling en masse and turning into managers (without admitting it to themselves)
* Technical programming discussions have become incredibly boring for people actually interested in the craft
* The externalities of LLM use remain the same (and, to an extent, can’t actually be fixed)
* Most of the benefits of LLM use are going to management; programmers have to do a lot more for the same pay
* There will always be programmers who code by hand, even in a professional capacity — and it’s quite likely they’ll be the ones dragging the industry forward (up the ladder of abstraction)
Yeah... This is about to age really badly, not to say that the principles in the post are incorrect, but this person doesn't seem to realize that they are in a free market and that each model improves on the last on almost every aspect. We will see what they'll think about this choice when all their competitors do 100s of peoples worth of work just with a few people
I agree with you, but also it won’t matter at that point because the job market for coding will have contracted to the point where practically no one is hiring.
“You’re not breaking up with me. I’m breaking up with you.”
For me, I don't mind if people want code written by LLMS. What I DO have a problem with is people handing over their problem solving to LLMS.
If someone uses Resharper to make some ugly code pretty, fine, I don't mind - as long as they can understand and explain the result. My issue I'm running into daily which drives me nuts is stopping people in their PR's and asking "Why did you do it this way? This seems like an odd approach" and get "Oh I dunno, Claude wrote it". Then what the hell are you checking it in for?
Between SO, Resharper + Fancy IDE tools, and the mountain of plug-and-play cloud services we have, I think the era of 'writing everything yourself' was already dwindling. But at least if someone chose one framework or library or SO post over another, they could explain why they chose it later on. Some sort of domain knowledge was being built up and transferred between devs over time (and I'm not talking about documentation). What I see more and more is systems being checked into production where the 'author' doesn't fully understand what it's doing, then it breaks in a way they don't expect, and then I see a team of clowns all with their claude terminals open desperately typing "WHAT DOES THIS ERROR MEAN" because nobody understands why it was built that way in the first place.
Fine get LLMS to help write your code, but do your job and handle the problem solving part. What are you being paid for otherwise?
This is a roundabout way of saying you're leaving the profession.
We now have people commonly running multiple concurrent programming tasks, while automatically and interactively testing them, reviewing them, and validating them. They're then handed for human review, where little is found because the quality regime is now set so high. We're talking weeks of development + testing/validating time brought down into the realm of days.
So this is pure "my horse & cart are just as good as the motorcar"-levels of argument. If I bury my head in the sand long enough, and deep enough, this will all just blow over, and we'll go back to doing stuff significantly slower/worse any day now...
The quality of stuff I am shipping today is the highest it has ever been, and tested/validated significantly more comprehensively. Why? Because time/resources was the limitation, not willingness or skill. I always wanted to test for every single possible edge case/scenario, but it wasn't in the time-budget (and diminish returns). Now I don't need to make that trade-off.
So I have some questions for agentic dev aficionados:
- Why should I even start vibing up my desired tools and projects when I can just wait it out so a better clanker emerges 6 months down the line?
- What guarantee is there that Rust is the best programming language for vibe coding when the models could improve to directly output assembly? What incentive do you have in vibing up something?
I can answer question #1 from the perspective of an employee who trades time for money: I don’t get immense joy [1] from writing code to do whatever dumb corporate thing my employer needs this week.
An agentic workflow lets me literally sit on my hands (or play Star Wars: Galactic Racer, or play my musical instrument, or work on my CAD hobby, etc) while the agent machine does my work for me.
The best part is that this is how my employer wants me to work. They literally want me to be lazy. Works for me!
Where is my incentive structure to not use AI?
[1] coding manually brings me a non-zero amount of joy and mental satisfaction and stimulation but I am still trading time for money.
1. At my company I am basically a regulatory requirement.
2. I’m paid to be a warm body who is available. That’s I am paid salaried instead of hourly.
3. I don’t really care if this situation changes in the future. If AI takes my job there’s nothing I can personally do to stop that from happening. I’m just saving my money and planning to retire as early as possible. I view work as a necessary evil.
Yes, but if I only use the excavator for 5 minutes and coast the remaining 55 minutes, I'm less useful than someone who uses the excavator the whole hour. Now, if I'm particularly skilled at using the excavator compared to my peers, I might get away with working less. If not, working 5 minutes while charging for 60 minutes will eventually get me fired.
Generally, automation does not make us work less because the expectations rise equivalently.
Most of us in the field have to produce software for money, and the economics of that have shifted to the point where LLM use is table stakes. Programming by hand is now an idle curiosity, a leisure-time activity.
In what way? I see it as the opposite if anything, the rise of LLMs marks the first time programmers have been expected to spend money on tools since around the 2000s.
You don't need to use LLMs for coding to stay "competitive" with your colleagues.
I work for a FAANG, we have unlimited AI credits to be used on any model we want, with basically any tooling we want.
My whole team massively uses AI, I barely do. I use not even 10% of the tokens that they do. Yet I have not only the highest rate of PRs raised, but also the highest rate of PRs I reviewed, and the second lowest number of revisions per PR.
AI is all about fake productivity. You feel productive while you're achieving the same, if not less (or even often, nothing at all).
Long term it's pretty obvious that people heavily using AI will become a lot less productive, if not simply unable to work as software engineers. My colleagues are already scared.
In fact, as a challenge to anyone who says they "haven't written a line of code by hand in X amount of time", go do a test. Try to write any code without any LLM use for just 30 minutes.
All that tells me is that your org hasn't learned how to use AI effectively yet.
There is no way a human programmer can keep up with a computer doing the work of four programmers at once. You might not see this for every problem of course - in product development the bottleneck is often the design/product work, feedback cycles, not the coding.
Yeah of course, it's always "you're not prompting it correctly", right?
I understand though, it's hard to feel your skills atrophy in real time while at the same time realizing that the data shows your productivity has in fact not increased at all.
This is extremely accurate, but HN doesn't like it when you burst their bubble.
A good software engineer has always been able to write a ton of code all by themselves in a short period of time without any oversight. There's nothing romantic or intelligent about that. It's just reckless.
Teamwork is more important than ever, and yes of course that slows things down. That's the point. The decision making is the slowest part. 5 hours of meetings today can completely change the trajectory of the next 5 years. This isn't a revelation for anyone but the most naive.
We're a greenfield team working on a new piece of software.
My colleagues are all also FAANG software engineers.
> Does you manager also agree you are the most productive engineer in team?
It would seem so.
Additionally, in my mid-year performance review a couple of months ago he specifically mentioned how every metric also looks great.
It seems the only option left is that I'm lying.
In reality, your knee jerk reaction was to be scared and deny that what you have taken as productivity increase was just an illusion, and that you've actively been losing your skills for literally nothing.
Hmm. I don't know to be honest. I actually ship way more features in my side projects. Even work wise I have seen projects delivery speed going half or 1/4th of what it used to be.
And all the engineers in my team are full on AI. Even the best ones.
For me I see the opposite of what you are saying.
I don't particularly see much value in handwriting the code itself after the tech specs and all is finalized.
So me personally I am liking how the industry is going.
Never really enjoyed writing thousands of lines of code to be honest.
> I don't particularly see much value in handwriting the code itself after the tech specs and all is finalized.
It's impossible. You are lying.
If you developed software, you should know "the tech specs and all" is never finalized, the requirements are always changed, when you are developing it, the specs or details are changed or improved.
> I actually ship way more features in my side projects. Even work wise I have seen projects delivery speed going half or 1/4th of what it used to be.
Again, you are conflating appearance of productivity, with actual productivity.
Are you shipping more features in your side projects because AI is allowing you to ship more features faster (let's assume at the same level of quality), or are you investing more time in shipping features in your side projects, because you FEEL like AI is a productivity booster and therefore you get more out of your time, even if it's not real?
Are projects at work estimated to be a lower cost because of AI productivity increases, or because estimates were too high previously, and you could always deliver at that speed?
For the second point, I'd add that any launch announcement I see at work touting AI gains of 50-75-90% NEVER hold to any sort of scrutiny, so it's also simply, lies? Employees currently are desperate to look good in the eyes of the CEOs pushing for higher AI adoption.
You're entitled to feeling more productive, I'm just saying you likely aren't, or not by very much. Add to that the fact that you didn't like writing code to begin with, it's easy to fall into this sort of falacy.
To be clear, I do use AI, and I do see some productivity gains, but they're not in writing production code (issue management, automation that was too expensive before, generation of code or artifacts that I don't actually care much about, etc.).
Very well-written, and undeniably relatable! Sadly, I am compelled by forces beyond my cognitive control to respond, especially to points I've seen and refuted before. If nothing else, I hope it's helpful to know the other side of these things :)
using LLMs in my codings
I hope it's not too combative to start by saying this is a huge red flag for someone who hasn't checked in on what post-Mythos agentic engineering is like. Of course LLMs are undeniably involved, but it comes off like someone quitting social media by decrying protocols (or worse: series of tubes). LLMs are an essential component that has finally thawed the AI Winter, yes, but they're still just parts of a system. A harness is far from a mere wrapper around a neural network, to say the least.
people argue that "LLMs are just a tool", but really, it is not, it is a SERVICE
That dichotomy is a false one (many software tools are productionized as services), but the underlying sentiment is clear and common: that querying a chatbot is akin to asking another human to do something for you. This comes up most often in Reddit's vicious "AI wars" about digital art, where generating an image cannot be a creative act on the users' part because it's more like comissioning a painter than it is like painting.
I think the response is obvious (and why this is merely an aside rather than a "dealbreaker" proper): this is granting personhood to neural networks, which no one who supports this point would admit to in a thousand years. Either they're people and you're asking a person to think/paint for you, or they're inanimate machines and it's a tool; there is no middle ground. (If unconvinced: what about a camera makes it a tool to be used rather than a peer to be delegated to? It can draw a picture in milliseconds!)
the current hype and craze for them
This is an underlying worlview thing that poisons the rest of the analysis, namely that nothing (important) ever happens. That surely this just a hype moment that will pass like the iPhone moment and the Bitcoin moment, and that anyone who says otherwise is surely crazy. It's begging the whole discussion.
And it's no wonder, there have been several studies confirming this:
The first paper is Microsoft's[1] recent incredibly informal survey of how people feel working in a career they know to be changing beyond their recognition, and with tools that didn't really exist 6 months ago. Yes, orchestrating agents is a different experience than we're used to; no, a simple survey could never prove that they are cognitively dangerous.
The second paper is notoriously misleading, and a stain upon MIT -- observing brain activity differences between people who have to think deeply and write an essay by hand and people who type a sentence and then sit there until the allotted time is over is not surprising, and definitely doesn't show what they clearly intended the flashy graphics and suggestive conclusion to show (that using chatbots leads to brain damage). There's more, but long story short: they're manipulating valid techniques to make a tool seem like a uniquely-dangerous toxin, when the exact same effect applies to all previous tools of note (calculators, typewriters, word processors, translators, even Grammarly).
The third paper is just highly-speculative, deeply-polemic schlock, obviously.
The quality of the output is not that great
1. This is an unfalsifiable claim, which is lucky because the goalposts have had to be moved many times to get to "looks impressive, but is sometimes complete bullshit". Turing refutes this thinking quite directly in `§6.5` of Computing Machinery and Intelligence (CMaI)[2].
2. Many experienced engineers disagree, to say the least, as do companies investing billions.
3. Again, you can't help but sense the author hasn't used post-Mythos models; even if they have, the fact that such a huge leap has occured in just the previous 24 months is overwhelming evidence against this notion. The linked sources being A) an /r/AntiAI post (!) and B) a pre-Mythos essay don't help.
Congratulations, you have let OpenAI/Anthropic/Elon Musk dictate what your code does and why.
I'm quickly getting the sense that the author is too vitriolic and dug in to be reasoned out of these views :( Hopefully it goes without saying that "your code sucks because you gave it to [HATED_FIGURE]!" is an invective, not a premise. For the rest: see previously preceeding section, which is indeed "closely related".
I like writing code
Same! I also like playing video games and tending to plants -- just had a blast on Beyond All Reason last night, and my Philodendron Florida Ghost just unfurled a wonderfully-ghostly new leaf. Neither are my career.
Environmental aspect
I'm most dissapointed by this part, as this person is Finnish and should know better about the Google story :( What's being framed as some unheard-of act of environmental terror is really just the planned and almost-completely-permitted early harvest of a small plot of "planted forest", i.e. a tree farm, which are one of Finland's main industries. Everything in this map in blue is tree farms, with the Muhos site in the middle: https://i.imgur.com/HyTVp1I.jpeg [3]
The preceeding 'this technology uses power' point doesn't need refutation, but it underlines the problem with the point above: this is post-hoc reasoning. Cutting down a tree farm in Finland is so, so far down the list of priorities for actual environmental activism that it's hard to describe, and yet this post has nothing about not working for companies that serve non-vegan meals for lunch, uses air conditioning, or flies people to yearly retreats.
But I just personally feel squeamish about having my work being done by rather skeezy companies
Even if this were relevant (which it's not in a post-GLM-5.3 world[3]) it offers no argument, and thus cannot support the conclusion.
Even if some technology or tool sticks around, it does not necessarily mean its good idea to work with it.
Also not an argument. Heroin isn't inadvisable because it's "here to stay", but rather because it's a toxic, extremely chemically addictive narcotic that kills many thousands of well-intentioned users every year, and ruins thousands more families before that.
TL;DR: Apologies to the (again, clear & well-intentioned) author, but this essay is like heroin -- I dislike it!
---
[1]: BTW, there's a reason Microsoft published this, and it's the opposite bias that this author assumed. Read this article and see how deep the conflict of interest admission is buried -- it says it all: https://www.project-syndicate.org/onpoint/anthropic-training...
The comparison with heroin frankly is bizarre, as if using LLMs was purely hedonistic activity.
LLMs are tools like motor vehicles. They allow you to get somewhere, quickly but brutishly. You won't be able to appreciate the beautiful scenery much, as it rushes by. You're going to have to compensate for the exercise you would have gotten, had you walked, or it's going to be unhealthy. It's undeniably bad for the environment (electric or not) and has other negative externalities. The politics of many of the countries supplying most motor vehicle fuel to the world are beyond fascist by modern leftist standards. Yet, we depend on them, we have constructed a lot of the infrastructure we need to live around their existence, and even if every city became walkable over night, the last mile for most transport would be covered by some motor vehicle. There are many "what ifs" surrounding motor vehicles where the answer boils down to: "Well, then we're fucked". But we're not fucked today, and so on it goes.
Of course you can try not to partake in motor vehicles, and insofar as you don't make a moral grandstand about it, that's totally fine with me. But the rest of the world is in it for the ride. The first cars weren't very good either.
I agree with most points made by the author, however the cognitive impact depends on how you use LLMs. Here's an example: I build so many Phoenix / Elixir applications and one of the things I really hate is the amount of boilerplate code I need to write for every project. It is exactly the same (eg. Setting up vite, removing existing mix based node integrations) and modifying scaffolded code to adhere to my design. I already know CSS inside out and Tailwind CSS too. So, by offloading the task of rewiring existing scaffolded CRUD templates, I would argue the opposite - I am saving precious cognitive load from doing repetitive data entry work.
That's why I have a very clear personal policy of always being the architect and instructing LLMs what AND how a task must be done as opposed to blindly just trusting them with everything - that is how you lose your ability to think.
That's because the history of new technologies, new tools, etc. is one of resistance from those who knew how to manually do what the technology enables for more folks. Sometimes it works out well for humanity, other times the technology fades into obscurity or is quickly replaced by something else, but at the time the pushback on both eventualities looks the same.
We'll see the same for automatic freight movement in the next few years, as just one example.
I was a competitive programmer, coded non-stop in many languages for 15+ years.
I haven't touched a line of code in over 6 months, didn't even look at it, but the work I do is faster and higher quality than ever.
Not sure how I feel about it
International Olympiad in Informatics (IOI) Gold Medalist here. I too did competitive programming for years. I pride myself on writing beautiful code that is succinct, effective, and efficient.
Yet I find myself using AI coding agents more and more. In this day and age, your choice is to either use them, or be stomped into the ground by programmers who do.
AI still can't write code at my level of quality, but it can do so at adequate quality now; and sadly, that is "good enough" for the real world.
I've made many friends and acquaintances over the years who are top notch, some world class, programmers.
I'd say that 90% of them are very excited about using LLMs for coding. They have nothing to prove to anyone and can easily steer AI to reach "godly" productivity (please note these guys were 10x programmers already).
I also know some weak programmers and most of them tend to be critical of AI and want to get rid of it.
Lastly, a couple of people I know are against AI for moral/ideological reasons without denying it can bring productivity increases.
This is purely anecdotal but I'm starting to notice this pattern everywhere I look.
All I want is an explanation of how you're all reliably getting good enough (or better) results from LLMs. Surely us AI critics are doing something wrong, something much more specific than needing to "prompt harder", if we accept the framing that 90% of world class programmings are achieving that, while the rest of us are not. There simply has to be some specific, repeatable, and yes, teachable thing we're missing. So what is it?
Try requesting a feature from Opus 5.5 high that would take you a day or two to implement and test well. It'll work for 20-30 minutes or so. Then ask it to review the changes with a sub agent of itself and with Codex Sol 6.1 high. Then let it address the findings and iterate the review/fix cycle until the reviewers are happy.
Anecdotally, for small tools and projects, it can crank out functional tools that would take me days or weeks to remember how to do manually. Every time I ask LLM to write something, it also writes tests and validates its code against known values. I additionally spot-check the LLM's code against my own known values in prod, and have had to correct it on some functions. The code I write is mainly analysis of logs and configurations, and they seem well trained on the products that I am using.
Testing. It's all about having unit tests, and known outcomes that the LLM can check against every time it makes changes. For my work, that is good enough. For safety-critical systems I would demand more rigor in the testing and the human review and creation of tests.
Most senior developers that steered juniors or interns in the past, are able to work with LLM's.
Sure, LLM's are unreliable. So are juniors.
Sure, LLM's code quality is not always great. Well, so is the juniors code.
The benefit of LLM's is that they can work super fast and have a vast amount of knowledge. The benefit of juniors is that they actually learn from their mistakes and get better over time. LLM's stay at intern/junior level, even with the correct context.
So for me, I see each LLM session as a new intern coming in. You hand them the right context, give them the correct instruction, and off they go. Then they come back, and you will have to judge how detailed you want to review what they produced. Or in other words, can you get away with some bad code? And for the next session, it's a new intern that starts from 0.
But it is also highly dependent on the project you are working on. If it's a big complex codebase, LLM's will struggle, and they can only do simple tasks (however, they can help with testing a lot!)
So the teachable thing is unfortunately experience:
- Know where quality matters, and where it doesn't
- Know what kind of mistakes could be made and should be checked for
- Know which things can be duck-taped together, because they live at the edge, and which things need a proper foundation, because the rest builts on it.
So in the end, I think it all comes down to making the right trade-offs and the right decisions (which LLM's are terrible at, by the way). And unfortunately that is gained by the slow process of experience.
I think it's very tough for junior developers right now, because they either go fast by letting the LLM's do the work, but then they learn nothing. Or they go slow by asking the LLM's what's going on, and then do learn.
A senior developer never understood the full code-base, and never reviewed every line of code. That's just impossible. And now every developer needs to be a senior developer that is able to steer these new "interns".
And just like with juniors and interns, you have to put a lot of effort into it, and it's not always clear in the end if you gained or lost time :D.
LLMs and juniors are not the same. i made this argument on a previous discussion of the same topic: https://news.ycombinator.com/item?id=48212898
One thing that stood out in that comment: You said "you like" the act of programming elegantly and understanding the problem.
There's nothing wrong with that. Many of us do (or did) like programming and the problem-solving itch it scratched for us. But getting work done for pay is more than what we like. If an LLM can reliably solve a problem for me in a day that would have taken a project, a team of several people, and close to a month of work to build out manually, then I go with the tool that works.
And that "if" is the reality I live in. About a decade ago, I wrote a program to do analysis of config files for a product our team uses. It took me weeks of side-work to implement the idea of passing boolean python functions as checks for the configuration. Such an elegant way of creating new checks on our system! It was company work, and when I left to a new place, I didn't have that code, just the idea. Fast forward five years and I want to write the same thing at a new place. I asked an LLM to do the same task, and it wrote exactly my solution immediately. It just worked. It shocked me. In the last few months, I've had it write analysis tools against this product that would have taken me days or weeks. I am admittedly not a comp-sci level programmer.
There is no denying that LLMs are powerful coding tools. That can be true at the same time that we lament the end of manual-coding-for-pay, the death of programming education as we know it, and the worries about employment and society.
I don't claim LLM's and juniors are the same. I claim that working with LLM's and juniors are similar. If you are able to work with juniors, you are probably able to work with LLM's.
To comment on the post you linked:
I agree that people can be thought. But on the other hand, I also had juniors that reached their limit pretty fast, which can also be frustrating. The best way to "teach" LLM's is the context, but I agree it has limits and is not really teaching anything, just steering them in the right direction every time (like a checklist).
Your comment basically states that running LLM's is a gamble, but according to my experience, most of the time it delivers what I ask. Maybe in a different way that how I would do it, but I want results, and am not interested in micro-managing.
Are you working on a project that requires high quality code? Or is it your preference to work in such a codebase? For me, I was always ok with "good enough" code. And sometimes "good enough" needs to be good, and other times you can get away with some really bad code.
I feel like code quality is important when humans have to reason about. However if the future is machines managing the code then all that matters is AI understanding it.
The only danger is losing grasp of internal components of the system, but maybe there'll be a "management" layer eventually for humans.
I don't know what the future of programming will look like but I don't see us rolling back the clock to 2021..
> or be stomped into the ground by EXPERIENCED programmers who do
FIFY.
I've found experienced devs with AI is a force multiplier, but AI in the hands of juniors however is my hovercraft is full of eels.
I hear this all the time, but the software I use is becoming obviously buggier and less pleasant.
It seems most people are bad at evaluating the quality of their work, especially if they purchased it from Anthropic.
I think there is a big industry push on "use AI to deliver features faster".
It could have also been a "use AI to test our product more", but I don't see that anywhere.
I hope you agree LLM's can actually help with quality, if used for that purpose?
Who cares about the theory? The fact is that the world is now worse due to LLM use.
And it's not just restricted to software. Everything I care about is getting worse.
Dribbling about how it could theoretically be better doesn't help undo the damage. "Imagine how much fun we could have playing baseball", says the man with the baseball bat, as he kneecaps you.
> Not sure how I feel about it
A phrase I've been toying with is eyes free vs hands free coding.
The distinction is important. While I too hardly write code these days, I do continue to make smaller changes and look at what's being done. This is as opposed to the group who has decided vibing mega commits is a good idea.
I am not doing small changes though, I add large features or refactors daily, which involve changing hundreds of files and thousands of lines, even if I wanted I couldn't review everything by hand.
I have done this too, for side projects, but I see the limits. Discovering what happens when we do this was one of my intentions and why I hold my opinions.
For these projects I make regular time to look through the code and do cleanup phases.
So you're saying simultaneously, the code is "higher quality than ever", but you also haven't even looked at the code to see its quality. Classic. I think you're mistaking quantity for quality.
I mentioned before, code is definitely worse, but end product is better.
High quality code doesn't always lead to a high quality product.
And bad code doesn't always lead to a bad product.
I think they are saying they are using proxies for project quality, like features and test coverage
AI is a hammer, problems are the nails. At the end of the day, you still need someone to swing the hammer. Aside from the occasional overstretch of scope and “reining it in”, the real bottleneck is humans.
We have more freedom than ever to build whatever we dream of, you still need a dreamer. And that’s why the profession of coding isn’t going away, you still need people to turn ideas into reality. I find AI soulless, it’s great at mimicking but is incapable of coming up with an original idea that wasn’t yours regurgitated.
But will we need fewer people is the question.
When am I (as a user of a lot of software) going to start seeing any results of this unprecedented productivity gain?
This thread is full of 100x supercharged programmers, so why is it that I can't name a single useful feature added in the last 5 years in e.g. macOS, Windows, Firefox, Chrome, YouTube, VS Code, YouTube, Slack, Photoshop, Word or any of the other 5 programs currently on my taskbar?
The productivity gain is invisible using your metric.
What I have seen is that, with LLMs, an entire class of process brokenness disappeared in the in-house codebase. Before, there were many trivial tickets that, in the end, required a 5-line bugfix sitting in the queue for months. Now, such tickets are resolved instantly, and the backlog is shrinking.
Because the code is and almost never was the problem. Product design and business involves a lot more than code.
Personally, I did see a lot of entry-level products having a lot higher quality and better UX. At the same time, most companies go for fast iterations and are profit-focused, do product quality is not really a target for many.
I insist on reviewing every line of code. But in the last few weeks I realized that LLMs are simply better than me at reviewing code too and I'm just finding excuses to not do the real work, which is to write more prompts.
Have you considered asking them to write the prompts?
I have been asking LLMs to review/edit prompts since GPT4o era, so I really don't know what the point of this snarky comment is.
Since GPT4o, I have been convinced that most of the digital work would be done by AI and humans' job is to "move the chairs around to not block AI's way." It's a given to me. I'm just debating whether reading the code makes me a better chair-remover.
Don’t think it was snarky. My guess is op is just suggesting that you could automate further, but you are ratcheting toward it one step at a time while op is suggesting to allow the ai more autonomy.
If you don't look at the code, how do you know it's higher quality than ever?
I simply test the final result,manual tests, automated tests, benchmarks, people using the apps and giving feedback, increased number of sales, etc.
Here is something I found this week: copies the entire db to memory, inserts a single row into in-memory db, deletes everything from real db, writes everything back. Sentence that caused this is "do XXX in one transaction".
All tests pass, everything seemed to work. Would not have noticed of I didn't read through the code. Amount of other stupid shit I found is crazy.
These anecdotes mean little without knowing context, model, harness, prompt. The technology has moved a lot in the past year, and does require some adjustment.
My very first experience with OpenCode led to a `rm -rf /` within minutes, which I caught by chance watching the output stream in. Yet 99% of my code is currently written through an agent.
Ah yes, the favorite response to any criticism of LLMs – you are using the wrong model.
A performance benchmark would have easily caught this though, ask the LLM to create and run benchmarks and see how those change after each new feature/major change.
I have found test coverage reports to be really helpful as well.
Also to make it clear, I am not saying the code itself is better, but the end-product and what the user sees and gets. Like that saying "if it's stupid, but it works, then it's not stupid"
for you, "if it's stupid, but it works, then it's not stupid."
for me, if it's stupid, but it works, then it's a coincidence.
I think LLMs themselves are a good example of "it's stupid but it works"
Because the exact same processes that create it faster, are also now generating large comprehensive test suites, and data-validation suites based around the actual business requirements and data/edge cases.
In essence, it is writing the code faster (great), but then also writing the code that was often previously never written due to budget/time limitations (comprehensive testing/validation).
So, how do you know the code is the highest quality ever? Because we have test result data that PROVES it to be the case. It isn't "trust but verify" it is "Don't trust. Verify."
This is my observation as well. I thought I was good at testing (I wanted to be good at testing), but the models are just better at it. Testing in particular rewards a tireless cataloging of the tiny and the tedious and in this respect LLMs are unmatched.
Single data point, my Sentry notifications across more than a half dozen client projects when from 2-4 a month to basically 0. That's while shipping 20x _more_ code.
Yeah but you don't test for stuff you don't know you have to test for. All tests can pass and internally its still done in a braindead way that will explode at some point.
Absolutely, and this is exactly why humans are weaker than LLMs. We consider what is likely, they consider what the data/logic shows is possible. So you get edge cases tests/flagged, that wouldn't even be something a real person would know to look for.
How do you know those large comprehensive test and validation suites you've never looked at actually reflect real user experiences at all?
You must have replied to the wrong comment, since the one you did replied to never claimed that the test and validation suites were "never looked at." They are reviewed, and the test/data results are reviewed.
It said verbatim: "Don't trust. Verify."
> Because we have test result data that PROVES it to be the case.
pgrust thought this too, but then another human discovered claude had hardcoded benchmark query plans.
Now pgrust has a "test" [1] to make sure the Ai doesn't do this again (unless it decides this test is bad for the current goal)
I have a growing list of these, another notable one is OpenCode having a security regression [2] because the Ai redesigned configuration loading for v2.
Real verification seems beyond transformer capabilities.
[1] https://github.com/malisper/pgrust/blob/38634b408dea373f3944...
[2] https://github.com/anomalyco/opencode/pull/54921
Very little code written in the world day to day ever has to justify its 'quality' or long term value. A lot it is just one off tools, bits and bobs to make a teams life easier or whatever.
I used to work in Web agency for sizeable brands and not a single site I built lasted over a year because the companies changed concept regularly. The next agency would come in and tell them it was built wrong and couldn't be reused etc etc. We did the same, it was irrelevant how it was built and we didn't even look. This is the nature of most code. The problem is that very few people will ever be in a position to be writing verifiable important code, but every developer likes to cosplay that they are.
Most code is ultimately an, annoyance businesses need to meet a goal that will always be a cost. It's often worth treating it as such and writing things that are easy to spin up and teardown.
The people most vexed by AI dev appear to be the ones who think writing code is a pinnacle role, it's not even though over our lives the salaries would sometime suggest otherwise. That's ultimately going to be a short term blip in the landscape and most code will be one seen as the cost it is.
A programmer's output was never code. It's was just what we had to do to get computers to work for us. Now I just ask a genie to do what I did and check the results.
Good for you. I prefer to communicate with computers using an unambiguous language that describes exactly what I want them to do.
How do you know it's high quality if you do look at the code?
Competitive programmers don't usually produce quality code, I'm guessing it could hardly be worse even without looking at it.
They do produce code optimizing for a different goal. But readability is often not one of them yeah.
That's true, code is usually shit but the result/outcome really good and performant.
He must have been a really bad coder.
Claude told him so.
> I haven't touched a line of code in over 6 months, didn't even look at it, but the work I do is faster and higher quality than ever.
Well that doesn't make sense if you are writing code that is going to be used on critical infrastructure.
Imagine a disaster were to happen and you said to the auditors that "I don't know what I am doing nor did I look at the code" and you cost the company tens of millions of dollars.
Sure if your building toys, that's fine, otherwise, why take the risk in being liable for not looking at what the code does and then believing it is high quality?
Don't you see the contraction you just did there?
Indeed, I am just building apps people use, they are not "critical infrastructure" and the world won't end if there's a small bug, I don't vibe code self driving cars, defense systems or medical devices. A
If there is a bug, it will be fixed quickly anyway, so only a few users might ever see it, or see it only for a brief time.
Even when manually coding, projects still have issues and bugs, I don't think much changes in that aspect now, if anything, there are fewer bugs now in most high quality apps than before, due to AI catching more issues. See all the vulnerabilities found in old core code and libraries nowadays, that humans didn't find.
There’s a huge gulf between toys and critical infrastructure.
LLMs write better code than humans with fewer bugs. They also do it much much faster so you can spend all the remaining time testing. Tests are written faster too so not only you have more time for testing but also you can use it better.
>>Sure if your building toys, that's fine, otherwise, why take the risk in being liable for not looking at what the code does and then believing it is high quality?
>>Don't you see the contraction you just did there?
I wouldn't trust anyone who refuse to use LLMs for programming. Their code is worse, they test it less and it takes longer to write. For me "no LLMs" attitude is a sign of incompetence. Good for hobbyist trying to keep their brain active but that's about it.
That is even more so for critical infrastructure. Just look at the mess human coding is when it comes to security. LLMs are fixing it at the pace we couldn't even imagine a year or so ago.
> LLMs write better code than humans with fewer bugs. They also do it much much faster so you can spend all the remaining time testing.
So does that mean you should never look at its code?
If a fault in the software occurs even after testing and there was an investigation, will you admit in the postmortem report that you did not look at the code at all and blame the agent for the error?
> I wouldn't trust anyone who refuse to use LLMs for programming.
Did I say I refuse to use LLMs for programming? I am telling you to check the agent's work.
I would not trust anyone who DOES NOT check the changes of an agent's code when using them for programming in highly regulated industries or in critical systems. For most companies in the Fortune 500, it is irresponsible to not check.
> That is even more so for critical infrastructure. Just look at the mess human coding is when it comes to security. LLMs are fixing it at the pace we couldn't even imagine a year or so ago.
No-one argued against that and it does not mean that you do not check with the agent at all even if the agent believes that they "fixed it".
"didn't even look at it" is a giveaway of the OP being a liability on top of a boaster and the company who employs him deserves to go out in flames
Wonder if he tells his boss to "I pushed critical code to production without even taking a look at it" or is it just for show on HN
This is akin to sticking to hand tools after the development of the electric motor.
There is no going back to writing code the old way. I don't see that happening in the industry, ever.
The grievances listed here are 100% real, but not fundamental - with some practice you can prompt an LLM to great effect without it taking the reins from you. If you let it write the code, it does become a management job more than an engineering job. That said, I do believe that there must be a way to structure your workflow such that the LLM becomes your read-only pair programmer/rubber duck while you yourself get to do the fun parts of coding.
I felt like the post for a while but ramped up on it since.
> I know Machine Learning
Knowing a thing and knowing how to use the think well are not the same.
> Cognitive impact
This is probably the greatest concern and it requires vigilance or routines to counter it.
> The quality of the output is not that great > Maintainability is a nightmare
Neither are my first prototypes. Refactor them using AIs.
> I like writing code
I like designing a system before coding it and the AIs are pretty good idea bouncing partners.
> If you let it write the code, it does become a management job more than an engineering job.
I disagree. It remains an engineering job. Us software engineers got confused about what the engineering part always was. The engineering part of chemical engineering isn’t cutting piping, welding shit, or rolling metal. The engineering in civil engineering isn’t pouring the concrete, or grading the site.
Yet somehow it’s a prevailing idea that the engineering part of software engineering was typing on keys and naming variables.
Writing high-level code was never as mechanical as “cutting piping.” That’s absurd. If that’s how you thought about writing code, you were simply a bad programmer. (Or working on some incredibly boring code.)
Writing the code absolutely was. Every character we had to type was accidental complexity
You are conflating designing the system and instantiating it with code. This is exactly what I’m talking about.
Typing characters absolutely is cutting pipe and pouring concrete. It is not where the engineer was or is.
You are conflating system design with high-level programming (with typing, which is trivial and takes almost no time).
The typing absolutely was mechanical. The thinking what you need to type is what's never been mechanical, and there's plenty of that to do LLM or not.
We took advantage of the typing time to also think, and in many ways typing code served a similar purpose to drafting your thoughts on paper. With an LLM you still think a lot and those thoughts turn into specs, prompts, plans, or whatever workflow you prefer.
I guess it's because throughout the lifetime of this profession, we have not witnessed a development like this. We went from punchcards to assembly to compilers to javascript, but at no point was it a process that would just "keep going" until you turned it off, much like a motorized machine.
I would disagree that "the grievances" are not fundemantel. The _profession_ of the programmer is about to cease to exist, much like the human computer. Sure, you can still compute without a computer and perhaps enjoy it, but you will not find anyone to pay you to do it. Whatever you think "babysitting an LLM" is, it's not programming, even if presumably programmers are fairly well suited for it.
Which is why none of us have or want job titles with "programmer" in them; even juniors are junior software engineers. As long as a human is needed to design and implement good software, they will be software engineers. The temporal affordances aren't nearly as unique as you imply, either: generated code and unit test results are two good examples of things that "keep going... much like a motorized machine".
That is, unless you treat the agents as if they were people and thus the true engineers, of course. I think that's a fascinating philosophical topic despite ultimately disagreeing, but to say the least it's incredibly controversial to even consider the personhood of agents, much less endorse it.
This is all moot anyway, so apologies if I'm rude or overly dismissive of your comment that I agree with the general thrust of. No point starting fights over deck chairs...
> AI is not inevitable
I have a hard time believing this. The businesses employing us and the businesses competing with them will view handwritten code as an evasion of financial responsibility. That does not mean inevitability is positive or worth welcoming with open arms. But it is so inevitable at this point.
> The businesses employing us and the businesses competing with them will view handwritten code as an evasion of financial responsibility.
If this were true, then we wouldn't be seeing the correction to reasonable limits. While I generally agree not using LLMs is irresponsible and not viable any more, I have real doubts transformers will live up to the hype projections and the end of the profession. On the other side (with too much Ai coding), there are market penalties from the users (because of Ai mistakes).
There are frequent news stories about companies that want to go capture an asteroid for mining, because it's worth "trillions" in rare metals. The companies don't seem to grasp the fact that flooding the market with a new supply said metals will diminish those metals' value dramatically. They can pump billions of dollars chasing that dream, and if they succeed, their reward will be to flood the market, and diminish the market.
LLMs feel like the same thing. They're spending billions of dollars on these machines that can flood the market with something once rare and valuable--human creativity. If they succeed, they'll just be ruining creativity and diminishing what humanity values.
LLMs and generative AI took what means to be a human away for many, not just programmers. The upcoming unrest will be fascinating.
I have a hard time understanding that position when it comes to programming. What is "human" about typing instructions for the computer into a terminal? Was perforating paper more human? And I say this as a programmer with 20 years of experience. The human part is the thinking and intention behind it, not the typing.
When it comes to generative art, yes, that's a much more significant issue.
Not OP, but all the choices made along the way are the human part. The understanding and creativity to solve the complex challenges that arise in an efficient way that fits into the structure of the greater program.
Programming never has had one right way to accomplish a task, and that is disappearing with agents. Why would pick Ruby for a project because it’s nice for the programmer, when the agent is the one coding? In fact, Why would anyone ask an LLM to write a new program in almost anything other than JavaScript and Rust?
Have you ever solved a problem with code? If you have, you will know why it hurts so bad to lose that ah-ha moment at that level. It's something special spending a long time on something, learning as you do it. I do understand you can get this through possibly an LLM, just different. Take a mathematician spending years on a problem. Seeing a computer do it in a matter of a second or "11 days", is devastating in a way.
Yeah, I used to get a kick out of building a perfect, performant, keyboard-accessible, a11y compliant and well-designed dropdown menu. Building my own rendering libraries. Making things run at 60fps. Optimizing server code, HTTP performance. Watch a full fleet of servers running my code in action. It was great.
Now I get the same feeling out of building an entire component library in an afternoon, running my code in a Nintendo Wii with twenty minutes of effort, hacking a LED display that I bought for €5, writing a tool to update my keyboard that only supported Windows, or building projects that would take a team of twenty engineers in the past.
We just got a power upgrade, the magic is still there.
This reads like "I used to enjoy making a home cooked meal for my family, but now I can buy ten off doordash in the same time".
in the end it's just sad.
Nobody is stopping you from home cooking however you want.
Working in a commercial kitchen however is a different matter. But there again, nobody is forcing you to use LLMs. Cook however you want.
> But there again, nobody is forcing you to use LLMs.
In the sense that I can quit my job at any time, sure. But my employer certainly requires LLM use, and even if I found another position that doesn't, I have no reason to believe that will last.
This is the commercial kitchen part of the analogy. Either you work in someone else kitchen based on their rules. Or start your own kitchen and you set the rules.
I am not denying the lack of freedom when working for someone else, or that it sucks when they impose rules on you. But that’s always been the way it goes.
The comment I replied to was about home projects and home cooking. Nothing there has to change.
If we're going with cooking analogies - I really enjoy it, yet a good rice cooker was one of the best purchases I've ever made. That's a better parallel to me.
Ah, yes, because just like a rice cooker, the work takes the same amount of time, it's just using less space on the stove, and is more reliable.
Wait, no, a rice cooker doesn't seem to fit.
A rice cooker? Is this a joke? Making white rice takes 10 minutes with a pot. Very confusing.
I know right? Yet, what I said is true, and you can ask anyone who owns one for japanese/korean/chinese cooking. It reduces effort to near zero while giving 100% consistent results.
The point though, is that I don’t feel “sad” about not having controlled the temperature and time myself. It’s a tool.
I thought the same thing until I got a rice cooker. It makes cooking a little less stressful while you make the rest of your meal. I eat rice once every 1-2 weeks and I still love it.
assuming you yourself had programmed pre-LLM i completely fail to relate to your lived experience. what a devastatingly sad way of viewing the world
setting aside the craft and mastery or satisfaction in goal accomplishment: to me the main thing is a sense of actualization, of the codebase or thing you were working on being better because you were there.
have you ever put up a shelf? did it feel good after?
Putting a shelf up is not fun. Designing, building the shelf from scratch with my own vision feels way better ;). It's a lot more of a hassle but you will always look at it and be like I did that, heck you might have even learn a whole bunch doing that as well. It's easy to go to the store, buy something and assemble it (automation).
I think this perspective comes from assuming that the LLM is doing the thinking for you. And that is not the right approach IMO. The code is still mine - I chose how to write it, reviewed changes, suggested improvements, picked the architecture, directed refactoring and benchmarking efforts, tooling, scope of tests, and so on. It feels quite similar to being a project lead.
Code can be art too. There are many ways to solve problems but finding this easy and elegant way which is just beautiful is marvelous.
Downgrading programming to typing instructions is like downgrading mathematics to writing characters.
This is not an issue.
Nobody cares about typing instructions. If someone can click instructions or voice them, it all the same.
Programming is about finding the right instructions. Not about typing.
As an illustrator/animator who codes as a hobby and to produce games that are mostly just making that art interactive. I feel like AI is taking over my humanity when it’s doing any visual art or design work. But when it does code. I care much less and am just happy that I reach my goals faster. This is very personal and I completely understand that if coding is your main thing, code by genAI feels worse. I do fear for the future… At least coders have been able to save some money. Visual artists are mostly broke.
If you were good with money hah!!
What will be the purpose of a graphic designer when Google can generate you a logo, endless combinations. Devastating to me.
I've seen it first hand, it's pretty mind blowing and rather scary. You can't not feel that way after some time. The hype disappears.
I feel like LLMs are akin to a performance enhancing drug that's gained mainstream acceptance.
Everyone can run a 5 minute mile now without training. I used to like training to be able to do that, but now that it's accepted everyone can do it for free (and people don't care if you did it the hard way) the joy has been sucked out of it a bit.
Very much so. I feel like LLMs are even greater force than something like "steroids" which in the end are deadly if abused.
Except performance enhancing drugs are banned from sports because that’s how they want it to be played (it has nothing to do with safety, look at non drugs like the LZR Racer swim suit).
If you wish to make software engineering your job then it stops being a game where we ban things simply because they provide an “unfair” advantage.
If you wish to play at programming “the way it used to be done” then by all means go ahead. But mixing methapors between sports and work is not helpful.
I think you grossly misunderstood my point. Just saying the hobby side of it is less fun because the effort part of it feels more pointless.
I guess I don’t understand the motivation you have for perusing your hobbies.
To me, the effort part only feels pointless if you want to accept LLM-derived code as comparable. Any marathon run is pointless, you go in a loop and we have cars. The point is to do the run yourself unaided.
That a computer can play a virtual instrument better than me (and continuously better than anyone) has little bearing on whether or not I continue practicing on my piano.
The world at large does accept LLM-derived code as comparable. The same cannot be said for driving v. running 26 miles.
It's more like they are being carried in the arms of a big robot who is doing the running for them, but everyone has somehow agreed to say that the human "ran" a five-minute mile because they ordered the robot where to run.
If they can take away your feelings of what being human is so easily then you should have taken care to develop it better.
Oh I'm fine but people around me aren't and that's from accountants, to writers, to artists(music, drawing, animating), look around you. I'm the kind of person who doesn't buy bread, I bake everything from scratch, AI won't take a lot away from me, I'm a lover and creator. I do worry though, it may take everything in a way eventually, that's the sad part if you think far enough into the future.
I'm curious, is your database work all hand-coded? Tidesdb is extremely impressive in any case, and I just saw Turborel which looks interesting. Your commit rate is pretty intense -- speaking as a hand-coding dinosaur myself, if this is all by hand too I'm now even more impressed (and a bit jealous for your level of productivity!)
Lots of people define themselves by their work. Might be able to indict that. Or that society made that a viable or indeed encouraged option.
I would blame society, yes.
People need to reflect and find themselves instead of relying to their own automaticity to get them through life, stop and smell the flowers a little.
I'd say they took the inhumane parts of being a programmer away and people who spend 30 years turning themselves into robots don't know what to do with themselves now.
Programmers were just the first shoe to drop. The same is now coming for the entry-level engineers as agents learn cad programming which has the same complexity barrier to entry.
We will soon trade that complexity barrier over to the agents and we won’t know how it is done, because the agents always did it for us.
That's a pretty funny take but you need to zoom out and look at other white collar occupations and then blue collar that will be cheaper to automate.
This is a totally fine position to take - if you have no intention of staying in the field as a professional.
The environmental aspects can be solved.
Quality is a measure of the person driving the process, models can write code better than the average engineer.
The impact on learning, seniority etc is the one big unknown - but I believe can/will also be solved.
> The environmental aspects can be solved.
I don't think that matters. What matters is that they ARE solved. Which is not the case today.
> models can write code better than the average engineer
If you're not interested in "average", volume isn't going to make up for quality. I'm certainly not perfectly satisfied with LLM output quality, but even the best programmer in the world will undeniably be helped by LLM tooling, even if only for having it write tests, benchmarks, run experiments, create research summaries, and so on.
> The environmental aspects can be solved.
I’m sure the people dying to air pollution and high temperatures feel good knowing that it can hypothetically be solved.
Even if you have a hard line against using LLMs to write code, for whatever reason, they are undoubtedly extremely useful for reviewing code and finding bugs. Why would you not take advantage of this?
It's not all black and white.
Do I write less and less code myself? Yes. Do I read less and less code? Maybe. Does it always matter? No. Sometimes, the agent writes code in a project or section of code that is sensitive and deserves a thorough review. Sometimes, it's in a tool that you would never have had the time to write if you didn't have an agent. Or it can be in a project that is so well covered by TDD that you can be confident that it won't break. There could be performance regressions or duplication / code creep, but once you realize it, you can ask an agent to simplify the code and find ways to prevent that from happening again.
There are cleanup / technical-debt-reduction tasks that I thought would never be done in my lifetime due to lack of time and other priorities. But now, I'm blasting through them with Claude. I cannot imagine the lack of productivity I would suffer if deprived from an agent.
That said, I agree with most points the author makes. It becomes harder to grok the code, just as it becomes hard to navigate without GPS navigation once you are used to it. It is maybe necessary to force oneself to do a development task once in a while without the help of an agent in order to stay sharp.
But stop using LLMs? that sounds counterproductive.
Retired after 4 decades of programming for a living… To that end I am now a "hobbyist" programmer and not affiliated with a Corporation™ when I "ship" code. Perhaps I would feel differently if I still were.
As a hobbyist though, I find that LLMs are allowing me to tackle projects that I would not have tackled at all but for the existence of the LLM.
It's an important point to make (to me).
Many of these projects are rather tedious. (Other coders though might enjoy what this one-man calls "tedious".) I have found that liberating.
I've been suggesting my junior colleagues recently the following mindset: for the last 5 years you have been milking cows, that was your job, and you were great at it. But this job ceased to exist [somewhere around August this year when Opus 5 appeared] You have a new job: you are a barista now [and you are going to serve oat milk]
You can still manually type code, it can be a great hobby, but it is unlikely that someone will pay you a full time salary for doing it
Except your job as a software engineer has never been to write code, it has always been to produce software. Whether you do this by using AI or by rolling your head on the keyboard doesn't matter, and nobody cares.
Yes, people care. Part of the job of management is not just to define what is to be done, but how it is to be done. Let's put to bed this notion of "nobody cares how you do the job as long as it gets done" because it's hogwash.
In the early 20th century, Frederick Winslow Taylor came up with scientific management, a set of principles for determining the most efficient way to perform work tasks using systematic observation and measurement rather than tradition and "rule of thumb". The problem Taylor was trying to solve was that of soldiering, or as we call it more euphemistically today, "quiet quitting"—doing the bare minimum of work necessary to keep your job. If the best way of performing a particular task were known to management, soldiering workers could be held to account for not performing as much work as they could, effectively stealing from their employers. So since that time, business has had a vested interest in understanding the best way to perform all business tasks and making that the institutional standard.
You might think "But that doesn't apply to us in software engineering/IT. We use our smarts to solve problems." You couldn't be more wrong. Milt Bryce's insight was that the exact same management principles that applied to the manufacturing and construction industries applied to information systems as well, and treating a software shop like an industrial factory would save the company time, money, and effort.
Today, it is known that, when properly prompted, LLMs write better code than humans, much faster than humans can, and test it much more thoroughly as well. So yes, your employer absolutely cares whether you use an LLM or not. What rational person wouldn't, especially if they don't want to waste time or money? Furthermore, now that LLM use has been standardized as best practice because they are vastly more efficient, if you refuse to use LLMs on the job, you are stealing from your employer. Your boss has every right to fire you, and they'd be right to do so.
Except usage of AI is not only about writing code, it produces software very often from very small intent, shallow context and few bread crumbs. And you don't need to play Planning Poker with it
I have the personal rules regarding LLM coding:
- Try to prove the concept early on. When you start spinning in circles, then it might be time for a different approach
- I’ve had a lot of success with projects that have not started out as LLM codebases. And adding features one by one and testing really carefully by hand
- UI generated by LLMs are overly verbose. The key lies in the iteration. What you can cut, move or approach differently. But you have to have taste.
> "LLMs expose the literacy gap between great and mediocre coders. If you can't see how bad the generated code is, LLMs will only make you not see it faster."
I wholeheartedly believe that if the general trend in SWE goes without hiring new grads/self-taught people (who can still use AI-assistance in their work), we're gonna be seeing huge outsourcing to AIaaS companies and generally become tremendously dependent on them when existing pool of seasoned programmers goes extinct and the work doesn't intrigue training new people.
Although there is cheap, open source models running locally or available at scale on reasonable prices without compromising programmer integrity.
Genuine question: Will you also reject the results and fixes regarding the current PHP CVEs until there are handcrafted versions? And - a question from another perspective - would you be open to using Mistral in a self hosted environment?
Good article.
I don't use LLMs in my personal work too. The reasons are like yours.
If you care about your privacy, security, skills, personal feelings and personal growth, you mustn't use AI or LLMs.
I work on what should be pretty simple things (3D models of projects for CNC machines) and based on flet.dev recently announcing 1.0 and a quick test one-shotting a convincing protototype of a drawing program description which heretofore every such system had failed at miserably, decided to proceed with it.
I got a quick prototype of a rabbet box generator:
https://studio.flet.dev/run/bicQWc3Aul/
but the geometry was all wrong and ultimately required that I describe the calculation of the position and dimensions of each element in exhaustive detail in order to get a usable DXF (the wireframe preview is still all messed up) which eventually worked to make a box:
https://community.carbide3d.com/uploads/default/original/3X/...
I was also drawing the design up in an interactive CAD/CAM program, and modeling it in BlockSCAD/OpenSCAD (and dropping into BelfrySCAD to figure out rotation):
https://www.blockscad3d.com/community/projects/2169316
(and speaking of rotation, at this time, the sliding and hinged lid options open on opposite sides in the preview...)
Since then, I've made a very simple generator which simple does a box decorated with lines, arcs, and circles on each side --- my intention is to dis-assemble that and use it to write a Domain Specific Language implementation for creating such designs and previewing them and writing out DXFs --- which is a long-winded way of saying I've been finding this tooling frustrating to use, but potentially useful to make rough drafts of programming templates which can then be used as a starting point for more traditional coding.
Eventually all of this will go into:
https://github.com/WillAdams/gcodepreview
I’m not disagreeing with the author, but if you look at his dealbreakers: most of them will be resolved over time (quality, maintainability, environmental impact & even politics), they are not so much against LLMs as they are against the current versions of them.
The only arguments against AI itself are about cognitive decline and “I like coding” While there is nothing wrong with those preferences, it’s akin to saying “I like building furniture with only hand tools, and not doing it by hand leads to decline in your ability.”
It could be the case that the environmental and ethical issues with LLMs are resolved, but that's about a projected future, not the present reality. Wouldn't you say that until such a time, the only ethical choice is to refuse to use LLMs?
I've struck the balance of using it at work but not at home.
At work I still read through every line in the diff (unless it's a personal util/non-production facing/critical etc). Even with this I feel less 'in touch' with my work code than I do with my home code.
> I just personally feel squeamish about having my work being done by rather skeezy companies like OpenAI, Anthropic, or, god forbid, Cursor/SpaceX.
Local models exist. Your data doesn't have to leave your computer.
As long as you can afford to spend 20000$ on your computer.
> Entrepreneur at heart
The post sounds more like a programmer at heart, and that's totally fine.
To me, being an entrepreneur is more about building products, solving problems, and creating business value. LLMs help to deliver bug fixes, new features, and entirely new products faster.
I'm not writing a blog post just for this, but the man is right. For me, the only thing I expecte from a LLM is a StackOverflow/Google that actually works and maybe some static code analysis.
Disclaimer: I use LLMs for support and deep dives into existing code, not for creating new substantial code that I intend to publish.
Quoting from the article:
> With these subsidized token prices currently, I bet we're seeing less and less AI usage encouragement in companies in the future.
I see a different trend, and for a different reason. Employees are encouraged to use open-weight LLMs hosted on-premise, or, at least, in the "correct" geographical area, in preference to models from big providers. The motivation is mostly compliance with GDPR and NDAs. And when this happens, complaints like this get ignored:
> Your local model wrote a wrong root cause analysis for the customer ticket. It's a broken tool, worse than nothing. Claude did it right. We really need either access to frontier models or, alternatively, reasonable expectations on your side about what is doable with the tools you provide.
And that's bad.
I see LLM usage as more of a spectrum than a binary decision. For the most critical parts of my day job, I still don't commit anything from an LLM that I haven't checked myself. My brain has never felt busier and more engaged on that stuff. But then I also produce absolute mountains of code (side projects, internal tooling) that I don't have time to review and frankly it doesn't really matter what the code looks like. You can choose how much to engage your brain. Every project is different.
I see AI coding as instant legacy code.
The brittle slop happens when you tack feature on top of feature because it’s fast and easy now.
The higher quality stuff happens when you dive into the details of what you/the agent implemented (looking at code, with agent, or not) trying to make the current feature set work better.
IMO there will be outsized competitive advantage to the latter. Features are now cheap. But quality remains rare.
> I feel that LLMs and their overtly verbose output trick less knowledgeable programmers of the quality of their output. When Claude spits out refactored code with tons of comments, documenting each method and variable, and tests for everything as well, it looks impressive, at a first glance. But if you dig deeper, it's sometimes just complete bullshit.
This is pretty spot on. But it's important to note that the resulting code, is still often significantly better than what those developers used to produce. Especially under tight deadlines and pressure to complete CRUD like interfaces. We simply can't afford spending a whole day tweaking a sortable table on the web anymore.
I agree that it produces code that is better than many of my colleagues. I have spent the last 14 years honing my ability to build code in a scalable way that works for basically any domain. I still produce better output than the LLM. But the incentive to encourage my colleagues to reach that kind of level is just gone, and that's what frustrates me. As humans, we could have been so much more efficient, but instead LLMs came in and are steering us towards the median of slop code. Slop by my standards anyways.
Exactly! It's a bit of a tragedy.
But then again, LLMs do offer benefits that are impossible not to want to harness.
I guess nobody cares about, if some one use LLM or hand written code. They all care if you are hired and deliver the output comparable to others with all their requirement fulfilled. I still remember how wordpress developers were against elementor during its early days and look how pagebuilders became default choice now for wordpress.
It is perhaps confirmation bias, but I feel like I see fewer and fewer of these posts on HN. All respect to the author, life is too short to force yourself to do something you don’t like. But, these post seem more like a goodbye to the train that has already pulled out of the station.
The quibble I would make is with the “code is not that good” and the implication that they are so much better at coding while those who have adopted AI are “mediocre”. It’s certainly possible this is right. I would be the first to call myself a middling programmer. I am still waiting to be inducted into the Real Developer (TM) society. (Is it a card? Or does someone teach you a handshake?). But my question is, why, if you’re an ace programmer, can you not get good results out of an LLM? These things are endlessly configurable. They are begging to be tested and, dare I say, engineered to your system and way of doing things. So, why are your results still bad?
The author's not wrong that left completely to their own devices, and especially if your working on something that's not well represented in their training data, LLMs will make a mess of things. But a Real Programmer (TM) isn't doing that. (Or so I assume. like I said, I haven't gotten the pin. Or is it a medal? A certificate perhaps?).
One reason is that there is zero point in posting this type of article to HN anymore. The replies are always the same and nothing is gained.
Rest assured, though, that the sentiment grows ever stronger.
Not to be a jerk, but what if I told you there was a raging debate about widgets vs wodgets in the last 6 months and, although it seems pretty clear that widgets were being adopted across the industry at large, there was an ever growing sentiment that wodgets were actually preferred and the market was going to reverse itself, any day now?
I can’t really point to any evidence of this because the wodget people have stopped posting about it and every month the cost of widgets keeps going down while they simultaneously get better and there’s so much capital and talent being thrown at widgets that it’s impossible to think a wholesale reversal could even be possible. Would you tell me that, “trust me, bro” is not really an argument?
Who said anything about a wholesale reversal?
All these things can be true simultaneously:
* AI has wholly taken over the corporate world
* Programmers can now generate (and are now expected to generate) massive amounts of code
* This massive productivity boost is, oddly enough, not reflected in consumer products at all
* In fact, most of this newfound productivity seems to be aimed at making AI widgets or infrastructure for maintaining AI widgets
* LLM use seems to hamper software development at its current level of complexity (because AI is incapable of independent abstraction and simplification)
* Programmers are deskilling en masse and turning into managers (without admitting it to themselves)
* Technical programming discussions have become incredibly boring for people actually interested in the craft
* The externalities of LLM use remain the same (and, to an extent, can’t actually be fixed)
* Most of the benefits of LLM use are going to management; programmers have to do a lot more for the same pay
* There will always be programmers who code by hand, even in a professional capacity — and it’s quite likely they’ll be the ones dragging the industry forward (up the ladder of abstraction)
Yeah... This is about to age really badly, not to say that the principles in the post are incorrect, but this person doesn't seem to realize that they are in a free market and that each model improves on the last on almost every aspect. We will see what they'll think about this choice when all their competitors do 100s of peoples worth of work just with a few people
I agree with you, but also it won’t matter at that point because the job market for coding will have contracted to the point where practically no one is hiring.
“You’re not breaking up with me. I’m breaking up with you.”
For me, I don't mind if people want code written by LLMS. What I DO have a problem with is people handing over their problem solving to LLMS.
If someone uses Resharper to make some ugly code pretty, fine, I don't mind - as long as they can understand and explain the result. My issue I'm running into daily which drives me nuts is stopping people in their PR's and asking "Why did you do it this way? This seems like an odd approach" and get "Oh I dunno, Claude wrote it". Then what the hell are you checking it in for?
Between SO, Resharper + Fancy IDE tools, and the mountain of plug-and-play cloud services we have, I think the era of 'writing everything yourself' was already dwindling. But at least if someone chose one framework or library or SO post over another, they could explain why they chose it later on. Some sort of domain knowledge was being built up and transferred between devs over time (and I'm not talking about documentation). What I see more and more is systems being checked into production where the 'author' doesn't fully understand what it's doing, then it breaks in a way they don't expect, and then I see a team of clowns all with their claude terminals open desperately typing "WHAT DOES THIS ERROR MEAN" because nobody understands why it was built that way in the first place.
Fine get LLMS to help write your code, but do your job and handle the problem solving part. What are you being paid for otherwise?
Reminds me of Oscar, the accountant from The Office who would refuse using a calculator.
That's kind of audacious, for a php programmer
Yeah, when I saw PHP it made me question everything.
It's the language I hate to write the most.
I can say the same about any opinion of an LLM 'programmer'
This is a roundabout way of saying you're leaving the profession.
We now have people commonly running multiple concurrent programming tasks, while automatically and interactively testing them, reviewing them, and validating them. They're then handed for human review, where little is found because the quality regime is now set so high. We're talking weeks of development + testing/validating time brought down into the realm of days.
So this is pure "my horse & cart are just as good as the motorcar"-levels of argument. If I bury my head in the sand long enough, and deep enough, this will all just blow over, and we'll go back to doing stuff significantly slower/worse any day now...
The quality of stuff I am shipping today is the highest it has ever been, and tested/validated significantly more comprehensively. Why? Because time/resources was the limitation, not willingness or skill. I always wanted to test for every single possible edge case/scenario, but it wasn't in the time-budget (and diminish returns). Now I don't need to make that trade-off.
So I have some questions for agentic dev aficionados:
- Why should I even start vibing up my desired tools and projects when I can just wait it out so a better clanker emerges 6 months down the line?
- What guarantee is there that Rust is the best programming language for vibe coding when the models could improve to directly output assembly? What incentive do you have in vibing up something?
Good software comes from good ideas, design, and a deep understanding of why it does things. A better LLM will not give you much of that.
To answer your question: 1) do you want it now, or in six months? and 2) it will still take the same amount of human effort.
I can answer question #1 from the perspective of an employee who trades time for money: I don’t get immense joy [1] from writing code to do whatever dumb corporate thing my employer needs this week.
An agentic workflow lets me literally sit on my hands (or play Star Wars: Galactic Racer, or play my musical instrument, or work on my CAD hobby, etc) while the agent machine does my work for me.
The best part is that this is how my employer wants me to work. They literally want me to be lazy. Works for me!
Where is my incentive structure to not use AI?
[1] coding manually brings me a non-zero amount of joy and mental satisfaction and stimulation but I am still trading time for money.
How long it will it take your employer to figure out that your hours are really only worth a fraction of your current rate?
1. At my company I am basically a regulatory requirement.
2. I’m paid to be a warm body who is available. That’s I am paid salaried instead of hourly.
3. I don’t really care if this situation changes in the future. If AI takes my job there’s nothing I can personally do to stop that from happening. I’m just saving my money and planning to retire as early as possible. I view work as a necessary evil.
Seems like you make best out of it :)
You're not being paid to be busy, you're paid to be useful. A man with a tea spoon digging a ditch is worth a lot less than one with a excavator.
Yes, but if I only use the excavator for 5 minutes and coast the remaining 55 minutes, I'm less useful than someone who uses the excavator the whole hour. Now, if I'm particularly skilled at using the excavator compared to my peers, I might get away with working less. If not, working 5 minutes while charging for 60 minutes will eventually get me fired.
Generally, automation does not make us work less because the expectations rise equivalently.
I will not be using a modern compiler, I will be using [assembly|punch-cards].
you can do that for personal/passion projects, but you will just get fired if you don't use LLMs at your job
Garment manufacturers do not hire knitters to knit jumpers.
That's an extremely privileged take.
How? Cognitive skills and enjoyment of coding is not something exclusive to the privileged.
Most of us in the field have to produce software for money, and the economics of that have shifted to the point where LLM use is table stakes. Programming by hand is now an idle curiosity, a leisure-time activity.
I can’t find a job at all. Hundreds of applications sent, all thrown in the trash.
To not use an LLM at all for software engineering? That’s just a joke. You can also deliver food with a bicycle. Good luck making a living doing that.
In what way? I see it as the opposite if anything, the rise of LLMs marks the first time programmers have been expected to spend money on tools since around the 2000s.
Looks like you didn't want that milkshake anyway...
> Before anyone calls me a luddite or a AI-skeptic
If you're afraid of being called a luddite, you've already lost.
You shouldn't value the opinion of those who would insult you for not wanting to offload something you find intellectually fulfilling to a machine.
I'm using it for Rust, easily handle 1mil/sec connections and I'm okay with this.
You don't need to use LLMs for coding to stay "competitive" with your colleagues.
I work for a FAANG, we have unlimited AI credits to be used on any model we want, with basically any tooling we want.
My whole team massively uses AI, I barely do. I use not even 10% of the tokens that they do. Yet I have not only the highest rate of PRs raised, but also the highest rate of PRs I reviewed, and the second lowest number of revisions per PR.
AI is all about fake productivity. You feel productive while you're achieving the same, if not less (or even often, nothing at all).
Long term it's pretty obvious that people heavily using AI will become a lot less productive, if not simply unable to work as software engineers. My colleagues are already scared.
In fact, as a challenge to anyone who says they "haven't written a line of code by hand in X amount of time", go do a test. Try to write any code without any LLM use for just 30 minutes.
All that tells me is that your org hasn't learned how to use AI effectively yet.
There is no way a human programmer can keep up with a computer doing the work of four programmers at once. You might not see this for every problem of course - in product development the bottleneck is often the design/product work, feedback cycles, not the coding.
Nah. It sounds like OP is using the tools where they help him instead of for everything regardless of utility.
Which seems like the right way to use tools?
Yeah of course, it's always "you're not prompting it correctly", right?
I understand though, it's hard to feel your skills atrophy in real time while at the same time realizing that the data shows your productivity has in fact not increased at all.
This is extremely accurate, but HN doesn't like it when you burst their bubble.
A good software engineer has always been able to write a ton of code all by themselves in a short period of time without any oversight. There's nothing romantic or intelligent about that. It's just reckless.
Teamwork is more important than ever, and yes of course that slows things down. That's the point. The decision making is the slowest part. 5 hours of meetings today can completely change the trajectory of the next 5 years. This isn't a revelation for anyone but the most naive.
Im sorry but nope.
Okay. My knee jerk reaction to this is
1. OP probably works on a team that does not ship much. It's a dead end team on maintenance mode.
2. OPs colleagues were not good engineers even before LLMS
3. OP is lying.
4. OP is delusional and is actually left behind. And is measuring wrong metrics.
Which one did I get correct and wrong? Does you manager also agree you are the most productive engineer in team?
We're a greenfield team working on a new piece of software.
My colleagues are all also FAANG software engineers.
> Does you manager also agree you are the most productive engineer in team?
It would seem so.
Additionally, in my mid-year performance review a couple of months ago he specifically mentioned how every metric also looks great.
It seems the only option left is that I'm lying.
In reality, your knee jerk reaction was to be scared and deny that what you have taken as productivity increase was just an illusion, and that you've actively been losing your skills for literally nothing.
Hmm. I don't know to be honest. I actually ship way more features in my side projects. Even work wise I have seen projects delivery speed going half or 1/4th of what it used to be.
And all the engineers in my team are full on AI. Even the best ones.
For me I see the opposite of what you are saying.
I don't particularly see much value in handwriting the code itself after the tech specs and all is finalized.
So me personally I am liking how the industry is going.
Never really enjoyed writing thousands of lines of code to be honest.
Though always like programming when I was young.
> I don't particularly see much value in handwriting the code itself after the tech specs and all is finalized.
It's impossible. You are lying.
If you developed software, you should know "the tech specs and all" is never finalized, the requirements are always changed, when you are developing it, the specs or details are changed or improved.
Hmm. None of us in our team has written hand written code for almost an year now. We don't really find the need anymore.
Pretty much defining tech spec and getting it implemented by breaking through tickets are more than enough.
There might be bugs. Wbut we catch it through testing and get it merged while building.
> I actually ship way more features in my side projects. Even work wise I have seen projects delivery speed going half or 1/4th of what it used to be.
Again, you are conflating appearance of productivity, with actual productivity.
Are you shipping more features in your side projects because AI is allowing you to ship more features faster (let's assume at the same level of quality), or are you investing more time in shipping features in your side projects, because you FEEL like AI is a productivity booster and therefore you get more out of your time, even if it's not real?
Are projects at work estimated to be a lower cost because of AI productivity increases, or because estimates were too high previously, and you could always deliver at that speed?
For the second point, I'd add that any launch announcement I see at work touting AI gains of 50-75-90% NEVER hold to any sort of scrutiny, so it's also simply, lies? Employees currently are desperate to look good in the eyes of the CEOs pushing for higher AI adoption.
You're entitled to feeling more productive, I'm just saying you likely aren't, or not by very much. Add to that the fact that you didn't like writing code to begin with, it's easy to fall into this sort of falacy.
To be clear, I do use AI, and I do see some productivity gains, but they're not in writing production code (issue management, automation that was too expensive before, generation of code or artifacts that I don't actually care much about, etc.).
Very well-written, and undeniably relatable! Sadly, I am compelled by forces beyond my cognitive control to respond, especially to points I've seen and refuted before. If nothing else, I hope it's helpful to know the other side of these things :)
I hope it's not too combative to start by saying this is a huge red flag for someone who hasn't checked in on what post-Mythos agentic engineering is like. Of course LLMs are undeniably involved, but it comes off like someone quitting social media by decrying protocols (or worse: series of tubes). LLMs are an essential component that has finally thawed the AI Winter, yes, but they're still just parts of a system. A harness is far from a mere wrapper around a neural network, to say the least. That dichotomy is a false one (many software tools are productionized as services), but the underlying sentiment is clear and common: that querying a chatbot is akin to asking another human to do something for you. This comes up most often in Reddit's vicious "AI wars" about digital art, where generating an image cannot be a creative act on the users' part because it's more like comissioning a painter than it is like painting.I think the response is obvious (and why this is merely an aside rather than a "dealbreaker" proper): this is granting personhood to neural networks, which no one who supports this point would admit to in a thousand years. Either they're people and you're asking a person to think/paint for you, or they're inanimate machines and it's a tool; there is no middle ground. (If unconvinced: what about a camera makes it a tool to be used rather than a peer to be delegated to? It can draw a picture in milliseconds!)
This is an underlying worlview thing that poisons the rest of the analysis, namely that nothing (important) ever happens. That surely this just a hype moment that will pass like the iPhone moment and the Bitcoin moment, and that anyone who says otherwise is surely crazy. It's begging the whole discussion. The first paper is Microsoft's[1] recent incredibly informal survey of how people feel working in a career they know to be changing beyond their recognition, and with tools that didn't really exist 6 months ago. Yes, orchestrating agents is a different experience than we're used to; no, a simple survey could never prove that they are cognitively dangerous.The second paper is notoriously misleading, and a stain upon MIT -- observing brain activity differences between people who have to think deeply and write an essay by hand and people who type a sentence and then sit there until the allotted time is over is not surprising, and definitely doesn't show what they clearly intended the flashy graphics and suggestive conclusion to show (that using chatbots leads to brain damage). There's more, but long story short: they're manipulating valid techniques to make a tool seem like a uniquely-dangerous toxin, when the exact same effect applies to all previous tools of note (calculators, typewriters, word processors, translators, even Grammarly).
The third paper is just highly-speculative, deeply-polemic schlock, obviously.
1. This is an unfalsifiable claim, which is lucky because the goalposts have had to be moved many times to get to "looks impressive, but is sometimes complete bullshit". Turing refutes this thinking quite directly in `§6.5` of Computing Machinery and Intelligence (CMaI)[2].2. Many experienced engineers disagree, to say the least, as do companies investing billions.
3. Again, you can't help but sense the author hasn't used post-Mythos models; even if they have, the fact that such a huge leap has occured in just the previous 24 months is overwhelming evidence against this notion. The linked sources being A) an /r/AntiAI post (!) and B) a pre-Mythos essay don't help.
I'm quickly getting the sense that the author is too vitriolic and dug in to be reasoned out of these views :( Hopefully it goes without saying that "your code sucks because you gave it to [HATED_FIGURE]!" is an invective, not a premise. For the rest: see previously preceeding section, which is indeed "closely related". Same! I also like playing video games and tending to plants -- just had a blast on Beyond All Reason last night, and my Philodendron Florida Ghost just unfurled a wonderfully-ghostly new leaf. Neither are my career. I'm most dissapointed by this part, as this person is Finnish and should know better about the Google story :( What's being framed as some unheard-of act of environmental terror is really just the planned and almost-completely-permitted early harvest of a small plot of "planted forest", i.e. a tree farm, which are one of Finland's main industries. Everything in this map in blue is tree farms, with the Muhos site in the middle: https://i.imgur.com/HyTVp1I.jpeg [3]The preceeding 'this technology uses power' point doesn't need refutation, but it underlines the problem with the point above: this is post-hoc reasoning. Cutting down a tree farm in Finland is so, so far down the list of priorities for actual environmental activism that it's hard to describe, and yet this post has nothing about not working for companies that serve non-vegan meals for lunch, uses air conditioning, or flies people to yearly retreats.
Even if this were relevant (which it's not in a post-GLM-5.3 world[3]) it offers no argument, and thus cannot support the conclusion. Also not an argument. Heroin isn't inadvisable because it's "here to stay", but rather because it's a toxic, extremely chemically addictive narcotic that kills many thousands of well-intentioned users every year, and ruins thousands more families before that.TL;DR: Apologies to the (again, clear & well-intentioned) author, but this essay is like heroin -- I dislike it!
---
[1]: BTW, there's a reason Microsoft published this, and it's the opposite bias that this author assumed. Read this article and see how deep the conflict of interest admission is buried -- it says it all: https://www.project-syndicate.org/onpoint/anthropic-training...
[2]: pp. 12 of https://www.hec.edu/sites/default/files/documents/Computing%...
[3]: That tool, more info, definitive Finnish zoning documents available at this ChatGPT link (ew, I know, I agree!): https://chatgpt.com/s/t_6af081bc590881919c7231419db48a72
[4]: https://www.anthropic.com/research/glm-5-3-and-the-spread-of...
The comparison with heroin frankly is bizarre, as if using LLMs was purely hedonistic activity.
LLMs are tools like motor vehicles. They allow you to get somewhere, quickly but brutishly. You won't be able to appreciate the beautiful scenery much, as it rushes by. You're going to have to compensate for the exercise you would have gotten, had you walked, or it's going to be unhealthy. It's undeniably bad for the environment (electric or not) and has other negative externalities. The politics of many of the countries supplying most motor vehicle fuel to the world are beyond fascist by modern leftist standards. Yet, we depend on them, we have constructed a lot of the infrastructure we need to live around their existence, and even if every city became walkable over night, the last mile for most transport would be covered by some motor vehicle. There are many "what ifs" surrounding motor vehicles where the answer boils down to: "Well, then we're fucked". But we're not fucked today, and so on it goes.
Of course you can try not to partake in motor vehicles, and insofar as you don't make a moral grandstand about it, that's totally fine with me. But the rest of the world is in it for the ride. The first cars weren't very good either.
I agree with most points made by the author, however the cognitive impact depends on how you use LLMs. Here's an example: I build so many Phoenix / Elixir applications and one of the things I really hate is the amount of boilerplate code I need to write for every project. It is exactly the same (eg. Setting up vite, removing existing mix based node integrations) and modifying scaffolded code to adhere to my design. I already know CSS inside out and Tailwind CSS too. So, by offloading the task of rewiring existing scaffolded CRUD templates, I would argue the opposite - I am saving precious cognitive load from doing repetitive data entry work.
That's why I have a very clear personal policy of always being the architect and instructing LLMs what AND how a task must be done as opposed to blindly just trusting them with everything - that is how you lose your ability to think.
Maybe an LLM would help him avoid the 418 error I am getting?
This sounds like, “I’m not going to buy any food at the store at all; I’m going to toil the soil for any nutrient I put in my mouth.”
Cool story bro, but it sounds like you are trying to convince yourself.
See you back here in a month, or so.
That's because the history of new technologies, new tools, etc. is one of resistance from those who knew how to manually do what the technology enables for more folks. Sometimes it works out well for humanity, other times the technology fades into obscurity or is quickly replaced by something else, but at the time the pushback on both eventualities looks the same.
We'll see the same for automatic freight movement in the next few years, as just one example.