I asked Codex to write some unit tests for Redux today. At first glance it looked fine, and I continued on. I then went back to add a test by hand, and after looking more closely at the output there were like 50 wtf worthy things scattered in there. Sure they ran, but it was bad in all sorts of ways. And this was just writing something very basic.
This has been my experience almost every time I use AI: superficially it seems fine, once I go to extend the code I realize it's a disaster and I have to clean it up.
The problem with "code is cheap" is that, it's not. GENERATING code is now cheap (while the LLMs are subsidized by endless VC dollars, anyway), but the cost of owning that code is not. Every line of code is a liability, and generating thousands of lines a day is like running up a few thousand dollars of debt on a credit card thinking you're getting free stuff and then being surprised when it gets declined.
EWD 1036: On the cruelty of really teaching computing science (1988)
“My point today is that, if we wish to count lines of code, we should not regard them as ‘lines produced’ but as ‘lines spent’: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.”
A better formulation is "every feature is a liability". Taking it to the line of code level is too prescriptive. Occasionally writing more verbose code is preferable if it makes it easier to understand.
> A better formulation is "every feature is a liability". Taking it to the line of code level is too prescriptive.
Amount of code is a huge factor but maybe not the best wording here. It's more a thing of complexity where amount of code is a contributing metric but not the only one. You can very easily have a feature implemented in a too complex way and with too much code (esp. if an LLM generated the code but also with human developers). Also not every feature is equal.
> Occasionally writing more verbose code is preferable if it makes it easier to understand.
Think this is more a classic case of "if the metric becomes a goal it ceases to be a metric" than it being a bad metric per se.
This sounds wrong, features have to be the value of your code. The required maintenance and slow down to build more features (technical debt) are the liability, which is how I understood the relationship to "lines of code" anyway.
I can sort of understand it if I squint: every feature is a maintenance burden, and a risk of looking bad in front of users when you break or remove it, even if those users didn't use this feature. It's really a burden to be avoided when the point of your product is to grow its user base, not to actually be useful. Which explains why even Fischer-Price toys look more feature-ful and ergonomic than most new software products.
Agreed, every line you ship,whether you wrote it or not, you are responsible. In that regard, while I write a lot of code completely with AI, I still endeavor to keep the lines as minimal as possible. This means you never write both the main code and the tests using AI. Id rather have no tests than AI tests (we have QA team writing that up). This kinda works.
But more code from AI means stocks go up. Stocks are assets. If you generate enough code the assets will outnumber the liabilities. It’s accounting 101. /s
The only people I've known that share this perspective are those that hate abstraction. Going back to their code, to extend it in some way, almost always requires a rewrite, because they wrote it with the goal of minimum viable complexity rather than understanding the realities of the real world problem they're solving, like "we all know we need these other features, but we have a deadline!"
For one off, this is fine. For anything maintainable, that needs to survive the realities of time, this is truly terrible.
Related, my friend works in a performance critical space. He can't use abstractions, because the direct, bare metal, "exact fit" implementation will perform best. They can't really add features, because it'll throw the timing of others things off to much, so usually have to re-architect. But, that's the reality of their problem space.
Maybe I am? How is it possible to abstract without encapsulation? And also, how is it possible to encapsulate without abstracting some concept (intentionally or not) contained in that encapsulation? I can't really differentiate them, in the context of naming/referencing some list of CPU operations.
> How is it possible to abstract without encapsulation.
Historically pure machine code with jumps etc lacked any from of encapsulation as any data can be accessed and updated by anything.
However, you would still use abstractions. If you pretend the train is actually going 80.2 MPH instead of somewhere between 80.1573 MPH to 80.2485 MPH which you got from different sensors you don’t need to do every calculation that follows twice.
I'm using the industry definition of abstraction [1]:
> In software, an abstraction provides access while hiding details that otherwise might make access more challenging
I read this as "an encapsulation of a concept". In software, I think it can be simplified to "named lists of operations".
> Historically pure machine code with jumps etc lacked any from of encapsulation as any data can be accessed and updated by anything.
Not practically, by any stretch of the imagination. And, if the intent is to write silly code, modern languages don't really change much, it's just the number of operations in the named lists will be longer.
You would use calls and returns (or just jumps if not supported), and then name and reference the resulting subroutine in your assembler or with a comment (so you could reference it as "call 0x23423 // multiply R1 and R2"), to encapsulate the concept. If those weren't supported, you would use named macros [2]. Your assembler would used named operations, sometimes expanding to multiple opcodes, with each opcode having a conceptually relevant name in the manual, which abstracted a logic circuit made with named logic gates, consisting of named switches, that shuffled around named charge carriers. Say your code just did a few operations, the named abstraction for the list of operations (which all these things are) there would be "blink_light.asm".
> If you pretend the train is actually going 80.2 MPH instead of somewhere between 80.1573 MPH to 80.2485 MPH which you got from different sensors you don’t need to do every calculation that follows twice.
I don't see this as an abstraction as much as a simple engineering compromise (of accuracy) dictated by constraint (CPU time/solenoid wear/whatever), because you're not hiding complexity as much as ignoring it.
I see what you're saying, and you're probably right, but I see the concepts as equivalent. I see an abstraction as a functional encapsulation of a concept. An encapsulation, if not nonsense, will be some meaningful abstraction (or a renaming of one).
I'm genuinely interested in an example of an encapsulation that isn't an abstraction, and an abstraction that isn't a conceptual encapsulation, to right my perspective! I can't think of any.
Incorrect definition = incorrect interpretation. I edited this a few times but the separation is you can use an abstraction even if you maintain access to the implementation details.
> assembler
Assembly language which is a different thing. Initially there was no assembler, someone had to write one. In the beginning every line of code had direct access to all memory in part because limited access required extra engineering.
Though even machine code itself is an abstraction across a great number of implementation details.
> I don't see this as an abstraction as much as a simple engineering compromise (of accuracy) dictated by constraint (CPU time/solenoid wear/whatever), because you're not hiding complexity as much as ignoring it.
If it makes you feel better consider the same situation with 5 senators X of which have failed. The point is you don’t need to consider all information at every stage of a process. Instead of all the underlying details you can write code that asks do we have enough information to get a sufficiently accurate speed? What is it?
It doesn’t matter if the code could still look at the raw sensor data, you the programmer prefer the abstraction so it persists even without anything beyond yourself enforcing it.
IE: “hiding details that otherwise might make access more challenging”
You can use TCP/IP or anything else as an abstraction even if you maintain access to the lower level implementation details.
I genuinely appreciate your response, because there's a good chance it'll result in me changing my perspective, and I'm asking these questions with that intent!
> You are thinking of assembly language which is a different thing. Initially there was no assembler, someone had to write one.
This is why I specifically mention opcodes. I've actually written assemblers! And...there's not much to them. It's mostly just replacing the names given to the opcodes in the datasheet back to the opcodes, with a few human niceties. ;)
> consider the same situation with 5 senators X of which have failed
Ohhhhhhhh, ok. I kind of see. Unfortunately, I don't see the difference between abstraction and encapsulation here. I see the abstraction as being speed as being the encapsulation of a set of sensors, ignoring irrelevant values.
I feel like I'm almost there. I may have edited my previous comment after you replied. My "no procrastination" setting kicked in, and I couldn't see.
I don't see how "The former is about semantic levels, the later about information hiding." are different. In my mind, semantic levels exist as compression and encapsulation of information. If you're saying encapsulation means "black box" then that could make sense to me, but "inaccessible" isn't part of the definition, just "containment".
Computer Science stole the term abstraction from the field of Mathematics. I think mathematics can be really helpful in clearing things up here.
A really simple abstraction in mathematics is that of numeric basis (e.g. base 10) for representing numbers. Being able to use the symbol 3 is much more useful than needing to write III. Of course, numbers themselves are an abstraction- perhaps you and I can reason about 3 and 7 and 10,000 in a vacuum, but young children or people who have never been exposed to numbers without units struggle to understand. Seven… what? Dogs? Bottles? Days? Numbers are an abstraction, and Arabic digits are a particular abstraction on top of that.
Without that abstraction, we would have insufficient tools to do more complex things such as, say, subtract 1 from 1,000,000,000. This is a problem that most 12 year olds can solve, but the greatest mathematicians of the Roman empire could not, because they did not have the right abstractions.
So if there are abstractions that enable us to solve problems that were formerly impossible, this means there is something more going on than “hiding information”. In fact, this is what Dijkstra (a mathematician by training) meant when he said:
The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise
When I use open(2), it’s because I’m operating at the semantic level of files. It’s not sensible to think of a “file” at a lower level: would it be on disk? In memory? What about socket files? But a “file” isn’t a real thing, it’s an abstraction created by the OS. We can operate on files, these made up things, and we can compose operations together in complex, useful ways. The idea of a file opens new possibilities for things we can do with computers.
Expanding on this regarding the difference between abstraction vs encapsulation: abstraction is about the distillation of useful concepts while encapsulation is a specific tactic used to accomplish a behavior.
To continue with the idea of numbers, let’s say you asked someone to add 3 and 5. Is that encapsulation? What information are you hiding? You are not asking them to add coins or meters or reindeer. 3 and 5 are values independent of any underlying information. The numbers aren’t encapsulating anything.
Encapsulation is different. When you operate a motor vehicle, you concern yourself with the controls presented. This allows you, as the operator, to only need a tiny amount of knowledge to interact with an incredibly complex machine. This details have been encapsulated. There may be particular abstraction present, such as the notion of steering, acceleration, and breaking, but the way you interact with these will differ from vehicle to vehicle. Additionally, encapsulation is not concerned with the idea of steering, it is concerned with how to present steering in this specific case.
The two ideas are connected because using an abstraction in software often involves encapsulation. But they should not be conflated, out the likely result is bad abstractions and unwieldy encapsulation.
> It's mostly just replacing the names given to the opcodes in the datasheet back to the opcodes
Under the assumption that the input data is properly formatted you can generate machine code. This is however an abstraction which can fail as nothing forces a user to input valid files.
So we have an abstraction without any encapsulation.
I don't see how the two are related, personally. I'm regularly accused of over-abstraction specifically because I aspire to make each abstraction do as little as possible, i.e. fewest lines possible.
"Abstracting" means extracting the commnon parts of multiple instances, and making everything else a parameter. The difficulty for software is that developers often start by writing the abstraction, rather than having multiple existing instances and then writing code that collects the common parts of those multiple instances into a single abstraction. I guess that is what "refactoring" is about.
In sciences and humanities abstraction is applied the proper way, studying the instances first then describing multitude of existing phenomena by giving names to their common repeating descriptions.
This matches my "ideal" way of writing software, which is something close to "reverse waterfall". Start with the non-negotiable truths at the lowest level, then work your way up towards the goal, which is sufficiently defined. As you go, the patterns became apparent, collapsing into nice abstractions.
The code always ends up nice and clean and modular. And, since I'm working towards the idea, I can say "here are the modular pieces I have to work with, dictated the fundamentals beneath, how do I use them to accomplish the task?". When working from the idea, I think it's easier to want to write something to achieve the immediate task, in a "not see the forest for the trees" kind of way (abstractions are about the goal, rather than the reality under). Of course, both directions are required, but I get the best "separation of concerns" going in reverse.
I call that lasagna code! From what I've seen, developers start with spaghetti, overcompensate with lasagna, then end up with some organization more optimized for the human, that minimizes cognitive load while reading.
To me, abstraction is an encapsulation of some concept. I can't understand how they're practically different, unless you encapsulate true nonsense, without purpose or resulting meaning, which I can't think of an example of, since humans tend to categorize/name everything. I'm dumb.
Hi, I'm the primary Redux maintainer. I'd love to see some examples of what got generated! (Doubt there's anything we could do to _influence_ this, but curious what happened here.)
FWIW we do have our docs on testing approaches here, and have recommended a more integrated-style approach to testing for a while:
Unfortunately I think I cleaned up the code before committing it, so I don't have an exact example! I did actually read that usage page though after looking at those tests, and that helped me in fixing the tests (maybe in retrospect I should have pointed the AI at the docs page first).
I think the main issue I was having with it was reusing the store object instead of creating a new one for each test. The other issue I was seeing was that it was creating mock objects and API's for things that weren't even being tested (lot of scope creep), and one of those API's was basically copy-pasted between two files (code duplication). It was also just testing things that weren't really necessary (ie, testing Redux itself, instead of my usage of it).
Another issue was just taking a complex approach to fixing something that could be more easily solved. For instance, I had debug: true turned on for redux-undo so I was seeing some unnecessary log messages in the test. Codex identified this, and asked if I wanted to disable them, so I said yes. What it did though, was instead of setting debug: false, or disabling it on tests, it patched console.log to look for redux-undo prefixes. Technically worked, but kind of byzantine!
None of this was a terrible disaster or anything, especially since I started pretty small, but I think what made me miss some of the issues at first glance is this is my first usage of Redux in a non-toy project so while I understand the fundamentals fine, it was easy to sneak working-but-bad stuff past me until I sat down with the code to write a test on my own and started to see the issues.
The equivalent of "draw me a dog" -> not a masterpiece!? who would have thought? You need to come up with a testing methodology, write it down, and then ask the model to go through it. It likes to make assumptions on unspecified things, so you got to be careful.
More fundamentally I think testing is becoming the core component we need to think about. We should not vibe-check AI code, we should code-check it. Of course it will write the actual test code, but your main priority is to think about "how do I test this?"
You can only know the value of a code up to the level of its testing. You can't commit your eyes into the repo, so don't do "LGTM" vibe-testing of AI code, it's walking a motorcycle.
Generating code was always cheap. That’s part of the reason this tech has to be forced on teams. Similar to the move to cloud, it’s the kind of cost that’s only gonna show up later - faster than the cloud move, I think. Though, in some cases it will be the correct choice.
ATM I feel like LLM writing tests can be a bit dangerous at times, there are cases where it's fine there are cases where it's not. I don't really think I could articulate a systemised basis for identifying either case, but I know it when I see it I guess.
Like the the other day, I gave it a bunch of use cases to write tests for, the use cases were correct the code was not, it saw one of the tests broken so it sought to rewrite the test. You risking suboptimal results when an agent is dictating its own success criteria.
At one point I did try and use seperate Claude instances to write tests, then I'd get the other instance to write the implementation unaware of the tests. But it's a bit to much setup.
I work with individuals who attempt to use LLMs to write tests. More than once, it's added nonsensical, useless test cases. Admittedly, humans do this, too, to a lesser extent.
Additionally, if their code has broken existing tests, it "fixes" them by not fixing the code under test, but changing the tests... (assert status == 200 becomes 500 and deleting code.)
Tests "pass." PR is opened. Reviewers wade through slop...
The most annoying thing is that even after cleaning up all the nonsense, the tests still contain all sort of fanfare and it’s essentially impossible to get the submitter to trim them because it’s death by a thousand cuts (and you better not say "do it as if you didn’t use AI" in the current climate..)
Yep. We've had to throw PRs away and ask them to start over with a smaller set of changes since it became impossible to manage. Reviews went on for weeks. The individual couldn't justify why things were done (and apparently their AI couldn't, either!)
Luckily those I work with are smart enough that I've not seen a PR thrown away yet, but sometimes I'm approving with more "meh, it's fine I guess" than "yeah, that makes sense".
This is how you do things if you are new to this game.
Get two other, different, LLMs to thoroughly review the code. If you don’t have an automated way to do all of this, you will struggle and eventually put yourself out of a job.
If you do use this approach, you will get code that is better than what most software devs put out. And that gives you a good base to work with if you need to add polish to it.
I actually have used other LLMs to review the code, in the past (not today, but in the past). It's fine, but it doesn't tend to catch things like "this technically works but it's loading a footgun." For example, the redux test I was mentioning in my original post, the tests were reusing a single global store variable. It technically worked, the tests ran, and since these were the first tests I introduced in the code base there weren't any issues even though this made the tests non deterministic... but, it was a pattern that was easily going to break down the line.
To me, the solution isn't "more AI", it's "how do I use AI in a way that doesn't screw me over a few weeks/months down the line", and for me that's by making sure I understand the code it generated and trim out the things that are bad/excessive. If it's generating things I don't understand, then I need to understand them, because I have to debug it at some point.
Also, in this case it was just some unit tests, so who cares, but if this was a service that was publicly exposed on the web? I would definitely want to make sure I had a human in the loop for anything security related, and I would ABSOLUTELY want to make sure I understood it if it were handling user data.
The quality of generated code does not matter. The problem is when it breaks 2 AM and you're burning thousands of dollars every minutes. You don't own the code that you don't understand, but unfortunately that does not mean you don't own the responsibility as well. Good luck on writing the postmortem, your boss will have lots of question for you.
AI can help you understand code faster than without AI. It allows me to investigate problems that I have little context in and be able to write fixes effectively.
> If you do use this approach, you will get code that is better than what most software devs put out. And that gives you a good base to work with if you need to add polish to it.
If you do use this approach, you'll find that it will descend into a recursive madness. Due to the way these models are trained, they are never going to look at the output of two other models and go "Yeah, this is fine as it is; don't change a thing".
Before you know it you're going to have change amplification, where a tiny change by one model triggers other models (or even itself) to make other changes, which triggers further changes, etc ad nauseum.
The easy part is getting the models to spit out working code. The hard part is getting it to stop.
I've never done this because i haven't felt compelled to do this because I want to review my own code but I imagine this works okay and isn't hard to set up by asking Claude to set this up for you...
What? People do this all the time. Sometimes manually by invoking another agent with a different model and asking it to review the changes against the original spec. I just setup some reviewer / verifier sub agents in Cursor that I can invoke with a slash command. I use Opus 4.5 as my daily driver, but I have reviewer subagents running Gemini 3 Pro and GPT-5.2-codex and they each review the plan as well, and then the final implementation against the plan. Both sometimes identify issues, and Opus then integrates that feedback.
It’s not perfect so I still review the code myself, but it helps decrease the number of defects I have to then have the AI correct.
The setup is much simpler than you might think. I have 4 CLI tools I use for this setup. Claude Code, Codex, Copilot and Cursor CLI. I asked Claude Code to create a code reviewer "skill" that uses the other 3 CLI tools to review changes in detail and provide feedback. I then ask Claude Code to use this skill to review any changes in code or even review plan documents. It is very very effective. Is it perfect? No. Nothing is. But, as I stated before, this produces results that are better than what an average developer sends in for PR review. Far far better in my own experience.
In addition to that, we do use CodeRabbit plugin on GitHub to perform a 4th code review. And we tell all of our agents to not get into gold-plating mode.
You can choose not to use modern tools like these to write software. You can also choose to write software in binary.
these two posts (the parent and then the OP) seem equally empty?
by level of compute spend, it might look like:
- ask an LLM in the same query/thread to write code AND tests (not good)
- ask the LLM in different threads (meh)
- ask the LLM in a separate thread to critique said tests (too brittle, testing guidelines, testing implementation and not out behavior, etc). fix those. (decent)
- ask the LLM to spawn multiple agents to review the code and tests. Fix those. Spawn agents to critique again. Fix again.
- Do the same as above, but spawn agents from different families (so Claude calls Gemini and Codex).
—-
these are usually set up as /slash commands like /tests or /review so you aren’t doing this manually. since this can take some time, people might work on multiple features at once.
I think if your job is to assemble a segment of a car based on a spec using provided tools and pre-trained processes, it makes sense if you worry that giant robot arms might be installed to replace you.
But if your job is to assemble a car in order to explore what modifications to make to the design, experiment with a single prototype, and determine how to program those robot arms, you’re probably not thinking about the risk of being automated.
I know a lot of counter arguments are a form of, “but AI is automating that second class of job!” But I just really haven’t seen that at all. What I have seen is a misclassification of the former as the latter.
A software engineer with an LLM is still infinitely more powerful than a commoner with an LLM. The engineer can debug, guide, change approaches, and give very specific instructions if they know what needs to be done.
The commoner can only hammer the prompt repeatedly with "this doesn't work can you fix it".
So yes, our jobs are changing rapidly, but this doesn't strike me as being obsolete any time soon.
This is actually a great way to foster the learning spirit in the age of AI. Even if the student uses AI to arrive at an answer, they will still need to, at the very least, ask the AI to give it an explanation that will teach them how it arrived to the solution.
No this is not the way we want learning to be - just like how students are banned from using calculators until they have mastered the foundational thinking.
That's a fair point, but AI can do much more than just provide you with an answer like a calculator.
AI can explain the underlying process of manual computation and help you learn it. You can ask it questions when you're confused, and it will keep explaining no matter how off the topic you go.
We don't consider tutoring bad for learning - quite the contrary, we tutor slower students to help them catch up, and advanced students to help them fulfill their potential.
If we use AI as if it was an automated, tireless tutor, it may change learning for the better. Not like it was anywhere near great as it was.
There is research that shows that banning calculators impedes the learning of maths. It is certainly not obvious to me that calculators will have a negative effect - I certainly always allowed my kids to use them.
LLMs are trickier and use needs to be restricted to stop cheating, just as my kids had restrictions on what calculators they could use in some exams. That does not mean they are all bad or even net bad if used correctly.
> There is research that shows that banning calculators impedes the learning of maths.
I've seen oodles of research concluding the opposite at the primary level (grades 1- 5, say). If your mentioned research exists, it must be very well hidden :-/
> Do calculators threaten basic skills? The answer consistently seemed to be no, provided those basic skills have first been developed with paper and pencil.
So, yeah, there are no studies I have found that support any assertion along the lines of:
>>> There is research that shows that banning calculators impedes the learning of maths.
If you actually find any, we still have to consider that things like this meta-study you posted is already 74-studies ahead in confirming that you are wrong.
Best would be for you to find 75 studies that confirm your hypothesis. Unfortunately, even though I read studies all the time, and even at one point had full access via institutional license to full-text of studies, and spent almost all of my after-hours time between 2009 and 2011 actually reading papers on primary/foundational education, I have not seen even one that supports your assertion.
I have read well over a hundred papers on the subject, and did not find one. I am skeptical that you will find any.
> There is research that shows that banning calculators impedes the learning of maths.
Please share what you know. My search found a heap of opinions and just one study where use of calculators made children less able to calculate by themselves, not the ability to learn and understand math in general.
Yeah; it gets steps 1-3 right, 4-6 obviously wrong, and then 7-9 subtly wrong such that a student, who needs it step by step while learning, can't tell.
That's roughly what we did as well. Use anything you want, but in the end you have to be able to explain the process and the projects are harder than before.
If we can do more now in a shorter time then let's teach people to get proficient at it, not arbitrarily limit them in ways they won't be when doing their job later.
Props to the teacher for putting in the work to thoughtfully grade an AI transcript! As I typed that I wondered if a lazy teacher might then use AI to grade the students AI transcript?
I think it's a bit like the Dunning-Kruger effect. You need to know what you're even asking for and how to ask for it. And you need to know how to evaluate if you've got it.
This actually reminds me so strongly of the Pakleds from Star Trek TNG. They knew they wanted to be strong and fast, but the best they could do is say, "make us strong." They had no ability to evaluate that their AI (sorry, Geordi) was giving them something that looked strong, but simply wasn't.
Yep, I've seen a couple of folks pretending to be junior PMs, thinking they can replace developers entirely. The problem is, they can't write a spec. They can define a feature at a very high level, on a good day. They resort to asking one AI to write them a spec that they feed to another.
People have tried that with everything from COBOL to low code. Its even succeeded in some problem domains (e.g. thing people code with spreadsheet formula) but there is no general solution that replaces programmers entirely.
That was literally the opposite of my intention. Maybe the choice of word wasn't perfect, but basically, I was trying to highlight that domain expertise is still valuable in the specific scenario of software engineering.
The same could be said about any other job, if you put me against a construction worker and give us both expensive power tools, he will still do a better job than me because I have no experience in that domain.
My job is to make people who have money think I'm indispensable to achieving their goals. There's a good chance AI can fake this well enough to replace me. Faking it would be good enough in an economy with low levels of competition; everyone can judge for themselves if this is our economy or not.
I don’t think this is the issue “yet”. It’s that no matter what class you are, your CEO does not care. Mediocre AI work is enough to give them immense returns and an exit. He’s not looking out for the unfortunate bag holders. The world has always had tolerance for highly distributed crap. See Windows.
This seems like a purely cynical lacking any substantive analysis.
Despite whatever nasty business practices and shitty UX Windows has foisted on the world, there is no denying the tremendous value that it has brought, including impressive backwards compatibility that rivals some of the best platforms in computing history.
AI shovelware pump-n-dump is an entirely different short term game that will never get anywhere near Microsoft levels of success. It's more like the fly-by-nights in the dotcom bubble that crashed and burned without having achieved anything except a large investment.
You misunderstand me. While I left Windows over a decade ago, I recognize it was a great OS in some aspects. I was referring to the recent AI fueled Windows developments and Ad riddled experiences. Someone decided that is fine, and you won't see orgs or regular users drop it...tolerance.
This is actually a really good description of the situation. But I will say, as someone that prided myself on being the second one you described, I am becoming very concerned about how much of my work was misclassified. It does feel like a lot of work I did in the second class is being automated where maybe previously it overinflated my ego.
SWE is more like formula 1 where each race presents a unique combination of track, car, driver, conditions. You may have tools to build the thing, but designing the thing is the main issue. Code editor, linter, test runner, build tools are for building the thing. Understanding the requirements and the technical challenges is designing the thing.
The other day I said something along the lines of, "be interested in the class, not the instance" and I meant to try to articulate a sense of metaprogramming and metaanalysis of a problem.
Y is causing Z and we should fix that. But if we stop and study the problem, we might discover that X causes the class of Y problem so we can fix the entire class, not just the instance. And perhaps W causes the class of X issue. I find my job more and more being about how far up this causality tree can I reason, how confident am I about my findings, and how far up does it make business sense to address right now, later, or ever?
is it? I really fail to see the metaphor as an F1 fan. The cars do not change that much; only the setup does, based on track and conditions. The drivers are fairly consistent through the season. Once a car is built and a pecking order is established in the season, it is pretty unrealistic to expect a team with a slower car to outcompete a team with a faster car, no matter what track it is (since the conditions affect everyone equally).
Over the last 16 years, Red Bull has won 8 times, Mercedes 7 times and Mclaren 1. Which means, regardless of the change in tracks and conditions, the winners are usually the same.
So either every other team sucks at "understanding the requirements and the technical challenges" on a clinical basis or the metaphor doesn't make a lot of sense.
Most projects don’t change that much either. Head over to a big open source project, and more often you will only see tweaks. To be able to do the tweaks require a very good understanding of the whole project (Naur’s theory of programming).
Also in software, we can do big refactors. F1 teams are restricted to the version they’ve put in the first race. But we do have a lot of projects that were designed well enough that they’ve never changed the initial version, just build on top of it.
I wonder about how true this was historically. I imagine race car driving had periods of rapid, exciting innovation. But I can see how a lot of it has probably reached levels of optimization where the rules, safety, and technology change well within the realm of diminishing returns. I'm sure there's still a ridiculous about of R&D though? (I don't really know race car driving)
Sure there is crazy levels of R&D but that mostly happens off season or if there is a change in regulations which happen every 4-5 years usually. Interestingly, this year the entire grid starts with new regs and we don't really know the pecking order yet.
But my whole point was that race to race, it really isn't that much different for the teams as the comment implied and I am still kind of lost how it fits to SWE unless you're really stretching things.
Even then, most teams dont even make their own engines etc.
Do you really think that rainy Canada is the same as Jedddah, or Singapore? And what is the purpose of the free practice sessions?
You’ve got the big bet to design the car between the season (which is kinda the big architectural decisions you make at the beginning of the project). Then you got the refinement over the season, which are like bug fixings and performance tweaks. There’s the parts upgrade, which are like small features added on top of the initial software.
For the next season, you either improve on the design or start from scratch depending on what you’ve learned. In the first case, It is the new version of the software. In the second, that’s the big refactor.
I remember that the reserve drivers may do a lot of simulations to provide data to the engineers.
You are describing tradition (deterministic?) automation before AI. With AI systems as general as today's SOTA LLMs, they'll happily take on the job regardless of the task falling into class I or class II.
Ask a robot arm "how should we improve our car design this year", it'll certainly get stuck. Ask an AI, it'll give you a real opinion that's at least on par with a human's opinion. If a company builds enough tooling to complete the "AI comes up with idea -> AI designs prototype -> AI robot physically builds the car -> AI robot test drives the car -> AI evaluates all prototypes and confirms next year's design" feedback loop, then theoretically this definitely can work.
This is why AI is seen as such a big deal - it's fundamentally different from all previous technologies. To an AI, there is no line that would distinguish class I from II.
> I know a lot of counter arguments are a form of, “but AI is automating that second class of job!”
Uh, it's not the issue. The issue is that there isn't that much demand for the second class of job. At least not yet. The first class of job is what feeds billions of families.
Discussing what we should do about the automation of labour is nothing new and is certainly a pretty big deal here. But I think you're reframing/redirecting the intended topic of conversation by suggesting that "X isn't the issue, Y is."
It wanders off the path like if I responded with, "that's also not the issue. The issue is that people need jobs to eat."
I see a lot of the same (well thought out) pushback on here whenever these kinds of blind hype articles pop up.
But my biggest objection to this "engineering is over" take is one that I don't see much. Maybe this is just my Big Tech glasses, but I feel like for a large, mature product, if you break down the time and effort required to bring a change to production, the actual writing of code is like... ten, maybe twenty percent of it?
Sure, you can bring "agents" to bear on other parts of the process to some degree or another. But their value to the design and specification process, or to live experiment, analysis, and iteration, is just dramatically less than in the coding process (which is already overstated). And that's without even getting into communication and coordination across the company, which is typically the real limiting factor, and in which heavy LLM usage almost exclusively makes things worse.
Takes like this seem to just have a completely different understanding of what "software development" even means than I do, and I'm not sure how to reconcile it.
To be clear, I think these tools absolutely have a place, and I use them where appropriate and often get value out of them. They're part of the field for good, no question. But this take that it's a replacement for engineering, rather than an engineering power tool, consistently feels like it's coming from a perspective that has never worked on supporting a real product with real users.
I'm not sure you're actually in disagreement with the author of this piece at all.
They didn't say that software engineering is over - they said:
> Software development, as it has been done for decades, is over.
You argue that writing code is 10-20% of the craft. That's the point they are making too! They're framing the rest of it as the "talking", which is now even more important than it was before thanks to the writing-the-code bit being so much cheaper.
When we say generating code is only a small percentage, that does not imply that the rest is just talking. Simon, you were part of a relatively small fast moving project in Django and the news website it powered, with from I understand a pretty small team. Have you worked as part of a team of 10, 20, 100, 1000 engineers? It's different.
"Talking" here doesn't literally mean talking. It means figuring out the scope of the problem, researching solutions, communicating with stakeholders, debating architecture, building exploratory prototypes, breaking down projects - it's all the stuff that isn't writing the code.
I've worked at various sizes of organization. Most notably I joined Eventbrite when they were less than 100 developers and stayed while they grew to around 1,000.
> Software development, as it has been done for decades, is over.
Simon I guess vb-8558's comment inn here is something which is really nice (definitely worth a read) and they mention how much coding has changed from say 1995 to 2005 to 2015 to 2025
Directly copying line from their comment here : For sure, we are going through some big changes, but there is no "as it has been done for decades".
My (point?) is that this pure mentality of code is cheap show me the talk is weird/net negative (even if I may talk more than I code) simply because code and coding practices are something that I can learn over my experience and hone in whereas talk itself constitutes to me as non engineers trying to create software and that's all great but not really understanding the limitations (that still exist)
So the point I am trying to make is that I feel as if when the OP mentioned code is 10-20% of the craft, they didn't mean the rest is talk. They meant all the rest are architectural decisions & just everything surrounding the code. Quite frankly, the idea behind Ai/LLM's is to automate that too and convert it into pure text and I feel like the average layman significantly overestimates what AI can and cannot do.
So the whole notion of show me the talk atleast in a more non engineering background as more people try might be net negative not really understanding the tech as is and quite frankly even engineers are having a hard time catching up with all which is happening.
I do feel like that the AI industry just has too many words floating right now. To be honest, I don't want to talk right now, let me use the tool and see how it goes and have a moment of silence. The whole industry is moving faster than the days till average js framework days.
To have a catchy end to my comment: There is just too much talk nowadays. Show me the trust.
I do feel like information has become saturated and we are transitioning from the "information" age to "trust" age. Human connections between businesses and elsewhere matter the most right now more than ever. I wish to support projects which are sustainable and fair driven by passion & then I might be okay with AI use case imo.
Yeah in a lot of ways, my assertion is that @
“Code is cheap” actually means the opposite of what everyone thinks it does. Software Engineer is even more about the practices we’ve been developing over the past 20 or so years, not less
Like Linus’ observation still stands. Show me that the code you provided does exactly what you think it should. It’s easy to prompt a few lines into an LLM, it’s another thing to know exactly the way to safely and effectively change low level code.
Liz Fong-Jones told a story on LinkedIn about this at HoneyComb, she got called out for dropping a bad set of PR’s in a repo, because she didn’t really think about the way the change was presented.
> Takes like this seem to just have a completely different understanding of what "software development" even means than I do, and I'm not sure how to reconcile it.
You're absolutely right about coding being less than 20% of the overall effort. In my experience, 10% is closer to the median. This will get reconciled as companies apply LLMs and track the ROI. Over a single year the argument can be made that "We're still learning how to leverage it." Over multiple years the 100x increase in productivity claims will be busted.
We're still on the upslope of Gartner's hype cycle. I'm curious to see how rapidly we descend into the Trough of Disillusionment.
My recent experience demonstrates this. I had a couple weeks of happily cranking out new code and refactors at high speed with Claude’s help, then a week of what felt like total stagnation, and now I’m back to high velocity again.
What happened in the middle was I didn’t know what I wanted. I hadn’t worked out the right data model for the application yet, so I couldn’t tell Claude what to do. And if you tell it to go ahead and write more code at that point, very bad things will start to happen.
Ive been using LLMs through the web to help with discreet pieces of code and scripts for a while now. I’ve been putting it off (out of fear?) but I finally sat down with Claude Code on the console and an empty directory to see what the fuss was about. Over about a total of 4 hrs and maybe $15 pay as you go it became clear things are drastically different now in web dev. I’m not saying changed for good or bad just things have definitely changed and will never go back.
The book Software Engineering at Google makes a distinction between software engineering and programming. The main difference is that software engineering occurs over a longer time span than programming. In this sense, AI tools can make programming faster, but not necessarily software engineering.
Just because a bunch of people tell you the practice of performing the art form of producing software via handwriting code is over doesn't mean it's over. This form of hyperbole is intended to overwhelm your reason, get you to forget your own expertise, and trick you into engaging with the topic in a fearful manner (literally FOMO). Don't fall for this cheap stunt.
There will always be a niche for any form of expression. However technologies change practice. It is your responsibility to be able to solve problems that balance performance, cost, schedule, and quality. Use the right tool for the job.
> crystal clear software development plan and the exact know-how to implement it
This is simply not how expert programmers work. Programming is planning, and programming languages are surprisingly good planning tools. But, of course, becoming an expert is hard and requires not only some general aptitude but also substantial time, experience and effort.
My theory is that this is a source of diverging views on LLMs for programming: people who see programming languages as tools for thought compared to people who see programming languages as, exclusively, tools to make computers do stuff. It's no surprise that the former would see more value in programming qua programming, while the latter are happy to sweep code under the rug.
The fundamental problem, of course, is that anything worth doing in code is going to involve pinning down a massive amount of small details. Programming languages are formal systems with nice (well, somewhat nice) UX, and formal systems are great for, well, specifying details. Human text is not.
Then again, while there might be a lot of details, there are also a lot of applications where the details barely matter. So why not let a black box make all the little decisions?
The question boils down to where you want to spend more energy: developing and articulating a good conceptual model up-front, or debugging a messy system later on. And here, too, I've found programmers fall into two distinct camps, probably for the same reasons they differ in their views on LLMs.
In principle, LLM capabilities could be reasonably well-suited to the up-front thinking-oriented programming paradigm. But, in practice, none of the tools or approaches popular today—certainly none of the ones I'm familiar with—are oriented in that direction. We have a real tooling gap.
> My theory is that this is a source of diverging views on LLMs for programming: people who see programming languages as tools for thought compared to people who see programming languages as, exclusively, tools to make computers do stuff. It's no surprise that the former would see more value in programming qua programming, while the latter are happy to sweep code under the rug.
i'd postulate this: most people see llms as tools for thought. programmers also see llms as tools for programming. some programmers, right now, are getting very good at both, and are binding the two together.
Most people? I'd suggest few people see LLMs as tools for thought and more that they're slop machines being cynically forced upon workers by capitalists with dollar signs in their eyes. Over and over and over again we see real-world studies showing that the people far more excited about genAI are managers than the people doing the actual work.
The original phrase "talk is cheap" is generally used to mean "it's easy to say a whole lot of shit and that talk often has no real value." So this cleaver headline is telling me the code has even less value than the talk. That alone betrays a level of ignorance I would expect from the author's work. I go to read the article and it confirmed my suspicion.
I think you are hyper-focusing on the headline, which is just a joke. The underlying article does not indicate to me that the author is ignorant of code, and if you care to look, they seem to have a substantial body of public open source contributions that proves this quite conclusively.
The underlying point is just that while it was very cognitively expensive to back up a good design with good code back in 2000, it's much cheaper now. And therefore, making sure the design is good is the more important part. That's it really.
And… the design (artistry) aspect is always the toughest. So explain to me, where do the returns come from if it is seemingly obviously only those who are very well informed of their domains/possess general intelligence can benefit from this tool?
Personally I don’t see it happening. This is the bitter reality the LLM producers have to face at some point.
> So explain to me, where do the returns come from if it is seemingly obviously only those who are very well informed of their domains/possess general intelligence can benefit from this tool?
I...don't think this is true at all. "The design of the car is more important than what specific material you use" does not mean that the material is unimportant", just that it is relatively* less important. To put a fake number on it, maybe 10% less important.
I think people who have domain knowledge and good coding skills will probably benefit the most from this LLM producer stuff.
> One can no longer know whether such a repository was “vibe” coded by a non-technical person who has never written a single line of code, or an experienced developer, who may or may not have used LLM assistance.
I am talking about what it means to invert that phrase.
Yes, the original phrase has a specific meaning. But in another context, "talk" is more important than the code.
In software development, code is in a real sense less important than the understanding and models that developers carry around in their heads. The code is, to use an unflattering metaphor, a kind of excrement of the process. It means nothing without a human interpreter, even if it has operational value. The model is never part of the implementation, because software apart from human observers is a purely syntactic construct, at best (even there, I would argue it isn't even that, as syntax belongs to the mind/language).
> Software development, as it has been done for decades, is over.
I'm pretty sure the way I was doing things in 2005 was completely different compared to 2015. Same for 2015 and 2025. I'm not old enough to know how they were doing things in 1995, but I'm pretty sure there very different compared to 2005.
For sure, we are going through some big changes, but there is no "as it has been done for decades".
I don't think things have changed that much in the time I've been doing it (roughly 20 years). Tools have evolved and new things were added but the core workflow of a developer has more or less stayed the same.
I also wonder what those people have been doing all this time... I also have been mostly working as a developer for about 20 years and I don't think much has changed at all.
I also don't feel less productive or lacking in anything compared to the newer developers I know (including some LLM users) so I don't think I am obsolete either.
At some point I could straight-up call functions from the Visual Studio debugger Watch window instead of editing and recompiling. That was pretty sick.
Yes I know, Lisp could do this the whole time. Feel free to offer me a Lisp job drive-by Lisp person.
Isn’t there a whole ton of memes about the increase in complexity and full stack everything and having to take in devops, like nothing has changed at all?
I don't think that's true, at least for everywhere I've worked.
Agile has completely changed things, for better or for worse.
Being a SWE today is nothing like 30 years ago, for me. I much preferred the earlier days as well, as it felt far more engineered and considered as opposed to much of the MVP 'productivity' of today.
MVP is not necessarily opposed to engineered and considered. It's just that many people who throw that term around have little regard for engineering, which they hide behind buzzwords like "agile".
Yeah, I remember being amazed at the immediate incremental compilation on save in Visual Age for Java many years ago. Today's neovim users have features that even the most advanced IDEs didn't have back then.
I think a lot of people in the industry forget just how much change has come from 30 years of incremental progress.
talk is even cheaper, still show me the code, people claim 10x productivity that translates to 10x of work done in a month, even with Opus 4.5 out since November 2025 I haven't seen signs of this. AI makes the level of complexity with modern systems bearable, it was getting pretty bad before and AI kinda saved us. A non-trivial React app is still a pain to write. Also creating a harness for a non-deterministic api that AI provides is also pain. At least we don't have to fight through typing errors or search through relevant examples before copying and pasting. AI is good at automating typing, the lack of reasoning and the knowledge cutoff still makes coding very tedious though.
Best example of this is Claude's own terminal program. Apparently renders react at 60fps and then translates it into ANSI chars that then diff the content of the terminal and do an overwrite...
All to basically mimic what curses can do very easily.
This is the fun part of whole AI-built things that a lot of people don’t want to accept - it really, really, really does not matter if the code “nice, maintainable and etc.”. Does it work? Is it somewhat extendable with AI? Are users generally happy and adoption rate is high? That’s it.
If you have high time preference yes. Over longer time horizons I think the issues with vibe coded software will reveal themselves in the same way badly written software does.
Remember 8 years ago how vibe coding was awful? Like i never used it in prod apps. Now i'm a daily CC user, and every few months models are getting better, some problems are being solved, the other ones still being worked on and so on.
This "Code is cheap. Show me the talk." punchline gets overused as a bait these days. It is an alright article but that's a lot of words to tell us something we already know. There's nothing here that we don't already know. It's not just greedy companies riding the AI wave. Bloggers and influencers are also riding the AI wave. They know if you say anything positive or negative about AI with a catchy title it will trend on HN, Reddit, etc.
Also credit where credit is due. Origin of this punchline:
In January 2026, prototype code is cheap. Shitty production code is cheap. If that's all you need—which is sometimes the case—then go for it.
But actually good code, with a consistent global model for what is going on, still won't come from Opus 4.5 or a Markdown plan. It still comes from a human fighting entropy.
Getting eyes on the code still matters, whether it's plain old AI slop, or fancy new Opus 4.5 "premium slop." Opus is quite smart, and it does its best.
But I've tried seriously using a number of high-profile, vibe-coded projects in the last few weeks. And good grief what unbelievable piles of shit most of them are. I spend 5% of the time using the vibe-coded tool, and 95% of the time trying to uncorrupt my data. I spend plenty of time having Opus try to look at the source to figure out what went wrong in 200,000 lines of vibe-coded Go. And even Opus is like, "This never worked! It's broken! You see, there's a race condition in the daemonization code that causes the daemon to auto-kill itself!"
And at that point, I stop caring. If someone can't be bothered to even read the code Opus generates, I can't be bothered to debug their awful software.
> Ignoring outright bad code, in a world where functional code is so abundant that “good” and “bad” are indistinguishable, ultimately, what makes functional AI code slop or non-slop?
I'm sorry, but this is an indicator for me that the author hasn't had a critical eye for quality in some time. There is massive overlap between "bad" and "functional." More than ever. The barrier-to-entry to programming got irresponsibly low for a time there, and it's going to get worse. The toolchains are not in a good way. Windows and macOS are degrading both in performance and usability, LLVM still takes 90% of a compiler's CPU time in unoptimized builds, Notepad has AI (and crashes,) simple social (mobile) apps are >300 MB download/installs when eight years ago they were hovering around a tenth of that, a site like Reddit only works on hardware which is only "cheap" in the top 3 GDP nations in the world... The list goes on. Whatever we're doing, it is not scaling.
I'd think there'll be a dip in code quality (compared to human) initially due to "AI machinery" due to its immaturity. But over-time on a mass-scale - we are going to see an improvement in the quality of software artifacts.
It is easier to 'discipline' the top 5 AI agents in the planet - rather than try to get a million distributed devs ("artisans") to produce high quality results.
It's like in the clothing or manufacturing industry I think. Artisans were able to produce better individual results than the average industry machinery, at least initially. But overtime - industry machinery could match the average artisan or even beat the average, while decisively beating in scale, speed, energy efficiency and so on.
The issue is that code isn't clothing. It's the clothing factory. We aren't artisans sewing clothing. We're production engineers deciding on layouts for robots to make clothes most efficiently.
I see this type error of thinking all the time. Engineers don't make objects of type A, we make functions of type A -> B or higher order.
Go concrete. In FAANG engineering jobs now what % is this factory designer category vs what % is writing some mundane glue code, moving data around in CRUD calls, or putting in a monitoring metric etc?
Once you look at the present engineering org compositions see what's the error in thinking.
There are other analogy issues in your response which I won't nitpick
> industry machinery could match the average artisan or even beat the average
Whether it could is distinct from whether it will. I'm sure you've noticed the decline in the quality of clothing. Markets a mercurial and subject to manipulation through hype (fast fashion is just a marketing scheme to generate revenue, but people bought into the lie).
With code, you have a complicating factor, namely, that LLMs are now consuming their own shit. As LLM use increases, the percentage of code that is generated vs. written by people will increase. That risks creating an echo chamber of sorts.
I don't agree with the limited point about fast fashion/enthittification, etc.
Quick check: Do you want to go back to pre-industrial era then - when according to you, you had better options for clothing?
Personally, I wouldn't want that - because I believe as a customer, I am better served now (cost/benefit wise) than then.
As to the point about recursive quality decline - I don't take it seriously, I believe in human ingenuity, and believe humans will overcome these obstacles and over time deliver higher quality results at bigger scale/lower costs/faster time cycles.
> Quick check: Do you want to go back to pre-industrial era then - when according to you, you had better options for clothing?
This does not follow. Fast fashion as described is historically recent. An an example, I have a cheap t-shift from the mid-90s that is in excellent condition after three decades of use. Now, I buy a t-shirt in the same price range, and it begins to fall apart in less than a year. This decline in the quality of clothing is well known and documented, and it is incredibly wasteful.
The point is that this development is the product of consumerist cultural presuppositions that construct a particular valuation that encourages such behavior, especially one that fetishizes novelty for its own sake. In the absence of such a valuation, industry would take a different direction and behave differently. Companies, of course, promote fast fashion, because it means higher sales.
Things are not guaranteed to become better. This is the fallacy of progress, the notion that the state of the world at t+1 must be better than it was at t. At the very least, it demands an account of what constitutes "better".
> I don't take it seriously, I believe in human ingenuity, and believe humans will overcome these obstacles
That's great, but that's not an argument, only a sentiment.
I also didn't say we'll experience necessarily a decline, only that LLMs are now trained on data produced by human beings. That means the substance and content is entirely derived from patterns produced by us, hence the appearance of intelligence in the results it produces. LLMs merely operate over statistical distributions in that data. If LLMs reduce the amount of content made by human beings, then training on the generated data is circular. "Ingenuity" cannot squeeze blood out of a stone. Something cannot come from nothing. I didn't say there can't be this something, but there does need to be a something from which an LLM or whatever can benefit.
> it is easier to 'discipline' the top 5 AI agents in the planet - rather than try to get a million distributed devs ("artisans") to produce high quality results.
Your take essentially is "let's live in a shoe box, packaging pipelines produce them cheaply en masse, who needs slow poke construction engineers and architects anymore"
Where have I said engineers/architects aren't necessary? My point is that it is easier to get AI to get better than try to improve a million developers. Isn't that a straightforward point?
What the role of an engineer in the new context - I am not speculating on.
> My point is that it is easier to get AI to get better than try to improve a million developers.
No it's not, your whole premise is invalid both in terms of financing the effort and in the AI's ability to improve beyond RNG+parroting. The AI code agents produce shoe boxes, your claim is that they can be improved to produce buildings instead. It won't happen, not until you get rid of the "temperature" (newspeak for RNG) and replace it with conceptual cognition.
Artisanal clothing is functionally equivalent to mass-produced clothing, but more expensive.
Much of contemporary software is functionally equivalent but more expensive to run and produce than previous generations. Chat, project management, document editing, online stores… all seem to have gotten more expensive to produce and run with little to no gain in functionality.
Complexity in software production and tooling keeps increasing yet functionally software is more or less the same as 20 years ago (obv. excluding advancements depending on hardware like video, 3D rendering, LLMs, etc.
Except I am not talking about clothing. You are guessing when you say "I'd think" based on your comparison to manufacturing clothing. Why guess and compare when you have more context than that? You're in this industry, right? The commodity of clothing is not like the commodity of software at all. Almost nothing is, as it doesn't really have a physical form. That impacts the economics significantly.
To highlight the gaps in your analogy; machinery still fails to match artisan clothing-makers. Despite being relatively fit, I've got wide hips. I cannot buy denim jeans that both; fit my legs, _and_ my waist. I either roll the legs up or have them hemmed. I am not all that odd, either. One size cannot fit all.
One issue is that tooling and internals have been optimized for individual people's tastes currently. Heterogeneous environments make the models spikier. As we shift to building more homogenized systems optimized around agent accessibility, I think we'll see significant improvements
Elegantly, agents finally give us an objective measure of what "good" code is. It's code that maximizes the likelihood that future agents will be able to successfully solve problems in this codebase. If code is "bad" it makes future problems harder.
> Elegantly, agents finally give us an objective measure of what "good" code is. It's code that maximizes the likelihood that future agents will be able to successfully solve problems in this codebase. If code is "bad" it makes future problems harder.
An analogous argument was made in the 90's to advocate for the rising desire for IDEs and OOP languages. "Bad" code came to be seen as 1000+ lines in one file because you could simply conjure up the documentation out-of-context, and so separation of concerns slipped all the way from "one function one purpose" to something not far from "one function one file."
I don't say this as pure refusal, but to beg the question of what we lose when we make these values-changes. At this time, we do not know. We are meekly accepting a new mental prosthesis with insufficient foresight of the consequences.
I don't disagree that shit is gonna get weird and not all the changes are good.
Ultimately I think we need to move away from the concept of codebases as they currently exist, towards "databases" of functionality that get composed as needed. Agents are going to make mixing and matching for bespoke purposes such a central paradigm that large monolithic packages don't make as much sense as they used to, just like monolithic apps make less sense in a world where agents programmatically call tools to do most work on computers.
Finally, someone articulates the middle better than I have:
> Thus, the extreme proponents of manic “agentic” vibe coding,[19] and the outright denouncers of LLMs, are both missing the forest for the trees. That there is a pragmatic middle path, where people who have the experience, expertise, competence, and the ability to articulate can use these tools to get the outcomes they desire with the right sets of trade-offs.
LLMs are tools. They are not gods to replace man, nor are they exclusively means of harm. It is entirely possible to denounce the blatant attempt of rent extraction in the form of OpenAI, Google Gemini, Microsoft CoPilot, Anthropic, and others, while still running Qwen and Ministral and their like on local hardware. You can, in fact, have it “both ways”.
As fun as it is to poke at cloud services to see their new features and advancements, I (in IT terms) personally could never recommend them in any serious enterprise context for the very reason that they’re fundamentally insecure; you will never, ever have full E2EE with these services because it would nullify their ability to evolve, improve, monetize, and exploit.
That said? I can truly be a one dinosaur army in an enterprise now, as a generalist with a modest Mac Mini (or Studio) and a local LLM to fill in edge cases as needed. I can query these local tools for questions on database schemas or build a one-off API integration for me, so I can focus on the substance of work in safeguarding and accelerating the enterprise. I don’t need fleets of specialists unless I’m running a huge conglomerate or have specific needs - and even then, it’s going to be cheaper to retain one or two seniors to direct the larger army of generalists when needed. The landscape has changed, and it’s why I target leadership and management roles accordingly with my sales pitch (“One senior generalist can do the work of three mid-level specialists”).
Don’t get me wrong, I still have immense grievances regarding theft of work, reductions in force, rent extraction, and the seeming attempt at destroying local general compute, but local LLMs as a tool have been in my kit for years, and that’s not going away.
Historically, it would take a reasonably long period of consistent effort and many iterations of refinement for a good developer to produce 10,000 lines of quality code that not only delivered meaningful results, but was easily readable and maintainable. While the number of lines of code is not a measure of code quality—it is often the inverse—a codebase with good quality 10,000 lines of code indicated significant time, effort, focus, patience, expertise, and often, skills like project management that went into it. Human traits.
Now, LLMs can not only one-shot generate that in seconds,
Evidence please. Ascribing many qualities to LLM code that I haven't (personally) seen at that scale. I think if you want to get an 'easily readable and maintainable' codebase of 10k lines with an LLM you need somebody to review its contributions very closely, and it probably isn't going to be generated with a 1 shot prompt.
My perspective is that AI is a multiplier if existing skill (both positive and negative aspects). A bad developer can now produce bad code at 10x the rate and a good developer can produce good code at 10x the rate.
There is a net positive gain on the automated testing side of things but I think a bad developer, even with AI will not be able to out-compete a good 10x developer without AI. The costs of incorrect abstractions is just too high and LLMs don't really help avoid those.
You have to ask the right questions. It's a bit like in Hitchhiker's Guide to the Galaxy... Where a super-intelligent computer took millions of years to calculate the meaning of life as the number 42. The wrong question will always waste computation.
Okay I was writing a comment to simon (and I have elaborated some there but I wanted this to be something catchy to show how I feel and something people might discuss with too)
Both Code and talk are cheap. Show me the trust. Show me how I can trust you. Show me your authenticity. Show me your passion.
Code used to be the sign of authenticity. This is whats changing. You can no longer guarantee that large amounts of code let's say are now authentic, something which previously used to be the case (for the most part)
I have been shouting into the void many times about it but Trust seems to be the most important factor.
Essentially, I am speaking it from a consumer perspective but suppose that you write AI generated code and deploy it. Suppose you talked to AI or around it. Now I can do the same too and create a project sometimes (mostly?) more customizable to my needs for free/very-cheap.
So you have to justify why you are charging me. I do feel like that's only possible if there is something additional added to value. Trust, I trust the decision that you make and personally I trust people/decisions who feel like they take me or my ideas into account. So, essentially not ripping me off while actively helping. I don't know how to explain this but the most thing which I hate is the feeling of getting ripped off. So justifiable sustainable business who is open/transparent about the whole deal and what he gets and I get just gets my respect and my trust and quite frankly, I am not seeing many people do that but hopefully this changes.
I am curious now what you guys of HN think about this & what trust means to you in this (new?) ever-changing world.
Like y'know I feel like everything changes all the time but at the same time nothing changes at the same time too. We are still humans & we will always be humans & we are driven by our human instincts. Perhaps the community I envision is a more tight knit community online not complete mega-sellers.
> because one is hooked on and dependent on the genie, the natural circumstances that otherwise would allow for foundational and fundamental skills and understanding to develop, never arise, to the point of cognitive decline.
After using AI to code, I came to the same conclusion myself. Interns and juniors are fully cooked:
- Companies will replace them with AI, telling seniors to use AI instead of juniors
- As a junior, AI is a click away, so why would you spend sleepless nights painstakingly acquiring those fundamentals?
Their only hope is to use AI to accelerate their own _learning_, not their performance. Performance will come after the learning phase.
If you're young, use AI as a personal TA, don't use it to write the code for you.
as someone who is sort of a medior programmer it is very hard to balance, trying to keep up with the advancements in AI while not shooting myself in the foot by robbing myself of learning experiences
> Code was always a means to an end. Unlike poetry or prose, end users don’t read or care about code.
Yes and no. Code is not art, but software is art.
What is art, then? Not something that's "beautiful", as beauty is of course mostly subjective. Not even something that works well.
I think art is a thing that was made with great care.
It doesn't matter if some piece of software was vibe-coded in part or in full, if it was edited, tested, retried enough times for its maker to consider it "perfect". Trash is something that's done in a careless way.
If you truly love and use what you made, it's likely someone else will. If not, well... why would anyone?
4. To learn (to get better by absorbing how the pros do it).
5. To verify and improve it (code review, pair programming).
6. To grade it (because a student wrote it).
7. To enjoy its beauty.
These are all I can think of right now, and they are ordered from most common to most rare case.
Personally, I have certainly read and re-read SICP code to enjoy its beauty (7), perhaps mixed in with a desire to learn (4) how to write equally beautiful code.
The best definition of art I've read is the one from "What is Art?" by Tolstoy. I haven't read it myself, but came across it in a Van Neistat video recently.
Tolstoy argued that art is essentially the transmission of feeling from the artist to the audience. He claimed that when an artist experiences an emotion and then, through their work, evokes that same emotion in others, that is art.
Code, talk, who cares. Show me the product. If it works and is useful I will incorporate it into my life. Ultimately no one cares how the sausage is made.
Uhh I kinda care? And some people do too? People have given software social permission so far. I have a feeling that it’s about to change. Engineers are thinking too narrowly about the effects of LLM assisted coding. They only see the shiny bits that benefit them.
I keep on wondering how much of the AI embrace is marketing driven. Yes, it can produce value and cut corners. But it seems like self driving by 2016 Musk prediction. Which never happened. With IPO/Stock valuations closely tied to hype, I wonder if we are all witnessing a giant bubble in the making
How much of this is mass financial engineering than real value. Reading a lot of nudges how everyone should have Google or other AI stock in their portfolio/retirement accounts
There's nothing to wonder about. It's obviously marketing.
The whole narrative of "inevitability" is the stock behavior of tech companies who want to push a product onto the public. Why fight the inevitable? All you can do is accept and adapt.
And given how many companies ask vendors whether their product "has AI" without having the slightest inkling of what that even means or whether it even makes sense, as if it were some kind of magical fairy dust - yeah, the stench of hype is thick enough you could cut it with a knife.
Of course, that doesn't mean it lacks all utility.
Maybe we haven't seen much economic value or productivity increase given all the AI hypes. I don't think we can deny the fact that programming has been through a paradigm shift where humans aren't the only ones writing code and the amount of code written by humans I would say is decreasing.
What you are saying may have made sense at the start of 2025 where people were still using github copilot tab auto completes(atleast I did) and was just toying with things like cursor, but unsure.
Things have changed drastically now, engineers with these tools(like claude code) have become unstoppable.
Atleast for me, I have been able to contribute to the codebases i was unfamiliar with, even with different tech stacks. No, I am not talking about generating ai slop, but I have been enabled to write principal engineer level code unlike before.
So i don't agree with the above statement, it's actually generating real value and I have become valuable because of the tools available to me.
To be honest, what you have described only shows lack of process.
I am not talking about vibe coding here, which is totally different and understandable. But I am talking about the professional context where the structure is already in place.
Here is my workflow, if it helps:
1. I have a system level prompt i execute(command/skill) before I start anything which says things like
i) follow SOLID principles
ii) follow TDD
iii) follow these testing principles like, don't test the implementation details etc
and 20 other things
2. I give it the context of what I need to accomplish, and toggle the plan mode ask it follow the above things I have set at system level, and generate me a document to review step by step
3. I review everything, add feedback to the generated plan, prompt again, and finally finalize the plan
4. now that the plan is finalized, I would have a small alignment with co-workers and ask it implement step by step, and then before proceeding with next step, i will tell it to ask me for feedback
each steps code is reviewed and commited, before proceeding to next step
5. once all steps are done, manual testing is done, i do a local review
6. I have a specific skill which reviews everything, and gives me feedback
7. we have human reviewers who will review the code, and coderabbit
8. then we take it to the staging and uat before taking to prod
so see we have not skipped any process of "software engineering", claude code is just an accelrant
but if you are not doing most of the above steps, i see what you are saying would happen by default
I realize many are disappointed (especially by technical churn, star-based-development JS projects on github without technical rigour). I don't trust any claim on the open web if I don't know the technical background of the person making it.
However I think - Nadh, ronacher, the redis bro - these are people who can be trusted. I find Nadh's article (OP) quite balanced.
>> Remember the old adage, “programming is 90% thinking and 10% typing”? It is now, for real.
> Proceeds to write literal books of markdown to get something meaningful
>> It requires no special training, no new language or framework to learn, and has practically no entry barriers—just good old critical thinking and foundational human skills, and competence to run the machinery.
> Wrote a paragraph about how it is important to have serious experience to understand the generated code prior to that
>> For the first time ever, good talk is exponentially more valuable than good code. The ramifications of this are significant and disruptive. This time, it is different.
> This time is different bro I swear, just one more model, just one more scale-up, just one more trillion parameters, bro we’re basically at AGI
Completely disagree that "software development, as it has been done for decades, is over".
AI is a useful tool, agreed - but it will always be reliant upon humans writing code.
Let's take a very simple example to prove my point. Let's say that everybody is now using AI to write code, and someone develops a new programming language with it. Cool! We have a new language now.
What we don't have, however, are any examples of how that programming language is used. Nothing that the AI can learn from.
How well do you think AI is going to handle being able to code in this new language which doesn't appear at all in its training data?
> One can no longer know whether such a repository was “vibe” coded by a non-technical person who has never written a single line of code, or an experienced developer, who may or may not have used LLM assistance
Ok imho this _blog’s_ words looks like stitching of some fancy words. Is this a thing for rich execs to write like this? Doesn't even convey the message easily.
I would like articles like this to have a quick "who" and "what experience" is talking. I can usually tell the conclusions based on experience/skill level regardless, but it would be nice.
Also, that projects page on his website is atrocious; hate to be "that guy" but I don't trust the author's insight since "personal projects" seems to include a lot more than just his work; the first several PRs I looked at where all vibed.
I'm not interested in re-implementations of the same wheel over and over again telling me and people who know how to write real software (have been doing it since I was 12) that we are becoming unnecessary bc you can bully an extremely complex machine built on a base theory of heuristics abstracted out endlessly (perceptually) to re-invent the same specs in slightly different flavors.
> 100% human written, including emdashes. Sigh.
If you can't write without emdashes, maybe you spend too much time with LLMs and not enough time reading and learning on your own. Also people can lie on the Internet, they do it all the time, and if not then I'm doing it right now.
Talk is never cheap. Communicating your thoughts to people without the exact same kind of expertise as you is the most important skill.
This quote is from Torvalds, and I'm quite sure that if he weren't able to write eloquent English no one would know Linux today.
Code is important when it's the best medium to express the essence of your thoughts. Just like a composer cannot express the music in his head with English words.
I don't think Linus is a people person. This is something which he talks about himself in the famous ted-ed video.
I just re-watched the video (currently halfway) & I feel like the point of Linux is something which you are forgetting but it was never intended to grow so much and Linux himself in the video when asked says that he never had a moment where he went like oh this went big.
In fact he talks about when the project was little. On how he had gratitude when the project had 10 people maybe 100 people working on it and then things only grow over a very large time frame (more than 25-30years? maybe now 35 just searched 34)
He talks about how he got other people's idea which he couldn't have thought of things themselves and when he first created the project he just wanted to show off to the world to look at what I did (and he did it mainly for both the end result of the project and programming itself too) and then he got introduced to open source (free software) by his friend and he just decided to have it open source.
My point is it was neither the code nor the talk. Linus is the best person to maintain Linux, why? Because he has been passionate over it for 25 years. I feel like Linux would be just as interested in talking about the code and any improvements now with maybe the same vigour as 34 years ago. He loves his creation & we love Linux too :)
Another small point I wish to add is that if talk was the only thing, then you are missing the point because Linux was created because hurd was getting delayed (so all talks no code)
Linux himself says that if the hurd kernel would've been released earlier, Linux wouldn't have been created.
So all talk no code Hurd project (which from what I hear right now is still a bit limbo as now everyone [rightfully?] uses linux) is what led to creation of linux project.
Everyone who hasn't watched Linus's ted ed should definitely watch it.
If you have a solid test environment that would allow for an agent to check if it is right or wrong, I encourage you to do the experiment.
Put the agent on the wheel and observe it as it tries ruthlessly to pass the test. These days, likely it will manage to pass the tests after 3-5 loops, which I find fascinating.
Close the loop, and try an LLM. You will be surprised.
Feels like this website is yelling at me with its massive text size. Had to drop down to -50% to get it readable.
Classical indicators of good software are still very relevant and valid!
Building something substantial and material (ie not an api wrapper+gui, to-do list) that is undeniably well made, while being faster and easier than it used to be, still takes a _lot_ of work. Even though you don't have to write a line of code, it moves so fast that you are now spending 3.5-4 days of your work week reading code, using the project, running benchmarks and experimental test lanes, reviewing specs and plans, drafting specs, defining features and tests.
The level of granularity needed to get earnestly good results is more than most people are used to. It's directly centered at the intersection between spec heavy engineering work and writing requirements for a large, high quality offshore dev team that is endearingly literal in how they interpret instructions. Depending on the work, I've found that I average around one 'task' per 22-35 lines of code.
You'll discover a new sense of profound respect for the better PMs, QA Leads, Eng Directors you have worked with. Months of progress happen each week. You'll know you're doing it right when you ask an Agent to evaluate the work since last week and it assumes it is reviewing the output of a medium sized business and offers to make Jira tickets.
It might be a mistake to think in terms of production costs.
The real "cost" of software is reliance: what risk do your API clients or customers take in relying on you? This is just as true for free-as-in-beer software as for SaaS with enterprise SLA's.
In software and in professions, providers have some combination of method and qualifications or authority which justifies reliance by their clients. Both education and software have reduced the reliance on naked authority, but a good track record remains the gold standard.
So providers (individuals and companies) have to ask how much of their reputation do they want to risk on any new method (AI, agile, ...)? Initially, it's always a promising boost in productivity. But then...
So the real question is what "Show me" means - for a quick meet, an enterprise sale, an enduring human-scale consumer dependence...
So, prediction: AI companies and people that can "show me" will be the winners.
(Unfortunately, we've also seen competitive advantage accrue to dystopian hiding of truth and risk, which would have the same transaction-positive effect but shift and defer the burden of risk. Let's hope...)
AI was never the problem we have been having a downgrade in software in general AI just amplifies how badly you can build software. The real problem is people who just dont care about the craft just pushing out human slop, whether it be because the business goes “we can come back to that dont worry” or what have you. At least with AI me coming back to something is right here and right now, not never or when it causes a production grade issue.
I hate this trend of using adjectives to describe systems.
Fast
Secure
Sandboxed
Minimal
Reliable
Robust
Production grade
AI ready
Let's you _____
Enables you to _____
But somewhat I agree, code is essentially free, you can shit out infinite amounts of code. Unless it's good, then show the code instead.
If your code is shit, show the program.
If your program is shit, your code is worse, but you still pursing an interesting idea (in your eyes), show the prompt instead of the slop generated. Or even better communicate an elaborate version of the prompt.
>One can no longer know whether such a repository was “vibe”
premise is wrong. have seen a number of claude/codex disasters that never make it to production with clients, yet consumed an enormous amount of human time and bandwidth.
expertise and effort is and will continue to be for the forseeable future essential.
I for one am quite happy to outsource this kind of simply memorisation to a machine. Maybe it's the thin end of the slippery slope? It doesn't FEEL like it is but...
> The real concern is for generations of learners who are being robbed of the opportunity to acquire the expertise to objectively discern what is slop and what is not.
How do new developers build the skills that seniors generated through time? I see my seniors having higher success in vibe-coding than me. How can I short-circuit the time they put through for myself?
for a group of people as smart as developers, it sure took us long enough to realize billionaires were liquidating our code integrity to become trillionaires
I think that's always been true. The ideas and reasoning process matter. So does the end product. If you produced it with an LLM and it sucks, it still sucks.
I asked Codex to write some unit tests for Redux today. At first glance it looked fine, and I continued on. I then went back to add a test by hand, and after looking more closely at the output there were like 50 wtf worthy things scattered in there. Sure they ran, but it was bad in all sorts of ways. And this was just writing something very basic.
This has been my experience almost every time I use AI: superficially it seems fine, once I go to extend the code I realize it's a disaster and I have to clean it up.
The problem with "code is cheap" is that, it's not. GENERATING code is now cheap (while the LLMs are subsidized by endless VC dollars, anyway), but the cost of owning that code is not. Every line of code is a liability, and generating thousands of lines a day is like running up a few thousand dollars of debt on a credit card thinking you're getting free stuff and then being surprised when it gets declined.
I've always said every line is a liability, its our job to limit liabilities. That has largely gone out the window these days.
EWD 1036: On the cruelty of really teaching computing science (1988)
“My point today is that, if we wish to count lines of code, we should not regard them as ‘lines produced’ but as ‘lines spent’: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.”
No code is as easy to maintain as no code.
No code runs as fast as no code.
A better formulation is "every feature is a liability". Taking it to the line of code level is too prescriptive. Occasionally writing more verbose code is preferable if it makes it easier to understand.
> A better formulation is "every feature is a liability". Taking it to the line of code level is too prescriptive.
Amount of code is a huge factor but maybe not the best wording here. It's more a thing of complexity where amount of code is a contributing metric but not the only one. You can very easily have a feature implemented in a too complex way and with too much code (esp. if an LLM generated the code but also with human developers). Also not every feature is equal.
> Occasionally writing more verbose code is preferable if it makes it easier to understand.
Think this is more a classic case of "if the metric becomes a goal it ceases to be a metric" than it being a bad metric per se.
This sounds wrong, features have to be the value of your code. The required maintenance and slow down to build more features (technical debt) are the liability, which is how I understood the relationship to "lines of code" anyway.
Wrong or not, the industry embraced it.
I can sort of understand it if I squint: every feature is a maintenance burden, and a risk of looking bad in front of users when you break or remove it, even if those users didn't use this feature. It's really a burden to be avoided when the point of your product is to grow its user base, not to actually be useful. Which explains why even Fischer-Price toys look more feature-ful and ergonomic than most new software products.
Agreed, every line you ship,whether you wrote it or not, you are responsible. In that regard, while I write a lot of code completely with AI, I still endeavor to keep the lines as minimal as possible. This means you never write both the main code and the tests using AI. Id rather have no tests than AI tests (we have QA team writing that up). This kinda works.
Followed by even better is code is no code, and best is deleting code.
It’s one of those things which has always strikes me funny about programming is how less usually really is more
> every line is a liability, its our job to limit liabilities.
Hard agree!
But more code from AI means stocks go up. Stocks are assets. If you generate enough code the assets will outnumber the liabilities. It’s accounting 101. /s
Ha ha NGU!
The only people I've known that share this perspective are those that hate abstraction. Going back to their code, to extend it in some way, almost always requires a rewrite, because they wrote it with the goal of minimum viable complexity rather than understanding the realities of the real world problem they're solving, like "we all know we need these other features, but we have a deadline!"
For one off, this is fine. For anything maintainable, that needs to survive the realities of time, this is truly terrible.
Related, my friend works in a performance critical space. He can't use abstractions, because the direct, bare metal, "exact fit" implementation will perform best. They can't really add features, because it'll throw the timing of others things off to much, so usually have to re-architect. But, that's the reality of their problem space.
I believe this is conflating abstraction with encapsulation. The former is about semantic levels, the later about information hiding.
Maybe I am? How is it possible to abstract without encapsulation? And also, how is it possible to encapsulate without abstracting some concept (intentionally or not) contained in that encapsulation? I can't really differentiate them, in the context of naming/referencing some list of CPU operations.
> How is it possible to abstract without encapsulation.
Historically pure machine code with jumps etc lacked any from of encapsulation as any data can be accessed and updated by anything.
However, you would still use abstractions. If you pretend the train is actually going 80.2 MPH instead of somewhere between 80.1573 MPH to 80.2485 MPH which you got from different sensors you don’t need to do every calculation that follows twice.
I'm using the industry definition of abstraction [1]:
> In software, an abstraction provides access while hiding details that otherwise might make access more challenging
I read this as "an encapsulation of a concept". In software, I think it can be simplified to "named lists of operations".
> Historically pure machine code with jumps etc lacked any from of encapsulation as any data can be accessed and updated by anything.
Not practically, by any stretch of the imagination. And, if the intent is to write silly code, modern languages don't really change much, it's just the number of operations in the named lists will be longer.
You would use calls and returns (or just jumps if not supported), and then name and reference the resulting subroutine in your assembler or with a comment (so you could reference it as "call 0x23423 // multiply R1 and R2"), to encapsulate the concept. If those weren't supported, you would use named macros [2]. Your assembler would used named operations, sometimes expanding to multiple opcodes, with each opcode having a conceptually relevant name in the manual, which abstracted a logic circuit made with named logic gates, consisting of named switches, that shuffled around named charge carriers. Say your code just did a few operations, the named abstraction for the list of operations (which all these things are) there would be "blink_light.asm".
> If you pretend the train is actually going 80.2 MPH instead of somewhere between 80.1573 MPH to 80.2485 MPH which you got from different sensors you don’t need to do every calculation that follows twice.
I don't see this as an abstraction as much as a simple engineering compromise (of accuracy) dictated by constraint (CPU time/solenoid wear/whatever), because you're not hiding complexity as much as ignoring it.
I see what you're saying, and you're probably right, but I see the concepts as equivalent. I see an abstraction as a functional encapsulation of a concept. An encapsulation, if not nonsense, will be some meaningful abstraction (or a renaming of one).
I'm genuinely interested in an example of an encapsulation that isn't an abstraction, and an abstraction that isn't a conceptual encapsulation, to right my perspective! I can't think of any.
[1] https://en.wikipedia.org/wiki/Abstraction_(computer_science)
[2] https://www.tutorialspoint.com/assembly_programming/assembly...
> I can't think of any.
Incorrect definition = incorrect interpretation. I edited this a few times but the separation is you can use an abstraction even if you maintain access to the implementation details.
> assembler
Assembly language which is a different thing. Initially there was no assembler, someone had to write one. In the beginning every line of code had direct access to all memory in part because limited access required extra engineering.
Though even machine code itself is an abstraction across a great number of implementation details.
> I don't see this as an abstraction as much as a simple engineering compromise (of accuracy) dictated by constraint (CPU time/solenoid wear/whatever), because you're not hiding complexity as much as ignoring it.
If it makes you feel better consider the same situation with 5 senators X of which have failed. The point is you don’t need to consider all information at every stage of a process. Instead of all the underlying details you can write code that asks do we have enough information to get a sufficiently accurate speed? What is it?
It doesn’t matter if the code could still look at the raw sensor data, you the programmer prefer the abstraction so it persists even without anything beyond yourself enforcing it.
IE: “hiding details that otherwise might make access more challenging”
You can use TCP/IP or anything else as an abstraction even if you maintain access to the lower level implementation details.
I genuinely appreciate your response, because there's a good chance it'll result in me changing my perspective, and I'm asking these questions with that intent!
> You are thinking of assembly language which is a different thing. Initially there was no assembler, someone had to write one.
This is why I specifically mention opcodes. I've actually written assemblers! And...there's not much to them. It's mostly just replacing the names given to the opcodes in the datasheet back to the opcodes, with a few human niceties. ;)
> consider the same situation with 5 senators X of which have failed
Ohhhhhhhh, ok. I kind of see. Unfortunately, I don't see the difference between abstraction and encapsulation here. I see the abstraction as being speed as being the encapsulation of a set of sensors, ignoring irrelevant values.
I feel like I'm almost there. I may have edited my previous comment after you replied. My "no procrastination" setting kicked in, and I couldn't see.
I don't see how "The former is about semantic levels, the later about information hiding." are different. In my mind, semantic levels exist as compression and encapsulation of information. If you're saying encapsulation means "black box" then that could make sense to me, but "inaccessible" isn't part of the definition, just "containment".
Computer Science stole the term abstraction from the field of Mathematics. I think mathematics can be really helpful in clearing things up here.
A really simple abstraction in mathematics is that of numeric basis (e.g. base 10) for representing numbers. Being able to use the symbol 3 is much more useful than needing to write III. Of course, numbers themselves are an abstraction- perhaps you and I can reason about 3 and 7 and 10,000 in a vacuum, but young children or people who have never been exposed to numbers without units struggle to understand. Seven… what? Dogs? Bottles? Days? Numbers are an abstraction, and Arabic digits are a particular abstraction on top of that.
Without that abstraction, we would have insufficient tools to do more complex things such as, say, subtract 1 from 1,000,000,000. This is a problem that most 12 year olds can solve, but the greatest mathematicians of the Roman empire could not, because they did not have the right abstractions.
So if there are abstractions that enable us to solve problems that were formerly impossible, this means there is something more going on than “hiding information”. In fact, this is what Dijkstra (a mathematician by training) meant when he said:
The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise
When I use open(2), it’s because I’m operating at the semantic level of files. It’s not sensible to think of a “file” at a lower level: would it be on disk? In memory? What about socket files? But a “file” isn’t a real thing, it’s an abstraction created by the OS. We can operate on files, these made up things, and we can compose operations together in complex, useful ways. The idea of a file opens new possibilities for things we can do with computers.
I hope that explanation helps!
Expanding on this regarding the difference between abstraction vs encapsulation: abstraction is about the distillation of useful concepts while encapsulation is a specific tactic used to accomplish a behavior.
To continue with the idea of numbers, let’s say you asked someone to add 3 and 5. Is that encapsulation? What information are you hiding? You are not asking them to add coins or meters or reindeer. 3 and 5 are values independent of any underlying information. The numbers aren’t encapsulating anything.
Encapsulation is different. When you operate a motor vehicle, you concern yourself with the controls presented. This allows you, as the operator, to only need a tiny amount of knowledge to interact with an incredibly complex machine. This details have been encapsulated. There may be particular abstraction present, such as the notion of steering, acceleration, and breaking, but the way you interact with these will differ from vehicle to vehicle. Additionally, encapsulation is not concerned with the idea of steering, it is concerned with how to present steering in this specific case.
The two ideas are connected because using an abstraction in software often involves encapsulation. But they should not be conflated, out the likely result is bad abstractions and unwieldy encapsulation.
> It's mostly just replacing the names given to the opcodes in the datasheet back to the opcodes
Under the assumption that the input data is properly formatted you can generate machine code. This is however an abstraction which can fail as nothing forces a user to input valid files.
So we have an abstraction without any encapsulation.
I don't see how the two are related, personally. I'm regularly accused of over-abstraction specifically because I aspire to make each abstraction do as little as possible, i.e. fewest lines possible.
"Abstracting" means extracting the commnon parts of multiple instances, and making everything else a parameter. The difficulty for software is that developers often start by writing the abstraction, rather than having multiple existing instances and then writing code that collects the common parts of those multiple instances into a single abstraction. I guess that is what "refactoring" is about.
In sciences and humanities abstraction is applied the proper way, studying the instances first then describing multitude of existing phenomena by giving names to their common repeating descriptions.
This matches my "ideal" way of writing software, which is something close to "reverse waterfall". Start with the non-negotiable truths at the lowest level, then work your way up towards the goal, which is sufficiently defined. As you go, the patterns became apparent, collapsing into nice abstractions.
The code always ends up nice and clean and modular. And, since I'm working towards the idea, I can say "here are the modular pieces I have to work with, dictated the fundamentals beneath, how do I use them to accomplish the task?". When working from the idea, I think it's easier to want to write something to achieve the immediate task, in a "not see the forest for the trees" kind of way (abstractions are about the goal, rather than the reality under). Of course, both directions are required, but I get the best "separation of concerns" going in reverse.
I call that lasagna code! From what I've seen, developers start with spaghetti, overcompensate with lasagna, then end up with some organization more optimized for the human, that minimizes cognitive load while reading.
To me, abstraction is an encapsulation of some concept. I can't understand how they're practically different, unless you encapsulate true nonsense, without purpose or resulting meaning, which I can't think of an example of, since humans tend to categorize/name everything. I'm dumb.
Hi, I'm the primary Redux maintainer. I'd love to see some examples of what got generated! (Doubt there's anything we could do to _influence_ this, but curious what happened here.)
FWIW we do have our docs on testing approaches here, and have recommended a more integrated-style approach to testing for a while:
- https://redux.js.org/usage/writing-tests
Unfortunately I think I cleaned up the code before committing it, so I don't have an exact example! I did actually read that usage page though after looking at those tests, and that helped me in fixing the tests (maybe in retrospect I should have pointed the AI at the docs page first).
I think the main issue I was having with it was reusing the store object instead of creating a new one for each test. The other issue I was seeing was that it was creating mock objects and API's for things that weren't even being tested (lot of scope creep), and one of those API's was basically copy-pasted between two files (code duplication). It was also just testing things that weren't really necessary (ie, testing Redux itself, instead of my usage of it).
Another issue was just taking a complex approach to fixing something that could be more easily solved. For instance, I had debug: true turned on for redux-undo so I was seeing some unnecessary log messages in the test. Codex identified this, and asked if I wanted to disable them, so I said yes. What it did though, was instead of setting debug: false, or disabling it on tests, it patched console.log to look for redux-undo prefixes. Technically worked, but kind of byzantine!
None of this was a terrible disaster or anything, especially since I started pretty small, but I think what made me miss some of the issues at first glance is this is my first usage of Redux in a non-toy project so while I understand the fundamentals fine, it was easy to sneak working-but-bad stuff past me until I sat down with the code to write a test on my own and started to see the issues.
> "write some unit tests for Redux today"
The equivalent of "draw me a dog" -> not a masterpiece!? who would have thought? You need to come up with a testing methodology, write it down, and then ask the model to go through it. It likes to make assumptions on unspecified things, so you got to be careful.
More fundamentally I think testing is becoming the core component we need to think about. We should not vibe-check AI code, we should code-check it. Of course it will write the actual test code, but your main priority is to think about "how do I test this?"
You can only know the value of a code up to the level of its testing. You can't commit your eyes into the repo, so don't do "LGTM" vibe-testing of AI code, it's walking a motorcycle.
I think you're assuming a lot about my prompting. I know to be specific with LLMs
Generating code was always cheap. That’s part of the reason this tech has to be forced on teams. Similar to the move to cloud, it’s the kind of cost that’s only gonna show up later - faster than the cloud move, I think. Though, in some cases it will be the correct choice.
ATM I feel like LLM writing tests can be a bit dangerous at times, there are cases where it's fine there are cases where it's not. I don't really think I could articulate a systemised basis for identifying either case, but I know it when I see it I guess.
Like the the other day, I gave it a bunch of use cases to write tests for, the use cases were correct the code was not, it saw one of the tests broken so it sought to rewrite the test. You risking suboptimal results when an agent is dictating its own success criteria.
At one point I did try and use seperate Claude instances to write tests, then I'd get the other instance to write the implementation unaware of the tests. But it's a bit to much setup.
I work with individuals who attempt to use LLMs to write tests. More than once, it's added nonsensical, useless test cases. Admittedly, humans do this, too, to a lesser extent.
Additionally, if their code has broken existing tests, it "fixes" them by not fixing the code under test, but changing the tests... (assert status == 200 becomes 500 and deleting code.)
Tests "pass." PR is opened. Reviewers wade through slop...
The most annoying thing is that even after cleaning up all the nonsense, the tests still contain all sort of fanfare and it’s essentially impossible to get the submitter to trim them because it’s death by a thousand cuts (and you better not say "do it as if you didn’t use AI" in the current climate..)
Yep. We've had to throw PRs away and ask them to start over with a smaller set of changes since it became impossible to manage. Reviews went on for weeks. The individual couldn't justify why things were done (and apparently their AI couldn't, either!)
Luckily those I work with are smart enough that I've not seen a PR thrown away yet, but sometimes I'm approving with more "meh, it's fine I guess" than "yeah, that makes sense".
This is how you do things if you are new to this game.
Get two other, different, LLMs to thoroughly review the code. If you don’t have an automated way to do all of this, you will struggle and eventually put yourself out of a job.
If you do use this approach, you will get code that is better than what most software devs put out. And that gives you a good base to work with if you need to add polish to it.
I actually have used other LLMs to review the code, in the past (not today, but in the past). It's fine, but it doesn't tend to catch things like "this technically works but it's loading a footgun." For example, the redux test I was mentioning in my original post, the tests were reusing a single global store variable. It technically worked, the tests ran, and since these were the first tests I introduced in the code base there weren't any issues even though this made the tests non deterministic... but, it was a pattern that was easily going to break down the line.
To me, the solution isn't "more AI", it's "how do I use AI in a way that doesn't screw me over a few weeks/months down the line", and for me that's by making sure I understand the code it generated and trim out the things that are bad/excessive. If it's generating things I don't understand, then I need to understand them, because I have to debug it at some point.
Also, in this case it was just some unit tests, so who cares, but if this was a service that was publicly exposed on the web? I would definitely want to make sure I had a human in the loop for anything security related, and I would ABSOLUTELY want to make sure I understood it if it were handling user data.
how long ago was this past? A review with latest models should absolutely catch the issue you describe, in my experience.
Ah, "It's work on my computer" edition of LLM.
December. Previous job had cursor and copilot automatically reviewing PRs.
The quality of generated code does not matter. The problem is when it breaks 2 AM and you're burning thousands of dollars every minutes. You don't own the code that you don't understand, but unfortunately that does not mean you don't own the responsibility as well. Good luck on writing the postmortem, your boss will have lots of question for you.
Frequently the boss is encouraging use of AI for efficiency without understanding the implications.
And we'll just have the AI write the postmortem, so no big deal there. ;)
AI can help you understand code faster than without AI. It allows me to investigate problems that I have little context in and be able to write fixes effectively.
> you will struggle and eventually put yourself out of a job.
We can have a discussion without the stakes being so high.
> If you do use this approach, you will get code that is better than what most software devs put out. And that gives you a good base to work with if you need to add polish to it.
If you do use this approach, you'll find that it will descend into a recursive madness. Due to the way these models are trained, they are never going to look at the output of two other models and go "Yeah, this is fine as it is; don't change a thing".
Before you know it you're going to have change amplification, where a tiny change by one model triggers other models (or even itself) to make other changes, which triggers further changes, etc ad nauseum.
The easy part is getting the models to spit out working code. The hard part is getting it to stop.
Im sick and tired of these empty posts.
SHOW AN EXAMPLE OF YOU ACTUALLY DOING WHAT YOU SAY!
There's no example because OP has never done this, and never will. People lie on the internet.
I've never done this because i haven't felt compelled to do this because I want to review my own code but I imagine this works okay and isn't hard to set up by asking Claude to set this up for you...
What? People do this all the time. Sometimes manually by invoking another agent with a different model and asking it to review the changes against the original spec. I just setup some reviewer / verifier sub agents in Cursor that I can invoke with a slash command. I use Opus 4.5 as my daily driver, but I have reviewer subagents running Gemini 3 Pro and GPT-5.2-codex and they each review the plan as well, and then the final implementation against the plan. Both sometimes identify issues, and Opus then integrates that feedback.
It’s not perfect so I still review the code myself, but it helps decrease the number of defects I have to then have the AI correct.
The setup is much simpler than you might think. I have 4 CLI tools I use for this setup. Claude Code, Codex, Copilot and Cursor CLI. I asked Claude Code to create a code reviewer "skill" that uses the other 3 CLI tools to review changes in detail and provide feedback. I then ask Claude Code to use this skill to review any changes in code or even review plan documents. It is very very effective. Is it perfect? No. Nothing is. But, as I stated before, this produces results that are better than what an average developer sends in for PR review. Far far better in my own experience.
In addition to that, we do use CodeRabbit plugin on GitHub to perform a 4th code review. And we tell all of our agents to not get into gold-plating mode.
You can choose not to use modern tools like these to write software. You can also choose to write software in binary.
these two posts (the parent and then the OP) seem equally empty?
by level of compute spend, it might look like:
- ask an LLM in the same query/thread to write code AND tests (not good)
- ask the LLM in different threads (meh)
- ask the LLM in a separate thread to critique said tests (too brittle, testing guidelines, testing implementation and not out behavior, etc). fix those. (decent)
- ask the LLM to spawn multiple agents to review the code and tests. Fix those. Spawn agents to critique again. Fix again.
- Do the same as above, but spawn agents from different families (so Claude calls Gemini and Codex).
—-
these are usually set up as /slash commands like /tests or /review so you aren’t doing this manually. since this can take some time, people might work on multiple features at once.
The main issue I've seen is it writing passing tests, the code being correct is a big (and often incorrect) assumption.
The majority of devs do the same thing.
A better agent can fix it in the future.
Living off only deep fried potatoes and large cola bottles is cheap...
nobody is going to care about your bespoke codework if there is no downstream measurable difference
I think if your job is to assemble a segment of a car based on a spec using provided tools and pre-trained processes, it makes sense if you worry that giant robot arms might be installed to replace you.
But if your job is to assemble a car in order to explore what modifications to make to the design, experiment with a single prototype, and determine how to program those robot arms, you’re probably not thinking about the risk of being automated.
I know a lot of counter arguments are a form of, “but AI is automating that second class of job!” But I just really haven’t seen that at all. What I have seen is a misclassification of the former as the latter.
A software engineer with an LLM is still infinitely more powerful than a commoner with an LLM. The engineer can debug, guide, change approaches, and give very specific instructions if they know what needs to be done.
The commoner can only hammer the prompt repeatedly with "this doesn't work can you fix it".
So yes, our jobs are changing rapidly, but this doesn't strike me as being obsolete any time soon.
I listened to an segment on the radio where a College Teacher told their class that it was okay to use AI assist you during test provided:
1. Declare in advance that AI is being used.
2. Provided verbatim the questions and answer session.
3. Explain why the answer given by the AI is good answer.
Part of the grade will include grading 1, 2, 3
Fair enough.
It’s better than nothing but the problem is students will figure out feeding step 2 right back to the AI logged in via another session to get 3.
This is actually a great way to foster the learning spirit in the age of AI. Even if the student uses AI to arrive at an answer, they will still need to, at the very least, ask the AI to give it an explanation that will teach them how it arrived to the solution.
No this is not the way we want learning to be - just like how students are banned from using calculators until they have mastered the foundational thinking.
That's a fair point, but AI can do much more than just provide you with an answer like a calculator.
AI can explain the underlying process of manual computation and help you learn it. You can ask it questions when you're confused, and it will keep explaining no matter how off the topic you go.
We don't consider tutoring bad for learning - quite the contrary, we tutor slower students to help them catch up, and advanced students to help them fulfill their potential.
If we use AI as if it was an automated, tireless tutor, it may change learning for the better. Not like it was anywhere near great as it was.
You're assuming the students are reading any of this. They're not, they're just copy/pasting it.
Well, you can lead the horse to water, but you can't make him drink.
If you assume all students are lazy assholes who want to cheat the system, then I doubt there's anything that would help them learn.
Also so much of the LLMs answer is fluff, when not outright wrong
There is research that shows that banning calculators impedes the learning of maths. It is certainly not obvious to me that calculators will have a negative effect - I certainly always allowed my kids to use them.
LLMs are trickier and use needs to be restricted to stop cheating, just as my kids had restrictions on what calculators they could use in some exams. That does not mean they are all bad or even net bad if used correctly.
> There is research that shows that banning calculators impedes the learning of maths.
I've seen oodles of research concluding the opposite at the primary level (grades 1- 5, say). If your mentioned research exists, it must be very well hidden :-/
There were 79 studies used in this meta analysis so it cannot be that well hiddne: https://psycnet.apa.org/record/1987-11739-001
> There were 79 studies used in this meta analysis so it cannot be that well hiddne: https://psycnet.apa.org/record/1987-11739-001
From the first page of that study
> Do calculators threaten basic skills? The answer consistently seemed to be no, provided those basic skills have first been developed with paper and pencil.
So, yeah, there are no studies I have found that support any assertion along the lines of:
>>> There is research that shows that banning calculators impedes the learning of maths.
If you actually find any, we still have to consider that things like this meta-study you posted is already 74-studies ahead in confirming that you are wrong.
Best would be for you to find 75 studies that confirm your hypothesis. Unfortunately, even though I read studies all the time, and even at one point had full access via institutional license to full-text of studies, and spent almost all of my after-hours time between 2009 and 2011 actually reading papers on primary/foundational education, I have not seen even one that supports your assertion.
I have read well over a hundred papers on the subject, and did not find one. I am skeptical that you will find any.
A meta analysis: https://psycnet.apa.org/record/1987-11739-001
Calculator don't tell you step by step. AI can.
Symbolic computation is a thing. How do you think wolfram alpha worked for 20 years before AI?
And it’s making that up as well.
Yeah; it gets steps 1-3 right, 4-6 obviously wrong, and then 7-9 subtly wrong such that a student, who needs it step by step while learning, can't tell.
That's roughly what we did as well. Use anything you want, but in the end you have to be able to explain the process and the projects are harder than before.
If we can do more now in a shorter time then let's teach people to get proficient at it, not arbitrarily limit them in ways they won't be when doing their job later.
Props to the teacher for putting in the work to thoughtfully grade an AI transcript! As I typed that I wondered if a lazy teacher might then use AI to grade the students AI transcript?
I think it's a bit like the Dunning-Kruger effect. You need to know what you're even asking for and how to ask for it. And you need to know how to evaluate if you've got it.
This actually reminds me so strongly of the Pakleds from Star Trek TNG. They knew they wanted to be strong and fast, but the best they could do is say, "make us strong." They had no ability to evaluate that their AI (sorry, Geordi) was giving them something that looked strong, but simply wasn't.
Oh wow this is a great reference/image/metaphor for "software engineers" who misuse these tools - "the great pakledification" of software
Yep, I've seen a couple of folks pretending to be junior PMs, thinking they can replace developers entirely. The problem is, they can't write a spec. They can define a feature at a very high level, on a good day. They resort to asking one AI to write them a spec that they feed to another.
It's slop all the way down.
People have tried that with everything from COBOL to low code. Its even succeeded in some problem domains (e.g. thing people code with spreadsheet formula) but there is no general solution that replaces programmers entirely.
A "commoner"... Could you possibly be more full of yourself?
That was literally the opposite of my intention. Maybe the choice of word wasn't perfect, but basically, I was trying to highlight that domain expertise is still valuable in the specific scenario of software engineering.
The same could be said about any other job, if you put me against a construction worker and give us both expensive power tools, he will still do a better job than me because I have no experience in that domain.
Agree totally.
My job is to make people who have money think I'm indispensable to achieving their goals. There's a good chance AI can fake this well enough to replace me. Faking it would be good enough in an economy with low levels of competition; everyone can judge for themselves if this is our economy or not.
I mean it sounds to me like a beautiful corporate poison. :)
I don’t think this is the issue “yet”. It’s that no matter what class you are, your CEO does not care. Mediocre AI work is enough to give them immense returns and an exit. He’s not looking out for the unfortunate bag holders. The world has always had tolerance for highly distributed crap. See Windows.
This seems like a purely cynical lacking any substantive analysis.
Despite whatever nasty business practices and shitty UX Windows has foisted on the world, there is no denying the tremendous value that it has brought, including impressive backwards compatibility that rivals some of the best platforms in computing history.
AI shovelware pump-n-dump is an entirely different short term game that will never get anywhere near Microsoft levels of success. It's more like the fly-by-nights in the dotcom bubble that crashed and burned without having achieved anything except a large investment.
You misunderstand me. While I left Windows over a decade ago, I recognize it was a great OS in some aspects. I was referring to the recent AI fueled Windows developments and Ad riddled experiences. Someone decided that is fine, and you won't see orgs or regular users drop it...tolerance.
This is actually a really good description of the situation. But I will say, as someone that prided myself on being the second one you described, I am becoming very concerned about how much of my work was misclassified. It does feel like a lot of work I did in the second class is being automated where maybe previously it overinflated my ego.
SWE is more like formula 1 where each race presents a unique combination of track, car, driver, conditions. You may have tools to build the thing, but designing the thing is the main issue. Code editor, linter, test runner, build tools are for building the thing. Understanding the requirements and the technical challenges is designing the thing.
The other day I said something along the lines of, "be interested in the class, not the instance" and I meant to try to articulate a sense of metaprogramming and metaanalysis of a problem.
Y is causing Z and we should fix that. But if we stop and study the problem, we might discover that X causes the class of Y problem so we can fix the entire class, not just the instance. And perhaps W causes the class of X issue. I find my job more and more being about how far up this causality tree can I reason, how confident am I about my findings, and how far up does it make business sense to address right now, later, or ever?
is it? I really fail to see the metaphor as an F1 fan. The cars do not change that much; only the setup does, based on track and conditions. The drivers are fairly consistent through the season. Once a car is built and a pecking order is established in the season, it is pretty unrealistic to expect a team with a slower car to outcompete a team with a faster car, no matter what track it is (since the conditions affect everyone equally).
Over the last 16 years, Red Bull has won 8 times, Mercedes 7 times and Mclaren 1. Which means, regardless of the change in tracks and conditions, the winners are usually the same.
So either every other team sucks at "understanding the requirements and the technical challenges" on a clinical basis or the metaphor doesn't make a lot of sense.
Most projects don’t change that much either. Head over to a big open source project, and more often you will only see tweaks. To be able to do the tweaks require a very good understanding of the whole project (Naur’s theory of programming).
Also in software, we can do big refactors. F1 teams are restricted to the version they’ve put in the first race. But we do have a lot of projects that were designed well enough that they’ve never changed the initial version, just build on top of it.
I wonder about how true this was historically. I imagine race car driving had periods of rapid, exciting innovation. But I can see how a lot of it has probably reached levels of optimization where the rules, safety, and technology change well within the realm of diminishing returns. I'm sure there's still a ridiculous about of R&D though? (I don't really know race car driving)
Sure there is crazy levels of R&D but that mostly happens off season or if there is a change in regulations which happen every 4-5 years usually. Interestingly, this year the entire grid starts with new regs and we don't really know the pecking order yet.
But my whole point was that race to race, it really isn't that much different for the teams as the comment implied and I am still kind of lost how it fits to SWE unless you're really stretching things.
Even then, most teams dont even make their own engines etc.
Do you really think that rainy Canada is the same as Jedddah, or Singapore? And what is the purpose of the free practice sessions?
You’ve got the big bet to design the car between the season (which is kinda the big architectural decisions you make at the beginning of the project). Then you got the refinement over the season, which are like bug fixings and performance tweaks. There’s the parts upgrade, which are like small features added on top of the initial software.
For the next season, you either improve on the design or start from scratch depending on what you’ve learned. In the first case, It is the new version of the software. In the second, that’s the big refactor.
I remember that the reserve drivers may do a lot of simulations to provide data to the engineers.
You are describing tradition (deterministic?) automation before AI. With AI systems as general as today's SOTA LLMs, they'll happily take on the job regardless of the task falling into class I or class II.
Ask a robot arm "how should we improve our car design this year", it'll certainly get stuck. Ask an AI, it'll give you a real opinion that's at least on par with a human's opinion. If a company builds enough tooling to complete the "AI comes up with idea -> AI designs prototype -> AI robot physically builds the car -> AI robot test drives the car -> AI evaluates all prototypes and confirms next year's design" feedback loop, then theoretically this definitely can work.
This is why AI is seen as such a big deal - it's fundamentally different from all previous technologies. To an AI, there is no line that would distinguish class I from II.
Well a lot of managers view their employees as doing the former, but they’re really doing the latter
> I know a lot of counter arguments are a form of, “but AI is automating that second class of job!”
Uh, it's not the issue. The issue is that there isn't that much demand for the second class of job. At least not yet. The first class of job is what feeds billions of families.
Yeah, I'm aware of the lump of labour fallacy.
Discussing what we should do about the automation of labour is nothing new and is certainly a pretty big deal here. But I think you're reframing/redirecting the intended topic of conversation by suggesting that "X isn't the issue, Y is."
It wanders off the path like if I responded with, "that's also not the issue. The issue is that people need jobs to eat."
It depends a lot on the type of industry I would think.
I see a lot of the same (well thought out) pushback on here whenever these kinds of blind hype articles pop up.
But my biggest objection to this "engineering is over" take is one that I don't see much. Maybe this is just my Big Tech glasses, but I feel like for a large, mature product, if you break down the time and effort required to bring a change to production, the actual writing of code is like... ten, maybe twenty percent of it?
Sure, you can bring "agents" to bear on other parts of the process to some degree or another. But their value to the design and specification process, or to live experiment, analysis, and iteration, is just dramatically less than in the coding process (which is already overstated). And that's without even getting into communication and coordination across the company, which is typically the real limiting factor, and in which heavy LLM usage almost exclusively makes things worse.
Takes like this seem to just have a completely different understanding of what "software development" even means than I do, and I'm not sure how to reconcile it.
To be clear, I think these tools absolutely have a place, and I use them where appropriate and often get value out of them. They're part of the field for good, no question. But this take that it's a replacement for engineering, rather than an engineering power tool, consistently feels like it's coming from a perspective that has never worked on supporting a real product with real users.
I'm not sure you're actually in disagreement with the author of this piece at all.
They didn't say that software engineering is over - they said:
> Software development, as it has been done for decades, is over.
You argue that writing code is 10-20% of the craft. That's the point they are making too! They're framing the rest of it as the "talking", which is now even more important than it was before thanks to the writing-the-code bit being so much cheaper.
When we say generating code is only a small percentage, that does not imply that the rest is just talking. Simon, you were part of a relatively small fast moving project in Django and the news website it powered, with from I understand a pretty small team. Have you worked as part of a team of 10, 20, 100, 1000 engineers? It's different.
"Talking" here doesn't literally mean talking. It means figuring out the scope of the problem, researching solutions, communicating with stakeholders, debating architecture, building exploratory prototypes, breaking down projects - it's all the stuff that isn't writing the code.
I've worked at various sizes of organization. Most notably I joined Eventbrite when they were less than 100 developers and stayed while they grew to around 1,000.
> Software development, as it has been done for decades, is over.
Simon I guess vb-8558's comment inn here is something which is really nice (definitely worth a read) and they mention how much coding has changed from say 1995 to 2005 to 2015 to 2025
Directly copying line from their comment here : For sure, we are going through some big changes, but there is no "as it has been done for decades".
Recently Economic Media made a relevant video about all of this too: How Replacing Developers With AI is Going Horribly Wrong [https://www.youtube.com/watch?v=ts0nH_pSAdM]
My (point?) is that this pure mentality of code is cheap show me the talk is weird/net negative (even if I may talk more than I code) simply because code and coding practices are something that I can learn over my experience and hone in whereas talk itself constitutes to me as non engineers trying to create software and that's all great but not really understanding the limitations (that still exist)
So the point I am trying to make is that I feel as if when the OP mentioned code is 10-20% of the craft, they didn't mean the rest is talk. They meant all the rest are architectural decisions & just everything surrounding the code. Quite frankly, the idea behind Ai/LLM's is to automate that too and convert it into pure text and I feel like the average layman significantly overestimates what AI can and cannot do.
So the whole notion of show me the talk atleast in a more non engineering background as more people try might be net negative not really understanding the tech as is and quite frankly even engineers are having a hard time catching up with all which is happening.
I do feel like that the AI industry just has too many words floating right now. To be honest, I don't want to talk right now, let me use the tool and see how it goes and have a moment of silence. The whole industry is moving faster than the days till average js framework days.
To have a catchy end to my comment: There is just too much talk nowadays. Show me the trust.
I do feel like information has become saturated and we are transitioning from the "information" age to "trust" age. Human connections between businesses and elsewhere matter the most right now more than ever. I wish to support projects which are sustainable and fair driven by passion & then I might be okay with AI use case imo.
Yeah in a lot of ways, my assertion is that @ “Code is cheap” actually means the opposite of what everyone thinks it does. Software Engineer is even more about the practices we’ve been developing over the past 20 or so years, not less
Like Linus’ observation still stands. Show me that the code you provided does exactly what you think it should. It’s easy to prompt a few lines into an LLM, it’s another thing to know exactly the way to safely and effectively change low level code.
Liz Fong-Jones told a story on LinkedIn about this at HoneyComb, she got called out for dropping a bad set of PR’s in a repo, because she didn’t really think about the way the change was presented.
> Takes like this seem to just have a completely different understanding of what "software development" even means than I do, and I'm not sure how to reconcile it.
You're absolutely right about coding being less than 20% of the overall effort. In my experience, 10% is closer to the median. This will get reconciled as companies apply LLMs and track the ROI. Over a single year the argument can be made that "We're still learning how to leverage it." Over multiple years the 100x increase in productivity claims will be busted.
We're still on the upslope of Gartner's hype cycle. I'm curious to see how rapidly we descend into the Trough of Disillusionment.
My recent experience demonstrates this. I had a couple weeks of happily cranking out new code and refactors at high speed with Claude’s help, then a week of what felt like total stagnation, and now I’m back to high velocity again.
What happened in the middle was I didn’t know what I wanted. I hadn’t worked out the right data model for the application yet, so I couldn’t tell Claude what to do. And if you tell it to go ahead and write more code at that point, very bad things will start to happen.
Ive been using LLMs through the web to help with discreet pieces of code and scripts for a while now. I’ve been putting it off (out of fear?) but I finally sat down with Claude Code on the console and an empty directory to see what the fuss was about. Over about a total of 4 hrs and maybe $15 pay as you go it became clear things are drastically different now in web dev. I’m not saying changed for good or bad just things have definitely changed and will never go back.
The book Software Engineering at Google makes a distinction between software engineering and programming. The main difference is that software engineering occurs over a longer time span than programming. In this sense, AI tools can make programming faster, but not necessarily software engineering.
Did you read the article? Author is one of the more thoughtful and least hype guys you'll find when it comes to these things
They're also great for writing design docs, which is another significant time sink for SWEs.
Just because a bunch of people tell you the practice of performing the art form of producing software via handwriting code is over doesn't mean it's over. This form of hyperbole is intended to overwhelm your reason, get you to forget your own expertise, and trick you into engaging with the topic in a fearful manner (literally FOMO). Don't fall for this cheap stunt.
There will always be a niche for any form of expression. However technologies change practice. It is your responsibility to be able to solve problems that balance performance, cost, schedule, and quality. Use the right tool for the job.
One of the tools require constant use to justify its existence though.
> crystal clear software development plan and the exact know-how to implement it
This is simply not how expert programmers work. Programming is planning, and programming languages are surprisingly good planning tools. But, of course, becoming an expert is hard and requires not only some general aptitude but also substantial time, experience and effort.
My theory is that this is a source of diverging views on LLMs for programming: people who see programming languages as tools for thought compared to people who see programming languages as, exclusively, tools to make computers do stuff. It's no surprise that the former would see more value in programming qua programming, while the latter are happy to sweep code under the rug.
The fundamental problem, of course, is that anything worth doing in code is going to involve pinning down a massive amount of small details. Programming languages are formal systems with nice (well, somewhat nice) UX, and formal systems are great for, well, specifying details. Human text is not.
Then again, while there might be a lot of details, there are also a lot of applications where the details barely matter. So why not let a black box make all the little decisions?
The question boils down to where you want to spend more energy: developing and articulating a good conceptual model up-front, or debugging a messy system later on. And here, too, I've found programmers fall into two distinct camps, probably for the same reasons they differ in their views on LLMs.
In principle, LLM capabilities could be reasonably well-suited to the up-front thinking-oriented programming paradigm. But, in practice, none of the tools or approaches popular today—certainly none of the ones I'm familiar with—are oriented in that direction. We have a real tooling gap.
> My theory is that this is a source of diverging views on LLMs for programming: people who see programming languages as tools for thought compared to people who see programming languages as, exclusively, tools to make computers do stuff. It's no surprise that the former would see more value in programming qua programming, while the latter are happy to sweep code under the rug.
i'd postulate this: most people see llms as tools for thought. programmers also see llms as tools for programming. some programmers, right now, are getting very good at both, and are binding the two together.
Most people? I'd suggest few people see LLMs as tools for thought and more that they're slop machines being cynically forced upon workers by capitalists with dollar signs in their eyes. Over and over and over again we see real-world studies showing that the people far more excited about genAI are managers than the people doing the actual work.
i mean - i think people recognize that they are pattern matching tools. pattern matching is useful for thinking.
The original phrase "talk is cheap" is generally used to mean "it's easy to say a whole lot of shit and that talk often has no real value." So this cleaver headline is telling me the code has even less value than the talk. That alone betrays a level of ignorance I would expect from the author's work. I go to read the article and it confirmed my suspicion.
I think you are hyper-focusing on the headline, which is just a joke. The underlying article does not indicate to me that the author is ignorant of code, and if you care to look, they seem to have a substantial body of public open source contributions that proves this quite conclusively.
The underlying point is just that while it was very cognitively expensive to back up a good design with good code back in 2000, it's much cheaper now. And therefore, making sure the design is good is the more important part. That's it really.
And… the design (artistry) aspect is always the toughest. So explain to me, where do the returns come from if it is seemingly obviously only those who are very well informed of their domains/possess general intelligence can benefit from this tool?
Personally I don’t see it happening. This is the bitter reality the LLM producers have to face at some point.
> So explain to me, where do the returns come from if it is seemingly obviously only those who are very well informed of their domains/possess general intelligence can benefit from this tool?
I...don't think this is true at all. "The design of the car is more important than what specific material you use" does not mean that the material is unimportant", just that it is relatively* less important. To put a fake number on it, maybe 10% less important.
I think people who have domain knowledge and good coding skills will probably benefit the most from this LLM producer stuff.
Did you get very far in? They're referring to a pretty specific contextual usage of the phrase (Linus, back in 2000), not the adage as a whole.
I read the whole thing, and GP is right. Code is important, whether it is generated or handwritten. At least until true AGI is here.
I think I made it to about here haha
> One can no longer know whether such a repository was “vibe” coded by a non-technical person who has never written a single line of code, or an experienced developer, who may or may not have used LLM assistance.
I am talking about what it means to invert that phrase.
Yes, the original phrase has a specific meaning. But in another context, "talk" is more important than the code.
In software development, code is in a real sense less important than the understanding and models that developers carry around in their heads. The code is, to use an unflattering metaphor, a kind of excrement of the process. It means nothing without a human interpreter, even if it has operational value. The model is never part of the implementation, because software apart from human observers is a purely syntactic construct, at best (even there, I would argue it isn't even that, as syntax belongs to the mind/language).
This has consequences for LLM use.
It's directly an inversion of https://www.goodreads.com/quotes/437173-talk-is-cheap-show-m...
> Software development, as it has been done for decades, is over.
I'm pretty sure the way I was doing things in 2005 was completely different compared to 2015. Same for 2015 and 2025. I'm not old enough to know how they were doing things in 1995, but I'm pretty sure there very different compared to 2005.
For sure, we are going through some big changes, but there is no "as it has been done for decades".
I don't think things have changed that much in the time I've been doing it (roughly 20 years). Tools have evolved and new things were added but the core workflow of a developer has more or less stayed the same.
I also wonder what those people have been doing all this time... I also have been mostly working as a developer for about 20 years and I don't think much has changed at all.
I also don't feel less productive or lacking in anything compared to the newer developers I know (including some LLM users) so I don't think I am obsolete either.
At some point I could straight-up call functions from the Visual Studio debugger Watch window instead of editing and recompiling. That was pretty sick.
Yes I know, Lisp could do this the whole time. Feel free to offer me a Lisp job drive-by Lisp person.
Isn’t there a whole ton of memes about the increase in complexity and full stack everything and having to take in devops, like nothing has changed at all?
I don't think that's true, at least for everywhere I've worked.
Agile has completely changed things, for better or for worse.
Being a SWE today is nothing like 30 years ago, for me. I much preferred the earlier days as well, as it felt far more engineered and considered as opposed to much of the MVP 'productivity' of today.
MVP is not necessarily opposed to engineered and considered. It's just that many people who throw that term around have little regard for engineering, which they hide behind buzzwords like "agile".
Yeah, I remember being amazed at the immediate incremental compilation on save in Visual Age for Java many years ago. Today's neovim users have features that even the most advanced IDEs didn't have back then.
I think a lot of people in the industry forget just how much change has come from 30 years of incremental progress.
But this time it will be different! This will be a huge change!
They always say and are saying again
1995 vs 2005 was definitely a larger change than subsequent decades; in 1995 most information was gathered through dead trees or reverse engineering.
talk is even cheaper, still show me the code, people claim 10x productivity that translates to 10x of work done in a month, even with Opus 4.5 out since November 2025 I haven't seen signs of this. AI makes the level of complexity with modern systems bearable, it was getting pretty bad before and AI kinda saved us. A non-trivial React app is still a pain to write. Also creating a harness for a non-deterministic api that AI provides is also pain. At least we don't have to fight through typing errors or search through relevant examples before copying and pasting. AI is good at automating typing, the lack of reasoning and the knowledge cutoff still makes coding very tedious though.
Best example of this is Claude's own terminal program. Apparently renders react at 60fps and then translates it into ANSI chars that then diff the content of the terminal and do an overwrite...
All to basically mimic what curses can do very easily.
This is the fun part of whole AI-built things that a lot of people don’t want to accept - it really, really, really does not matter if the code “nice, maintainable and etc.”. Does it work? Is it somewhat extendable with AI? Are users generally happy and adoption rate is high? That’s it.
If you have high time preference yes. Over longer time horizons I think the issues with vibe coded software will reveal themselves in the same way badly written software does.
In this case, no, it does not work. CC is full of reported rendering issues, including some that affect me.
Remember 8 years ago how vibe coding was awful? Like i never used it in prod apps. Now i'm a daily CC user, and every few months models are getting better, some problems are being solved, the other ones still being worked on and so on.
This "Code is cheap. Show me the talk." punchline gets overused as a bait these days. It is an alright article but that's a lot of words to tell us something we already know. There's nothing here that we don't already know. It's not just greedy companies riding the AI wave. Bloggers and influencers are also riding the AI wave. They know if you say anything positive or negative about AI with a catchy title it will trend on HN, Reddit, etc.
Also credit where credit is due. Origin of this punchline:
https://nitter.net/jason_young1231/status/193518070341689789...
https://programmerhumor.io/ai-memes/code-is-cheap-show-me-th...
In January 2026, prototype code is cheap. Shitty production code is cheap. If that's all you need—which is sometimes the case—then go for it.
But actually good code, with a consistent global model for what is going on, still won't come from Opus 4.5 or a Markdown plan. It still comes from a human fighting entropy.
Getting eyes on the code still matters, whether it's plain old AI slop, or fancy new Opus 4.5 "premium slop." Opus is quite smart, and it does its best.
But I've tried seriously using a number of high-profile, vibe-coded projects in the last few weeks. And good grief what unbelievable piles of shit most of them are. I spend 5% of the time using the vibe-coded tool, and 95% of the time trying to uncorrupt my data. I spend plenty of time having Opus try to look at the source to figure out what went wrong in 200,000 lines of vibe-coded Go. And even Opus is like, "This never worked! It's broken! You see, there's a race condition in the daemonization code that causes the daemon to auto-kill itself!"
And at that point, I stop caring. If someone can't be bothered to even read the code Opus generates, I can't be bothered to debug their awful software.
> Ignoring outright bad code, in a world where functional code is so abundant that “good” and “bad” are indistinguishable, ultimately, what makes functional AI code slop or non-slop?
I'm sorry, but this is an indicator for me that the author hasn't had a critical eye for quality in some time. There is massive overlap between "bad" and "functional." More than ever. The barrier-to-entry to programming got irresponsibly low for a time there, and it's going to get worse. The toolchains are not in a good way. Windows and macOS are degrading both in performance and usability, LLVM still takes 90% of a compiler's CPU time in unoptimized builds, Notepad has AI (and crashes,) simple social (mobile) apps are >300 MB download/installs when eight years ago they were hovering around a tenth of that, a site like Reddit only works on hardware which is only "cheap" in the top 3 GDP nations in the world... The list goes on. Whatever we're doing, it is not scaling.
This is the "artisanal clothing argument".
I'd think there'll be a dip in code quality (compared to human) initially due to "AI machinery" due to its immaturity. But over-time on a mass-scale - we are going to see an improvement in the quality of software artifacts.
It is easier to 'discipline' the top 5 AI agents in the planet - rather than try to get a million distributed devs ("artisans") to produce high quality results.
It's like in the clothing or manufacturing industry I think. Artisans were able to produce better individual results than the average industry machinery, at least initially. But overtime - industry machinery could match the average artisan or even beat the average, while decisively beating in scale, speed, energy efficiency and so on.
The issue is that code isn't clothing. It's the clothing factory. We aren't artisans sewing clothing. We're production engineers deciding on layouts for robots to make clothes most efficiently.
I see this type error of thinking all the time. Engineers don't make objects of type A, we make functions of type A -> B or higher order.
Go concrete. In FAANG engineering jobs now what % is this factory designer category vs what % is writing some mundane glue code, moving data around in CRUD calls, or putting in a monitoring metric etc?
Once you look at the present engineering org compositions see what's the error in thinking.
There are other analogy issues in your response which I won't nitpick
Production egineers don't design the looms in a weaving factory either.
> industry machinery could match the average artisan or even beat the average
Whether it could is distinct from whether it will. I'm sure you've noticed the decline in the quality of clothing. Markets a mercurial and subject to manipulation through hype (fast fashion is just a marketing scheme to generate revenue, but people bought into the lie).
With code, you have a complicating factor, namely, that LLMs are now consuming their own shit. As LLM use increases, the percentage of code that is generated vs. written by people will increase. That risks creating an echo chamber of sorts.
I don't agree with the limited point about fast fashion/enthittification, etc.
Quick check: Do you want to go back to pre-industrial era then - when according to you, you had better options for clothing?
Personally, I wouldn't want that - because I believe as a customer, I am better served now (cost/benefit wise) than then.
As to the point about recursive quality decline - I don't take it seriously, I believe in human ingenuity, and believe humans will overcome these obstacles and over time deliver higher quality results at bigger scale/lower costs/faster time cycles.
> Quick check: Do you want to go back to pre-industrial era then - when according to you, you had better options for clothing?
This does not follow. Fast fashion as described is historically recent. An an example, I have a cheap t-shift from the mid-90s that is in excellent condition after three decades of use. Now, I buy a t-shirt in the same price range, and it begins to fall apart in less than a year. This decline in the quality of clothing is well known and documented, and it is incredibly wasteful.
The point is that this development is the product of consumerist cultural presuppositions that construct a particular valuation that encourages such behavior, especially one that fetishizes novelty for its own sake. In the absence of such a valuation, industry would take a different direction and behave differently. Companies, of course, promote fast fashion, because it means higher sales.
Things are not guaranteed to become better. This is the fallacy of progress, the notion that the state of the world at t+1 must be better than it was at t. At the very least, it demands an account of what constitutes "better".
> I don't take it seriously, I believe in human ingenuity, and believe humans will overcome these obstacles
That's great, but that's not an argument, only a sentiment.
I also didn't say we'll experience necessarily a decline, only that LLMs are now trained on data produced by human beings. That means the substance and content is entirely derived from patterns produced by us, hence the appearance of intelligence in the results it produces. LLMs merely operate over statistical distributions in that data. If LLMs reduce the amount of content made by human beings, then training on the generated data is circular. "Ingenuity" cannot squeeze blood out of a stone. Something cannot come from nothing. I didn't say there can't be this something, but there does need to be a something from which an LLM or whatever can benefit.
> This is the "artisanal clothing argument".
> it is easier to 'discipline' the top 5 AI agents in the planet - rather than try to get a million distributed devs ("artisans") to produce high quality results.
Your take essentially is "let's live in a shoe box, packaging pipelines produce them cheaply en masse, who needs slow poke construction engineers and architects anymore"
Where have I said engineers/architects aren't necessary? My point is that it is easier to get AI to get better than try to improve a million developers. Isn't that a straightforward point?
What the role of an engineer in the new context - I am not speculating on.
> My point is that it is easier to get AI to get better than try to improve a million developers.
No it's not, your whole premise is invalid both in terms of financing the effort and in the AI's ability to improve beyond RNG+parroting. The AI code agents produce shoe boxes, your claim is that they can be improved to produce buildings instead. It won't happen, not until you get rid of the "temperature" (newspeak for RNG) and replace it with conceptual cognition.
Artisanal clothing is functionally equivalent to mass-produced clothing, but more expensive.
Much of contemporary software is functionally equivalent but more expensive to run and produce than previous generations. Chat, project management, document editing, online stores… all seem to have gotten more expensive to produce and run with little to no gain in functionality.
Complexity in software production and tooling keeps increasing yet functionally software is more or less the same as 20 years ago (obv. excluding advancements depending on hardware like video, 3D rendering, LLMs, etc.
Except I am not talking about clothing. You are guessing when you say "I'd think" based on your comparison to manufacturing clothing. Why guess and compare when you have more context than that? You're in this industry, right? The commodity of clothing is not like the commodity of software at all. Almost nothing is, as it doesn't really have a physical form. That impacts the economics significantly.
To highlight the gaps in your analogy; machinery still fails to match artisan clothing-makers. Despite being relatively fit, I've got wide hips. I cannot buy denim jeans that both; fit my legs, _and_ my waist. I either roll the legs up or have them hemmed. I am not all that odd, either. One size cannot fit all.
One issue is that tooling and internals have been optimized for individual people's tastes currently. Heterogeneous environments make the models spikier. As we shift to building more homogenized systems optimized around agent accessibility, I think we'll see significant improvements
Elegantly, agents finally give us an objective measure of what "good" code is. It's code that maximizes the likelihood that future agents will be able to successfully solve problems in this codebase. If code is "bad" it makes future problems harder.
> Elegantly, agents finally give us an objective measure of what "good" code is. It's code that maximizes the likelihood that future agents will be able to successfully solve problems in this codebase. If code is "bad" it makes future problems harder.
An analogous argument was made in the 90's to advocate for the rising desire for IDEs and OOP languages. "Bad" code came to be seen as 1000+ lines in one file because you could simply conjure up the documentation out-of-context, and so separation of concerns slipped all the way from "one function one purpose" to something not far from "one function one file."
I don't say this as pure refusal, but to beg the question of what we lose when we make these values-changes. At this time, we do not know. We are meekly accepting a new mental prosthesis with insufficient foresight of the consequences.
I don't disagree that shit is gonna get weird and not all the changes are good.
Ultimately I think we need to move away from the concept of codebases as they currently exist, towards "databases" of functionality that get composed as needed. Agents are going to make mixing and matching for bespoke purposes such a central paradigm that large monolithic packages don't make as much sense as they used to, just like monolithic apps make less sense in a world where agents programmatically call tools to do most work on computers.
Finally, someone articulates the middle better than I have:
> Thus, the extreme proponents of manic “agentic” vibe coding,[19] and the outright denouncers of LLMs, are both missing the forest for the trees. That there is a pragmatic middle path, where people who have the experience, expertise, competence, and the ability to articulate can use these tools to get the outcomes they desire with the right sets of trade-offs.
LLMs are tools. They are not gods to replace man, nor are they exclusively means of harm. It is entirely possible to denounce the blatant attempt of rent extraction in the form of OpenAI, Google Gemini, Microsoft CoPilot, Anthropic, and others, while still running Qwen and Ministral and their like on local hardware. You can, in fact, have it “both ways”.
As fun as it is to poke at cloud services to see their new features and advancements, I (in IT terms) personally could never recommend them in any serious enterprise context for the very reason that they’re fundamentally insecure; you will never, ever have full E2EE with these services because it would nullify their ability to evolve, improve, monetize, and exploit.
That said? I can truly be a one dinosaur army in an enterprise now, as a generalist with a modest Mac Mini (or Studio) and a local LLM to fill in edge cases as needed. I can query these local tools for questions on database schemas or build a one-off API integration for me, so I can focus on the substance of work in safeguarding and accelerating the enterprise. I don’t need fleets of specialists unless I’m running a huge conglomerate or have specific needs - and even then, it’s going to be cheaper to retain one or two seniors to direct the larger army of generalists when needed. The landscape has changed, and it’s why I target leadership and management roles accordingly with my sales pitch (“One senior generalist can do the work of three mid-level specialists”).
Don’t get me wrong, I still have immense grievances regarding theft of work, reductions in force, rent extraction, and the seeming attempt at destroying local general compute, but local LLMs as a tool have been in my kit for years, and that’s not going away.
From the article:
Evidence please. Ascribing many qualities to LLM code that I haven't (personally) seen at that scale. I think if you want to get an 'easily readable and maintainable' codebase of 10k lines with an LLM you need somebody to review its contributions very closely, and it probably isn't going to be generated with a 1 shot prompt.It’s like the google claim. There was a years worth of work up front, but AI took the typing from a few days to a day.
My perspective is that AI is a multiplier if existing skill (both positive and negative aspects). A bad developer can now produce bad code at 10x the rate and a good developer can produce good code at 10x the rate.
There is a net positive gain on the automated testing side of things but I think a bad developer, even with AI will not be able to out-compete a good 10x developer without AI. The costs of incorrect abstractions is just too high and LLMs don't really help avoid those.
You have to ask the right questions. It's a bit like in Hitchhiker's Guide to the Galaxy... Where a super-intelligent computer took millions of years to calculate the meaning of life as the number 42. The wrong question will always waste computation.
Okay I was writing a comment to simon (and I have elaborated some there but I wanted this to be something catchy to show how I feel and something people might discuss with too)
Both Code and talk are cheap. Show me the trust. Show me how I can trust you. Show me your authenticity. Show me your passion.
Code used to be the sign of authenticity. This is whats changing. You can no longer guarantee that large amounts of code let's say are now authentic, something which previously used to be the case (for the most part)
I have been shouting into the void many times about it but Trust seems to be the most important factor.
Essentially, I am speaking it from a consumer perspective but suppose that you write AI generated code and deploy it. Suppose you talked to AI or around it. Now I can do the same too and create a project sometimes (mostly?) more customizable to my needs for free/very-cheap.
So you have to justify why you are charging me. I do feel like that's only possible if there is something additional added to value. Trust, I trust the decision that you make and personally I trust people/decisions who feel like they take me or my ideas into account. So, essentially not ripping me off while actively helping. I don't know how to explain this but the most thing which I hate is the feeling of getting ripped off. So justifiable sustainable business who is open/transparent about the whole deal and what he gets and I get just gets my respect and my trust and quite frankly, I am not seeing many people do that but hopefully this changes.
I am curious now what you guys of HN think about this & what trust means to you in this (new?) ever-changing world.
Like y'know I feel like everything changes all the time but at the same time nothing changes at the same time too. We are still humans & we will always be humans & we are driven by our human instincts. Perhaps the community I envision is a more tight knit community online not complete mega-sellers.
Thoughts?
> because one is hooked on and dependent on the genie, the natural circumstances that otherwise would allow for foundational and fundamental skills and understanding to develop, never arise, to the point of cognitive decline.
After using AI to code, I came to the same conclusion myself. Interns and juniors are fully cooked:
- Companies will replace them with AI, telling seniors to use AI instead of juniors
- As a junior, AI is a click away, so why would you spend sleepless nights painstakingly acquiring those fundamentals?
Their only hope is to use AI to accelerate their own _learning_, not their performance. Performance will come after the learning phase.
If you're young, use AI as a personal TA, don't use it to write the code for you.
Young folks are gonna figure out how to use this stuff way better than us older folks. We just start with a big advantage.
as someone who is sort of a medior programmer it is very hard to balance, trying to keep up with the advancements in AI while not shooting myself in the foot by robbing myself of learning experiences
if it helps, that kind of thoughtfulness is how to learn the things that matter most. you're already on the right track.
> Code was always a means to an end. Unlike poetry or prose, end users don’t read or care about code.
Yes and no. Code is not art, but software is art.
What is art, then? Not something that's "beautiful", as beauty is of course mostly subjective. Not even something that works well.
I think art is a thing that was made with great care.
It doesn't matter if some piece of software was vibe-coded in part or in full, if it was edited, tested, retried enough times for its maker to consider it "perfect". Trash is something that's done in a careless way.
If you truly love and use what you made, it's likely someone else will. If not, well... why would anyone?
Well, why do humans read code:
1. To maintain it (to refactor or extend it).
2. To test it.
3. To debug it (to detect and fix flaws in it).
4. To learn (to get better by absorbing how the pros do it).
5. To verify and improve it (code review, pair programming).
6. To grade it (because a student wrote it).
7. To enjoy its beauty.
These are all I can think of right now, and they are ordered from most common to most rare case.
Personally, I have certainly read and re-read SICP code to enjoy its beauty (7), perhaps mixed in with a desire to learn (4) how to write equally beautiful code.
The best definition of art I've read is the one from "What is Art?" by Tolstoy. I haven't read it myself, but came across it in a Van Neistat video recently.
Tolstoy argued that art is essentially the transmission of feeling from the artist to the audience. He claimed that when an artist experiences an emotion and then, through their work, evokes that same emotion in others, that is art.
Art is expression. What the software provides (an experience) for which the artist (software engineer) expresses in code.
Code, talk, who cares. Show me the product. If it works and is useful I will incorporate it into my life. Ultimately no one cares how the sausage is made.
As for me, I'm looking forward to the Golden Age of Everyone Relearns Computer Security Is Important.
Uhh I kinda care? And some people do too? People have given software social permission so far. I have a feeling that it’s about to change. Engineers are thinking too narrowly about the effects of LLM assisted coding. They only see the shiny bits that benefit them.
> Ultimately no one cares how the sausage is made.
Yeah...now that prompt injection is a fact of life and basically unsolvable - we can't really afford this luxury anymore.
> there is no universal measure of what makes a codebase good or great.
We practically found one thought. The measure is: how well can an AI operate in/with your codebase.
I regularly find myself wondering if skeptics throwing around their empirical failure are obscuring their bad code/docs/setup.
I keep on wondering how much of the AI embrace is marketing driven. Yes, it can produce value and cut corners. But it seems like self driving by 2016 Musk prediction. Which never happened. With IPO/Stock valuations closely tied to hype, I wonder if we are all witnessing a giant bubble in the making
How much of this is mass financial engineering than real value. Reading a lot of nudges how everyone should have Google or other AI stock in their portfolio/retirement accounts
There's nothing to wonder about. It's obviously marketing.
The whole narrative of "inevitability" is the stock behavior of tech companies who want to push a product onto the public. Why fight the inevitable? All you can do is accept and adapt.
And given how many companies ask vendors whether their product "has AI" without having the slightest inkling of what that even means or whether it even makes sense, as if it were some kind of magical fairy dust - yeah, the stench of hype is thick enough you could cut it with a knife.
Of course, that doesn't mean it lacks all utility.
No need to wonder, just look at the numbers - investments versus revenue are hugely disparate, growth is plateauing.
Maybe we haven't seen much economic value or productivity increase given all the AI hypes. I don't think we can deny the fact that programming has been through a paradigm shift where humans aren't the only ones writing code and the amount of code written by humans I would say is decreasing.
What you are saying may have made sense at the start of 2025 where people were still using github copilot tab auto completes(atleast I did) and was just toying with things like cursor, but unsure.
Things have changed drastically now, engineers with these tools(like claude code) have become unstoppable.
Atleast for me, I have been able to contribute to the codebases i was unfamiliar with, even with different tech stacks. No, I am not talking about generating ai slop, but I have been enabled to write principal engineer level code unlike before.
So i don't agree with the above statement, it's actually generating real value and I have become valuable because of the tools available to me.
> Things have changed drastically now, engineers with these tools(like claude code) have become unstoppable
I’ve spent the last week unwinding my coworkers slop who said the same thing.
To be honest, what you have described only shows lack of process.
I am not talking about vibe coding here, which is totally different and understandable. But I am talking about the professional context where the structure is already in place.
Here is my workflow, if it helps:
1. I have a system level prompt i execute(command/skill) before I start anything which says things like
2. I give it the context of what I need to accomplish, and toggle the plan mode ask it follow the above things I have set at system level, and generate me a document to review step by step3. I review everything, add feedback to the generated plan, prompt again, and finally finalize the plan
4. now that the plan is finalized, I would have a small alignment with co-workers and ask it implement step by step, and then before proceeding with next step, i will tell it to ask me for feedback
each steps code is reviewed and commited, before proceeding to next step
5. once all steps are done, manual testing is done, i do a local review
6. I have a specific skill which reviews everything, and gives me feedback
7. we have human reviewers who will review the code, and coderabbit
8. then we take it to the staging and uat before taking to prod
so see we have not skipped any process of "software engineering", claude code is just an accelrant
but if you are not doing most of the above steps, i see what you are saying would happen by default
I realize many are disappointed (especially by technical churn, star-based-development JS projects on github without technical rigour). I don't trust any claim on the open web if I don't know the technical background of the person making it.
However I think - Nadh, ronacher, the redis bro - these are people who can be trusted. I find Nadh's article (OP) quite balanced.
> ronacher
I think he’s soured a bit on the 10x claim echoing many of the quality concerns expressed by others in this thread: https://lucumr.pocoo.org/2026/1/18/agent-psychosis/
When you mention Redis bro, I think you are talking about Antirez correct?
yeah, forgot his name.
>> Remember the old adage, “programming is 90% thinking and 10% typing”? It is now, for real.
> Proceeds to write literal books of markdown to get something meaningful
>> It requires no special training, no new language or framework to learn, and has practically no entry barriers—just good old critical thinking and foundational human skills, and competence to run the machinery.
> Wrote a paragraph about how it is important to have serious experience to understand the generated code prior to that
>> For the first time ever, good talk is exponentially more valuable than good code. The ramifications of this are significant and disruptive. This time, it is different.
> This time is different bro I swear, just one more model, just one more scale-up, just one more trillion parameters, bro we’re basically at AGI
Completely disagree that "software development, as it has been done for decades, is over".
AI is a useful tool, agreed - but it will always be reliant upon humans writing code.
Let's take a very simple example to prove my point. Let's say that everybody is now using AI to write code, and someone develops a new programming language with it. Cool! We have a new language now.
What we don't have, however, are any examples of how that programming language is used. Nothing that the AI can learn from.
How well do you think AI is going to handle being able to code in this new language which doesn't appear at all in its training data?
I was thinking about this and wonder if a LLM trained exclusively on the language spec and API docs would be able to generate code in it?
> One can no longer know whether such a repository was “vibe” coded by a non-technical person who has never written a single line of code, or an experienced developer, who may or may not have used LLM assistance
Usually one can tell quite easily, actually...
Ok imho this _blog’s_ words looks like stitching of some fancy words. Is this a thing for rich execs to write like this? Doesn't even convey the message easily.
Anyone who says with LLMs coding is over wasn’t that good at coding to begin with.
I would like articles like this to have a quick "who" and "what experience" is talking. I can usually tell the conclusions based on experience/skill level regardless, but it would be nice.
Also, that projects page on his website is atrocious; hate to be "that guy" but I don't trust the author's insight since "personal projects" seems to include a lot more than just his work; the first several PRs I looked at where all vibed.
I'm not interested in re-implementations of the same wheel over and over again telling me and people who know how to write real software (have been doing it since I was 12) that we are becoming unnecessary bc you can bully an extremely complex machine built on a base theory of heuristics abstracted out endlessly (perceptually) to re-invent the same specs in slightly different flavors.
> 100% human written, including emdashes. Sigh. If you can't write without emdashes, maybe you spend too much time with LLMs and not enough time reading and learning on your own. Also people can lie on the Internet, they do it all the time, and if not then I'm doing it right now.
The hubris on display is fascinating.
Lots of words to say that “now” communicating in regular human language is important.
What soft-skill buzzword will be the next one as the capital owners take more of the supposed productivity profits?
"Smalltalk is cheap". Sorry, couldn't resist, this was my slogan decades ago when I was advocating Smalltalk.
Long blog posts are cheap. Show me the prompt.
Prompts are cheap. Show me the spark of consciousness that brings the whole thing to life, that which makes all of it worthwhile and meaningful.
Talk is never cheap. Communicating your thoughts to people without the exact same kind of expertise as you is the most important skill.
This quote is from Torvalds, and I'm quite sure that if he weren't able to write eloquent English no one would know Linux today.
Code is important when it's the best medium to express the essence of your thoughts. Just like a composer cannot express the music in his head with English words.
You want a real mind bender? Imagine a universe where Linus's original usenet post didn't go viral.
I don't think Linus is a people person. This is something which he talks about himself in the famous ted-ed video.
I just re-watched the video (currently halfway) & I feel like the point of Linux is something which you are forgetting but it was never intended to grow so much and Linux himself in the video when asked says that he never had a moment where he went like oh this went big.
In fact he talks about when the project was little. On how he had gratitude when the project had 10 people maybe 100 people working on it and then things only grow over a very large time frame (more than 25-30years? maybe now 35 just searched 34)
He talks about how he got other people's idea which he couldn't have thought of things themselves and when he first created the project he just wanted to show off to the world to look at what I did (and he did it mainly for both the end result of the project and programming itself too) and then he got introduced to open source (free software) by his friend and he just decided to have it open source.
My point is it was neither the code nor the talk. Linus is the best person to maintain Linux, why? Because he has been passionate over it for 25 years. I feel like Linux would be just as interested in talking about the code and any improvements now with maybe the same vigour as 34 years ago. He loves his creation & we love Linux too :)
Another small point I wish to add is that if talk was the only thing, then you are missing the point because Linux was created because hurd was getting delayed (so all talks no code)
Linux himself says that if the hurd kernel would've been released earlier, Linux wouldn't have been created.
So all talk no code Hurd project (which from what I hear right now is still a bit limbo as now everyone [rightfully?] uses linux) is what led to creation of linux project.
Everyone who hasn't watched Linus's ted ed should definitely watch it.
The Mind Behind Linux | Linus Torvalds | TED : https://www.youtube.com/watch?v=o8NPllzkFhE
If you have a solid test environment that would allow for an agent to check if it is right or wrong, I encourage you to do the experiment.
Put the agent on the wheel and observe it as it tries ruthlessly to pass the test. These days, likely it will manage to pass the tests after 3-5 loops, which I find fascinating.
Close the loop, and try an LLM. You will be surprised.
Feels like this website is yelling at me with its massive text size. Had to drop down to -50% to get it readable.
Classical indicators of good software are still very relevant and valid!
Building something substantial and material (ie not an api wrapper+gui, to-do list) that is undeniably well made, while being faster and easier than it used to be, still takes a _lot_ of work. Even though you don't have to write a line of code, it moves so fast that you are now spending 3.5-4 days of your work week reading code, using the project, running benchmarks and experimental test lanes, reviewing specs and plans, drafting specs, defining features and tests.
The level of granularity needed to get earnestly good results is more than most people are used to. It's directly centered at the intersection between spec heavy engineering work and writing requirements for a large, high quality offshore dev team that is endearingly literal in how they interpret instructions. Depending on the work, I've found that I average around one 'task' per 22-35 lines of code.
You'll discover a new sense of profound respect for the better PMs, QA Leads, Eng Directors you have worked with. Months of progress happen each week. You'll know you're doing it right when you ask an Agent to evaluate the work since last week and it assumes it is reviewing the output of a medium sized business and offers to make Jira tickets.
It might be a mistake to think in terms of production costs.
The real "cost" of software is reliance: what risk do your API clients or customers take in relying on you? This is just as true for free-as-in-beer software as for SaaS with enterprise SLA's.
In software and in professions, providers have some combination of method and qualifications or authority which justifies reliance by their clients. Both education and software have reduced the reliance on naked authority, but a good track record remains the gold standard.
So providers (individuals and companies) have to ask how much of their reputation do they want to risk on any new method (AI, agile, ...)? Initially, it's always a promising boost in productivity. But then...
So the real question is what "Show me" means - for a quick meet, an enterprise sale, an enduring human-scale consumer dependence...
So, prediction: AI companies and people that can "show me" will be the winners.
(Unfortunately, we've also seen competitive advantage accrue to dystopian hiding of truth and risk, which would have the same transaction-positive effect but shift and defer the burden of risk. Let's hope...)
AI was never the problem we have been having a downgrade in software in general AI just amplifies how badly you can build software. The real problem is people who just dont care about the craft just pushing out human slop, whether it be because the business goes “we can come back to that dont worry” or what have you. At least with AI me coming back to something is right here and right now, not never or when it causes a production grade issue.
My latest take on AI assisted coding is that AI tools are an amplifier of the developer.
- A good and experienced developer who knows how to organize and structure systems will become more productive.
- An inexperienced developer will also be able to produce more code but not necessarily systems that are maintainable.
- A sloppy developer will produce more slop.
Please no. Talk is cheap.
I hate this trend of using adjectives to describe systems.
Fast Secure Sandboxed Minimal Reliable Robust Production grade AI ready Let's you _____ Enables you to _____
But somewhat I agree, code is essentially free, you can shit out infinite amounts of code. Unless it's good, then show the code instead. If your code is shit, show the program. If your program is shit, your code is worse, but you still pursing an interesting idea (in your eyes), show the prompt instead of the slop generated. Or even better communicate an elaborate version of the prompt.
>One can no longer know whether such a repository was “vibe”
This is absurd. Simply false, people can spot INSTANTLY when the code is good, see: https://news.ycombinator.com/item?id=46753708
I used to have the original quote as the first cell in my every Jupyter notebook. This is an amazing title for the current era.
premise is wrong. have seen a number of claude/codex disasters that never make it to production with clients, yet consumed an enormous amount of human time and bandwidth.
expertise and effort is and will continue to be for the forseeable future essential.
talk, like this, still cheap.
Regardless, knowing syntax of programming language or remember some library API, is a dead business.
I for one am quite happy to outsource this kind of simply memorisation to a machine. Maybe it's the thin end of the slippery slope? It doesn't FEEL like it is but...
Why even learn how to read when you can just yell at the computers?
> The real concern is for generations of learners who are being robbed of the opportunity to acquire the expertise to objectively discern what is slop and what is not. How do new developers build the skills that seniors generated through time? I see my seniors having higher success in vibe-coding than me. How can I short-circuit the time they put through for myself?
for a group of people as smart as developers, it sure took us long enough to realize billionaires were liquidating our code integrity to become trillionaires
code is cheap, show me the prompt
Uhh... how about show me both?
I think that's always been true. The ideas and reasoning process matter. So does the end product. If you produced it with an LLM and it sucks, it still sucks.
OK, fuck it, show me the demo (without staging it). show me the result.
I have replied to a comment adjacent to yours, for my parent comment. Please check i think if you follow the "process", it is avoidable.