ZH version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
56% Positive
Analyzed from 9212 words in the discussion.
Trending Topics
#code#software#llms#coding#solved#llm#more#don#doesn#things
Discussion (165 Comments)Read Original on HackerNews
What LLMs make possible is for me to say: find out all the ways this thing works. Analyze the different ways we can run this software, build a fuzzer, build property tests, and run this software in every scenario possible. Log full traces. Log all the outputs. Now, analyze each scenario for bugs. You can't do that by hand.
If we are committed to it, if we put the resources towards it and dedicate the time to it (and we could do this just by saying: it will take half as long as it used to take!), software built by llms in healthcare, finance, automotive, defense, power plans, aviation, manufacturing can all be made MORE reliable and better with LLMs... without ever reading a single line of code. The LLMS are very good at logic, by the way.
Anyway all of this reads like someone who is not actually using LLMs to build software or hasn't tried them in a while. I felt the same way in 2025. I've written 100s of thousands of lines of difficult code. You, the person reading this, has probably interacted with software I've written. For a time you would've interacted with it every time you made a debit card transaction in the united states, for example. I understand code, and care about quality, and that's why I'm all in on LLMs for code.
Testing isn’t the same as understanding the code, or proving (even informally) that it is correct. Having the LLM do all these things above doesn’t lead you or the LLM to understand the code, to logically reason about its behavior over all possible states and inputs.
“Finding out that it doesn't” means that you didn’t properly reason through the code beforehand, checking all your assumptions against what the code and underlying systems are actually guaranteeing. This may be a matter of formal education (proving computer science theorems and algorithmic correctness in university), I don’t know.
Reading the code may not be enough to understand the behaviour of your program, but believing you can understand the behaviour of a program without at least reading the high level code is truly silly.
(by high level, I mean the code living in the higher layers - of course we don't often read the code of the generated assembly, or the interpreter, or the browser, but that's because they're reliable abstractions, unlike prompts!)
Interpretability is the same, our abilities to do that have increased rather than decreased. I think a codebase generated by AI is actually more understandable than one generated by humans at this point, and you can ask clarifying questions whenever you get stuck.
TFA's points only make sense if the mental model the author has in mind is someone who writes a prompt then immediately puts an app into production without any thought behind it.
At my current place we not only have automated tests, static analysis and static rector but also: - architecture tests that define relationships between application layers - ADRs that guide developers (and agents as well) that communicate how new code should be written and how existing code should be treated
I find that "how code should look like"/"what code should do" is an ambiguous idea that always is preached, but never defined = everyone's idea of quality is slightly different and only looking at existing code you tend to align. Everyone's idea of what the product does/should is kept within their heads. LLM then can not only write code according to the patterns that are thus defined, review existing code based on these documents, but also actually read acceptance criteria documents to check if the code does what it's intended to do (by following gherkin)
Same goes for understandability - if LLM applies one pattern this time, another pattern another time, if you have multiple coding patterns then that hurts clarity. Sometimes LLMs work as common denominator thus achieving clarity, but I find that actually giving LLMs reference works.
I agree. What does coverage-guided fuzzing fuzz if there is 100% test coverage?
So, then, 100% branch test coverage is not a sufficient metric (because it doesn't indicate whether the code is fuzzed or formally verified for example).
Would Branch coverage even be a sufficient software quality metric if we were to instead measure how many times each branch of code is covered by tests? How to verify that one test which executes 100% of the code and runs only one assertion on, say, a CLI utility exit code integer is actually sufficiently covering?
> I think a codebase generated by AI is actually more understandable than one generated by humans at this point,
From doing a larger port (of sphinx, docutils, myst-md-parser, pygments, to rust in westurner/dsport) with a lot of human in the loop and currently ~80% branch coverage, this seems to be at least initially true but just like real life there's drift from even a good plan that you pay a more expensive model to prepare.
I suppose it's the same challenge as architectural drift in open source non-LLM-assisted products and the solutions are pretty much the same: give better instructions (AGENTS.md,) and use better sufficiency criteria as an engineering manager (branch test coverage, fuzzing, formal methods, TLA+), and train and pay humans to do secure code review.
Sometimes the agent doesn't notice that the code already solves for that and implements its own implementation with tests and it's wastefully redundant when the code should be refactored and the tests should be refactored so that we can delete code in order to minimize bloat.
Unfortunately often, just like IRL software development, the response from the agent is not sufficient to close the issue.
One proposed solution for this that is in retrospect obvious and also essential to success in "normal"/"traditional"/"legacy" (non-AI) engineering projects, is to always verify whether the candidate solution satisfies the criteria;
From "Groundtruth – checks your AI coding agent's claims against the Git diff" https://news.ycombinator.com/item?id=48838209 :
> "Follow up to verify that the work was actually satisfactorily completed"
> Are there other sound management practices that aren't yet effectively implemented in current gen agents?
Oh, and always write tests, docs, commit messages, and changelog entries; but don't waste tokens on documenting something that doesn't verifiably pass sufficient tests.
At least some places are abolishing formal QA because LLMs. There's a cult of speed uber alles that has a big intersection with LLM enthusiasm.
If coding were solved, then this would be true no?
This sounds like a typical testimonial whose mind has become captive to Claude. It is like Scientology.
if you're an MBA-brained exec who doesn't actively use LLMs to code and you just believe whatever slop it outputs at first without checking it, you're not going to realize how recklessly it can be used, how you need to be critical and skeptical of its outputs, that you need to explore it's reasoning and logic (which is still really easy compared to understanding legacy code and barely takes any time!)
say you also believe all this marketing hype about 'how dangerous (ie capable) AI agents are.' LLMs can do anything you think so you just say 'ship it' without building out the tooling and capabilities to enable faster code review and better tests. and to keep the shareholders happy, you start cutting jobs that you can't directly connect to a KPI (ie the platform/SRE team who would be the ones who can trial, onboard, and maintain those capabilities for your teams)
and from this, suddenly a lot of debit card stops working and the only one getting the blame are individual SWEs trying to hit their sprint velocity. the fact that you fucked up the whole SDLC real bad with your incompetence gets you a golden parachute and you job hop to a better paycheck. rinse and repeat
I've built payment rails. Six nines SLA, high capacity, resilient distributed systems.
I haven't written a single line of code since February, and I don't think I ever will again. These systems are incredibly good at replacing much of our work. They're only going to get better.
Rather than debating if these models are good (they are), we should be trying to figure out if most of us will still be around in three years. You don't need a two pizza team anymore.
"Look to the person to your left and to your right. Only one of you will remain by graduation" kind of energy. I'm not sure all of us is going to be in this career much longer. We'll have to see what the demand side looks like.
It must have been a huge shock when you were suddenly transported from a working parallel universe into ours back in 2024.
Correctness has never been a priority across an industry where rapid iteration and feature delivery drive sales. There's always some opportunity cost to doing things right, at the price of technical debt down the road. If AI is primarily used to produce fragile code, people will be wary of AI solutions. There's also ongoing public debate about AI safety and alignment. Deploying AI in safety critical applications feels riskier than ever in the current environment, even though it doesn't have to be.
"I never understood the code. You think it works a certain way, until you find out that it doesn't."
Bret Victor made a talk called "seeing spaces" in 2014 that should have woken up this whole industry: https://www.youtube.com/watch?v=klTjiXjqHrQ
He emphasizes that without the ability to see inside what is being built, creators often fall into "non-scientific thinking" (14:42), moving away from deep understanding and instead "blindly following recipes, from superstitions and rules of thumb" (14:47-14:51).
The worse is performance problems I've had engineers say some bizzaro things when discussing performance — we have the tools you can just measure the answer - we don't need to waste our time guessing
Those are two separate claims, unless by the former you mean “I never perfectly understood the code.” You can understand code imperfectly. And even with LLMs, you can’t get truly infallible guarantees about a system.
> I understand code
Are you sure?
> I understand code
Er, ok.
I guess time will tell if the consumer will adapt to the lower quality of products, allowing companies to justify the existence of lazy and incompetent developers, or if the consumer will push back, forcing companies to increase the quality of their developers.
Note: I use AI every day and it is entirely possible to create high quality software with it, so long as you are not lazy and incompetent.
Brings to mind this classification https://en.wikipedia.org/wiki/Kurt_von_Hammerstein-Equord#Cl...
"""I distinguish four types. There are clever, hardworking, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and hardworking; their place is the General Staff. The next ones are stupid and lazy; they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the mental clarity and strength of nerve necessary for difficult decisions. One must beware of anyone who is both stupid and hardworking; he must not be entrusted with any responsibility because he will always only cause damage"""
Now instead of 90% stupid and lazy (harmless, useful for grunt work) you have 90% stupid and hardworking (aggressively causing damage).
> I hope you can see the stupidity here if you expect to see any deterministic results at all.
Are you expecting humans to be deterministic in the code they produce?
And?
The p(that kind of error) is pretty small now. At what point does a probability coming out of an LLM look like "knowing", such that spitting out the wrong answer despite that probability looks like a health problem, a typo, or even just boredom? (Thinking of the Lizardman constant here: https://en.wiktionary.org/wiki/Lizardman%27s_Constant)
It's a continuum for both them and us, even if the mechanism is wildly different.
> Making mistakes is not the same as non-deterministic.
i.e. when the dismissal is "non-deterministic" when it should be "Making mistakes", is itself a mistake.
A couple more step functions in model capability of the type we've seen in the past year, and there will pretty much be no reason for humans to be involved in the development process at all. All humans would need to do is communicate clearly what needs to be made and flag problems as they come up.
It just gets “reviewed” by an LLM, which will find a nitpick while ignoring the huge fire in the core of the design, force the planner to make even more sloppy code to cover for an irrelevant test case. Rinse old tokens and repeat until you hit limits.
Yeah. To me it seems very much like the "use dynamic typing for everything" fad. You had a bunch of junior and/or incompetent developers who went around insisting that type declarations are bad, static typing slows down development, you just code so much faster if everything is dynamically typed. And in the context of a new project, they were totally right. It took a few years for the debt to finally catch up, and people realized that these massive, untyped monoliths they had were unmaintainable. Now the two biggest dynamic languages (Python/JavaScript) are effectively typed languages, because nobody uses their untyped variants for serious work.
Dynamic typing still has great uses -- interactive data exploration, putting together quick scripts (though less relevant with AI...), or even just simple prototypes -- but what we tried to do with it at the start, as an industry, was clearly dumb as hell. I suspect we'll look back in 5-10 years and realize that with some of the stuff we're doing with AI, too. It's already happened with things like Gastown.
I like to put this as "LLMS give lazy and incompetent developers more runway."
What I in general try to teach the other people about AI: It can be a great tool, but check the results! Especially in the case of engineering: Check and then double check.
This is all that's needed to actually use LLMs nowadays. How is it a "multiplier" rather than an "equalizer"?
Because without the responsible human engineer in the loop, it'll all gradually decay in a cascade of edge-cases. This happens with human written code as well (every "we'll replace this prototype before we ship" you've ever worked on), but with LLMs it happens at 10-100x the rate.
You will be surprised how many times, catches errores made by the AI coding agent. However,as you point, isn't deterministic. And you can guarantee the end results is 100% fine code
I totally understand where this is coming from. I too am struggling with accepting that my 30+ years of programming experience is quickly becoming obsolete. I'm losing sleep about this, it's tough.
But just go ahead and give the latest models (Opus 5.5 / Astra 6 as of today) another try. See what they are capable of and read the code which they produce. Any problem area, low level C++ or high level Typescript or Clojure or a weird combination of these..
Don't be shy, give them a big task, let them build an entire app, UI and all..
Now compare the output to Opus 4 or gpt-5 from 1 year ago - when they couldn't put together a single function without it being weird and buggy.
This is exactly my problem, not that the models are very good already, but how fast they got so good. So if coding is not solved yet, it'll get there very soon.
I can't think of a single example apart from perhaps the 99.9th percentile difficulty of work that wouldn't be solvable with that configuration.
Now the syntax is handled for you, you have a research assistant, and someone that can really dig through the details for you.
The rest ... is still there.
My issue with it, is that it gives you a "lazy" option every time that doesn't require the same level of thinking. I understand that this is completely on me as the developer, and the simple solution is that I need to make sure I'm taking my time to learn and understand what exactly the LLM is producing. I try this and have set up separate skills to make sure I'm building my understanding as I go.
Regardless, if I sit down today and implement something without the use of LLM, it takes me a lot longer, but once I get into it, I find a state of flow that I can never get from the back and forth reading of LLM output. Then when I finish, even if my solution is not perfect, I have learned so much more and my own context of problem is so much better, where usually then I can review with an LLM. This usually leaves me with a better implementation and more importantly one I can stand over. I think for a newer dev like me (~2 years experience), since I haven't built up years and years of problem solving experience, if I don't carve out time in my day to put down the AI tools and improve on my problem solving, I'll plateau and that's my biggest push against all this LLM use. I don't necessarily disagree that 'coding is solved', to be honest, I think it largely is, but it's still the foundation for me to be a good Software Engineer and I definitely haven't solved it.
But 'coding' per sey is 100% solved by LLMs - they write compiler perfect code all the time.
The question is not 'what it writes'.
The LLM is like a writer's assistant, who has perfect prose and grammar, but doesn't really write 'stories'.
""The reason LLMs are successful in writing code is because we’ve made a feedback loop that feeds the syntax/runtime errors back to the LLM and loops until most errors are solved or hidden."""
No - LLMs are 'good at code' because they have been ultimately 'trained' by the compiler.
All of the various SFT/RLHF methods etc. are using the compiler as the verifier.
So transportation is not solved either? In that case, beam me up Scotty, I can't see any hoverboards around.
This is not a good premise. All over law, you will find people made responsible for what they don't control and they kind of own. Unleash a dog that harms a child, or just have it in an environment where it can escape, and see what happens.
There is such things as unpredictable situations where one might not be held responsible, as a problem might occur well past reasonable guidelines.
So of course you can be held accountable for what an AI that uou supposedly cannot quite control does, or for the AI-written code you deliver. Treat it like the releasing a wolf pack, or selling an unsafe toy that can maim children. There's precedent everywhere.
The difference seems to be that some companies are above the law apparently.
[1] https://github.com/anthropics/claude-code/issues/88715
[2] https://github.com/anthropics/claude-code/issues/7547
> LLMs can wing it for tasks that are related to natural language (e.g. writing social media posts, reports, articles, etc.) but when it comes to code, the same engine that struggles to count number of R’s in “Raspberry” or suggests a walk to the carwash, also exposes other logical fallacies
Weirdly none of those things matter when writing code and actually LLMs fail at social media posts and articles to anyone who has seen enough of it can clock it's AI straight away, yet everyone who's used these models properly has solved harder problems than walk to the carwash with them, neither of the problems he's claiming are code were proposed as code problems or tested as code problems.
A lot of what's said just comes across as wishful thinking and being out of touch with the level of output current models can do, and I mean hard problems too.
I was just at the Explore DDD conference in Denver and a portion of Friday was sitting at the cafe tables informally discussing the impact of GenAI on software engineering with notable people. Most of these people were deeply concerned that if we lean into using GenAI for “everything” that our collective knowledge will dissipate. I was the vocal contrarian. There are many historical examples of humans obfuscating knowledge to simplify progress. Does anyone solder their own microchips at scale anymore? No. We have highly sophisticated robots and machinery to do that work with extraordinary outcomes. In software engineering, if you remove “coding” as a discipline you’re left with all the other aspects of designing software which I contend can be retargeted in college CS curriculum. The leap isn’t about code reviews. It’s about design reviews and that’s where better outcomes are served regardless of whether GenAI is involved or not. I have a roughly year old codebase at https://github.com/ChicagoDave/sharpee/ that is designed by me, but generated by Claude Code with my own skills and agents as guardrails. I’m fairly certain the code I extract from Claude doesn’t require human review, but the design of the system and its changes are continually reviewed by me. My contention is that we “collectively” are still trying to discern where the AI/human line is and most are still “holding” that line to human interactions. Let it go. Define what part you do need human decisions on and focus on those things.
/s
Just a simple reactor, my laptop's only little. But still.
I think a few of the industries listed like defense and aviation have low risk tolerance. However, from my (somewhat brief) experience of working in two health techs for a couple of years, I strongly disagree that healthcare has low risk tolerance for tech. Granted, they make run-of-the-mill CRMs, but I was baffled at how tolerable it is to have egregious user experience that makes users waste multiple hours per month with clerical work that is very painful because the UIs are very slow and buggy.
It means risk that the software stops working after an update. Which usually trades off iteration speed and best practices (i'm pretty sure the average startup has way better security practices by just delegating to google/aws than the average manufacturing software business) in exchange for a rigorous testing and rollout schedule.
So I'm also not sure that the article has a point at all, the human writing the code was never relevant to avoiding the "risk" in these industries in the first place.
I have no doubt that if you provide any AI system with an oracle with expected behavior that it can match that oracle with some amount of $ and tokens. I haven't seen any demonstration of anything else. Rewriting a codebase was always a challenge for humans not because of complexity, but because of the time and effort involved in matching the old version's prior behavior. It doesn't have anything to do with the serious level of work required to build something truly new from scratch in a performant way.
For example, any amount of software development involves fixing bugs, getting feedback from users on ideal workflows, an iteration loop of performance and bug tuning, etc. AI cannot simply create, from scratch, perfect software. Even using the SOTA models on max effort does not produce bug free software of any meaningful complexity or innovation out of the box. All that has changed is that the act of physically writing code and implementing existing patterns is now effectively a marginal cost.
Most line of business software is not e.g., delivering a company's income. Most software is in back-of-the-house internal products that do various internal tasks. I have no doubt that these processes are now far easier to build.
If the new Copilot is so great, why is it completely out of the current zeitgeist when compared to Codex and Claude Code?
GitHub's Copilot cloud agent offering is suffering with a case of some of the worst corporate ADHD I've seen. We built a cloud agentic development pipeline on it, and it seems like almost every other week they silently change something with zero public announcement or documentation that creates real disruption for our team.
That's real, breaking changes to the platform that clearly aren't being tested/reviewed before being pushed to prod. Again with zero public announcement or documentation.
Support is useless – we're paying customers in the 4-5 figures and our tickets go unanswered.
Especially expensive when you take into account the amount of that code which must have been boilerplate & meta-code in nature, meaning it should have been straightforward to move.
When the Go team ported the original compiler from C to Go, they wrote a program that did ~99% of the work
https://www.youtube.com/watch?v=QIE5nV5fDwA
https://go.dev/talks/2014/c2go.slide#18
would be curious to know how many times "unsafe" appears in there, have seen rust devs comment on how the ais like to use unsafe to work around difficulties with memory management, like how they will sometimes subvert tests
- Coding in the small is solved. I have a current state, I want to change it, and I know how I want to change it. Eg, I have a blocking TCP handler for some reason, and I want to make it async. I can either fiddle with it or just let LLM make the changes for me.
- Coding in the larger sense is never solved. You need judgement to decide what you want made. No matter what you're building, there will be decisions to make (Who/what is it for?) and those decisions change over time. LLMs can take some default decisions for you, and if you're fine with those, you get the default (great for POCs). However you might not even realize what it decided to do for you. At some scale, you will be spending a lot of time going over those decisions. But what we have now is that the friction of changing the decisions is quite a lot lower. You can now test a lot of things that previously were very time consuming.
- The point that LLMs are probabilistic is not as important as it's made out to be. If I ask a junior dev to code up something, I also don't know what he'll make. Heck, you can be sure that you are able to solve something, yet you yourself don't know what the solution will look like. Maybe it turns out the library you were going to use isn't appropriate after all. You don't know what you will use in the end, but you do know that something will fix the issue. There can be more than one solution to a problem, and it doesn't always matter which one you find.
- I STILL think that LLMs are at their best mostly as advanced predictive text. In the sense that it's mostly good at implementing things that you've decided are needed. This can mean a heck of a lot of code, but you have to know the tradeoffs. What was decided, what were the costs of those decisions in terms of maintainability, money, time to change it, and so on.
All this doesn't change the fact that software engineers are going nowhere because nobody trusts AI. If a model can escape highly secured sandboxes, then we're definitely not running these agents overnight on our systems. I am sure the next-gen of models will focus more on security and the trust factor will start developing, but that's a long way down the road.
People trust people, not systems.
As for accountability, it always laid with the employer. You think those nameless contractors whom Boeing hired suffered any consequences for that 737 Max glitch? Using AI won't change that.
AI doesn't have to solve all these coding problems to be worth handing the reins to it: it just has to substantially better on average than humans over the long haul, which it already is, especially if you have good verification of "done" and "working" in place through automated testing mechanisms. Perhaps we might say that QA is having its moment.
It doesn't mean humans aren't needed, but they aren't writing much if any code anymore.
Coding is not solved because you can’t simply prompt an LLM to make an AAA game or enterprise tool.
Instead, I think what's closer to solved and what we're in the process of solving is product development.
Story: A while ago, I had a few programmers who were really, really fast almost always missed the mark on the assignment wrong. I loved having them on projects because in the time my senior precise engineers could deliver a MVP, the fast engineers would build the wrong thing, collect feedback, reiterate, build the wrong thing, collect feedback, eventually inching closer and closer to a product people would pay for, and it would almost always get delivered faster than my seniors.
I feel AI does the same thing.
I got lazy around claude fable and astra, and asked them to work in loop (pick specified issue, develop it, qa it ...) have a separate CTO checking on arch.
at the end both models swore that the code is perfect and well designed and nothing is lacking.
I ran the software and it suddenly started writing large amount of data to CSV files instead of the typical DB usage.
AI decided to use csv for testing, and just drifted away. 0 regards to the actual project, 0 regards to common sense.
anecdotal but really weird, the project category is rather standard, I wouldn't accept such a mistake from a junior developer.
It compiled and ran just fine. If you weren’t reviewing the code holistically or keeping tight book keeping of your allocations you would not have noticed. Every single commit in isolation looks perfect. Very eye-opening
Isn't it the opposite? How to build something is rather solved, but what to build isn't?
But that's not solved in traditional product development either.
Product development an iterative process to get a product fully functional. In 2021, if you ask me what the timeline for a small product/substantial feature, I'd say a few weeks to a month to get a basic MVP, and then another 12 to 18 months to get a feature polished and in a good shape to be stable.
When people put it in the coding frame, what they do it as is saying we've gone from 18 months to minutes or days. That's just not true.
We have gone from eighteen months to depending on the complexity, a 1-4 months.
aside: To be candid though, the compressed time also means the frustrations people experience with a product in 18 months have also been compressed. They still exist, they're all there, they're now just non-stop.
That concept might work a lot of the time but you will definitely run into situations where that'll never produce a correct or working response. To actually learn something you need an environment/playground to apply what you think you know and observe the results. Without that you're not really learning, you're jus regurgitating what people want to hear.
Dear lord. Is that supposed to reflect the average thoughts and motivation of a person you want to hire? Or that of their employer?
Nobody has to be in fear, but we do have an ingrained knowledge that there are consequences, good and bad, for our actions
AI can write CRUD API endpoints almost perfectly now. It can also write quicksort, a heap, whatever much quicker than I can.
It really sucks at designing types and apis though and when it creates types and apis it doesn't think or plan for the future way the system will evolve (even if it's known up front how the system will evolve).
I suspect this will remain a problem for the models for a long time. All the things that the models are currently good at are the low hanging fruit of reinforcement learning for coding.
Think about the kind of reinforcement learning environment that needs to be created to train a model to become good at building and designing large scale software end to end. It would be a slog because you need to build the large scale software up front and then break it down to train the model to construct it in a systematic manner that allows for the software to evolve. And then you need enough of these training environments for it to generalize. I think they will eventually figure it out though but it may take a while.
Does that really matter? Those are things so that humans can better understand and extend a code base. That mattered when writing code was expensive and took time.
Now if it can pass all the tests it’s fine. If there’s an issue just have it rewrite things immediately. New bug? Generate a new test and rewrite code.
All, or many, of the old things that mattered just sort of don’t anymore.
Much of the code needs to be performant and the LLM knows this and grinds on it. Less and less human inspection is needed.
I think 90% of software can be written like this today.
You’re simply testing outputs. Make a spec but ultimately ungodly amounts of tests can be built quickly to ensure the program is outputting the right things.
However, software engineering isn't solved. Which is basically what this article is talking about. But having coding solved is still very beneficial - not long ago many software engineers would struggle very hard with turning a description of the logic required into syntactically correct code - and even for those capable it was incredibly time consuming.
So now the question becomes: Is software engineering solved? And my answer is no. People still need to read the code and understand the code and how it fits into the bigger picture. However, I feel like we are kidding ourselves if we think that we can go from producing code being a niche task for nerds to getting syntactically correct code from plain language without any deskilling of our work and careers. I feel like my personal "moat" has gone from "can speak computer" to "has ok reading, writing, comprehension and judgement skills" (I hate the word "taste" being used here ).
At the same time - I don't yet feel like there's a sudden abundance of competent software engineers - it's just that the folks who used to submit untested spaghetti code now submit big bowls of barely working slop. So maybe it the moat was never "can speak computer" - that was just the expression of more general skills.
The existential question for me is how far the deskilling will go. Because right now - you still need a solid grasp on computer science and software engineering concepts to do this job, as well as sufficient levels of grit and problem solving ability - but I'm not too confident that will last, and when it goes I don't think many of us will find this career enjoyable.
They are thinking: Please input everything you know, or just use it and it will collect everything in your PC or server automatically.
Stop lazy, stupid and dangerous behaviors.
It's not clear to me if the claim is:
(1) "If you used an LLM to generate code, and the code works, you're wrong if you think the code is okay"
or
(2) "If you used an LLM to generate code, you reviewed the code and found it to be of decent quality, then you're wrong".
> If you’re toying around, LLMs do a great job. That’s why some of the most aggressive proponents of the “coding is solved” narrative have nothing to show for it.
I also don't get the "LLM proponents have nothing to show for it" statement.
It's really quite common now to see on HN all sorts of LLM-assisted programming projects. The quality varies from slop where little thought was put into it, to high quality results where LLM coding assistance was able to let talented developers produce things they otherwise wouldn't have time to do.
I'd say it's obvious that LLM coding agents can be very useful for a lot of programming related tasks.
EDIT: That is to say, LLMs are obviously useful for use cases above/beyond toying around. It's not a dichotomy between "I'm never touching an AI" and "thoughtlessly accepting everything the LLM outputs".
"coding is solved" == "gastown-like systems give a brand-new and useful software"
I don't recall whether GasTown succeeded...
Over this weekend in chat with the games discord watching as it iterated a harness built an entire implementation of the board game terraforming mars https://tfmbot.com using agents and harnesses for them.
I think if you can implement a board game end to end by feeding in the rulebooks and having a harness spawn agents to validate it’s reasonably solved.
But they gathered employees who had been working as PMs at that company and developed a product using only prompts. It turned into a project where fixing one bug created ten more, and nobody could understand why the bugs were being generated.
Management framed it as "the beginning of in-house development and the end of outsourcing," but the employees who actually contact me about work say things are going badly.
In fact, there have been several incidents in Korea related to vibe coding.
So I don't think coding is a solved problem.
Even when I code with AI, it's not really my code, so fixing bugs is hard... I don't think coding is a solved problem.
That's not a boast, I don't think I was particularly good at that back then, e.g. I didn't really get how to think about automated tests until much later.
It's just to say that no, coding and software engineering are not the same thing. "Code Monkey" is a dead (or perhaps "undead") role now, but it wasn't always so.
What’s your number?
"Don't confuse coding with software engineering" is a valid point, the rest seems like ranting.
If you were a professional software developer, you a) learned to touch type, b) started using vim/emacs keybindings to navigate around the project, and c) used a framework which already abstracted away a large part of the menial work.
And going all-in on the loop and no-code-review nonsense in a project someone is actually paying you for, I can only assume means you're hoping not to be around when the slop tower collapses.
The real tension is in the human AI interface and there are many unknowns. Can a software engineer with weak design skill use AI to produce good code. Will the future make those requisites less important. Will productivity increase with AI stagnate even for the best. Can a new way to interface humans and AI break that wall. Will software be created in a new way using dynamic libraries that AI agents prepare to cover a large scope of problems. Nobody knows yet. The article is strong on what is closed, accountability, ownership, NFRs, slop, and silent on what is open, which is where the argument actually is.
So - prose, code, or image, it appears that some work has been done, but in fact the [actually needed] work has likely not been done.
I don't like the feeling being judged and tested by the author (missing number 5 point in the list).
Doesn't matter what you think about AI, "it isn't perfect" is clearly a nonsense reason not to object to it.
It's for example impossible to have a discussion with an LLM where you both learn something which you can apply tomorrow. The LLM doesn't learn until the next model is released and by then your discussion is just a tiny fraction of the training data (if present at all). AGENTS.md, skills and so on are just a proxy for what we actually want, an agent that listens and understands. A proxy mind you, that requires constant tweaking with no sign of generalisation in sight.
I'm also not sure what humans being non-deterministic even means here. The point is if you're comparing results with NFR, pure agentic coding falls short.
If anyone has counter-arguments or cares to make me smarter, I'm all ears.
But maybe I'm misremembering how fragile GH was in the 2010s.
But to anyone even vaguely thinking of taking this seriously, go look at what antirez, dhh, jared sumner, mark brooker, and many other real engineers who have ship real things are doing and saying.
Most of these people have spent their entire lives contributing to open source, and they have proved their skill shipping working software and scale for decades. They are really trying to help people by showing and telling them exactly how AI works and how to use it to make better software.
Long term planning in LLMs has not been solved.