I learned BASIC, Pascal and x86 Assembly language by the age of 14-15. None of which I remember (nor care to). The strict instructions (aka language) we gave the compiler was not the point. Those experiences taught me how to think logically, and over time develop a taste/structure for how software should be built, as well as foot guns to avoid. I don't know how you teach that without coding, but the "coding expertise" was always a means to an end. LLMs are just another abstraction layer above programming languages, machine language, etc.
In contrast with Pascal, I could see in my mind the PDP-11 instructions behind my C code. By the time I started running code on x86, there were debuggers that could step through source code, and I didn't really want to think like an i386.
Are engineers still making 100s of thousands a year still just for vibe coding while a nurse and other skilled / highly trained medical professionals working their butt off make half of that?
Do we think there is going to be a correction for the vibe coders?
Pardon I know such question is controversial but thinking ahead.
While it depends on the market, job, and hours, but the bedside nurses I know make in the low $100k range. Typical shift structure at the hospital is three 12 hour shifts in a row and then four days off. Most of the time, they are union jobs, so they receive many benefits from collective bargaining such as increased holiday and overtime pay in the range of 1.5-2x normal rate. A nurse practitioner tends to make something in the 180-220k realm.
Again, to be clear, this is highly dependent on the market, job, and hours and one needs to understand the difference between a CNA, RN, NP, etc. However, it's a regulated typically union job that's very secure and in high demand. It probably pays more than what you expect.
Yes, they are still making that much. I am. I don't fully understand why yet but I think it is because of a few reasons:
1. We still need to keep the lights on. If things go wrong, which they still do, humans have to debug it.
2. Jevon's paradox: now the expectation is that we ship stuff faster and there is still a LOT of stuff to do, not less.
3. We are still in the very early days of this and it is too soon for corporations to make a dramatic call like laying off 80% of engineering. We just don't know how that would look like.
Here in germany I would say that the median salary for teachers is quite close to a software developer's one. I know Teachers that earn more/ have more benefits with less work years experience than me. (Not complaining tho, I just hope they put that into good use)
Actually, they have for a large majority of the population. And fun fact: that debate is still going on, and the Mathematical Association of America (MAA) enacted a rule prohibiting calculator use in AMC.
Math fosters critical thinking, and we've been in a critical thinking deficit for decades and decades. I don't think we can afford to sink even deeper...
Because the 1890s and 1930s were famous for their population wide critical thinking, of course. Good heavens, what do they teach in the schools these days.
I mean you may be trying to make a point but the counterpoint is Einstein, Bohrs, Planck, Shannon, Turing, Von Nuemann, Feynman, Bohr and most of the other big names all came out during that time.
In contrast since then we've had almost not noteable physicists or Computer Scientists that I'm aware, we've got a couple, Hawking and Knuth. But apart from that I don't know if there is a single scientist I could point out today that has revolutionized our understanding or even done any real breakthrough work in the field of Physics since Einsteins era.
We have gotten better at working as a group. The standard model is a tour de force. It was a collaborative effort over decades but is a lot more complex than anything Einstein did. To some extent we haven’t gotten new physics since then because of reality - we have built higher energy experiments but haven’t got new results.
But my reply was I guess implicitly assuming the post I was replying to was talking about the median level of critical thinking. Your reply is talking about the peaks of creative accomplishment which is not what I was addressing.
Not a good argument. Those were big names because they were (co)founders of major fields. Physics and CS aren’t like fashion where you can come out with a new color or design every six months.
You also seem to be restricting yourself to pop science knowledge of who’s made breakthroughs. That’s because our collective understanding of physics has become much more detailed, to the point where it starts to lose the ability to be meaningfully comprehensible to the average layperson.
There’ve been many major developments just in that area since the early 1970s, to through the late 90s all the way to 2019 (the island formula), with many major contributors like Bekenstein, ‘t Hooft, Susskind, Maldacena, and many less well-known names.
If you resurrected some of the scientists you mentioned, they’d have a lot of work to do to catch up, and making field-changing major breakthroughs would be just as difficult for them as for anyone else alive today.
Something similar is true in CS. There’s been plenty of progress in all fields of CS, but similar to the situation with physics, its nature is not as simple as what the founders of the field were dealing with, so there’s less awareness of it outside the field. Just to pick one small example, Conor McBride’s insight that the derivative of a regular type is the type of its one-hole context ( https://news.ycombinator.com/item?id=34358663 ) is beautiful and kind of amazing, but not a result that you’re going to hear much about outside of PhD programs and the like. CS is chock-full of such work. The entire field of programming language theory has come a long, long way since Turing and Von Neumann’s time, to pick a broader example.
My question would be if "math" is the right tool for that. It can achieve that as a side-effect, but how we express it and talk about it is full of legacy cruft, cargo-culting and general bullshit that makes it not exactly snap into place for all kinds of brain wirings.
Math I believe is not an end in itself. Maybe with that perspective, solutions that satisfy our needs there can be found
This is the same kind of analogy people make when they "poo-pooh" any sort of technological advance, especially with AI.
"Oh, that old simple device didn't displace anything, so this one which is now quickly taking over every job will be just like that simple one". So I guess people today know how to sew and knit and bake bread?
"Oh, humans were always needed, so it'll be the same this time." Is that true of horses and oxen after cars and tractors were invented?
I think we'll find that the people doing that, like the people spending all their time and energy reading slasher pulp fiction in the 1950s, won't be doing as well as the people learning to enhance the power of their education and their expertise via LLMs and strategic alternating between GenAI and thinking about problems. And eventually, if society ever steadies up a bit, people will learn the useful ways of using technology in school and youth; and we'll be glad to be alive to see such marvels.
Assuming we can re-establish the will for democracy and taking care of the whole group.
Those are some big ifs and assumptions unfortunately, and the use of AI unfortunately has an isolating effect that is only likely to move the needle in the wrong direction.
I mean I use coffee quite a lot to prop up my software career. I don’t really find purity to be useful for anything except to answer questions like “should I steal this money now that I am alone” or “should I backstab this friend who pissed me off today.”
> questions like “should I steal this money now that I am alone” or “should I backstab this friend who pissed me off today.”
Ah, yes, a very BOFH approach [0] to workplace quandaries.
> I mean I use coffee quite a lot
Perhaps, but I don't think either of us would agree with the claim: "The way we integrated caffeine for productivity offers a useful and practical model for integrating meth for productivity."
There's an extremely detectable difference in the feedback loops that form between the tool and the people using it. If we assume for the sake of argument that coffee is "good" and "productive", then that leads us to the question:
Are these LLM systems more like coffee, or more like meth?
That's a very good point. People don't pull out their calculator in the grocery store to do analysis of unit costs or whatever, it's too much of a hassle for that small kind of analysis. But calculators have robbed us of the need to be good at doing that math in our heads. So the math doesn't get done.
A more apt analogy is the diminishing understanding of assembly language and machine instruction sets. I love programming and something got lost in both transitions, first to high level languages and now to coding agents. I am quite sure some contexts will require programming by hand for a long while as there are still people who are writing amd64/avx512/sass by hand. I hope in time we will find new ways to enjoy solving problems with this new programming modality. By now, I am pretty sure it is here to stay and evolve from its current crude form.
> the diminishing understanding of assembly language and machine instruction sets
This is true and nobody complains that GCC or LLVM is making programmers dumber. They are code-generation tools from higher-level source code. Much like LLMs are code-generation tools for higher-level language/prompting.
With a calculator you still need to understand the fundamentals of mathematics. You also need to understand how to operate a calculator and know its functions.
Even when removing numbers and manual calculation, being a function or formula oriented mathematician still requires you to know the theory and functionality.
With an LLM, you don't even need to know anything other than asking the robot to perform. You don't understand the output, nor can an unskilled person explain it.
I'm also concerned about people asking an opaque machine for an answer and stopping there instead of going to different sources, evaluating their credibility, exercising their own ability to construct their own worldview from disparate facts and opinions.
Flagged for the expressing the most obvious and legitimate concern about LLM-backed "research".
"I use AI to generate a summary which I print out and read slowly every time I use a new codebase" is the new propaganda line pushed by Anthropic and OpenAI. They cannot tolerate this rebuttal.
Coders should be treated as as well as as other software users. Tools like Claude code, Antigravity, and others are applying AI to solving that problem.
I know how to create a multi year P&L projection from scratch. It gives me some insight into how much capital a startup will need to get to breakeven. A good AI tool that creates that same spreadsheet in minutes should also be able to explain why different businesses have different shaped cash flow troughs. I don't think people using tools like that is bad even if they don't gain deep insight.
Very few people know how to hand set typography anymore, but many of the conventions still exist and people don't have to understand the origin of a lot of them to use them properly.
Does anyone else feel like the web has become so "readable" it is illegible?
I have such a hard time quickly reading pages like TFA. Headings, bullets, line-spacing, width, link hover animations, even the font. Even reader mode defaults aren't great for me.
I'm looking forward to having the same experience as COBOL engineers did after retirement: companies backing up the brinks truck to anyone with the skills to keep the lights on.
Yeah, every COBOL job paid pretty terrible relative to other types of work (like web dev).
Sure there might be a dozen individuals making over $300k but most COBOL devs live in the deep south making less than $100k for their entire careers. Fine salary, but that line of work is severely limited and the salaries do not reflect how valuable that work is.
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.
> 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.
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?"
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.
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.
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.
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 ;)
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, and generally don't become reliable enough to use.
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!
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
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.
> 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?
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...
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 skills
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.
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.
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
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.
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.
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.
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)
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.
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.
>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?
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.
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.
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?
> 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.
> 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 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.
> 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.
I really didn't want to get into computing only to be relegated to a declarative sentence writer. If I wanted to do that as a career, I'd have gone into literature.
> 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.
> 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. All that's left for most of us is slicing and dicing of what has been already been implemented.
> 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.
> 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
Transit 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!
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.
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.
staying within free tiers has led to some really great optimizations for me
took 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
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.
> 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.
1. 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.
> 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.
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?
> 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.
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...
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.
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.
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).
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.
> My hope is that we'll see a number of companies collapse as they scale - with basically no hope of rescue
If 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.
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).
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.
> 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.
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.
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.
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.
> 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).
> 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.
> 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
Not 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.
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
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.
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
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 ago
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.
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.
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.
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.
> 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).
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.
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.
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.
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.
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!"
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.
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.
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.
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 code?
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.
> 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.
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.
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.
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.
> 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.
> 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.
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 :)
Bart
> the reality is that engineers are pumping out code faster than the humans can understand and (honestly) review it
The 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.
> 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.
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.
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.
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.
>the hardest part about being a software engineer is just filtering through AI generated artifacts
This 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.
I'm seeing it happen in real time. I've seen several folks claim they "vibe-coded" something and upon review it's some seriously low quality garbage. Unfortunately it's just "functional enough" where it's encouraging the one who talked to the robot to continue thinking they can code for some reason.
It is important to ensure that any LLM code is named and shamed.
The industry has always had niches where quality is really important, such as NASA where you install your product in a multi-billion-dollar, one-of-a-kind robot and launch it into space. However, for the most part all that matters is that it roughly does what it advertises to do and ships as quickly as possible. LLMs are ideally suited to the latter form of software and the need for humans to ever see or think about the code will drop to zero soon, if it hasn't already.
The snake eating it's own tail for llm software development has really been met with a shoulder shrug whenever it gets brought up. At best you might have a small cohort of developers that don't cook their brains with AI and their reward for that appears to be having to review terrible AI code written by people who have cooked their brains.
Maybe I’m naive, or misguided, or something else, but I decided almost 2 years ago that I’m going to bank on not using LLMs to do my job. I still write code by hand everyday. I don’t use AI to write code or lookup docs, or anything else. I just figure that if we really, truly, indisputably hit the point of AI assisted coding being mandatory, I can learn it and get up to speed in a few weeks (or at worst a couple months), whereas uncooking my brain is way way more expensive and time consuming and difficult. We’ll see how it plays out, but so far I don’t feel left behind at all really.
I would agree if companies did not have a vested interest in over complicating things and creating eco systems to sell certifications and offer a consulting arm aka FDE. Using AI to improve your coding is quick, as you say, but learning all the jargons and protocols and RFC specs so some single company can try to control the new "open source" world is what is going to take a while. All the weird little token and model nuances and stuff. I would say at least keep up with knowing the acronyms of you're not going to learn it directly.
Same here! The slight difference being I'll just do something else for money and code purely for fun if hand written code stops being economically viable. I'll highly confident that won't happen though.
I am in exactly the same position; I don't feel left behind per se but I was just fired for my stance. Management is entirely deluded across the industry, and in my case it was even acknowledged and agreed that my output and the quality of work was not in question, simply the fact that I didn't use LLMs to produce it.
I reckon everything needs another 6-18 months to ripen, then those of us who haven't bet the farm on slop will be in big business contracting and consulting to drag companies out of the pit they're digging themselves.
So far I think I have learned far more from LLMs than I've lost to them. I forget some syntax, definitely. But I now reach for a much wider range of tools that I have become familiar with because of LLMs.
Yeah, I have to say some of this deskilling argument sounds like Socrates complaining about the invention of writing ruining people's ability to truly own the text. I really don't mourn my lost assembly skills or my lost C skills. And I'm not missing the details of whatever web framework du jour my Claude is vibing for me on my extremely useful dataviz internal tools; and I have learned how to rein the agents in to not ruin my high-performance Go code and yet debug concurrency issues. Maybe coding qua coding is what some people find their summum bonum, but for me programming is instrumentive - to build real things in the world that do things to make something better. When I want pure virtuosity of intellectual construction, I read maths papers in arxiv.
(Not to say that the current state of the art with LLMs merits borrowing money for a multi-trillion spend on hardware that will be obsolete in 5 years, but for me that is a different issue).
The master decrying the invention that resulted in more wisdom for more people than anything prior:
"For this invention will produce forgetfulness in the minds of those who learn to use it, because they will not practice their memory. Their trust in writing, produced by external characters which are no part of themselves, will discourage the use of their own memory within them. You have invented an elixir not of memory, but of reminding; and you offer your pupils the appearance of wisdom, not true wisdom, for they will read many things without instruction and will therefore seem [275b] to know many things, when they are for the most part ignorant and hard to get along with, since they are not wise, but only appear wise." (quoting from https://www.historyofinformation.com/detail.php?id=3439)
Yeah. Thought in Socrates' defense I think the jury is still out on writing, in the scale of human existence it's still very new. Give it a hundred thousand years or so.
I posted this elsewhere, but that story has a lot more nuance.
Plato (who actually wrote these quotes, because Socrates only spoke) wasn't against just "writing" in a general sense, or that he felt it was going to hold humanity back. He was against treatises and felt that someone could "memorize facts" without having to actually think about them on a deep level. Which I think, ironically, is not all that off the mark especially in the age of the internet and now LLMs, right? He also felt that memory could decay if we relied on written facts instead of having dialogues, which again, not all that off the mark, either. He underestimated the compounding capability of technology and our ability to record data and information, but people remember a lot less these days than they used to because we'd largely given up that ability in exchange for the instant information machines.
Of course, he's just one man (or two, if you consider he was conveying Socrates' thoughts, as well) who lived in ancient times and couldn't possibly foresee how technology would evolve...but when I went back and read his concerns, it was ironic to admit that much of what he warned about still applies to this day. People are far less informed despite having access to more information than we've ever had because we've exchanged the ability to remember for the ability to just look things up. And, we also have less meaningful dialog than ever before; people just sit on social media, copying and pasting "facts" to each other, instead of having actual productive discourse. When I look around, the world doesn't seem brimming with mindful critical thinkers and there's reasons for that (many reasons, of course).
AI tooling can be a boon to learning, but it requires us to stop using them for code generation as a primary purpose (at least for juniors) and instead advocate for Socratic workflows that still require manual coding practices. When someone decides to code something, it's not just learning syntax; it engages a variety of mental disciplines from critical thinking to planning to creative problem solving to logic and math, even.
There is an argument to be made though that writing stuff down yourself results in better retention than simply reading the same material. People still write by hand and take notes. And they still process ideas and thoughts verbally. Doing so is often more effective than going in circles with a chatbot.
This is where I'm suspicious of people who say they're learning more from LLMs. Are they actually learning, or do they just think they're learning (like how Duolingo is gameified pattern matching so it feels like you're making progress, but most people are learning the pattern matching instead of the language).
It's not just speculation, we have data from multiple studies at this point that suggest leaning on AI for productivity leads to skill depreciation across domain.
// The need for ongoing friction in long-term skill formation.
The subtitle of the story tells it all.
There are some people who seek out friction. Think about an athlete or a hardcore nerd.
The best engineers are ones who were fascinated with computers and learning as kids and persued it at every opportunity. Found their own friction in other words.
For those kinds of people, friction-seeking is the constant and what LLMs did is moved the point of where the friction occurs.
For example - the best engineers I've worked with didn't necessarily have lots of experience coding in assembly because that kind of friction was no longer necessary. But they could solve hard problems (and if a problem really required assembly they could go learn it)
What I think will be hit much harder by AI is the low tier engineer. Someone who was never truly curious and committed to it, for whom it was just a job. For example a typical offshore ticket pusher kind of person. That kind of person never went out to find friction and that's the kind of thing that's never going to fly again - if I want mediocre or average, the LLMs are sufficient
I mean if you think about it, that sounds like a miserable existence to begin with.
I would not rule out that some people will use this.. uh.. disruption, to start pursuing something that actually brings them joy.
Of course, bills need to be paid and it's not all that simple. But at least there might be such a silver lining.
I think this expresses what I've been trying to form in my mind.
I've been trying to map the LLM advancements and the current state of software development onto prior technological improvements. History is littered with similar cases where the abstraction layer ends up getting lifted, and people struggle with getting accustomed to working at that higher abstraction level.
For the people that fall in love with a single abstraction layer or don't have an interest in learning new paradigms, when their known pattern is abstracted away, they're condemned to being left behind, either unwilling or unable to adapt.
I don't think any industry is free from this, any person in any industry/profession over a period of 20 years or more has likely had to undergo massive adjustments as technology changed their field.
We're not unique, but that doesn't stop it from feeling so jarring when it happens to us
> History is littered with similar cases where the abstraction layer ends up getting lifted, and people struggle with getting accustomed to working at that higher abstraction level.
But there's no abstraction layer that ends up getting lifted. When I use a library like SDL or a standard like POSIX, I don't tend to look at the underlying implementation. Instead I work with the high level concepts that they come up with. There's no such things with AI tooling. The most similar is when fully vibing software and everyone knows the quality of the result.
I've learned something at every abstraction layer in computing from electronics (hardware), theory of computation (software) to high level programming languages with their paradigms. Same with several domains embodied by libraries. LLM tooling is more like shamanic ritual than engineering.
Yeah, a bespoke program that does exactly what I need it to do, at a speed that I had forgotten was possible on computers, with customization that is an exact fit to me, at a cost that is smaller than a rounding error.
I get that LLMs struggle with the old paradigm of a single piece of software meant to serve every conceivable use case of every conceivable user, but I kinda hope that paradigm dies.
> There's no such things with AI tooling. The most similar is when fully vibing software and everyone knows the quality of the result.
This is the same “but the ai can’t even do fingers” argument all over again, and it will age just a well.
The whole vibe coding thing only really started taking hold with the release of opus 4.5. That wasn’t even a year ago. you absolutely can be quality software without looking at the code. The only thing up for debate in my mind is how big that software can get before you need to look under the hood.
But that’s dictated by current model capabilities. And I don’t see any reason to believe that they will suddenly stop improving on this front.
Exactly this. You still have to understand the abstraction layer the LLM is working at in order to be able to form an opinion about the quality of the code. (If you DON’T care about the quality of the code, there’s always been ways to get an extra 1000% short-term speed improvement by just not giving a shit.)
AI isn’t “a code abstraction layer” any more than Jira is, or the engineer themselves is.
I think "the engineer themselves" is much closer to the abstraction layer I'm referring to.
Imagine for a moment that, rather than using a compiler to translate c++ into assembly, that it instead has to be done by a person on the team. If that were the case, the resulting assembly code would certainly have to be reviewed and assessed before it was accepted.
Why?
Because people can also be leaky, non-deterministic abstraction layers. The only reason that the output of a compiler isn't regularly reviewed (in 99% of cases) is because it's extraordinarily reliable and consistently correct, or correct enough for most cases.
It's not terribly dissimilar from delegating engineering tasks to other engineers. When I ask someone else to develop one component of a larger application, I'm not telling them exactly what lines to write, I'm giving them some kind of structure and they're filling in the rest. The communication to them is above the implementation layer.
Agents are increasingly letting us work at that same boundary. Just because the current state of LLMs requires engineering knowledge to review the result doesn't mean an abstraction hasn't occurred. It speaks more to the current quality of that abstraction than the absence of one.
I think that if LLMs were able to achieve the same consistency as a compiler, most people wouldn't ever bother to check the underlying code it produced. I also think it would be difficult to not acknowledge that LLMs have gotten better at converting natural language into functioning software. The abstraction is certainly not perfect, but it is clearly improving.
I think coding experts who are only experts at writing code will also be hit pretty hard. Every problem given to them is solved by writing code, and only code, their way and only their way. I think people like that are having a very hard time relinquishing control regardless of the quality and correctness of the LLM output. If it didn't come from them, or conform to their conventions and style, then it's wrong. These are the people that seem to be terrific developers but then when asked to be a team lead and bring a group of developers to their level completely fail.
Curiosity is really key, and I find that LLMs diminish curiosity in people that might otherwise have it because the allure of the answer is often a lot stronger than the allure of the friction. I guess that's just the distilling of the industry over time, but that could certainly lead to a shortage of expertise.
If that is representative of your personal experience, then I'm saddened to hear it. I believe your article is an argument from incredulity [1]. You may not personally know anyone who thrives in learning from and applying knowledge with AI. But being unaware that it is even possible is not evidence that expertise will inevitably collapse.
I don't see this at all. If anything they are curiosity amplifiers. But perhaps this mostly applies to the kind of people I spend most of my time with.
Who else is going to talk about a topic like how Searle would approach differentiating ownership from privilege in RBAC?
This has largely been my experience. On the one hand I now have AI writing 99% of my code. On the other hand I'm not dealing with a whole new class of problems that come out of that.
I strongly agree with the concept that cognitive friction is the engine of learning.
First and foremost, it's an issue of "dependency": if you stop training the "muscle" of logic and reasoning, it gradually atrophies, just like unused physical muscles. You become dependent on external tools that replace a capability you once had yourself.
A historical example that brought about a similar shift is this: when the production process moved from the craftsman's mind and hands to the Fordist factory (and the assembly line), the skill of building things shifted from human craftsmanship to anonymous, structured processes.
Bit by bit, traditional artisans lost their knowledge and "know-how." Today, having a piece of furniture in our home depends on a massive production and supply chain; the "average" person no longer has the ability to build it themselves.
> Today, having a piece of furniture in our home depends on a massive production and supply chain; the "average" person no longer has the ability to build it themselves.
Tangential, but this is one of many reasons that I (and I suspect many others here) have taken up wood working.
> Bainbridge argues that new, severe problems are caused by automating most of the work, while the human operator is responsible for tasks that can not be automated. Thus, operators will not practice skills as part of their ongoing work. Their work now also includes exhausting monitoring tasks. Thus, rather than needing less training, operators need to be trained more to be ready for the rare but crucial interventions
I can totally see where that could be the case. I'm sure there have been breakthroughs already, but it's not mainstream news. The mountain of AI slop is all over the mainstream though. You have to wonder why.
TBH it was already pretty bad. There is a stark difference between the best and the average in my experience. The top, say, ten percent of coders are vastly better than anyone else when it comes to anything but boilerplate glue code(which is still needed and is better done by average coders anyway).
This is speaking from my experience as a systems/c/c++ guy. If you are a js web frontend guy, python, or whatever I have no idea if this applies to you.
Yea, it does apply. Honestly I'd argue that as you move up the abstraction layer cake, it applies even more. If a team gets a tool which 2x's their output (maybe a higher level language vs writing in C), then the difference in absolute output someone who produces 1 widget per day and 5 widgets per day becomes substantial. If you're given a tool which 10x's your output in a day, then it's even bigger. And of course you can have devs on a team who produce -.5 widgets per day.
Think about the worst colleague you've had, now give them a tool which 10x's their output :)
I used to think this was a problem. But now? I don’t think it matters.
Why? Because people are going to get so much more ambitious about the stuff they build with AI, that code expertise for the stuff they are building is already scarce anyway. People will choose difficult and less popular languages, and will replace open source packages with stuff built entirely in-house by AI.
Going forward, there is no choice except for AI to fully replace the need for code expertise. Depending on humans won’t be scalable.
Do we even need to get LLMs to create code in the end then? Can we imagine a future where the thing simply does it all, you deploy the LLM like a docker image and have it process all requests directly. Sounds far fetched today, coming to your cluster in five years.
In theory yes, but you would need LLMs that basically have frontier level capabilities but with zero latency, meaning you enter a prompt and as you type the prompt is regenerating instantly like some kind of autocomplete.
I think that would feel like crack for some people who are addicted to using or building stuff with LLMs.
443 comments
[ 0.26 ms ] story [ 16.9 ms ] threadDo we think there is going to be a correction for the vibe coders?
Pardon I know such question is controversial but thinking ahead.
Again, to be clear, this is highly dependent on the market, job, and hours and one needs to understand the difference between a CNA, RN, NP, etc. However, it's a regulated typically union job that's very secure and in high demand. It probably pays more than what you expect.
1. We still need to keep the lights on. If things go wrong, which they still do, humans have to debug it.
2. Jevon's paradox: now the expectation is that we ship stuff faster and there is still a LOT of stuff to do, not less.
3. We are still in the very early days of this and it is too soon for corporations to make a dramatic call like laying off 80% of engineering. We just don't know how that would look like.
Not surprised Germany values education a bit higher than us.
https://ivyleaguecenter.org/2024/03/12/over-reliance-on-calc...
Math fosters critical thinking, and we've been in a critical thinking deficit for decades and decades. I don't think we can afford to sink even deeper...
In contrast since then we've had almost not noteable physicists or Computer Scientists that I'm aware, we've got a couple, Hawking and Knuth. But apart from that I don't know if there is a single scientist I could point out today that has revolutionized our understanding or even done any real breakthrough work in the field of Physics since Einsteins era.
But my reply was I guess implicitly assuming the post I was replying to was talking about the median level of critical thinking. Your reply is talking about the peaks of creative accomplishment which is not what I was addressing.
You also seem to be restricting yourself to pop science knowledge of who’s made breakthroughs. That’s because our collective understanding of physics has become much more detailed, to the point where it starts to lose the ability to be meaningfully comprehensible to the average layperson.
Consider AdS/CFT, for example: https://en.wikipedia.org/wiki/AdS/CFT_correspondence
There’ve been many major developments just in that area since the early 1970s, to through the late 90s all the way to 2019 (the island formula), with many major contributors like Bekenstein, ‘t Hooft, Susskind, Maldacena, and many less well-known names.
If you resurrected some of the scientists you mentioned, they’d have a lot of work to do to catch up, and making field-changing major breakthroughs would be just as difficult for them as for anyone else alive today.
Something similar is true in CS. There’s been plenty of progress in all fields of CS, but similar to the situation with physics, its nature is not as simple as what the founders of the field were dealing with, so there’s less awareness of it outside the field. Just to pick one small example, Conor McBride’s insight that the derivative of a regular type is the type of its one-hole context ( https://news.ycombinator.com/item?id=34358663 ) is beautiful and kind of amazing, but not a result that you’re going to hear much about outside of PhD programs and the like. CS is chock-full of such work. The entire field of programming language theory has come a long, long way since Turing and Von Neumann’s time, to pick a broader example.
I kinda agree, but I also kinda disagree.
My question would be if "math" is the right tool for that. It can achieve that as a side-effect, but how we express it and talk about it is full of legacy cruft, cargo-culting and general bullshit that makes it not exactly snap into place for all kinds of brain wirings.
Math I believe is not an end in itself. Maybe with that perspective, solutions that satisfy our needs there can be found
Compared to when?
"Oh, that old simple device didn't displace anything, so this one which is now quickly taking over every job will be just like that simple one". So I guess people today know how to sew and knit and bake bread?
"Oh, humans were always needed, so it'll be the same this time." Is that true of horses and oxen after cars and tractors were invented?
This is more like paying someone else to read your math homework and then submit the answers on your behalf.
Assuming we can re-establish the will for democracy and taking care of the whole group.
Bad outcomes may not be guaranteed, but there are behavioral and cybernetic pitfalls which are both numerous and deep.
Ah, yes, a very BOFH approach [0] to workplace quandaries.
> I mean I use coffee quite a lot
Perhaps, but I don't think either of us would agree with the claim: "The way we integrated caffeine for productivity offers a useful and practical model for integrating meth for productivity."
There's an extremely detectable difference in the feedback loops that form between the tool and the people using it. If we assume for the sake of argument that coffee is "good" and "productive", then that leads us to the question:
Are these LLM systems more like coffee, or more like meth?
[0] https://www.theregister.com/bofh
This is true and nobody complains that GCC or LLVM is making programmers dumber. They are code-generation tools from higher-level source code. Much like LLMs are code-generation tools for higher-level language/prompting.
With a calculator you still need to understand the fundamentals of mathematics. You also need to understand how to operate a calculator and know its functions.
Even when removing numbers and manual calculation, being a function or formula oriented mathematician still requires you to know the theory and functionality.
With an LLM, you don't even need to know anything other than asking the robot to perform. You don't understand the output, nor can an unskilled person explain it.
People can no longer drive a stick-shift car, whereas it used to be that a valet would always be able to drive one to park it.
so many folks struggle to calculate a 20% tip in their head
llms have absolutely made education much more complicated for educators
LLM chatbots are good at making you feel good. Facts don't care about your feelings.
"I use AI to generate a summary which I print out and read slowly every time I use a new codebase" is the new propaganda line pushed by Anthropic and OpenAI. They cannot tolerate this rebuttal.
I know how to create a multi year P&L projection from scratch. It gives me some insight into how much capital a startup will need to get to breakeven. A good AI tool that creates that same spreadsheet in minutes should also be able to explain why different businesses have different shaped cash flow troughs. I don't think people using tools like that is bad even if they don't gain deep insight.
I have such a hard time quickly reading pages like TFA. Headings, bullets, line-spacing, width, link hover animations, even the font. Even reader mode defaults aren't great for me.
Compared to, for example, https://www.paulgraham.com/best.html
Sure there might be a dozen individuals making over $300k but most COBOL devs live in the deep south making less than $100k for their entire careers. Fine salary, but that line of work is severely limited and the salaries do not reflect how valuable that work is.
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.
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.
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.
- 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.
Current project has over 60,000 LOC, I find using an antagonistic agent code and architecture reviews are really handy for keeping things grounded.
I do very little actual reading of code anymore. Now I am more of a results merchant.
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 ;)
At the same size I only heard of AI generated projects reimplementing compilers and browser engines which come with amazing tests written by hand, and generally don't become reliable enough to use.
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!
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
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.
Is there ANY field where good engineers don't understand the basics? Can an electrical engineer do any work without understanding Volts and Amperes?
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.
https://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
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.
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.
This is not non-coding work. This is coding.
My claim is just that LLMs are basically fine now with the "coding" part. Not so much with development, definitely not with engineering.
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.
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.
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?
An explicit query returns a specific answer, but means nothing about whether it can use that knowledge to create better software.
"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.
> 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 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.
> 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.
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.
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. All that's left for most of us is slicing and dicing of what has been already been implemented.
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.
Transit 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!
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.
Not to mention we told everyone to not roll their own anything, just use the free library for, clocks, time, crypto, auth, IPC, etc!
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.
took 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
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.
Horrible if you got into engineering because you wanted to solve problems.
Amazing if you only ever wanted to see the problem solved.
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.
1. 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.
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.
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.
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...
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.
Please 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).
It's probably more accurate to call it the slop phase.
A bad or below average dev with AI will run your product and company into the ground in a matter of weeks.
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.
If 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.
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).
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.
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.
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.
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.
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).
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.
Not 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.
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
Where does it land?
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.
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
Knowing what not to do has always been important, but it is perhaps more important than ever.
Aka “actual deep understanding”.
;-)
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.
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).
I guess that is taste?
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.
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.
Why would programming be any different?
That doesnt clearly apply here
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.
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.
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.
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.
1. Yes, we know, and can tell.
2. 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.
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.
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.
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.
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.
The 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.
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.
This 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.
He would call you a moron.
He might even just fire you as a customer if you annoyed him enough.
It is important to ensure that any LLM code is named and shamed.
You need to take it further.
We need to shame and mock the people (read: delusional imbeciles) who think this is acceptable if we want it to stop.
AI users need to fear for their careers and reputations if we want to get software development back on the right track.
Completely unsustainable.
I reckon everything needs another 6-18 months to ripen, then those of us who haven't bet the farm on slop will be in big business contracting and consulting to drag companies out of the pit they're digging themselves.
So, partly agree, partly disagree.
(Not to say that the current state of the art with LLMs merits borrowing money for a multi-trillion spend on hardware that will be obsolete in 5 years, but for me that is a different issue).
The master decrying the invention that resulted in more wisdom for more people than anything prior:
"For this invention will produce forgetfulness in the minds of those who learn to use it, because they will not practice their memory. Their trust in writing, produced by external characters which are no part of themselves, will discourage the use of their own memory within them. You have invented an elixir not of memory, but of reminding; and you offer your pupils the appearance of wisdom, not true wisdom, for they will read many things without instruction and will therefore seem [275b] to know many things, when they are for the most part ignorant and hard to get along with, since they are not wise, but only appear wise." (quoting from https://www.historyofinformation.com/detail.php?id=3439)
Plato (who actually wrote these quotes, because Socrates only spoke) wasn't against just "writing" in a general sense, or that he felt it was going to hold humanity back. He was against treatises and felt that someone could "memorize facts" without having to actually think about them on a deep level. Which I think, ironically, is not all that off the mark especially in the age of the internet and now LLMs, right? He also felt that memory could decay if we relied on written facts instead of having dialogues, which again, not all that off the mark, either. He underestimated the compounding capability of technology and our ability to record data and information, but people remember a lot less these days than they used to because we'd largely given up that ability in exchange for the instant information machines.
Of course, he's just one man (or two, if you consider he was conveying Socrates' thoughts, as well) who lived in ancient times and couldn't possibly foresee how technology would evolve...but when I went back and read his concerns, it was ironic to admit that much of what he warned about still applies to this day. People are far less informed despite having access to more information than we've ever had because we've exchanged the ability to remember for the ability to just look things up. And, we also have less meaningful dialog than ever before; people just sit on social media, copying and pasting "facts" to each other, instead of having actual productive discourse. When I look around, the world doesn't seem brimming with mindful critical thinkers and there's reasons for that (many reasons, of course).
AI tooling can be a boon to learning, but it requires us to stop using them for code generation as a primary purpose (at least for juniors) and instead advocate for Socratic workflows that still require manual coding practices. When someone decides to code something, it's not just learning syntax; it engages a variety of mental disciplines from critical thinking to planning to creative problem solving to logic and math, even.
The subtitle of the story tells it all.
There are some people who seek out friction. Think about an athlete or a hardcore nerd.
The best engineers are ones who were fascinated with computers and learning as kids and persued it at every opportunity. Found their own friction in other words.
For those kinds of people, friction-seeking is the constant and what LLMs did is moved the point of where the friction occurs.
For example - the best engineers I've worked with didn't necessarily have lots of experience coding in assembly because that kind of friction was no longer necessary. But they could solve hard problems (and if a problem really required assembly they could go learn it)
What I think will be hit much harder by AI is the low tier engineer. Someone who was never truly curious and committed to it, for whom it was just a job. For example a typical offshore ticket pusher kind of person. That kind of person never went out to find friction and that's the kind of thing that's never going to fly again - if I want mediocre or average, the LLMs are sufficient
Of course, bills need to be paid and it's not all that simple. But at least there might be such a silver lining.
I've been trying to map the LLM advancements and the current state of software development onto prior technological improvements. History is littered with similar cases where the abstraction layer ends up getting lifted, and people struggle with getting accustomed to working at that higher abstraction level.
For the people that fall in love with a single abstraction layer or don't have an interest in learning new paradigms, when their known pattern is abstracted away, they're condemned to being left behind, either unwilling or unable to adapt.
I don't think any industry is free from this, any person in any industry/profession over a period of 20 years or more has likely had to undergo massive adjustments as technology changed their field.
We're not unique, but that doesn't stop it from feeling so jarring when it happens to us
But there's no abstraction layer that ends up getting lifted. When I use a library like SDL or a standard like POSIX, I don't tend to look at the underlying implementation. Instead I work with the high level concepts that they come up with. There's no such things with AI tooling. The most similar is when fully vibing software and everyone knows the quality of the result.
I've learned something at every abstraction layer in computing from electronics (hardware), theory of computation (software) to high level programming languages with their paradigms. Same with several domains embodied by libraries. LLM tooling is more like shamanic ritual than engineering.
Yeah, a bespoke program that does exactly what I need it to do, at a speed that I had forgotten was possible on computers, with customization that is an exact fit to me, at a cost that is smaller than a rounding error.
I get that LLMs struggle with the old paradigm of a single piece of software meant to serve every conceivable use case of every conceivable user, but I kinda hope that paradigm dies.
This is the same “but the ai can’t even do fingers” argument all over again, and it will age just a well.
The whole vibe coding thing only really started taking hold with the release of opus 4.5. That wasn’t even a year ago. you absolutely can be quality software without looking at the code. The only thing up for debate in my mind is how big that software can get before you need to look under the hood.
But that’s dictated by current model capabilities. And I don’t see any reason to believe that they will suddenly stop improving on this front.
AI isn’t “a code abstraction layer” any more than Jira is, or the engineer themselves is.
Imagine for a moment that, rather than using a compiler to translate c++ into assembly, that it instead has to be done by a person on the team. If that were the case, the resulting assembly code would certainly have to be reviewed and assessed before it was accepted.
Why?
Because people can also be leaky, non-deterministic abstraction layers. The only reason that the output of a compiler isn't regularly reviewed (in 99% of cases) is because it's extraordinarily reliable and consistently correct, or correct enough for most cases.
It's not terribly dissimilar from delegating engineering tasks to other engineers. When I ask someone else to develop one component of a larger application, I'm not telling them exactly what lines to write, I'm giving them some kind of structure and they're filling in the rest. The communication to them is above the implementation layer.
Agents are increasingly letting us work at that same boundary. Just because the current state of LLMs requires engineering knowledge to review the result doesn't mean an abstraction hasn't occurred. It speaks more to the current quality of that abstraction than the absence of one.
I think that if LLMs were able to achieve the same consistency as a compiler, most people wouldn't ever bother to check the underlying code it produced. I also think it would be difficult to not acknowledge that LLMs have gotten better at converting natural language into functioning software. The abstraction is certainly not perfect, but it is clearly improving.
[1]: https://en.wikipedia.org/wiki/Argument_from_incredulity
Who else is going to talk about a topic like how Searle would approach differentiating ownership from privilege in RBAC?
First and foremost, it's an issue of "dependency": if you stop training the "muscle" of logic and reasoning, it gradually atrophies, just like unused physical muscles. You become dependent on external tools that replace a capability you once had yourself.
A historical example that brought about a similar shift is this: when the production process moved from the craftsman's mind and hands to the Fordist factory (and the assembly line), the skill of building things shifted from human craftsmanship to anonymous, structured processes.
Bit by bit, traditional artisans lost their knowledge and "know-how." Today, having a piece of furniture in our home depends on a massive production and supply chain; the "average" person no longer has the ability to build it themselves.
The exact same thing is happening to software.
We are the (now "former") software craftsmen.
Tangential, but this is one of many reasons that I (and I suspect many others here) have taken up wood working.
> Bainbridge argues that new, severe problems are caused by automating most of the work, while the human operator is responsible for tasks that can not be automated. Thus, operators will not practice skills as part of their ongoing work. Their work now also includes exhausting monitoring tasks. Thus, rather than needing less training, operators need to be trained more to be ready for the rare but crucial interventions
This is speaking from my experience as a systems/c/c++ guy. If you are a js web frontend guy, python, or whatever I have no idea if this applies to you.
Think about the worst colleague you've had, now give them a tool which 10x's their output :)
Why? Because people are going to get so much more ambitious about the stuff they build with AI, that code expertise for the stuff they are building is already scarce anyway. People will choose difficult and less popular languages, and will replace open source packages with stuff built entirely in-house by AI.
Going forward, there is no choice except for AI to fully replace the need for code expertise. Depending on humans won’t be scalable.
I think that would feel like crack for some people who are addicted to using or building stuff with LLMs.