8/24/2026 at 4:17:09 PM
100%We're already seeing this at the enterprise level. Companies have dictates from leadership that "if you're writing code manually, you're doing it wrong."
Okay, that kind of works for a while. We are indeed producing a shit-ton of code, but the reality is that engineers are pumping out code faster than the humans can understand and (honestly) review it. That sounds great until you realize that "hey Claude, read this Jira ticket and implement the feature in this code base" isn't really worth $200K/year.
This is all complicated by the fact that we're also losing our grasp on reality from the other direction because we have leadership air dropping AI generated manifestos on the product owners and product owners having to use AI to transmute all that shit into 1,500 word Jira tickets that are 10% necessary feature work and 90% LLM boilerplate.
So now you have software engineers whose job has changed radically to the point that the hardest part about being a software engineer is just filtering through AI generated artifacts from all directions just to try to get a feature out the door.
by ryandvm
8/24/2026 at 4:26:29 PM
> That sounds great until you realize that "hey Claude, read this Jira ticket and implement the feature in this code base" isn't really worth $200K/year.Nor even €50k/year.
Two things are true:
1) The coding part of my career is over. LLMs are capable of doing everything I've ever been paid to *write*.
2) My actual job also included non-coding work: Does this attempted solution even work at all? Is this solving the right problem? Even if it's a valid solution to the right problem, is it the best solution given the time constraints?
That last one, "given the time constraints", is a place where my experience is still useful. The AI is as lazy (or as optimised for fast wins) as the humans whose examples it was trained upon; but an LLM costs so little that the answer is always "do it right" rather than "do it fast". A lot of people don't know what "do it right" even looks like, having only ever known e.g. websites that take 5 seconds to load because of all the adverts and analytics, and never the world where machines with 1% of the CPU and no GPU at all could fit a fully playable first person shooter in the same memory footprint as that page.
At least, I hope this "is a place where my experience is still useful"; I may just be telling myself a nice story, same as all the other people through history who have found themselves obsoleted when the automation came for them.
by ben_w
8/24/2026 at 4:42:56 PM
Before, if I would start working / thinking on a problem and discover it was harder than anticipated, that often was a signal that the feature may not be worth it. Because implementing it doesn't fit the current model of how things work or similar. Then it was back to the drawing table and find a better way of solving the underlying issue.But an LLM just happily chugs along and does it, no one feels the friction, which means you never stop up to think if you're solving the right problem, or in the right way. I'm already seeing this bite us in the ass, as you get hacks upon hacks.
by matsemann
8/25/2026 at 3:44:14 AM
That's why you first ask the LLM: "tell me how you would do this, and ask me any clarifications and questions you may have, and share any other thoughts you may have. Don't implement yet."The LLM will look through the codebase, think, and tell you what it would do and if there's any design decisions you would have to make, as well as other things you probably need to be aware of. Then you go through the LLM's output and address all those decisions point by point, asking the LLM more questions if something isn't clear or requires more investigation or you're unsure what to do. And end with "address what I wrote, and share any other thoughts or questions or things to clarify you might still have, don't implement yet"
And you do this back and forth until all the design decisions have been addressed and you feel confident of what the code and architecture will look like, and only then say "ok, implement"
That way you get a lot of the benefits of writing it by hand (being forced to think through what the best design would be and how it would integrate with existing code, and increasing understanding of how existing code works) but it's still much faster. The tool I personally use is Cursor in auto mode.
P.S. actually before even that you first ask the LLM "what is the current state of X in the codebase" and then you ask follow-up questions until you have a good understanding of all the details that are relevant to you. And then you can start having the design/implementation conversation in the same chat context, since having the above information in context is useful.
P.P.S. and you can also ask a bridge question like "can XYZ be cleanly added with how things are currently structured?" or "what would it take to add XYZ to the project?"
by bogdanoff_2
8/25/2026 at 8:36:03 AM
Sure, but I'm only able to do that because I'm intimately aware of everything in the code base. The more I do this where the LLM ends up writing the code (even based on my decisions), the less good critique I'll be able to give in the future.by matsemann
8/25/2026 at 2:23:02 PM
Is that the experience you had? What if you ask it questions about the codebase?I find AI agents really great for codebase exploration and understanding how it works. In some ways even moreso than from manual implementation since it's easier to get a global picture.
You can also ask it questions like "are there recurring patterns of how X is done in the codebase?" to which it might answer sometime like "there are actually three competing patterns" and tell you what they are and the exact files, and then you can choose to refactor them if you want.
by bogdanoff_2
8/25/2026 at 6:27:11 PM
Not everything is encoded in code, though.by matsemann
8/25/2026 at 9:28:08 PM
Like what?by bogdanoff_2
8/25/2026 at 5:31:36 AM
I like using grill me in conjunction with obra superpowers spec driven developmenthttps://www.aihero.dev/skills-grill-me
https://github.com/obra/superpowers
When I'm doing something quite complex I'll also throw in gstack office hours but I find that its usually overkill for many things
https://github.com/garrytan/gstack
I do often use the /qa skill regardless though. I always hated QA because it was so monotonous and it required a level of organization and creativity i never had (i mean im the developer so if I thought of edge cases id have solved for them)
I like that /qa covers and documents every edge case that it tested and I can nudge it about other ones
by abustamam
8/25/2026 at 2:38:57 AM
LLMs absolutely do not write good code, nor documentation. They write even worse code when they have to modify what they wrote earlier and we are exclusively using the top models. The code is coming faster than it can be evaluated and there is a push to just implement things with less review but on so many occasions I have found things that would have been completely destructive.by hattmall
8/24/2026 at 10:07:06 PM
I think this is one of the most popular patterns seen nowadays. We approach problems that we didn't before because they were absurdly stupid and touched so many places that it seemed risky, hacky, costed too much time. It would be nice to go back to simpler problem solving and saying no to things that extend team skillsby lackoftactics
8/24/2026 at 6:27:09 PM
So exactly true! With ideas people unbridled, the painting-yourself-in-a-corner tendency that was always there has gone exponential, add to it the not-completely-aligned incentives, and the oh-so-clever impressive writer of long prose LLMs just end up churning. The real value add may end up being the lesson in honesty and humility to us all...by polotics
8/24/2026 at 5:28:45 PM
I first brought this up late last year – that there used to exist a kind of selection pressure against both developers and against features which would prevent certain functionality from ever being shipped, specifically:- Functionality which exceed the technical ability or knowledge of the developer which built it; and
- Functionality which would require an excessive number of changes that time/cost became a constraint (likely because it wasn't an incremental change but a significant rework, or just a bad fit with the existing product).
Sometimes I had the displeasure of joining a company where you could see developers hit these blockers and tried to fight through them (likely under pressure from management) rather than avoid them. And in the process they created a mess of buggy, half-functional spaghetti code which someone else later had to resolve.
Today however, people can use agents to smash through these blockers and ship an incomprehensible amount of crap. And what's worse is they're celebrated by management who don't know any better and see this all as a productivity win with no downside.
I suppose there are two ways to look at this – some would argue that engineers don't need to understand what they're building in detail anymore so non of this matters. Instead they can always use agents to explain what's going on and prompt them to fix any issues that come up.
Then there's another camp which might argue that agents will fundamentally have all the same limitations as humans, and that at some point a codebase will grow too complex that it exceeds even the limits of an agent's knowledge retention or intelligence. Or a codebase may just grow so large that it costs 1 million tokens to make even a simple change.
Unless agents start saying, "there's no way I'm shipping that" like humans used to I don't really see how we avoid the latter scenario... Complexity simply must have limits even if agents allow the bounds of those limits to grow.
At some point models will have to take control or we risk hitting these limits in irrecoverable ways since complexity far exceed that of what a human can reason about well.
If this wasn't true then "build me all the software" would be a reasonable prompt. Because why wouldn't we just get an agent to build everything we could ever possibly need? It's obvious that in the limit there will be limits in knowledge, intelligence and cost.
Whether it's humans or agents, someone needs to manage complexity. That is the most important thing a good SWE used to do. It's why technology selection mattered, it's why good architecture mattered, it's why clean code mattered.
by kypro
8/24/2026 at 6:54:41 PM
In my personal project I've found having a hard lines of code limit has been a good limit on complexity. Makes me really ask if I need things.One theory I have floating around in my head is that if a whole code base was microservices and micro front ends that were all less than 5,000 loc then you could fit the whole thing into a 100k token AI context window when working on it. And being few lines of code would force them to be somewhat simple
by pianopatrick
8/24/2026 at 10:23:11 PM
Yeah, I think microservices are going to see a new wave of enthusiasm for this reason in the coming years.I've had a lot success at the company I work for shipping small contained microservices for less technical teams to maintain with agents.
Personally I think this most of what SWEs should be doing these days... Code is easy to produce now. We should be handing over the creation and shipping of code to the relevant teams.
Maybe there will be more complexity overall, but it will be constrained via well designed microservices and distributed across the organisation.
by kypro
8/24/2026 at 5:52:28 PM
There is a limit, after a few 10,000's of LOC ai projects start disintegrating and becoming unmanageable.by visarga
8/25/2026 at 12:55:57 AM
Depends on the language, obviously. Some languages are more verbose than others, and relatedly, some languages force simple code structures that are less likely to become unmanageable.by marcus_holmes
8/25/2026 at 3:06:53 AM
Really?I just did the LoC measure that isn't "official" but actually closer to how AI would read it: I.e. simply actual lines. Never mind "context window".
Just in the actual source folder there are 1.9 million lines. That's not tokens. Lines. Not even LoC as per some official canonicalized definition. Various languages. ~15 year old code base.
We work with Claude just fine.
For variable measures of "fine" depending on how much devs just trust whatever Claude spits out ;)
by tharkun__
8/25/2026 at 4:22:39 AM
Yes, a 15 year old code base written by hand obviously, not by a coding agent from the start.At the same size I only heard of AI generated projects reimplementing compilers and browser engines which come with amazing tests written by hand, but even these projects generally don't become reliable enough to use.
by visarga
8/25/2026 at 4:35:56 AM
Well we also have an AI first code base, new product 160k "LoC" by the same measure. Not even a year old.That 1.9m code base, within the same time frame as the 160k was created? <10k by the same measure.
10k I can comfortably throw at a local agent on my system (see recent posts in my history). Whether I can keep it that small is another question I suppose lol!
by tharkun__
8/24/2026 at 9:34:20 PM
I believe tinygrad still caps the total LoC in their repository to 10kby Kinrany
8/24/2026 at 7:05:40 PM
10,000 LOC, hell my LLM can do that in a day!Current project has over 60,000 LOC, I find using an antagonistic agent code and architecture reviews are really handy for keeping things grounded.
by BatFastard
8/24/2026 at 10:20:50 PM
How do you know things are grounded?by ChoGGi
8/25/2026 at 2:45:24 AM
My tests work, multiple agents confirm the code base. Code reviews pass.I do very little actual reading of code anymore. Now I am more of a results merchant.
by BatFastard
8/25/2026 at 3:37:06 AM
Right, but what are you doing? Placing UI elements on a page?by glouwbug
8/25/2026 at 11:21:17 AM
> I suppose there are two ways to look at this – some would argue that engineers don't need to understand what they're building in detail any more so none of this matters.Is there ANY field where good engineers don't understand the basics? Can an electrical engineer do any work without understanding Volts and Amperes?
by oblio
8/25/2026 at 5:33:37 AM
I do agree with you, but I found that with good llm discipline you can prevent the llm from chugging in the wrong direction with a bit of planning and good ol engineering before even talking to the llm.by abustamam
8/24/2026 at 6:25:10 PM
> The coding part of my career is over. LLMs are capable of doing everything I've ever been paid to write.Remember we used to spend enormous amount of time in school and in our spare time studying computer science? Algorithms, operating systems, compilers, and etc. All kinds of insights. All kinds of fun. All kinds of hard engineering. Yet, how much time do we really need to spend in our day-to-day work implementing or using the algorithms and etc that we have learned?
Engineers have done amazing work of abstracting away the hard algorithms and data structures. In the meantime, there has been little progress or few new fields in the past 10 years or so in business that ask for implementation of new algorithms. In contrast, getting LLM to work is a new field, so it requires tons of new implementations: KV caches, speculative decoding, all kinds of variants of attention like FlashAttention, all kinds of parallel processing techniques, RL pipelines, post-training pipelines, and etc. It's just that the field is so concentrated that only luck few get to work on them.
So, maybe it's not LLM per se that removes the need of writing code. It is the maturity of the software engineering that has done so. It's just that LLM fills the last gap: making knowledge transfer so much faster and cheaper - if all that's left for most of us is slicing and dicing of what has been already been implemented, then LLM can reliably take over.
by hintymad
8/25/2026 at 12:06:31 AM
Yeah, but actually implementing those algorithms was extremely key to really grokking them. Testing those edge cases, seeing them fail, fixing them, learning "oh, that didn't fix it", repeat. Yeah, you can do it on paper (which I did), but the whole idea of going through the motions of writing yet another binary search algorithm was to lock in those concepts.But that isn't the real problem here. Computer Science was always a theoretical concept, really. The meat of the issue is the rug being pulled out from the juniors and mids.
Reading code and writing it are two different skills. I believe that both are needed to maintain a codebase. It is much, much easier to understand what a service is doing when you're actually writing code that supports it, just like it's easier to remember the contents of a report that you wrote versus one that you read.
by nunez
8/24/2026 at 9:06:07 PM
I think it follows the path of the spreadsheet. For a long while, only geeks and finance or accountants or data monkeys used spreadsheets. Then, it was such that anyone could create a spreadsheet. Vlookup was something you learned early in school or on your home computer tinkering around. There’s still some modeling gurus out there but largely everyone is developing solutions using spreadsheets everyday. And they’re doing it rather autonomously even prior to AI helping. We can talk about how they’re ugly and crappy spreadsheets but they generally solve the problem the user had.With AI, people can build and collaborate on applications much more complex with much less technical knowledge. It might be ugly and crappy but I bet they’ll be mostly autonomous and not need to work through their IT team, or go through the hell of PM and requirements. If I know my requirements, I don’t need you. Hell, I can just start building and add requirements as I come across them. It’s not a major risk to the project like it used to be.
It will, and is, going much faster than the spreadsheet did.
by conductr
8/24/2026 at 8:34:55 PM
> there has been little progress or few new fields in the past 10 years or so in business that ask for implementation of new algorithmsTransit routing is still moving fast in this area. We're still figuring out the best ways to return thousands-by-thousands transit time matrices with query-time truck dimensions and traffic updates. It can't be the only field!
by n4r9
8/24/2026 at 8:22:58 PM
> Remember we used to spend enormous amount of time in school and in our spare time studying computer science? Algorithms, operating systems, compilers, and etc. All kinds of insights. All kinds of fun. All kinds of hard engineering. Yet, how much time do we really need to spend in our day-to-day work implementing or using the algorithms and etc that we have learned?Because great insight and expertise stems from foundational knowledge.
I am a huge hockey fan. In the NHL, the players do not stop practicing the fundamentals once they make it to the NHL. They practice the fundamentals even more. Many practice the same drills as youth leagues -- stick handling, passing back and forth, shooting, edgework, shooting, rebound control, etc..
The best of the NHL might not hit the hardest, have the most accurate shot, or skate the fastest. What separates them from the rest of the lot is that they are fundamentally better than everyone else.
by hirvi74
8/25/2026 at 2:01:42 AM
So what drills do you practiceby whattheheckheck
8/24/2026 at 11:08:37 PM
> Engineers have done amazing work of abstracting away the hard algorithms and data structures.Not to mention we told everyone to not roll their own anything, just use the free library for, clocks, time, crypto, auth, IPC, etc!
by calvinmorrison
8/24/2026 at 5:11:28 PM
>My actual job also included non-coding work: Does this attempted solution even work at all? Is this solving the right problem? Even if it's a valid solution to the right problem, is it the best solution given the time constraints?This is not non-coding work. This is coding.
by roncesvalles
8/24/2026 at 6:29:12 PM
this is software developmentby polotics
8/24/2026 at 9:53:53 PM
Sir, this is a Wendy’sby mekael
8/24/2026 at 7:15:13 PM
There's a reason it's called Software Engineeringby bhavansig
8/24/2026 at 7:31:57 PM
Coding < Development < Engineering.My claim is just that LLMs are basically fine now with the "coding" part. Not so much with development, definitely not with engineering.
by ben_w
8/24/2026 at 11:28:42 PM
Outside of the most niche domains like frontier AI development, are there software engineering questions that Sol 5.6/Fable 5 can't answer better than the median software engineer if explicitly asked? It strikes me that models already have superhuman software architecture capabilities, they are simply underelicited.Furthermore the AI companies are spending gobs of money and compute to address this—harness development, orchestration/agent coordination, computer use are all designed to lower the skill level required to get the best results out of a given model.
Soon the models themselves will be more persistent, more observant, and more skilled than any of us at driving models to obtain the "right" solution in a given SWE context.
by ryeights
8/25/2026 at 12:26:41 AM
In terms of getting a the consensus answer to a specific question, they're likely better than a median software engineer at most questions.Where they still fall massively short, even compared to a straight out of college junior developer, is figuring out what the correct question to ask is.
This has led to situations like Fable 5 spending six days debugging a deadlock because it didn't think to add any observability to detect when the job stalls, and would wait until the job timed out each time. Any junior developer would have fixed it in a few mins, but I left Fable running out of curiosity to see how long it'd take.
by cameronh90
8/25/2026 at 2:02:28 AM
This may be true now but isn’t the trend clear? GPT-2 couldn’t write a coherent function. Now we have the SWE oracle that can autonomously navigate your codebase, write code at a superhuman level, and give the correct answer to most engineering questions.If anything I feel I am understating the capability of current models here. What is stopping the next generation of models from closing the feedback loop further?
by ryeights
8/25/2026 at 12:30:39 AM
Google can also answer it better than most if explicitly asked.An explicit query returns a specific answer, but means nothing about whether it can use that knowledge to create better software.
by Rumple22Stilk
8/25/2026 at 9:35:07 AM
> Outside of the most niche domains like frontier AI development, are there software engineering questions that Sol 5.6/Fable 5 can't answer better than the median software engineer if explicitly asked?"Median" is kinda hard to judge given how rapidly the number of software engineers has been growing, how imprecise our within-industry skill assessments are, and also how fast everything within software was shifting even before agentic coding. Two examples: (1) an old estimate I heard was that 50% of the skills we would put on our CVs would be obsolete every few years, but we'd never know which ones; (2) The reason for the creation of FizzBuzz as an interview question (far too many people are *that* bad).
For the LLMs themselves: the METR time horizons estimates are based on an expert developer's wall-clock times, and the graph on their website only goes as far as Mythos preview which is kinda about this level. Mythos preview shows only 80% success at tasks that would take a human 3h6m on average (95% confidence interval 1h37m-6h39m), which is evidence that yes, there is plenty that the models can't do. I naturally break down larger tasks to smaller ones, the agentic coding models I've used also attempt to do this, but seem to be worse at it than I am.
> It strikes me that models already have superhuman software architecture capabilities, they are simply underelicited.
While they can do better when elicited correctly (and the same is true for humans), they are too "lazy" by themselves to attempt self-elicitation.
The second part, just like the first, is also true for humans; but LLMs are so much cheaper than humans that this is a disappointment for the LLM to stop early and say "[Thought for 35m 24s] Here's your MVP, I've not done subtasks 35 onwards", even though it's an advantage for the humans to say "[Invoice for a 2 week sprint with a team of 5 developers and their manager for a total cost of $23,000] Here's your MVP, we can discuss which of subtasks 35 onwards you want in the next sprint".
I'm not sure where I'd rate LLMs on a strict 0-10 scale from "hack" to "formal methods followed by end-to-end testing", but the examples given by the research companies themselves suggest that even they are only at the "this is starting to get interesting" level for both architecture and their own idea of what "I have now completed this to a good quality" looks like, not at the "actually good" level for complete big projects.
> Furthermore the AI companies are spending gobs of money and compute to address this—harness development, orchestration/agent coordination, computer use are all designed to lower the skill level required to get the best results out of a given model.
The observation is that money and compute spent are not strongly correlated with the general quality of the models. If the correlation was strong then Meta would be near the top, while the multitude of open-weight Chinese models that keep popping to the top of leaderboards every couple of months would be jokes. Grok would have been better from the start and not suddenly gotten good around when they bought up the much smaller and lower-budget Cursor.
https://llm-stats.com/models/muse-spark-1.1
https://llm-stats.com/models/gpt-5.6-sol
https://llm-stats.com/models/kimi-k3
> Soon the models themselves will be more persistent, more observant, and more skilled than any of us at driving models to obtain the "right" solution in a given SWE context.
My experience has been that predictions of "soon" fare about as poorly as predictions of "never" in the context of AI. Regarding the failures of "soon" predictions, I do not know the degree to which this is company leadership BSing how good their stuff is, vs. Goodhart's law where they're fooled by the difference between their metrics and reality.
by ben_w
8/25/2026 at 12:57:54 AM
maybe they meant typing? lolby whateveracct
8/26/2026 at 3:09:13 AM
That's the most reasonable read of "coding" as opposed to the overall discipline of software development/"engineering", yeah.by andrewflnr
8/24/2026 at 4:44:01 PM
I feel like there is also the "Nerd Factor" to consider which is this unrelenting passion to type away at a screen all day, whether that is yesterday's code or tomorrow's prompt. Few non-technical people have the attention span to suffer such monotony. (Even most devs don't have that to varying extents)by warmedcookie
8/24/2026 at 5:53:02 PM
Aye. This is true for many professions, I think.I'm trying to write a novel, have been for a while now; one thing I hear from professional writers is that one should only do this if you are prepared to re-read whole thing six times before you even send it to the editor, and when you do send it to the editor, you and they will likely spend several months repeatedly re-reading the whole thing as you respond to a long list of changes they give you.
by ben_w
8/24/2026 at 5:02:29 PM
It's only monotone from someone looking, not from someone doing. If you look at digital painting tutorial, you'll see a lot of timelapse, because it's a very slow process where you spend the majority of time correcting stuff. But if you're the one doing it, each individual brush stroke is the result of a conscious decision.by skydhash
8/24/2026 at 5:07:20 PM
I'm not sure; I find the job pretty boring.by orangedog
8/24/2026 at 5:33:57 PM
Working on a passion project or working through the hairy details of a complex algorithm or whatever can be fun. But that's not really what the job is like most of the time.by emodendroket
8/24/2026 at 6:24:53 PM
All the boring parts I've encountered have soon been automated out of my workflow. There's the waiting part of some process, but that's why I have HN for.by skydhash
8/25/2026 at 5:18:36 AM
> 2) My actual job also included non-coding work: Does this attempted solution even work at all? Is this solving the right problem? Even if it's a valid solution to the right problem, is it the best solution given the time constraints?Unfortunately, this won't be captured by the metrics, because its not easily observable or instrumentable. There will be relentless pressure to use AI and more and more and prove that it is adding value. It won't add value, but whats available to executives is to lower wages and employment. There will be 'success' stories by most VPs that they've been using AI and here is proof (low wages + employment) and trillions of lines of code. LOC has always been a useless metric, but nobody cares.
> At least, I hope this "is a place where my experience is still useful"; I may just be telling myself a nice story, same as all the other people through history who have found themselves obsoleted when the automation came for them.
I don't think there will be more automation (at least not in a productive, helpful way), but a lot more enshittification and success stories of AI. Nobody cares about consumer experience or who is actually using the product.
Almost all CEOs/C-Suite/VPs are far removed from reality, they will do whatever is being hyped right now. Every Corp has had massive DEI initiatives in the previous administration and now anti-DEI in the current administration. Corps were doing blockchain nonsense and now they do AI.
by thelastgallon
8/24/2026 at 11:54:35 PM
> 1) The coding part of my career is over. LLMs are capable of doing everything I've ever been paid to write.Horrible if you got into this industry because you loved to code.
Amazing if you only ever saw the code as a means to an end.
by nunez
8/25/2026 at 1:37:49 PM
I think this can be generalized even more:Horrible if you got into engineering because you wanted to solve problems.
Amazing if you only ever wanted to see the problem solved.
by yuye
8/24/2026 at 4:41:40 PM
FWIW: The highest paid devs I know excel at 2, and aren't even that good at 1.by enraged_camel
8/24/2026 at 4:52:34 PM
I guess that somewhat describes me - and guess what, that also transfers to "should we even throw AI at that specific problem, or are there other solutions?". Early curiousity in figuring out the limits of LLMs now is turning into revenue by customers with problems that didn't exist a few years ago at all - which currently is quite an exciting field to work in as a lot of things just don't have pre-established solutions yet.It's a similar level of excitement as when we started doing devops stuff before devops even was a thing (which has been one of our main things for a very long time now).
by finaard
8/25/2026 at 12:17:00 AM
Complement: I know many devs who are exceptional at 1 (writing code), and 2 (contextual thinking) never even occurs to them. They will happily implement whatever they are told, without ever thinking to ask "why am I being asked to implement this?" or "is this actually solving the problem?"by wnmurphy
8/24/2026 at 9:45:48 PM
This I solemnly swear. To take my paycheck with gratitude, even if my employer makes three times as much based on my output. To take whatever technological disruption that graces my path as an immaterial and impersonal force. To politely and discreetely bow out when the statistics soup trained on my fellow colleagues makes me unemployable and worthless. Amen.by keybored
8/24/2026 at 8:45:45 PM
staying within free tiers has led to some really great optimizations for metook complex pub/sub event architectures down to the events postgres can do on its own, and a system architecture that works with that payload. am aware of the limits with this approach and stress potential on db
by yieldcrv
8/24/2026 at 5:58:42 PM
> The coding part of my career is over. LLMs are capable of doing everything I've ever been paid to write.That is certainly not true. LLMs can't write code worth a damn still, and you have to babysit them to make sure they aren't doing stupid stuff. A human is still by far the best choice for doing programming, and when trend-chasing companies realize the damage they've done to their businesses they will stop pushing LLMs so hard.
by bigstrat2003
8/24/2026 at 6:03:11 PM
"LLMs can't write code worth a damn"I think it depends on the - ahem - context. In my experience they usually can, sometimes they can't.
But generally their sense of software architecture remains abysmal, so even if their writing is ok, you need to have architectural authority the very least to guide them.
by fsloth
8/24/2026 at 8:08:59 PM
The fact that they sometimes can't means you can't have someone who is not a software engineer. Otherwise there is no way to verify whether the LLM wrote correct code or not.by izzydata
8/25/2026 at 12:21:12 AM
I feel like this depends on the kind of project/work to some degree. Lots of software engineering time is spent on very simple websites, apps and other projects that LLMs have been well trained on. I suspect if you want a static site with a contact form or a CMS theme/plugin, you could probably get a usable result by having some non-technical person plug some prompts into an AI.They wouldn't be able to verify if the code is correct, but based on my testing, if the work is simple enough, it probably wouldn't matter much.
There are a lot of companies whose modus operandi is basically "build the same basic site 300 times, except with a different colour scheme and logo".
by CM30
8/25/2026 at 7:02:25 AM
Yeah configuring whitelabel products for customer’s brand should be right in LLM:s ballpark.by fsloth
8/24/2026 at 9:38:24 PM
Exactly. Expertise is frequently required to steer, correct, rework, know what is good and what isn't. This happens 500 times a day on both the micro level and the architecture level.by wek
8/25/2026 at 3:41:30 AM
Unless they can produce the right thing 100% of the time, they require an observer with enough technical merit and experience to validateby glouwbug
8/25/2026 at 7:01:06 AM
Well we would think that wouldn’t we but businesses can be run by people for whose business ”works mostly” is good enough.by fsloth
8/24/2026 at 4:40:59 PM
Ai can work through all of those questions in number 2 and design around it.I was just doing that yesterday designing a game demo lol
by tayo42
8/24/2026 at 6:01:23 PM
I have also tried developing games with them. I find them very weak at these things.Often they can't figure out how to test the thing, so "does this attempted solution even work at all?" is its guess from reading the source code, and sometimes I've even caught them writing "tests" which are a regex on the source code, not functionality.
They know almost nothing about "is this solving the right problem?", they're trained to assume the user is right, not to frame-challenge.
My general experience both in game and non-game projects is that it will be lazy by default rather than solving things correctly. Sometimes I spot this from their responses, other times I only notice with manual testing.
by ben_w
8/25/2026 at 3:50:26 AM
That's for code,I'm not talking about that.by tayo42
8/24/2026 at 4:44:32 PM
Works for a demo, but quickly stagnates. Future models may of course push the limits further, but right now it quickly goes sideways without someone knowledgeable at the helm.by matsemann
8/24/2026 at 4:55:55 PM
You don't design things with never ending details though. If your developing a feature there's a limited scope to it. If your designing the direction of a large project you're working with higher level concepts.The point is that AI is aware of constraints and can manage a round it. You've got to keep in mind the size of a typical software project and plan. Most people aren't writing a kernel. They're writing some backend tool and need a project that fits into a couple of quarters with a handful of people at most involved.
by tayo42
8/24/2026 at 5:20:43 PM
> The point is that AI is aware of constraints and can manage a round it.Only if you instruct it with constraints. Otherwise, it's happy to implement whatever workaround it needs. But it still takes a dev to know what those constraints are and why they're needed.
by addandsubtract
8/24/2026 at 5:01:06 PM
[flagged]by dan_ggggg
8/24/2026 at 10:14:08 PM
I meticulously described the netcode structure for my tactics game and it's simple enough to just send over on web sockets and fable was still giving me an endless hydra of sync issuesby Madmallard
8/24/2026 at 4:45:16 PM
Are you an AI?by nevertoolate
8/24/2026 at 4:52:18 PM
Your right to push back on that...by tayo42
8/24/2026 at 5:15:08 PM
> Your right to push back on that...Human test passed. AIs make giant flashy mistakes. They don't fuck up basic grammar.
by lee_ars
8/25/2026 at 7:57:31 AM
> They don't fuck up basic grammar.Sometimes they do. From Gemini 3, some AppleScript:
if something then
if something then
if something then
stuff
end if
end if
</if>
After about 10 turns the problem went away.
by jlokier
8/24/2026 at 5:29:09 PM
I have found it intriguingly difficult in my own tests to make LLMs deliberately fuck up grammar in any way similar to how humans do. I suppose this is actually an architectural limitation.by dofm
8/24/2026 at 6:13:37 PM
Out of curiosity, I just tried this: write a comment about how to use ChatGPT to write a game like you're a barely literate reddit user, short answer, maximum incoherency
Not perfect, gptzero.me still knew it was AI generated (tayo42 is human by the same measure), but if for some reason someone was using an LLM prompted with that pattern, I suspect it would fool me in a Turing test unless I found the keyword to force the agent to change the role it was playing.
by ben_w
8/24/2026 at 6:22:25 PM
Redditor is too easy.Conveying the errors typical in a Raise The Colours group on Facebook, that's the hard stuff.
by dofm
8/24/2026 at 7:34:25 PM
I'll take your word for it, I think I'm in zero groups on Facebook, I only even look at the feed when I see a notification in Messenger; and I barely use Messenger, too.by ben_w
8/24/2026 at 5:02:33 PM
We have a product guy on the team who was in a deeply not technical role before AI who is trying to do the “hey Claude, read this Jira ticket, implement” thing.It doesn’t work for the vast majority of tickets he attempts because he doesn’t have the necessary understanding to even start thinking about if the solution that the autocomplete generates is even remotely workable. And that’s with fancy dev loops and whatnot.
The spacer between the keyboard and the chair still matters in my experience.
by jgilias
8/24/2026 at 5:20:38 PM
Not everyone has this, but I always felt that a significant percentage of the value I bring is in immediately recognizing what you shouldn’t do.I have a hard enough time explaining why “yet another bespoke application on some unmanaged azure resources” is a bad idea when they have more reasonable alternatives at hand.
Now these goofs can (very nearly) press a button and do it anyway, with no comprehension of the consequences. It’s high fives and pats on the back, until I’m cleaning up the mess.
by dd8601fn
8/24/2026 at 6:13:15 PM
Yes, there is a post that made the rounds not long ago entitled Taste Is All That's Left: https://notashelf.dev/posts/taste-is-all-thats-leftKnowing what not to do has always been important, but it is perhaps more important than ever.
by devin
8/24/2026 at 10:13:09 PM
Taste, judgment, and wisdom.Aka “actual deep understanding”.
by dwaltrip
8/24/2026 at 5:42:23 PM
This lands. Llms are bad precisely at following what not to do. They work best off of positive constraints.I have a design principles + tech preferences doc I force llms "lint" their approach against. It's not perfect but it helps. I call it a bias field, pushes them toward hopefully the happy and harmonious (with the rest of the system) paths. Obviously this is only partial and imperfect enforcement, but if it's applied to everything consistently it naturally encodes some self-consistency and harmony.
by chermi
8/24/2026 at 6:34:20 PM
> I have a design principles + tech preferences doc I force llms "lint" their approach against. It's not perfect but it helps.I’ve done the same but it’s a moving target as models advance and I find half of my points are ignored until I’m prompting “No wtf why are you still trying to symlink the global Python executable just use the virtual environment that’s already activated”.
Anyway, companies are pouring billions into improving AI tooling user experience so most of what I do manually I just anticipate to be a waste of time. There’s no way my hobby fiddling will outpace whatever gets released in the next couple months.
In the meantime, real linting does work pretty well, if you can write a detector for whatever antipattern you find LLMs fall into (like multiline comments).
by datsci_est_2015
8/24/2026 at 6:48:20 PM
> Anyway, companies are pouring billions into improving AI tooling user experience so most of what I do manually I just anticipate to be a waste of time.I get patches into the biggest AI projects all the time to make inference faster on my 3090 and all you have to do is read the contribution docs and open a small PR.
It’s not a cabal of super geniuses. We are literally in the Wright Brothers era of AI.
You can trivially outpace what big companies are doing it’s insane, why do you think so many innovations are coming out of scrappy Chinese labs? They are willing to engage instead of being defeatist about it.
by oceanplexian
8/24/2026 at 7:48:09 PM
> It’s not a cabal of super geniuses. We are literally in the Wright Brothers era of AI. You can trivially outpace what big companies are doing it’s insaneNot my core competence and I’m not interested in making it a core competence while the field is still rapidly changing. I find harness engineering interesting, but not lucrative enough to push one of the many very important other things on my plate to the backburner.
I don’t think Python language developers are super geniuses either, and I’ve never submitted code for consideration.
by datsci_est_2015
8/24/2026 at 8:10:01 PM
Oh I'm certain I'm not doing it optimally or close to best practices. It's just an example I had in my head related to my comment.Although, given opus 4.8->5.0 experience within claude code, I don't know if I'd agree they necessarily improve things with time. But that's just my experience. I should probably read their release notes, maybe just a tweak to my claude.md would help
by chermi
8/24/2026 at 6:31:41 PM
I would be interested in see that. I have reems of rules I use with Claude.by BatFastard
8/25/2026 at 4:00:08 AM
>This lands.Where does it land?
by latentsea
8/25/2026 at 5:19:08 PM
Did I use the saying wrong? My bad I confuse them sometimesby chermi
8/25/2026 at 9:55:22 PM
I think it's technically right use of the meaning, but the way it's used somehow feels weird and out of place. Like I'm trying to remember ever seeing it as an assertive statement about a concept, instead of a question ("how does this land?") or a reference to something specific (new release has landed).I don't think people have identified that as an LLMism, but the way it feels out of place I wouldn't be surprised if someone did. Being a punchy two word sentence doesn't help here.
by Izkata
8/26/2026 at 12:59:04 AM
Wait I'm I being accused of being an llm?Edit- it being weird and out of place is probably right because I probably used it wrong. I probably shouldve said this lands for me. That sounds more normal
Edit2 I am not a bot trying to improve to sound more human. I promise
by chermi
8/25/2026 at 11:57:22 AM
The AI-maximalist on my team does a lot of work to setup fancy loops and burn tokens like crazy. It feels a lot like guitar players who get all these fancy pedals and forget that they can plug a nice guitar into a nice amp and it actually sounds better.I guess that is taste?
by ianmarcinkowski
8/24/2026 at 6:09:01 PM
I've had some success with: here is this android bug ticket in a product that I don't know much about, fix it! And it works sometimes. I'm still technical, so it isn't the same, but it was crazy that AI could just solve some problems automagically without me know much about the system being modified.by seanmcdirmid
8/24/2026 at 7:27:01 PM
> It doesn’t work for the vast majority of tickets he attempts because he doesn’t have the necessary understanding to even start thinking about if the solution that the autocomplete generates is even remotely workable. And that’s with fancy dev loops and whatnot.Remove the dev from the equation. Suppose you need to produce circumstances for the slop machine to succeed on its own (imagine a loop).
What is missing? A good enough description of the current behavior, desired changes and how it should work? Understanding of the business domain or the system in question, its architectural choices? Enough guardrails and linters and tests to ensure that the solution will indeed be testable and work end to end? Cause a lot of the things that will help human devs will also help LLMs make their output more workable - for example ADRs in the repo and custom in-house tools to ensure they follow architectural conventions and practices (or just something like ArchUnit). Realistically, how close to a finished implementation must you get and how far backwards from that can you go before its output degrades too much?
I tried figuring that out myself on a personal project where I mostly want what I want in GitHub issues and then feed them to Kepler, which spawns OpenCode in worktrees and also gives me a UI to follow the execution. Most models, even SOTA, occasionally implement things wrong, but it's suprising how far you can take things when you've spent a dozen hours planning out what you want the end result to be vs not to be (talking about the goals for an entire system, maybe an hour of planning for a more bounded type of task).
by KronisLV
8/24/2026 at 7:46:22 PM
In general, when I’ve worked on projects where I’ve spent that much time planning, having a magic AI box that wrote perfect code wouldn’t have helped that much. When you spec every everything out like that, writing the code is the most trivial part of this whole process.by jwalton
8/24/2026 at 10:10:21 PM
If you want to make it a nontrivial mess you can get Claude to write it.by pydry
8/25/2026 at 8:43:24 AM
When does the intense planning just become programming in a natural language though? And at that point, it just becomes less accurate coding. I feel like this is the biggest trade off when it comes to agentic coding. You are practically trading accuracy and control for speed and efficiency. And if you want the same accuracy and control when using agents for coding, you as a validator become the bottleneck, removing in most instances all of the speed and efficiency gains. It all comes down to this, what matters the most: speed, or accuracy and control. Todays capitalism typically favours short-term thinking, speed and efficiency, which is bad news for everyone. Software developers will be forced to have less control and produce less accurate code, because the validation step is not permitted, due to it being the bottleneck.by civvv
8/24/2026 at 5:35:10 PM
But isn't it only a matter of time before the AI generated autocomplete will contain the correct solution? What then?by ahussain
8/24/2026 at 5:50:41 PM
fucking is it? AI labs certainly want you to think so but they're running out of time and money. they've been telling me that the advancements of the last three months have made this a reality for the last five years. it's starting to feel a lot like Elon promising fully automated taxi services by next year... 11 years agoby gghkiuv
8/24/2026 at 6:36:54 PM
next year I PROMISE!by BatFastard
8/24/2026 at 10:21:22 PM
"Its done, when its done";-)
by KellyCriterion
8/24/2026 at 8:11:27 PM
Come on bro, PhD level intelligence!by morkalork
8/24/2026 at 5:57:31 PM
For the completion to work, the source text needs to be ‘good’. That’s a basic kernel of how the thing works. Even with a perfect oracle autocomplete if the source text is ‘bullshit’, the output is too.Or, slightly changing this. The source text needs to speak the correct vocabulary and language to produce a good completion. See the chat where Terry Tao is doing maths with an LLM. There’s _no way in hell_ I could get to his output because I just have no idea, and can’t speak the language.
Same with any field.
by jgilias
8/24/2026 at 5:37:40 PM
So far, the LLMs I've used need problems to be fairly specifically scoped, or they don't produce the correct solution. Scoping problems correctly is a different skill-set than implementation, but it's still a technical skill that is expected from mid-level and higher engineers.by organsnyder
8/24/2026 at 6:16:47 PM
Yep and I just ran a simple enterprisey "ambiguity" bench on the big three (US) model providers: same ambiguous initial-prompt with same clarifications and pushback prompt sequence afterwards.The edge of correct/better when facing ambiguity is very fuzzy, all models from the past 6 month or so have similar random ways of spinning between too-literal avenues and oddly misplaced misled fixations. Taking the right initiatives in face of uncertainty is definitely AGI, and its not there, and perceptrons + attention layers just ain't got what it takes no matter how hard you push.
by polotics
8/24/2026 at 7:16:17 PM
The best I've come up with is to ask an agent to come up with questions to help get to a focused design. But it still needs me in the loop for that.by organsnyder
8/24/2026 at 6:17:58 PM
Probably worth not getting too comfortable. It's only a matter of time before a new generation of product people can do this. Also, I have said this before, instead of 1 product person and 10 engineers on a team, you may have 2-3 product+eng people and 3 engineers, etc.by deadmutex
8/24/2026 at 9:56:42 PM
You have it mixed up. This guy is “the new generation of product people”. The old generation had to be technical enough to be able to grok the systems that they ‘producted’ over. It’s exactly the ‘new generation’ that LLM themselves right into Dunning-Kruger.by jgilias
8/24/2026 at 5:04:09 PM
[flagged]by dan_ggggg
8/24/2026 at 5:15:43 PM
honestly "product guy" is enough of a slur for most technical folks. What you are saying just sounds nasty.by mcbuilder
8/24/2026 at 5:18:26 PM
It's a troll account. Stuff like this isn't productive and should get flagged.by orangedog
8/24/2026 at 6:14:17 PM
Boris: "I don't prompt Claude anymore. I have loops prompting Claude and figuring what to do".Boris: "I haven’t written a line of code by hand in, I think, eight months now… Claude Code, 100% written by Claude Code".
Boris: "There’s no manually written code anywhere at the company… All of the SQL is written by models. Everything is just built by the models... Claude instances communicate with each other (e.g., over Slack) in autonomous loops"
This does not sound like they review the code either. So, either the frontier labs like Anthropic have figured out something that very few companies could replicate, or they are being incredibly deceptive. I don't know which is true.
by hintymad
8/24/2026 at 6:54:20 PM
Judging by how it feels being a customer and using their products, I can confidently say:1. Yes, we know, and can tell.
2. No, they haven't figured out anything. Just vibe coding it with their bleeding dege models.
by kilroy123
8/24/2026 at 9:25:14 PM
> No, they haven't figured out anything. Just vibe coding it with their bleeding dege models.I'm sure you were saying "bleeding edge" but my first impression was to translate dege to mean degen/degenerate which made this so much more fun to read.
by saratogacx
8/25/2026 at 3:28:56 AM
A new term has been coined! aka "hodl"by langfo
8/25/2026 at 12:46:46 AM
So with #2 they are betting that the future models will be able to reign in the mess that the current generation leaves in its wake. It's a bold bet but not an outrageous one either.by abraxas
8/25/2026 at 12:27:01 AM
Where I'm at we use Claude for many coding tasks but we don't have infinite token pockets like Anthropic does. Everything is very focused on how to get the most out of the tokens and prove you're the one who deserves to have a ton extra granted next month. We can't afford things like have one guy tossing the equivalent in $165k at 64 simultaneous instances for days on end to just see if a Rust rewrite really works well or not like they did with Bun - but Anthropic still did that regardless. This doesn't prove the opposite either, it just appears asking whether or not others are doing the same is a bad oracle for Anthropic's honesty here.I think that will be one of the most interesting things with models in the future. Even if we somehow 100% stopped dead where they are from a a model perspective, being able to run it twice and fast for half the price in the future will enable a hell of a lot more practical usage.
by zamadatix
8/24/2026 at 6:28:47 PM
They work on research problems you can define a clear solution criteria for.The kinds of business software I work on don't have those characteristics. If I needed something like a utils library, I think I could easily have Claude write the whole thing and not read the code.
by wry_discontent
8/24/2026 at 8:40:32 PM
What puzzles me is this: research means that we are exploring something that has not done before, yet using Claude to generate code means slicing and dicing what has been done many times before. So, I'm not sure how to make sense of both at the same time: Anthropic is pushing the boundary of AI, yet all the knowledge and engineering in form of code can be generated from the previous work?by hintymad
8/25/2026 at 4:55:51 PM
How I interpreted their thoughts on "loops" and "graphs" etc, is that they 1. have unlimited token allowances, and 2. are working on problems where the solution itself can be described by code.It reminds me of property based testing. I really liked the idea when I heard about it, but most of what I work on does not tend to behave in a way that can be easily described mathematically like that.
Maybe I'm just not clever enough to do it.
by wry_discontent
8/24/2026 at 7:13:37 PM
As always, the essential skill in engineering is not providing the right answer it's about asking the right questions.by throwway120385
8/24/2026 at 5:32:19 PM
People are fundamentally short-term thinkers. Just imagine spraying neurotoxins on your lawn. You're "saved" from the "terror" of noticing more than one kind of grass, but of course you're incrementally increased the cancer risk for yourself, your children, and who knows who else. This is just one example; people do this constantly. Plastic fleece puts an untold amount of poison into the environment, but "I need to be warm RIGHT NOW." etc. Or lead paint. "It's only toxic when it breaks down, and that won't be for decades!"Why would programming be any different?
by everdrive
8/24/2026 at 6:12:18 PM
All the issues you mention here have a death horizon: the people engaged in the behaviour will be dead when its effects are most acute. That they engage in it then isnt very mysterious.That doesnt clearly apply here
by mjburgess
8/24/2026 at 6:41:35 PM
The problem is further away when the next quarter, which for some companies, might as well be in the year 3000.by everdrive
8/24/2026 at 11:18:12 PM
>the hardest part about being a software engineer is just filtering through AI generated artifactsThis is so real. Jira tickets used to include a paragraph about what the change or feature needed is, a screenshot from figma for what it should look like and that's it.
Now I get tickets from the product manager that contain a whole novel waffling on about specific variables in the codebase that need to be changed which I have to wade through to work out what the prompt was that explains the actual product change desired.
by Gigachad
8/24/2026 at 4:39:30 PM
> That sounds great until you realize that "hey Claude, read this Jira ticket and implement the feature in this code base" isn't really worth $200K/year.When you factor in overhead and benefits, many companies were regularly paying that much for someone (many someones) to "read this Jira ticket and implement the feature".
We are currently in the "centaur" phase where a human-AI combination produces the best output, but I think some people are betting on the fact that the AI only product will eventually outperform the centaur. And with the cost of tokens falling thanks to fierce competition from the Chinese open weight models, it's definitely possible that those that bet on AI early will reap payoffs in lower expenditures for more output.
Honestly not sure which side I land on that bet but I definitely can't rule it out.
by doctoboggan
8/24/2026 at 4:55:51 PM
We've gone through this with chess, and the days when a human can do anything to help AI there are long past; the human can only drag it down. It seems to me to be a form of the bitter lesson. I expect this will happen in every field where we don't add guardrails to require humans in the network. I have a hard time seeing regulation happening around this in the US but vanity may also serve, will CEOs be satisfied ruling armies of virtual assistants, or do they need big buildings full of human thralls?by svachalek
8/24/2026 at 5:35:26 PM
Well, maybe. But most fields of human endeavor aren't very much like a board game with clear, unchanging rules and a single, unambiguous objective.by emodendroket
8/24/2026 at 6:40:40 PM
Have we really though?This is not a silly question, because it's kind of silly:
Has an AI ever actually gone through all of the steps necessary to become a chess master? Go to competitions, raise in the ranks, take a plane to the masters, organize support and all the real life details necessary? Playing chess is just the small formal part here, and all of the obvious things humans obviously do, well...
by polotics
8/24/2026 at 7:33:38 PM
I don't agree.Chess is a perfect information game with objective, easily measurable outcomes.
Show me a software business that looks like that and I'll agree with your hypothesis.
Otherwise I don't believe your metaphor proves much of anything.
by unknownfuture
8/24/2026 at 9:11:58 PM
Another thing is, I have been playing Chinese chess a bit lately and, yes, Pikafish is stronger than any human player, but if you actually share a board state or list of moves with an LLM they will fail to accurately interpret the state of the board, let alone give good advice on what moves to make. Doesn't really prove or disprove the claim that LLMs will replace human programmers but it does show that the word "AI" is papering over a lot of specifics of particular technologies.by emodendroket
8/25/2026 at 2:23:03 AM
Several influential people are deluded into thinking that LLMs will bring forth AGI. A lot of people don't really understand that LLMs are just one type of AI. This creates a paradigm where we're nearly all-in on LLMs and very few people are thinking of the other ways to engineer task-specific artificial intelligence. Stockfish is a great example of a non-LLM AI that is the best at it's task.by dpc050505
8/24/2026 at 5:05:14 PM
At some point the whims of the CEOs don’t win. The shareholders demand more growth.by LPisGood
8/24/2026 at 5:28:15 PM
Demand from whom, if not the CEO?by dotancohen
8/24/2026 at 5:35:56 PM
The board, presumablyby emodendroket
8/24/2026 at 5:40:02 PM
Of course the demand will be directed at the CEO and they will have to provide results or be replaced.by LPisGood
8/24/2026 at 6:20:48 PM
> the days when a human can do anything to help AI there are long past; the human can only drag it down.I disagree, currently a human guiding an AI agent is far better (more productive for less money) than an AI agent with very loose non-technical guidance and The Ralph Wiggum Loop.
I don't know how much longer humans have, but I don't think they can be cut out of the loop entirely just yet.
by doctoboggan
8/24/2026 at 6:39:06 PM
In chess? That ended in ~2017.by svachalek
8/24/2026 at 6:47:19 PM
Sorry, I thought we were talking about Human + LLM agent for software development. I misinterpreted your initial statement.by doctoboggan
8/25/2026 at 11:34:31 AM
> We've gone through this with chessPlease never compare perfect information games (https://en.wikipedia.org/wiki/Perfect_information) with actual reality, which is probably many orders of magnitude more complex.
Kind of similar story with math (pure) and other sciences (impure): https://xkcd.com/435/
OpenAI & co keep presenting their achievements at maths competitions as their path to AGI/ASI/singularity. But if you look at that XKCD graph, the way the joke reads is in terms of arrogance (scientists working on purer fields are more arrogant), but the actual science complexity work the exactly the other way around. Impure sciences are orders of magnitude more complex.
Implementing a sorting function = coding (relatively pure).
Creating an entire commercial software product/service with high performance and other professional-level characteristics = software engineering (wildly impure; after 60+ years we can't even agree on the best programming language to use).
by oblio
8/24/2026 at 5:34:51 PM
Yes, but aren't you just restating the premise in more words?by emodendroket
8/24/2026 at 10:12:48 PM
>We are currently in the "centaur" phase where a human-AI combinationIt's probably more accurate to call it the slop phase.
by pydry
8/24/2026 at 4:23:06 PM
My job improved significantly since I managed to get into their (managers) thick skulls to tell Claude to not be verbose. I'm tired of 1200-word tickets for "put the totals in the automated emails".by javcasas
8/24/2026 at 4:38:39 PM
I think there are two parts to it1. Execution of engineering task - Companies happen to focus on this mostly and this is the metric to measure easily. Using LLM tools gives a impression of improvement on this area which is what everyone is chasing
2. Growth of the Engineer - This is the one which was always a side product of company culture, individuals interest, work being done, time being spent to understand, learn from failures. A job being executed perfectly for the first time itself does not gives the opportunity for learning, no memories/experiences are built up mind of the person executing the job after a while.
The second part is the one which is under appreciated in current scheme of things since it was a by product. There is a concept of muscle memory which pretty much applies to everything.
by sandeepkd
8/24/2026 at 6:51:23 PM
> the reality is that engineers are pumping out code faster than the humans can understand and (honestly) review itThe word "engineering" means doing things using a repeatable process to get predictable results. If you can get predictable results (e.g. guaranteeing the absence of data integrity issues, security issues, anything that will cause downtime, etc.) without looking at the code, you're still doing the work of engineering.
Your job as an engineer is to choose high-value problems to work on, solve them in the correct way, and guarantee that the functional and non-functional requirements are met. If you no longer need to read the code to guarantee that it has the right set of ilities, then I'm not sure that's obviously a bad thing, as long as the ilities you're enforcing result in a codebase that is sustainably secure and maintainable over the long term.
by Alex3917
8/24/2026 at 7:29:50 PM
> as long as the ilities you're enforcing result in a codebase that is sustainably secure and maintainable over the long term.Perfect example of begging the question.
Vibe coding works great as long as vibe coding works great.
Personally, I'd love to see how you enforce security and long-term maintainability without looking at the code cuz we need to add that to our build pipelines ASAP.
by unknownfuture
8/24/2026 at 8:07:37 PM
Mythical man month should still apply for AI coding. If you look at the code you're shipping, and you can't quickly edit it by hand, or fix a bug with it, you will be in trouble if the models are down, and your website is down at the same unfortunate time.by giancarlostoro
8/25/2026 at 10:52:05 PM
If the models are down you are probably in the same situation as when aws is down. A collective shrug, everyone is down, no one will take the blame individually.by confidantlake
8/24/2026 at 8:15:04 PM
1. I think LLMs will end up pretty dramatically shrinking MTTR, a lot of that will be tooling to proactively resolve problems as soon as they start, but a lot of it is that agents are very good at finding and fixing problems by correlating data, something humans can do but I think we're going to be slower at 2. "The models are down" doesn't seem like a very realistic problem unless you have a single provider/set of endpoints. I do not recommend this setup but I guess if you have a single point of failure that is a risk.by oh_no
8/24/2026 at 10:42:23 PM
They may very well shrink MTTR and increase deploy frequency at the cost of all other metricsby Kinrany
8/24/2026 at 6:12:23 PM
Up to now, manual coding has produced mountains of code, faster than humans can un derstand it! Already!The nincompoops at the top think that if mountains of code can appear by snapping your fingers, they will be less of a problem.
If the mountain doesn't work, no problem; since it was so cheap to produce, just scrap it and snap you fingers again. The next one will be better.
Comparatively evaluating 2, 3, ... mountains of code is harder than trying to understand one.
by kazinator
8/24/2026 at 4:40:46 PM
Maybe some day, not in the short term. I've seen output of bad developers using Fable and after that I sleep safe.A bad or below average dev with AI will run your product and company into the ground in a matter of weeks.
by risyachka
8/24/2026 at 5:12:40 PM
It's like a tool that has caused a fan out of both good and bad outcomes.Good: you can refactor your codebase at will, throw out legacy cruft by the megabyte, improve build/CI time, and simplify ruthlessly. Not to mention kick out new features in simple and consistent ways that align with what a user actually wants.
Or you could add megabytes of vibe coded crap, solutions that add a ton of mass but don't actually solve the problem at hand (seriously!), implement abstractions that are logically inconsistent with the rest of the system, etc.
Both of these are happening right now, and I think the latter is happening at a rate far higher than the former. But our fundamental dynamics are still at play - the ball of mud is still a ball of mud, even if AI lets you make it 100x bigger. The problem just gets more entrenched.
Eventually AI will learn how to simplify code, understand coupling, etc - and hopefully it will just iron out problems as it goes. I think we're a long way away from that. But this is uncharted territory, and I don't think anyone really knows. I certainly don't hear anyone focusing on that as a target of optimization however.
My hope is that we'll see a number of companies collapse as they scale - with basically no hope of rescue, and perhaps we can re-learn these lessons yet again. It kind of feels like GitHub might be the first example of this.
by switchbak
8/24/2026 at 6:35:06 PM
> My hope is that we'll see a number of companies collapse as they scale - with basically no hope of rescueIf you worked in SV like I did from 2010-2020 you know that the exact opposite of that will happen. I saw hundreds of companies successfully scale out of their garbage stack such as Facebook and PHP.
The only thing that matters is the problem you’re solving and the quality of the code is irrelevant.
by oceanplexian
8/24/2026 at 11:32:06 PM
They didn't succeed per-se, they rode a gigantic wave of free money and barely avoided catastrophe.I think much of what we see there is really heroic efforts: subsystems get swapped out with things that suck less, PHP gets a new optimized runtime, etc. Basically - unsung people do the hard work that rights the ship, meanwhile 10x more people are adding tons of crap and it barely balances out.
Now that 10x is more like 1000x - and if we don't use these tools responsibly, I think we'll see the costs outweigh any kind of benefit.
Or I could be completely wrong. Worse might actually be better. People can vibe up a new replacement thing when the original thing becomes unmaintainable. That feels wrong/gross to me, but maybe I'm just old fashioned (like the old folks from Inmos/Symbolics/Transmeta were).
by switchbak
8/24/2026 at 11:46:38 PM
Scaling means something different in this context IMO. It's not whether your DB can go from serving 100 to 10000 users, it's whether your B2B app can serve 100 to 10000 different real world customers without starting to fall apart. While it becomes an unintelligible 40000 line "if else" tree that breaks in a new way every time you open a ticket with your agent to Vibe Jira a fix (but forget to specify 1 out of the hundreds of niche constraints that someone doing the job likely knows from experience). You then ask it to reimplement cleanly, but it basically reimplements the broken mess of business logic you're trying to escape since the current codebase is the only reliable source of truth.by qlte
8/24/2026 at 5:41:04 PM
> A bad or below average dev with AI will run your product and company into the ground in a matter of weeks.I had a recent experience with this. Although it was months and not weeks and there were other factors into play such as the market etc but the last company i was in had a poor engineering culture with inexperienced engineers equipped with AI output some of the lowest quality features for both customer-facing products and internal dev tools. A lot of customers churned, and im sure quality us part of the reason.
by wreath
8/25/2026 at 3:16:06 PM
Would you say the same thing about people not knowing assembly after compilers came out?by peab
8/24/2026 at 6:31:21 PM
Engineers, free from writing thousands of lines of boilerplate, now have more time to review code and be more efficient in that armed with LLMs. E.g. instead of asking a question about the code and waiting for the author to respond, I can ask an LLM and get the answer almost immediately. Or, if I see some strange code being changed, I am always curious why it was there in the first place and, instead of tracing it through git blame over formatting, renaming, and moving files around dirs I can delegate this to an LLM. If I have doubts about it working in some environment I can, again, make an LLM test it out instead of asking the author etc. etc.And no, telling Claude to implement a Jira ticket is not worth $200K/year. Checking if it has not done something stupid and correcting it when it's trying to - is.
by pandaman
8/25/2026 at 12:30:37 AM
Imagine hiring a carpenter and then telling him if he’s using a tablesaw instead of a hammer he’s doing it wrong.He would call you a moron.
He might even just fire you as a customer if you annoyed him enough.
by throwatdem12311
8/24/2026 at 5:30:11 PM
Decades ago, enterprises said, "If you're writing assembly you're doing it wrong".That led to a reduction in knowledge of assembly in the average programmer but the people who specialize in it haven't gotten any worse at it.
The result was a generation of programmers who make useful software while very few of them understand the machine they program. You could easily make either a positive or negative value judgement about that result.
by mohamedkoubaa
8/24/2026 at 9:11:40 PM
I came here to rephrase the headline as "Punch card expertise is going to collapse from compiler reliance."Yes, it's true... but who cares? We lost that skill because we don't need it anymore.
English is becoming a very popular programming language.
by mapontosevenths
8/24/2026 at 9:13:24 PM
The people who swizzle registers on GPU drivers need that skill, and there's no evidence that they lost it. There's a reason why we use the stack metaphor for a programming ecosystem. You trust the lower layers below the one you work in.by mohamedkoubaa
8/24/2026 at 6:32:03 PM
> We are indeed producing a shit-ton of code, but the reality is that engineers are pumping out code faster than the humans can understand and (honestly) review it. That sounds great until you realize that "hey Claude, read this Jira ticket and implement the feature in this code base" isn't really worth $200K/year.My argument here is that what is worth $200k+ is the ability to distinguish the changes that must get thorough, critical review from those that need only a couple of specific things verified and those that require no manual review at all.
Our jobs have never been to write code. We’ve been saying for decades that LoC isn’t a rational way to measure engineering output, and now we have our chance to structurally change that system before processes re-solidify. In fact, I think the flexibility to adopt new systems and the experience and foresight to choose a path that is better than the status quo without throwing out everything we’ve learned is going to be what sets companies apart and makes individual careers over the next few years.
> we have leadership air dropping AI generated manifestos on the product owners and product owners having to use AI to transmute all that shit into 1,500 word Jira tickets that are 10% necessary feature work and 90% LLM boilerplate.
There’s an important criticism here IMO - the relationship between “business” and “engineering” is changing drastically. It’s going to be a challenge to set the expectation that just because Marketing was able to vibe-code a prototype in a day, actual implementation may well take weeks or months. Engineering should be considering things like security, scalability, and systems integration that aren’t a concern for Marketing - that’s why we’re being paid!
> So now you have software engineers whose job has changed radically to the point that the hardest part about being a software engineer is just filtering through AI generated artifacts from all directions just to try to get a feature out the door.
I think it’s an extremely heterogenous landscape right now. Where I work I’m struggling mostly with organization - keeping the (literal) dozens of inbound features that come in every day straight long enough to hook up an agent harness, review, validate, and deploy. At other companies the issues seem to revolve around their Agile-based processes. Or maybe it’s non-technical vibe-coders and their expectations. Or maybe it’s executive leadership flirting with AI psychosis.
Everything is in flux. It’s stressful and exciting, and I’m thankful to be around for it, even if I am in my 40s at this point and looking at the core skills I’ve built rapidly become worth exponentially less. It’s a huge opportunity for growth.
by Ancapistani
8/24/2026 at 9:02:44 PM
> My argument here is that what is worth $200k+ is the ability to distinguish the changes that must get thorough, critical review from those that need only a couple of specific things verified and those that require no manual review at all.The problems:
1. The market is/has been saturated with engineers/developers earning well into the six-figures who are basically decent at writing code but not so good at anything else. So sorting out who is really worth these salaries is not going to be easy and the people who decide often lack the knowledge and skills to determine it.
2. You need to successfully make this argument to people who control budgets and more and more of them just aren't going to buy it.
by ElProlactin
8/25/2026 at 12:56:29 AM
I'm 70 and glad I am retired because I can now do what I want with software and now with AI's help. Yes AI is a pain but its one I embrace to give me the capability to create and reason over domains where I would otherwise have little skill. Certainly glad I don't have to do someone else's bidding so they and make money off of my labor. I never had the courage to go out on my own so that's on me. But I am really enjoying the various types of projects I can start on a whim and continue with over time when they are really monumental. I even made a deterministic analysis tool to help me with that using AI with some gentle AI narration over the results. Now I'm doing blender stuff, where I don't know the commands but I can yell at Claude till he gets it done right :) Bartby bartleeanderson