Copying from another post. I’m very puzzled on why people don’t talk more about essential complexity of specifying systems any more:
In No Silver Bullet, Fred Brooks argues that the hard part of software engineering lies in essential complexity - understanding, specifying, and modeling the problem space - while accidental complexity like tool limitations is secondary. His point was that no tool or methodology would "magically" eliminate the difficulty of software development because the core challenge is conceptual, not syntactic.
Fast forward to today: there's a lot of talk about AI agents replacing engineers by writing entire codebases from natural language prompts. But that seems to assume the specification problem is somehow solved or simplified. In reality, turning vague ideas into detailed, robust systems still feels like the core job of engineers.
If someone provides detailed specs and iteratively works with an AI to build software, aren’t they just using AI to eliminate accidental complexity—like how we moved from assembly to high-level languages? That doesn’t replace engineers; it boosts our productivity. If anything, it should increase opportunities by lowering the cost of iteration and scaling our impact.
So how do we reconcile this? If an agent writes a product from a prompt, that only works because someone else has already fully specified the system—implicitly or explicitly. And if we’re just using AI to replicate existing products, then we’re not solving technical problems anymore; we’re just competing on distribution or cost. That’s not an engineering disruption—it’s a business one.
I think the crux is that specification has been neglected since even before AI.
Stakeholders (client, managers) have been "vibe coding" all along. They send some vague descriptions and someone magically gives back a solution. Does the solution completely work? No one knows. It kinda works, but no one knows for sure.
Most of the time, it's actually the programmers' understanding of the domain that fills out the details (we all know what a correct form submission webpage looks like).
Now the other end has become AI, it remains to be seen whether this can be replicated.
with all due respect but what does this mean? we can either "all know" or we can all not have a clue and have our own "visions" of the correct form, both of these are complete opposites.
decades of building garbage-barely-working forms is a proof that we just do not know (much like we (generally) don't know how to center a div on the page so once-per-year, without fail, top story on HN is "how to center a div" :) ).
This is spot-on, and a comment I wish I could pin for others to see.
GenAI is such a boon at present because it occasionally delivers acceptable mediocrity to PMs and Stakeholders who will accept said mediocrity because they have no real clue what they (or their customers) actually want. It’s a system of roles and output that delivers based on patterns in incomprehensively large data sets, provided to humans who cannot hope to validate that information is accurate or legitimate (and not just random patterns in a large enough data set), but passed along as gospel from digital machinegods. To a withering empire obsessed with nostalgia and whose institutions are crumbling beneath them, GenAI appears as a savior; to those confident in their position in the world order, it is merely a thin tool in a larger toolbox, to be used toward greater ends rather than middling output.
Those who understand the specification problems are in a position to capitalize off such monumental shifts, while those blindly chasing get-rich-quick schemes, grifts, and fads will be left behind.
Or you are in Germany and phone number have variable length. They even have the word “number street” to mean “all phone numbers starting with 0123456” for example. It’s not a block, it’s a street, which can branch out in blocks of different lengths. Completely insane.
The split between essential and incidental complexity is a really key insight for thinking about how far AI can be pushed into software development. I think it's likely the detail many developers are feeling intuitively but not able to articulate, in regards to why they won't be replaced just yet.
It's certainly how actually using AI in earnest feels, I have been doing my best to get agents like Claude to work through problems in a complex codebase defined by enormous amounts of outside business logic. This lack of ability to truly intuit the business requirements and deep context requirements means it cannot make business related code changes. But it can help with very small context code changes, ie incidental complexity unrelated to the core role of a good developer, which is translating real world requirements into a system.
But I will add that it shouldn't be underestimated how many of us are actually solving the distribution problem, not technical problems. I still would not feel confident replacing a junior with AI, the core issue being lack of self-correction. But certainly people will try, and businesses built around AI development will be real and undercut established businesses. Whether that's net good or bad will probably not matter to those who lose their jobs in the scuffle.
A terrifyingly large percentage of people employed to write software cannot write software. Not even a little. These are the people that can be easily replaced.
In my prior line of work I wrote JavaScript for a living. There were people doing amazing, just jaw dropping astounding, things. Those people were almost exclusively hobbyists. At work most people struggled to do little more than copy/paste in a struggle just to put text on screen. Sadly, that is not an exaggeration.
Some people did what they considered to be advanced engineering against these colossal frameworks, but the result is just the same: little more than copy/paste and struggle to put text on screen. Yes, they might be solving for advanced complexity, but it is almost always completely unnecessary and frequently related to code vanity.
Virtually none of those people could write original applications, measure anything, write documentation, or do just about anything else practical.
> So how do we reconcile this?
Alienate your workforce by setting high standards, like a bar exam to become a lawyer. Fire those people that fail to rise to the occasion. Moving forward employ people who cannot meet the high standards only as juniors or apprentices, so that the next generation of developers have the opportunity to learn the craft without rewarding failure.
> Alienate your workforce by setting high standards, like a bar exam to become a lawyer ...
This would work if the world was willing to pay for software. So at the very least you'd have to outlaw the ad-based business model, or do what lawyers do: things that are absolutely critical for software development (think "program needs to be approved or it won't execute", that deep) that normal people aren't allowed ... and unable ... to do.
From a purely economic perspective its all the same whether you are paying for products or paying for people and whether your revenue comes for media or sales. Those cost/profit first concerns are entirely the wrong questions to ask though, because they limit available routes of revenue generation.
The only purpose of software is automation. All cost factors should derive from that one source of truth. As a result the only valid concerns should be:
* Lowering liabilities
* Increasing capabilities
From a business perspective that means not paying money for unintended harms, and simultaneously either taking market share from the competition or inventing new markets. If your people aren't capable of writing software or your only options are free choices provided to you then you are the mercy of catastrophic opportunity costs that even the smallest players can sprint past.
An easy answer for what's missing is that the industry isn't run by people who read "No Silver Bullet".
- Articles about tricky nature of tech debt aren't written by people who call the shots on whether the team can spend the entire next week on something that a customer can't see.
- Articles about systems architecture aren't written by people who decide how much each piece of work was significant for business.
- Books on methodologies are optional read for engineers, not essential for their job, and adoption happens only when they push it upwards.
Most of the buzz about AI replacing coding is coming from people who don't see a difference between generating a working MVP of an app, and evolving an app codebase for a decade and fixing ancient poor design choices in a spaceship which is already in flight.
I've even seen a manager who proposed allocating 33% time every day on 3 projects, and engineers had to push back. Such old and common knowledge that it doesn't work is apparently still not a job requirement in 2025. Despite that organizing and structuring project time allocation is management competency and not an engineering skill, it is de-facto entirely up to engineers to make sure it's done right. The same managers are now proud to demonstrate their "customer focus" by proposing to ask AI to resolve all the tech debt and write all the missing tests so that engineers could focus on business requests, and same engineers have to figure how to explain why it didn't just work when they tried.
To talk about complexity is to repeat the same old mistake. I am sure most engineers already know and I am yet to see an experienced engineer who believes their job will be taken by simple prompts. The problem we should be talking about should be titled something like,
"Software Engineering Has Poor Management Problem, and AI is Amplifying It"
People (especially people who don't have a lot of hands on tech experience, or students who also aren't into building things) get the sense that writing software requires learning a lot of arcane tools. And the idea is to promise that anyone who can write a specification should be able to make software (yes, handwaving away the learning to specify well, which is a real skill with many dependent skills). This was the promise of no-code, and then they realized that the no-code system (in addition to usually being limited in power) is actually complex and requires specialized learning, and more of that the more powerful the system is. The LLM will replace SWEs approach is another take on that, because you don't need to learn a system, you prompt in natural language, and the model knows how to interface with the underlying system so you don't have to. In that sense, vibe coding is already the culmination of this goal (despite weaknesses such as maintainability issues).
I've seen it written that the main reason managers tend to want to get rid of SWEs is because they don't understand how to interface with them. Using an LLM solves that problem, because you don't need a nerd to operate it.
> I've seen it written that the main reason managers tend to want to get rid of SWEs is because they don't understand how to interface with them
That’s because software is nebulous enough that you can get away with promising the moon to customers/boss, but in the next meeting, you’re given a reality check by the SWEs. And then you realize the mess you’re thrown everyone in.
Managers knows how to interface with SWEs well (people interface with professionals all the time). Most just hates going back to the engineers to get real answers when they fancy themselves as products owners.
> Using an LLM solves that problem, because you don't need a nerd to operate it.
Until you do. LLMs are great ar building prototypes but at some point if you don’t know what you’ll doing you’ll end up with an unmaintainable mess and you won’t have anyone to fix it.
I mean LLMs perhaps are capable of doing that too but they still need to be guided by people who are capable of understanding their output.
Being able to reduce the number of engineers that you need by e.g. 80% would still be a great deal though.
I'm not sure what the answer is - but I will say that LLMs do help me wrangle with essential complexity / real-world issues too.
Most problems businesses face have been seen by other businesses; perhaps some knowledge is in the training set or perhaps some problems are so easy to reason through that a LLM can do the "reasoning" more-or-less from first principles and your problem description.
I am speculating that AI will help with both sides of the No Silver Bullet dichotomy?
So in other words it's helping you race to the median. It can give your business the advantage of moving always in a direction that's average and uninteresting. Nobody will need to lead anymore, so nobody will have the skill of a leader anymore.
It sounds to me like a corporate equivalent of a drug-fueled rager. They want everything good now while deferring all the expenses to tomorrow.
Yeah, I give it about two years until we get to "Hey AI, what should we do today?" "Hi, I've noticed an increase in users struggling with transactions across individual accounts that they own. It appears some aspect of multitenancy would be warmly received by a significant fraction of our userbase. I have compiled a report on the different approaches taken by medium and large tech companies in this regard, and created a summary of user feedback that I've found on each. Based on this, and with the nuance of our industry, current userbase, the future markets we want to explore, and the ability to fit it most naturally into our existing infrastructure, I have boiled it down to one of these three options. Here are detailed design docs for each, that includes all downstream services affected, all data schema changes, lists out any concerns about backwards compatibility, user interface nuances, and has all the new operational and adoption metrics that we will want to monitor. Please read these through and let me know which one to start, and if you have any questions or suggestions I'll be more than happy to take them. For the first option, I've already prepared a list of PRs that I'm ready to commit and deploy in the designated order, and have tested e2e in a test cluster of all affected services, and it is up and running in a test cluster currently if you would like to explore it. It will take me a couple hours to do the same with the other two options if you'd like. If I get the green light today, I can sequence the deployments so that they don't conflict with other projects and have it in production by the end of the week, along with communication and optional training to the users I feel would find the feature most useful. Of course any of this can be changed, postponed, or dropped if you have concerns, would like to take a different approach, or think the feature should not be pursued."
Yeah, PM, data science, compliance, accounting...all largely automatable. You just need a few directors to call the shots on big risks. But even that goes away at some point because in a few months it'll have implemented everything you were thinking about doing for the next ten years and it simply runs out of stuff for humans to do.
What happens after that, I have no idea.
Seems like OpenAI (or whoever wins) could easily just start taking over whole industries at that point, or at least those that are mostly tech based, since it can replicate anything they can do, but cheaper. By that point, probably the only tech jobs left will be building safeguards so that AI doesn't destroy the planet.
Which sounds niche, but conceivably, could be a real, thriving industry. Once AI outruns us, there'll probably be a huge catastrophe at some point, after which we'll realize we need to "dumb down" AI in order to preserve our own species. It will serve almost as a physical resource, or maybe like a giant nuclear reactor, where we mine it as needed but don't let it run unfettered. Coordinating that balance to extract maximal economic growth without blowing everything up could end up being the primary function of human intelligence in the AI age.
Whether something like that can be sustained, in a world with ten billion different opinions on how to do so, remains to be seen.
You're right but I think we will be among the first to take the hit, we don't have the regulatory protections many doctors, accountants and lawyers have.
Kind of, but the models also output really awful code, even if it appears to work, and people (especially juniors) will push that awful code into PRs and people eventually approve of it because there's engineers who don't care about the craft, only collecting a paycheck. Then when things break or slow down to a crawl, nobody has any idea how to fix it because its all AI generated goop.
I think AI also introduces a new form of accidental complexity. When using Copilot, I often find myself telling it something to the effect of, “this seems needlessly complex and confusing, is there a better way to do this, or is this level of complexity justified?” It almost always apologizes and comes back with a solution I find much more pleasing, though on rare occasions it does justify its solution as a form of the original accidental complexity you mention. The more we lean on these tools, the more this accidental complexity from the model itself compounds.
There is a lot of truth in No Silver Bullet and I had the same idea in my mind.
Downside is there is much more non essential busy work because of which people had their jobs and now loads of those people will lose the job.
People who do work on real essential complexity of systems are far and between. People who say things like "proper professionals will always have work" are utter assholes thinking mostly that "they are those proper professionals".
In reality AI will be like F1 racing team not needing pit workers and have only drivers, how many drivers are there like 20 so it is 10 teams each having 2 drivers. Each team has 300-1000 people that do all the other things.
If you go to corporate level let's say 1 person working on essential complexity requires 10-20 people doing all kinds of non essential stuff that will be taken over by AI, or to be realistic instead of 10-20 people that person will need headcount of 5.
That is still 15 people out of job - are those people able to take over some essential complexity in a different company or different area of the same company, some would but it is also if they would like to do it. So those people will be pushed around or end up jobless, bitter whatever.
What you are saying is true. In a way, programmers still need to think about and wrestle with architectural complexity. And I agree the biggest overall gain is adding another layer of abstraction. But combine those two things and suddenly you have junior engineers that can very quickly learn how to architect systems. Because that will be the bulk of the job and they will be doing it every day.
Once you remove all the roadblocks with syntax and language blindspots, the high cost of refactoring, the tedium of adding validation and tests, the challenges of integrating systems... suddenly, the work becomes more pure. Yes, you need to know how to do advanced structural things. But you don't need to learn very much about all the rest of it.
And we very quickly get to a point where someone who can break down problems into tidy Jira tickets is effectively programming. Programming was never really about learning languages but making computers do things, which is a transferrable skill and why so many engineers know so many languages.
Even the simplest tickets sometimes that end up requiring a one line change can require hours of investigation to fully understand/stamp the effects of that change.
And perhaps I havent used the greatest or latest, but in my experience LLMs break down hard st anything sufficiently large. They make changes and introduce new errors, they end up changing the feature, or worst case just ouright break everything.
Id never trust it unless you have an extensive amount of good tests for validation
Actually, you're not missing anything. The thing is, hype cycles are just that, cycles. They come around with a mix of genuine amnesia, convenient amnesia, and junior enthusiasm, because cycles require a society (and/or industry) both able and willing to repeat exploration and decisions, whether they end up in wins or losses. Some people start to get get the pattern after a while but they are seen as cynics. After all, the show must go on, "what if this or the next cycle is the one that leads us to tech nirvana?"
Software engineering for any non-trivial problem means a baseline level of essential complexity that isn't going away, no matter the tool, not even if we someday "code" directly from our minds in some almost-free way via parallel programming thought diffusion. That's because (1) depth and breadth of choice; and (2) coordination/socials, mostly due but not uniquely related to (1) are the real bottlenecks.
Sure, accidental complexity can shrink, if you design in a way that's aligned with the tools, but even then, the gains are often overhyped. These kinds of "developer accelerators" (IDEs, low-code platforms, etc.) are always oversold in depth and scope, LLMs included.
The promise of the "10x engineer" is always there, but the reality is more mundane. For example, IDEs and LSPs are helpful, but not really transformative. Up to a point that people are being payed right now and don't use them at all, and they still deliver in a "economically justifiable" (by someone) way.
Today it's LLMs. Tomorrow it'll be LISP Machines v2.
You first start using a hammer well, and then internalizing when to use a hammer. Most are now getting excited about the new shinny hammer. Few knows hammer is not for everything. Some will never know. It has always been the case. Microservice, NoSQL, kubernetes, crypto, web3, now LLM. They range from useful some of the time to completely useless. But they surely appeared to be panacea at some time to some people.
You're missing the part where building a modern website is a huge amount of dev time for largely UI work. Also modern deployment is 100x more complicated than in Brook's day. I'd say 90% of my projects are on these two parts which really shows how productivity has gone down (and AI can fix)
This is mostly self inflicted though. We create complex deployments with the promise that the incremental savings will overtake the upfront costs when they rarely do (and the hidden complexity costs).
So it seems AI will just let us stretch further and make more accidentally complex systems.
The value of automation ("complex deployments") is not only incremental cost savings (ie because you don't need to do the work over and over), but also the reduction or outright elimination of human error, which especially in the case of security-sensitive activities like deploying software on the Internet can be orders of magnitude more costly than the time it takes to automate it.
Back when IE was king and IE6 was still 10% of users, I did frontend web work. I remember sitting next to our designer with multiple browsers open playing with pixel offsets to get the design as close as practically possible to the mockups for most users and good enough for every one else. This isn't something LLMs do without a model of what looks good.
My current job involves exactly this (thanks not on IE) and AI is, as you said, absolutely bad at it.
And I’m saying this as someone who kind of adopted AI pretty early for code and who learned how to prompt it.
The best way to make AI worth your time is to make it work towards a predictable output. TDD is really good for this : you write your test cases and you make the AI do the work.
But when you want a visual result ? It will have no feedback of any clue, will always answer "Ok, I solved this" while making things worse. Even if the model is visual, giving it screenshots as feedback is useless too.
Modern development is more complex, not more complicated. We’re still using the same categories of tools. What’s changed is the tower of abstraction we put between ourselves and the problem.
> aren’t they just using AI to eliminate accidental complexity
After using Claude Code to vibe code some stuff, it seems to me that AI doesn't eliminate accidental complexity, it just creates more of it and takes away some of the pain of really bad APIs.
> it should increase opportunities by lowering the cost of iteration and scaling our impact
This is very much up for debate and the weakest point of the argument I think. If developers are now 2-3x (remains to be seen..) as productive what will happen to the job market?
I suppose it depends on how much potential software is there that's not currently viable due to cost? How much would scope be increased on current products?
I agree on the essential complexity, but I think there is a missing piece that we don't really have good mental tools how to operate (compose) the SW systems with uncertainty. Something like fuzzy logic?
I think there is a promise of that in AI and LLMs (but I remain skeptical, because I it needs a formal and not ad hoc definition). The idea you can build the systems using a fuzzy human language and the things will somehow work out.
you're spot on. Building software is first and foremost making a team of person understand a problem. The fact that part of it is solved by writing code is almost a byproduct of that understanding, and certainly does not come before.
on this topic I suggest everybody who works in our industry to read Peter Naur's "Programming as Theory Building"[1] and a nice corollary from Baldur Bjarnson: "Theory-building and why employee churn is lethal to software companies"[2]
i think the difference is that now someone with no coding knowledge could start describing software and make the agent build that software iteratively. so for example a mechanical engineer wants to build some simulation tool. you still need to define those requirements and understand what you want to do but the work could be (and this is the big if still, if agents become good enough for this sort of work) done by the agent not a humand programmer. i do not see that happening at the moment but still this does change the dynamic. you are right in that it is not a silver bullet and a lot of the complexity is impossible to get rid of. but i wonder if for a lot of use cases there will not be a software engineer in the loop. for bigger systems, for sure, but for a lot of smaller business software?
A mechanical engineer has a job to do. They can't all spend their time yak shaving with an AI agent building software that they then use to do their actual job. The whole point of building software is it's more efficient to build it once then use it many times. Why would a "someone with no coding knowledge" do this when someone with coding knowledge could do it?
Small businesses often understand domain less, not more, because they cannot invest as much as big businesses in building expertise. They may achieve something within that limited understanding, but the outcome will limit their growth. Of course, AI can help with discovery, but it may overcomplicate things. Product discovery is an art of figuring out what to do without doing too much or not enough, which AI has not mastered yet.
This totally breaks due to complexity. This "works", except that AI destroys earlier functionality when adding new things. Also there is a very low level of complexity where AI just blows up and won't work anymore, not even a little bit.
(and certainly Google's newest AI model is actually a step backwards on this front)
Add to that that nothing changes for difficult work. Writing a driver still requires hardware knowledge ... of the actual hardware. Which AI doesn't have ... and doesn't make any attempt to acquire.
I've seen articles that this part can actually be fixed. If you create a loop where the AI is forced to slowly build up low-level knowledge it can actually find this sort of things. But you need 10 expert AI researchers to do anything like this.
(frankly I don't see how this part could be fixed by better AI models)
What's in danger is the coding job consisting of "write me a form with these 20 fields". The 100% repetitive ones.
Making any non trivial system with AI only highlights this problem. My repo is littered with specs the AI has to refer to to build the system. But the specs are unclear files that have been added to and grown outdated over time, so now we often end up gling back and forth without much progress.
I don't think anyone thinks engineers are going away. But companies will hire less employees to do the same amount of work, and they won't pay engineers more.
… because programming languages are the right level of precision for specifying a program you want. Natural language isn’t it. Of course you need to review and edit what it generates. Of course it’s often easier to make the change yourself instead of describing how to make the change.
I wonder if the independent studies that show Copilot increasing the rate of errors in software have anything to do with this less bold attitude. Most people selling AI are predicting the obsolescence of human authors.
Transformers can be used to automate testing, create deeper and broader specification, accelerate greenfield projects, rapidly and precisely expand a developer's knowledge as needed, navigate unfamiliar APIs without relying on reference, build out initial features, do code review and so much more.
Even if code is the right medium for specifying a program, transformers act as an automated interface between that medium and natural language. Modern high-end transformers have no problem producing code, while benefiting from a wealth of knowledge that far surpasses any individual.
> Most people selling AI are predicting the obsolescence of human authors.
It's entirely possible that we do become obsolete for a wide variety of programming domains. That's simply a reality, just as weavers saw massive layoffs in the wake of the automated loom, or scribes lost work after the printing press, or human calculators became pointless after high-precision calculators became commonplace.
This replacement might not happen tomorrow, or next year, or even in the next decade, but it's clear that we are able to build capable models. What remains to be done is R&D around things like hallucinations, accuracy, affordability, etc. as well as tooling and infrastructure built around this new paradigm. But the cat's out of the bag, and we are not returning to a paradigm that doesn't involve intelligent automation in our daily work; programming is literally about automating things and transformers are a massive forward step.
That doesn't really mean anything, though; You can still be as involved in your programming work as you'd like. Whether you can find paid, professional work depends on your domain, skill level and compensation preferences. But you can always program for fun or personal projects, and decide how much or how little automation you use. But I will recommend that you take these tools seriously, and that you aren't too dismissive, or you could find yourself left behind in a rapidly evolving landscape, similarly to the advent of personal computing and the internet.
> Modern high-end transformers have no problem producing code, while benefiting from a wealth of knowledge that far surpasses any individual.
It will also still happily turn your whole codebase into garbage rather than undo the first thing it tried to try something else. I've yet to see one that can back itself out of a logical corner.
This is it for me. If you ask these models to write something new, the result can be okay.
But the second you start iterating with them... the codebase goes to shit, because they never delete code. Never. They always bolt new shit on to solve any problem, even when there's an incredibly obvious path to achieve the same thing in a much more maintainable way with what already exists.
Show me a language model that can turn rube goldberg code into good readable code, and I'll suddenly become very interested in them. Until then, I remain a hater, because they only seem capable of the opposite :)
That's not true in my experience. Several times now i've given Claude Code a too-challenging task and after trying repeatedly it eventually gave up, removing all the previous work on that subject and choosing an easier solution instead.
.. unfortunately that was not at all what i wanted lol. I had told it "implement X feature with Y library", ie specifically the implementation i wanted to make progress towards, and then after a while it just decided that was difficult and to do it differently.
You'd be surprised what a combination of structured review passes and agent rules (even simple ones such as "please consider whether old code can be phased out") might do to your agentic workflow.
> Show me a language model that can turn rube goldberg code into good readable code, and I'll suddenly become very interested in them.
They can already do this. If you have any specific code examples in mind, I can experiment for you and return my conclusions if it means you'll earnestly try out a modern agentic workflow.
An LLM which was capable of refactoring all the duplicated logic into the common core and restructuring all the drivers to be simpler would be very very useful for me. It ought to be able to remove a few thousand lines of code there.
It needs to do it iteratively, in a sting of small patches that I can review and prove to myself are correct. If it spits out a giant single patch, that's worse than nothing, because I do systems work that actually has to be 100% correct, and I can't trust it.
That's a combination of current context limitations and a lack of quality tooling and prompting.
A well-designed agent can absolutely roll back code if given proper context and access to tooling such as git. Even flushing context/message history becomes viable for agents if the functionality is exposed to them.
> It's entirely possible that we do become obsolete for a wide variety of programming domains. That's simply a reality…
It is not a reality since it has not happen. In the real world it has not happened.
There is no reason to believe that the current rate of progress will continue. Intelligence is not like the weaving machines. A software engineer is not a human calculator.
To be fair he didn't say it is the reality now, he said the possibility is a reality. At least that's how I read his sentence.
And yeah, I do think it's a real possibility now.
> That's simply a reality, just as weavers saw massive layoffs in the wake of the automated loom
They didn’t just see layoffs. There were the constant wars with Napoleon and the War of 1812 causing significant economic instability along with highly variable capital investments in textile production at the time. They we’re looking at huge wealth disparity and losing their jobs for most meant losing everything.
What many Luddite supporters were asking for in many parts of England were: better working conditions, a raise to minimum wage, abolishment of child labour, etc. Sabotage was a means to make such demands from a class that held almost all of the power.
Many of those protestors were shot. Those who survived and were laid off were forced into workhouses.
The capitalists won and got to write the history and the myths. They made it about the technology and not the conditions. They told us that the displaced workers found new, better jobs elsewhere.
Programmers, while part of the labour class, have so far enjoyed a much better bargaining position and have been compensated in kind. Many of us also complain about the quality of output from AI as the textile workers complained about the poor quality of the lace. But fortunately the workhouses were shut down. Although poor quality code tends to result in people losing their life’s savings, having their identities stolen, etc. Higher stakes than cheap lace.
> That's simply a reality, just as weavers saw massive layoffs in the wake of the automated loom, or scribes lost work after the printing press, or human calculators became pointless after high-precision calculators became commonplace.
See, this is the kind of conception of a programmer I find completely befuddling. Programming isn't like those jobs at all. There's a reason people who are overly attached to code and see their job as "writing code" are pejoratively called "code monkeys." Did CAD kill the engineer? No. It didn't. The idea is ridiculous.
I'm sure you understand the analogy was about automation and reduction in workforce, and that each of these professions have both commonalities and differences. You should assume good faith and interpret comments on Hacker News in the best reasonable light.
> There's a reason people who are overly attached to code and see their job as "writing code" are pejoratively called "code monkeys."
Strange. My experience is that "code monkeys" don't give a crap about the quality of their code or its impact with regards to the product, which is why they remain programmers and don't move on to roles which incorporate management or product responsibilities. Actually, the people who are "overly attached to code" tend to be computer scientists who are deeply interested in computation and its expression.
> Did CAD kill the engineer? No. It didn't. The idea is ridiculous.
Of course not. It led to a reduction in draftsmen, as now draftsmen can work more quickly and engineers can take on work that used to be done by draftsmen. The US Bureau of Labor Statistics states[0]:
Expected employment decreases will be driven by the use of computer-aided design (CAD) and building information modeling (BIM) technologies. These technologies increase drafter productivity and allow engineers and architects to perform many tasks that used to be done by drafters.
Similarly, the other professions I mentioned were absorbed into higher-level professions. It has been stated many times that the future focus of software engineers will be less about programming and more about product design and management.
I saw this a decade ago at the start of my professional career and from the start have been product and design focused, using code as a tool to get things done. That is not to say that I don't care deeply about computer science, I find coding and product development to each be incredibly creatively rewarding, and I find that a comprehensive understanding of each unlocks an entirely new way to see and act on the world.
My father in law was a draftsman. Lost his job when the defense industry contracted in the '90s. When he was looking for a new job everything required CAD which he had no experience in (he also had a learning disability, it made learning CAD hard).
He couldn't land a job that paid more than minimum wage after that.
Wow, that's a sad story. It really sucks to spend your life mastering a craft and suddenly find it obsolete and your best years behind you. My heart goes out to your father.
This is a phenomenon that seems to be experienced more and more frequently as the industrial revolution continues... The craft of drafting goes back to 2000 B.C.[0] and while techniques and requirements gradually changed over thousands of years, the digital revolution suddenly changed a ton of things all at once in drafting and many other crafts. This created a literacy gap many never recovered from.
I wonder if we'll see a similar split here with engineers and developers regarding agentic and LLM literacy.
> Actually, the people who are "overly attached to code" tend to be computer scientists who are deeply interested in computation and its expression.
What academics are you rubbing shoulders with? Every single computer scientist I have ever met has projects where every increment in the major version goes like:
"I was really happy with my experimental kernel, but then I thought it might be nice to have hotpatching, so I abandoned the old codebase and started over from scratch."
The more novel and cutting edge the work you do is, the more harmful legacy code becomes.
"I saw this a decade ago at the start of my professional career and from the start have been product and design focused"
I have similar view of the future as you do. But I'm just curious what the quoted text here means in practice. Did you go into product management instead of software engineer for example?
I don't disagree exactly, but the AI that fully replaces all the programmers is essentially a superhuman one. It's matching human output, but will obviously be able to do some tasks like calculations much faster, and won't need a lunch break.
At that point it's less "programmers will be out of work" as "most work may cease to exist".
Not sure about this. Coding has some unique characteristics that may it easier even if from a human perspective it requires some skill:
- The cost of failure is low: Most domains (physical, compliance, etc) don't have this luxury where the cost of failure is high and so the validator has more value.
- The cost to retry/do multiple simulations is low: You can perform many experiments at once, and pick the one with the best results. If the AI hallucinates, or generates something that doesn't work the agent/tool could take that error and simulate/do multiple high probability tries until it passes. Things like unit tests, compiler errors, etc make this easier.
- There are many right answers to a problem. Good enough software is good enough for many domains (e.g. a CRUD web app). Not all software is like this but many domains in software are.
What makes something hard to disrupt won't be intellectual difficulty (e.g. software harder than compliance analyst as a made up example), it will be other bottlenecks like the physical world (energy, material costs, etc), regulation (job isn't entirely about utility/output). etc.
> The cost of failure is low: Most domains (physical, compliance, etc) don't have this luxury where the cost of failure is high and so the validator has more value.
This is not entirely sensible, some code touches the physical / compliance world. Airports, airplanes, hospitals, cranes, water systems, military they all use code to different degrees. It's true that they can perhaps afford to run experiments over landing pages, but I don't think they can simply disrupt their workers and clients on a regular basis.
I did say "not all software is like this, but many domains are". So I agree with you.
Also note unlike say for physical domains where it's expensive to "tear down" until you commit and deploy (i.e. while the code is being worked on) you can try/iterate/refine via your IDE, shell, whatever. Its just text files after all; in the end you are accountable for the final verification step before it is published. I never said we don't need a verification step; or a gate before it goes to production systems. I'm saying its easier to throw away "hallucinations" that don't work and you can work around gaps in the model with iterations/retries/multiple versions until the user is happy with it.
Conversely I couldn't have an AI build a house, I don't like it, it demolishes it and builds a slightly different one, etc etc until I say "I'm happy with this product, please proceed". The sheer amount of resource waste and time spent in doing so would be enormous. I can simulate, generate plans, etc maybe with AI but nothing beats seeing the "physical thing" for some products especially when there isn't the budget/resources to "retry/change".
TL;DR the greater the cost of iteration/failure; the less likely you can use iteration to cover up gaps in your statistical model (i.e. tail risks are more likely to bite/harder to mitigate).
Doesn't AI have diminishing returns on it's pseudo creativity? Throw all the training output of LLM into a circle. If all input comes from other LLM output, the circle never grows. Humans constantly step outside the circle.
Perhaps LLM can be modified to step outside the circle, but as of today, it would be akin to monkeys typing.
I think you're either imagining the circle too small or overestimating how often humans step outside it. The typical programming job involves lots and lots of work, and yet none of it creating wholly original computer science. Current LLMs can customize well known UI/IO/CRUD/REST patterns with little difficulty, and these make up the vast majority of commercial software development.
I agree humans only rarely step outside the circle, but I do have this intuition that some people sometimes do, whereas LLMs never do. This distinction seems important over long time horizons when thinking about LLM vs human work.
But I can't quite articulate why I believe LLMs never step outside the circle, because they are seeded with some random noise via temperature. I could just be wrong.
Frameworks and low code systems have been able to do that for years. The reason they haven’t replaced programmers is that every system eventually becomes a special unique snowflake as long as it has time and users.
I’m getting maybe a 10-20% productivity boost using AI on mature codebases. Nice but not life changing.
a 20% boost is huge, for 3 years since chatgpt. even if it stopped there, that's 20% fewer people that need to be in your role, which is at least tens of thousands of jobs
That’s far less than the productivity boost I got by building some internal tooling with phoenix liveview instead of react.
10-20% productivity posts have been happening regularly over the course of my career. They are normally either squandered by inefficient processes or we start building more complex systems.
When Rails was released, for certain types of projects, you could move 3 or 4x faster almost overnight.
If devs produce 20% more, won't companies hire more since the gain/loss equation is starting to tilt their way even more? I find it odd that people think productivity increases lead to layoffs.
> Of course you need to review and edit what it generates.
Treating LLMs as a scaffolding tool yields better results at least for me personally. I just brain dump what I'm thinking of building and ask for it to give me models, and basic controllers using said models, then I just worry about the views and business logic.
I wasn’t in the industry to see it first hand, but was this same criticism levied against higher level languages when they first hit the scene? Something to the effect of high level languages not being the right level of precision, because the programmer wanted to directly manipulate what was happening in memory, and the high level languages are not the right level of precision for that?
The issue with natural language isn’t that it’s impossible to be precise, it’s that most people aren’t, or they are precise about what they want it to do for them, but not what the computer needs to do to make it happen. This leads to a lot of guessing by engineerings as they try to translate the business requirements into code. Now the LLM is doing that guessing, often with less context about the broader business objectives, or an understanding of the people writing those requirements.
> was this same criticism levied against higher level languages when they first hit the scene?
No.
Some were concerned that the output of compilers couldn’t match the quality of what could be done by a competent programmer at the time. That was true for a time. Then compilers got better.
Nobody was concerned that compilers were going to be used by capitalists to lay them off and seize the means of producing programs by turning it into property.
In my experience the best use of AI is to stay in the flow state when you get blocked by an API you don't understand or a feature you don't want to implement for whatever reason.
AI can very efficiently apply common patterns to vast amounts of code, but it has no inherent "idea" of what it's doing.
Here's a fresh example that I stumbled upon just a few hours ago. I needed to refactor some code that first computes the size of a popup, and then separately, the top left corner.
For brevity, one part used an "if", while the other one had a "switch":
I wanted the LLM to refactor it to store the position rather than applying it immediately. Turns out, it just could not handle different things (if vs. switch) doing a similar thing. I tried several variations of prompts, but it very strongly leaning to either have two ifs, or two switches, despite rather explicit instructions not to do so.
It sort of makes sense: once the model has "completed" an if, and then encounters the need for a similar thing, it will pick an "if" again, because, well, it is completing the previous tokens.
Harmless here, but in many slightly less trivial examples, it would just steamroll over nuance and produce code that appears good, but fails in weird ways.
That said, splitting tasks into smaller parts devoid of such ambiguities works really well. Way easier to say "store size in m_StateStorage and apply on render" than manually editing 5 different points in the code. Especially with stuff like Cerebras, that can chew through complex code at several kilobytes per second, expanding simple thoughts faster than you could physically type them.
Just pointing out that there are limits and there’s no reason to believe that models will improve indefinitely at the rates we’ve seen these last couple of years.
There is reason to believe that humans will keep trying to push the limitations of computation and computer science, and that recent advancements will greatly accelerate our ability to research and develop new paradigms.
Look at how well Deepseek performed with the limited, outdated hardware available to its researchers. And look at what demoscene practitioners have accomplished on much older hardware. Even if physical breakthroughs ceased or slowed down considerably, there is still a ton left on the table in terms of software optimization and theory advancement.
And remember just how young computer science is as a field, compared to other human practices that have been around for hundreds of thousands of years. We have so much to figure out, and as knowledge begets more knowledge, we will continue to figure out more things at an increasing pace, even if it requires increasingly large amounts of energy and human capital to make a discovery.
I am confident that if it is at all possible to reach human-level intelligence at least in specific categories of tasks, we're gonna figure it out. The only real question is whether access to energy and resources becomes a bigger problem in the future, given humanity's currently extraordinarily unsustainable path and the risk of nuclear conflict or sustained supply chain disruption.
> And remember just how young computer science is as a field, compared to other human practices that have been around for hundreds of thousands of years.
How long do you think Homo sapiens have been on Earth and how long has civilization been here?
I’ve been programming since 89. I know what you can squeeze into 100k.
But you can only blast so much electricity into a dense array of transistors before it melts the whole thing and electrons jump rails. We hit that limit a while ago. We’ve done a lot of optimization of instruction caching, loading, and execution. We front loaded a ton of caching in front of the registers. We’ve designed chips specialized to perform linear algebra calculations and scaled them to their limits.
AI is built on scaling the number of chips across the board. Which has the effect of requiring massive amounts of power. And heat dissipation. That’s why we’re building out so many new data centres: each one requiring land, water, and new sources of electricity generation to maintain demand levels for other uses… those sources mostly being methane and coal plants.
Yes, we might find local optimizations in training to lower the capital cost and external costs… but they will be a drop in the bucket at the scale we’re building out this infrastructure. We’re basically brute forcing the scale up here.
And computer science might be older than you think. We just used to call it logic. It took some electrical engineering innovations to make the physical computers happen but we had the theoretical understanding of computation for quite some time before those appeared.
A young field, yes, and a long way to go… perhaps!
But let’s not believe that innovation is magic. There’s hard science and engineering here. Electrons can only travel so fast. Transistor density can only scale so much. Etc.
> How long do you think Homo sapiens have been on Earth and how long has civilization been here?
I already corrected my typo in a child comment.
> We’re basically brute forcing the scale up here
Currently, but even that will eventually hit thermodynamic and socioeconomic limits, just as single chips are.
> And computer science might be older than you think. We just used to call it logic.
In my opinion, two landmark theory developments were type theory and the lambda calculus. Type theory was conceived to get around Russell's paradox and others, which formal logic could not do on its own.
As far as hardware, sure we had mechanical calculators in the 17th century, and Babbage's analytical engine in the 19th century, and Ada Lovelace's program, but it wasn't until the mid-20th century that computer science coalesced as its own distinct field. We didn't used to call computer science logic; it's a unification of physical advancements, logic and several other domains.
> Electrons can only travel so fast.
And we have no reason to believe that current models are at all optimized on a software or theoretical level, especially since, as you say yourself, we are currently just focused on brute-forcing innovation as its the more cost-effective solution for the time being.
But as I said, once theoretical refinement becomes more cost-effective, we can look at the relatively short history of computer science to see just how much can be done on older hardware with better theory:
>> Even if physical breakthroughs ceased or slowed down considerably, there is still a ton left on the table in terms of software optimization and theory advancement.
I agree. And if human civilization survives, your concerns about energy and resources will be only short term on the scale of civilization, especially as we make models more efficient.
The human brain uses just 20 watts of power, so it seems to me like it is possible to reach human-level intelligence in principle by using much greater power and less of the evolutionary refinement over billions of years that the brain has.
I am working on a GUI for delegating coding tasks to LLMs, so I routinely experiment with a bunch of models doing all kinds of things. In this case, Claude Sonnet 3.7 handled it just fine, while Llama-3.3-70B just couldn't get it. But that is literally the simplest example that illustrates the problem.
When I tried giving top-notch LLMs harder tasks (scan an abstract syntax tree coming from a parser in a particular way, and generate nodes for particular things) they completely blew it. Didn't even compile, let alone logical errors and missed points. But once I broke down the problem to making lists of relevant parsing contexts, and generating one wrapper class at a time, it saved me a whole ton of work. It took me a day to accomplish what would normally take a week.
Maybe they will figure it out eventually, maybe not. The point is, right now the technology has fundamental limitations, and you are better off knowing how to work around them, rather than blindly trusting the black box.
3) autistic rigidity regarding a single hallucination throwing the whole experience off
4) subconscious anxiety over the threat to their jerbs
5) unnecessary guilt over going against the tide; anything pro AI gets heavily downvoted on Reddit and is, at best, controversial as hell here
I, for one, have shipped like literally a product per day for the last month and it's amazing. Literally 2,000,000+ impressions, paying users, almost 100 sign ups across the various products. I am fucking flying. Hit the front page of Reddit and HN countless times in the last month.
Idk if I break down the prompts better or what. But this is production grade shit and I don't even remember the last time I wrote more than two consecutive lines of code.
If you are launching one product per day, you are using LLMs to convert unrefined ideas into proof-of-concept prototypes. That works really well, that's the kind of work that nobody should be doing by hand anymore.
Except, not all work is like that. Fast-forward to product version 2.34 where a particular customer needs a change that could break 5000 other customers because of non-trivial dependencies between different parts of the design, and you will be rewriting the entire thing by humans or having it collapse under its own weight.
But out of 100 products launched on the market, only 1 or 2 will ever reach that stage, and having 100 LLM prototypes followed by 2 thoughtful redesigns is way better than seeing 98 human-made products die.
Can you provide links to these 30 products you have shipped?
I keep hearing how people are so god damn productive with LLMs, but whenever I try to use them they can not reliably produce working code. Usually producing something that looks correct at first, but either doesn't work (at all or as intended).
Going over you list:
1. if the problem is that I need to be very specific with how I want LLM to fix the issue, like providing it the solution, why wouldn't I just make the change myself?
2. I don't even know how you can think that not vibe coding means you lack experience
3. Yes. If the model keeps trying to use non-existent language feature or completely made up functions/classes that is a problem and nothing to do with "autism"
4. This is what all AI maximalists want to think; that only reason why average software developer isn't knee deep in AI swamp with them is that they are luddites who are just scared for their jobs. I personally am not as I have not seen LLMs actually being useful for anything but replacing google searches.
5. I don't know why you keep bringing up Reddit so much. I also don't quite get who is going against the tide here, are you going against the tide of the downvotes or am I for not using LLMs to "fucking fly"?
>But this is production grade shit
I truly hope it is, because...
>and I don't even remember the last time I wrote more than two consecutive lines of code.
Means if there is a catastrophic error, you probably can't fix it yourself.
> if the problem is that I need to be very specific with how I want LLM to fix the issue, like providing it the solution, why wouldn't I just make the change myself?
I type 105 wpm on a bad day. Try gpt-4.1. It types like 1000 wpm. If you can formally describe your problem in English and the number of characters in the English prompt is less than whatever code you write, gpt-4.1 will make you faster.
Obviously you have to account for gpt-4.1 being wrong sometimes. Even so, if you have to run two or three prompts to get it right, it still is going to be faster.
> I don't even know how you can think that not vibe coding means you lack experience
If you lack experience, you're going to prompt the LLM to do the wrong thing and engineer yourself into a corner and waste time. Or you won't catch the mistakes it makes. Only experience and "knowing more than LLM" allows you to catch its mistakes and fix them. (Which is still faster than writing the code yourself, merely by way of it typing 1000 wpm.)
> If the model keeps trying to use non-existent language feature or completely made up functions/classes that is a problem and nothing to do with "autism"
You know that you can tell it those functions are made up and paste it the latest documentation and then it will work, right? That knee-jerk response makes it sound like you have this rigidity problem, yourself.
> I personally am not as I have not seen LLMs actually being useful for anything but replacing google searches.
Nothing really of substance here. Just because you don't know how to use this tool that doesn't mean no one does.
This is the least convincing point for me, because I come along and say "Hey! This thing has let me ship far more working code than before!" and then your response is just "I don't know how to use it." I know that it's made me more productive. You can't say anything to deny that. Do you think I have some need to lie about this? Why would I feel the need to go on the internet and reap a bunch of downvotes while peddling some lie that does stand to get me anything if I convince people of the lie?
> I also don't quite get who is going against the tide here, are you going against the tide of the downvotes
Yeah, that's what I'm saying. People will actively shame and harass you for using LLMs. It's mind boggling that a tool, a technology, that works for me and has made me more productive, would be so vehemently criticized. That's why I listed these 5 reasons, the only reasons I have thought of yet.
> Means if there is a catastrophic error, you probably can't fix it yourself.
See my point about lacking experience. If you can't do the surgery yourself every once in a while, you're going to hate these tools.
Really, you've just made a bunch of claims about me that I know are false, so I'm left unconvinced.
I'm trying to have a charitable take. I don't find joy in arguing or leaving discussions with a bitter taste. I genuinely don't know why people are so mad at me claiming that a tool has helped me be more productive. They all just don't believe me, ultimately. They all come up with some excuse as to why my personal anecdotes can be dismissed and ignored: "even though you have X, we should feel bad for you because Y!" But it's never anything of substance. Never anything that has convinced me. Because at the end of the day, I'm shipping faster. My code works. My code has stood the test of time. Insults to my engineering ability I know are demonstrably false. I hope you can see the light one day. These are extraordinary tools that are only getting better, at least by a little bit, in the foreseeable future. Why deny?
Would also love to see those daily shipped products. What I see on reddit is the same quiz done several times just for different categories and the pixel art generator. That does not look like shipping a product per day as you claim.
On my main, not gonna dox myself. Being pro AI is clearly a faux pas for personal branding.
Just a few days ago got flamed for only having 62 users on GameTorch. Now up to 91 and more paying subs. Entire thing written by LLMs and hasn't fallen over once. I'd rather be a builder than an armchair critic.
People would rather drag you down in the hole that they're in than climb out.
This is going to be all over the place and possibly hard to follow, I am just going to respond in "real time" as I read your comment, if you think that is too lazy to warrant reading I completely understand. I hope you have a nice day.
WPM is not my limiting factor. Maybe the difference is that I am not working on trivial software so a lot of thought goes into the work, typing is the least time consuming part. Still I don't see how your 105 wpm highly descriptive and instructive English can be faster than just fixing the thing. Even if after you prompt your LLM takes 1ms to fix the issue you have probably already wasted more time by debugging the issue and writing the prompt.
So your "you lack engineering experience" was actually "you don't know LLMs well", maybe use the words you intend and not make them into actual insults.
I am not going to be pasting in any C++ spec into an LLM.
Yet when I checked your profile you have shipped one sprite image generator website. I find all these claims so hard to believe. Everyone just keeps telling me how they are making millions off of LLMs but no one has to the recipes to show. Just makes me feel like you have stock in OpenAI or something and are trying your hardest to pump it up.
I think the shaming and harassing is mostly between your ears, at least I am not trying to shame or harass you for using LLMs, if anything I want to have superpowers too. If LLMs really work for you that is nice and you should keep doing it, I just have not seen the evidence you are talking about. I am willing to admit that it could very well be a skill issue, but I need more proof than "trust me" or "1000 wpm".
I don't think I have made any claims about you, although you have used loaded language like "autism" and "lack of engineering experience" and heavily implied that I am just too dumb to use the tools.
>I'm trying to have a charitable take.
c'mon nothing about your comments has been charitable in anyway. No one is mad at you personally. Do not take criticism of your tools as personal attacks. Maybe the tools will get good, but again my problem with LLMs and hype around them is that no one has been able to demonstrate them actually being as good as the hype suggests.
What is everyone working on that takes more than five minutes to think about?
For me, the work is insurmountable and infinite, while coming up with the solution is never too difficult. I'm not saying this to be cocky. I mean this:
In 99.9999999999% of the problems I encounter in software engineering, someone smarter than me has already written the battle tested solution that I should be using. Redis. Nginx. Postgres. etc. Or it's a paradigm like depth first search or breadth first search. Or just use a hash set. Sometimes it's a little crazier like Bloom filters but whatever.
Are you like constantly implementing new data structures and algorithms that only exist in research papers or in your head?
Once you've been engineering for 5 or 10 years, you've seen almost everything there is to see. Most of the solutions should be cached in your brains at that point. And the work just amounts to tedious, unimportant implementation details.
Maybe I'm forgetting that people still get bogged down in polymorphism and all that object oriented nonsense. If you just use flat structs, there's nothing too complicated that could possibly happen.
I worked in HFT, for what it's worth, and that should be considered very intense non-CRUD "true" engineering. That, I agree, LLMs might have a little more trouble with. But it's still nothing insane.
Software engineering is extremely formulaic. That's why it's so easy to statistically model it with LLMs.
I write embedded software in C++ for industrial applications. We have a lot of proprietary protocols and custom hardware. We have some initiatives to train LLMs with our protocols/products/documentation, but I have not been impressed with the results. Same goes with our end-to-end testing framework. I guess it isn't so popular so the results vary a lot.
I have been doing this for 8 year and while yes I have seen a lot you can't just copy-paste solutions due to flash, memory, and performance constraints.
Again maybe this is a skill issue and maybe I will be replaced with an LLM, but so far they seem more like cool toys. I have used LLMs to write AddOns for World of Warcraft since my Lua knowledge is mostly writing Wireshark plugins for our protocols and for that it has been nice, but it is nothing someone who actually works with Lua or with WoW API couldn't produce faster or just as fast, because I have to describe what I want and then try and see if the API the LLM provides exists and if it works as the LLM assumed it would.
Again, I appreciate the reply. I think my view on LLMs is skewed towards the positive because I've only been building CRUD apps, command line tools, and games with them. I apologize if I came off as incendiary or offensive.
The interesting questions happen when you define X, Y and Z and time. For example, will llms be able to solve the P=NP problem in two weeks, 6 months, 5 years, a century? And then exploring why or why not
> AI can very efficiently apply common patterns to vast amounts of code, but it has no inherent "idea" of what it's doing.
AI stands for Artificial Intelligence. There are no inherent limits around what AI can and can't do or comprehend. What you are specifically critiquing is the capability of today's popular models, specifically transformer models, and accompanying tooling. This is a rapidly evolving landscape, and your assertions might no longer be relevant in a month, much less a year or five years. In fact, your criticism might not even be relevant between current models. It's one thing to speak about idiosyncrasies between models, but any broad conclusions drawn outside of a comprehensive multi-model review with strict procedure and controls is to be taken with a massive grain of salt, and one should be careful to avoid authoritative language about capabilities.
It would be useful to be precise in what you are critiquing, so that the critique actually has merit and applicability. Even saying "LLM" is a misnomer, as modern transformer models are multi-modal and trained on much more than just textual language.
I learned neural networks around 2000, and it was old technology then. The last real jump we saw was going from ChatGPT 3.5 to 4, and that is more than 2 years ago.
It seems you don't recollect how much time passed without any big revolutions in AI. Deep learning was a big jump. But when the next jump comes? Might be tomorrow, but looking at history, might be in 2035.
According to what I see, the curve has already flattened and now only a new revolution could get us to the next big step.
Since I can't seem to add an edit to my post, here's a realization:
My 2035 prediction actually seems pretty optimistic. It was more than 20 years that we haven't seen any big AI revolutions, so 2045 would be more realistic.
And it seems our current AI is also not going to get us there any faster.
Agree, the AI companies aren’t able to improve the base models so they’re pivoting to making add-ons like “agents” which seem to only be instructions atop the base models.
> AI stands for Artificial Intelligence. There are no inherent limits around what AI can and can't do or comprehend.
Artificial, as in Artificial sand or artificial grass. Sure, it appears as sand or grass at first, but upon closer examination, it becomes very apparent that it's not real. Artificial is basically a similar word to magic - as in, it offers enough misdirection in order for people to think there might be intelligence, but upon closer examination, it's found lacking.
It's still impressive that it can do that, going all the way back to gaming AIs, but it's also a veil that is lifted easily.
What a ridiculous response, to scold the GP for criticising today's AI because tomorrow's might be better. Sure, it might! But it ain't here yet buddy.
Lots of us are interested in technology that's actually available, and we can all read date stamps on comments.
You're projecting that I am scolding OP, but I'm not. My language was neutral and precise. I presented no judgment, but gave OP the tools to better clarify their argument and express valid, actionable criticism instead of wholesale criticizing "AI" in a manner so imprecise as to reduce the relevance and effectiveness of their argument.
> But it ain't here yet buddy . . . we can all read date stamps on comments.
That has no bearing on the general trajectory that we are currently on in computer science and informatics. Additionally, your language is patronizing and dismissive, trading substance for insult. This is generally frowned upon in this community.
You failed to actually address my comment, both by failing to recognize that it was mainly about using the correct terminology instead of criticizing an entire branch of research that extends far beyond transformers or LLMs, and by failing to establish why a rapidly evolving landscape does not mean that certain generalizations cannot yet be made, unless they are presented with several constraints and caveats, which includes not making temporally-invariant claims about capabilities.
I would ask that you reconsider your approach to discourse here, so that we can avoid this thread degenerating into an emotional argument.
> They were obviously not trying to make a sweeping comment about the entire future of the field
OP said “AI can very efficiently apply common patterns to vast amounts of code, but it has no inherent "idea" of what it's doing.”
I'm not going to patronize you by explaining why this is not "very precise", or why its lack of temporal caveats is an issue, as I've already done so in an earlier comment. If you're still confused, you should read the sentence a few times until you understand. OP did not even mention which specific model they tested, and did not provide any specific prompt example.
> Are you using ChatGPT to write your loquacious replies?
If you can't handle a few short paragraphs as a reply, or find it unworthy of your time, you are free to stop arguing. The Hacker News guidelines actually encourage substantive responses.
I also assume that in the future, accusing a user of using ChatGPT will be against site guidelines, so you may as well start phasing that out of your repertoire now.
Here are some highlights from the Hacker News guidelines regarding comments:
- Don't be snarky
- Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.
- Assume good faith
- Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken.
This is a lot of words, but does any of it contradict this:
> AI can very efficiently apply common patterns to vast amounts of code, but it has no inherent "idea" of what it's doing.”
Are you saying that AI does have an inherent idea of what it's doing or is doing more than that? Today?
We're in an informal discussion forum. I don't think the bar we're looking for is some rigorous deductive proof. The above matches my experience as well. Its a handy applied interactive version of an Internet search.
If someone has a different experience that would be interesting. But this just seems like navel-gazing over semantics.
> Are you saying that AI does have an inherent idea of what it's doing or is doing more than that?
No. I stated that OP cannot make that kind of blanket, non-temporally constrained statements about artificial intelligence.
> We're in an informal discussion forum. I don't think the bar we're looking for is some rigorous deductive proof
We're in a technology-oriented discussion forum, the minimum bar to any claim should be that it is supported by evidence, otherwise it should be presented as what it is: opinion.
> this just seems like navel-gazing over semantics.
In my opinion, conversation is much easier when we can agree that words should mean something. Imprecise language matched with an authoritative tone can mislead an audience. This topic in particular is rife with imprecise and uninformed arguments, and so we should take more care to use our words correctly, not less.
Furthermore, my argument goes beyond semantics, as it also deals with the importance of constraints when making broad, unbacked claims.
I had a fun result the other day from Claude. I opened a script in Zed and asked it to "fix the error on line 71".
Claude happily went and fixed the error on line 91....
1. There was no error on line 91, it did some inconsequential formatting on that line
2. More importantly, it just ignored the very specific line I told it to go to. It's like I was playing telephone with the LLM which felt so strange with text-based communication.
This was me trying to get better at using the LLM while coding and seeing if I could "one-shot" some very simple things. Of course me doing this _very_ tiny fix myself would have been faster. Just felt weird and reinforces this idea that the LLM isn't actually thinking at all.
I suspect if OP highlighted line 71 and added it to chat and said fix the error, they’d get a much better response. I assume Cursor could create a tool to help it interpret line numbers, but that’s not how they expect you to use it really.
That's the thing. We're expecting the tool to have a clear understanding of its own limitations by now and ask for better prompts (or say: I don't know, I can't etc). The fact it just does something wacky is not good at all to the consistency of these tools.
I do not code/program, but I do read thousands of fiction pages annually. LLMs (Perplexity, specifically) have been my lifetime favorite book club member — I can ask anything.
However, I can't just say "on page 123..." I've found it's better to either provide the quote, or describe the context, and then ask how it relates to [another concept]. Or I'll say "at the end of chapter 6, Bob does X, then why Y?" (perhaps this is similar to asking a coding LLM to fix a specific function instead of a specific line?).
My favorite examples of this have been sitting with living human authors and discussing their books — usually to jaw-dropped creators, particularly to Unknowns.
Works for non-fiction, too (of course). But for all those books you didn't read in HS English classes, you can somewhat recreate all that class discussion your teachers always attempted to foster — at your own discretion/direction.
> This was me trying to get better at using the LLM while coding
And now you've learned that LLMs can't count lines. Next time, try asking it to "fix the error in function XYZ" or copy/paste the line in question, and see if you get better results.
> reinforces this idea that the LLM isn't actually thinking at all.
Of course it's not thinking, how could it? It's just a (rather big) equation.
54 def dicts_to_table_string(
55 headings: List[str], dicts: List[Dict[str, str]]
56 ) -> List[str]:
57 max_lengths = [len(h) for h in headings]
58
59 # Compute maximum length for each column
60 for d in dicts:
That’s not what he’s saying there. There’s a separate tool that adds line numbers before feeding the prompt into the LLM. It’s not the LLM doing it itself.
It's a tool. It's not a human. A line number works great for humans. Today, they're terrible for LLMs.
I can choose to use a screwdriver to hammer in a nail and complain about how useless screwdrivers are. Or I can realize when and how to use it.
We (including marketing & execs) have made a huge mistake in anthropomorphizing these things, because then we stop treating them like tools that have specific use cases to be used in certain ways, and more like smart humans that don't need that.
Maybe one day they'll be there, but today they are screwdrivers. That doesn't make them useless.
Check the whole ecosystem around editors, grep tools, debuggers, linting and build tools. One common thing about all of this is line (and column) number so you can integrate them together if you want to automate stuff. Like jumping to errors (quickfix in vim,…), search all files and jump to the occurrences (grep mode in emacs,…), etc…
Personally, I define the job of a software engineer as transform requirements into software.
Software is not only code. Requirements are not only natural language.
At the moment I can't manage to be faster with the AI than manually. Unless its a simple task or software.
In my experience AI's are atm junior or mid-level developers. And in the last two years, they didn't get significant better.
Most of the time, the requirements are not spelled out. Nobody even knows what the business logic is supposed to be. A lot of it has to be decided by the software engineer based on available information. It sometimes involve walking around the office asking people things.
It also requires a fair bit of wisdom to know where the software is expected to grow, and how to architect for that eventuality.
I can't picture an LLM doing a fraction of that work.
I think that's my problem with AI. Let's say I have all the requirements, down to the smallest detail. Then I make my decisions at a micro level. Formulate an architecture. Take all the non-functionals into account. I would write a book as a prompt that is not able to express my thoughts as accurately as if I were writing code right away. Apart from the fact that the prompt is generally a superfluous intermediate step in which I struggle to create an exact programming language with an imprecise natural language with a result that is not reproduce-able.
AI is less useful when I'm picking through specific, careful business logic.
But we still have lots of boilerplate code that's required, and it's really good at that. If I need a reasonably good-looking front-end UI, Claude will put that together quickly for me. Or if I need it to use a common algorithm against some data, it's good at applying that.
What I like about AI is that it lets me slide along the automation-specificity spectrum as I go through my work. Sometimes it feels like I've opened up a big stretch of open highway (some standard issue UI work with structures already well-defined) and I can "goose" it. Sometimes there's some tricky logic, and I just know the AI won't do well; it takes just as long to explain the logic as to write it in code. So I hit the brakes, slow down, navigate those tricky parts.
Previously, in the prior attempt to remove the need for engineers, no-code solutions instead trapped people. They pretended like everything is open highway. It's not, which is why they fail. But here we can apply our own judgment and skill in deciding when a lot of "common-pattern" code is required versus the times where specificity and business context is required.
That's also why these LLMs get over-hyped: people over-hype them for the same reason they over-hyped no-code; they don't understand the job to be done, and because of that, they actually don't understand why this is much better than the fanciful capabilities they pretend it has ("it's like an employee and automates everything!"). The tools are much more powerful when an engineer is in the driver's seat, exercising technical judgment on where and how much to use it for every given problem to be solved.
My strategy has almost always been to copy the code example from the docs of whatever css framework I’m using, especially for forms. Then there’s a threshold where I use the project as source instead.
At a certain point, huge prompts (which you can readily find available on Github, used by large LLM-based corps) are just....files of code? Why wouldn't I just write the code myself at that point?
Almost makes me think this "AI coding takeover" is strictly pushed by non-technical people.
Back in the day, there used to be professionals known as systems analysts whose job it was to determine the business logic. The information system went through several phases of stepwise refinement. First the requirements were determined: WHO needs WHAT information, WHERE, WHEN, and WHY. (And from WHOM do they get it?) Then, a series of procedures were developed to be implemented either manually or by computer (The "Playscript" format by Les Matthies was particularly useful for the former; standard flowcharts for the latter). Each piece of data, its type, and its purpose was also identified and registered in a standard vocabulary. The programmers only got in on it towards the end: once the major decisions had been made, they wrote the code instructing the computer on HOW to do it. Their focus was on the HOW; the WHAT was not in their job description, and was usually beyond their capability. It takes holistic, big-picture thinking and great social skills to develop an understanding of an entire business division and come up with a plan to implement an information system for that division. The programmers' work entailed about 15% of the total work, and was mainly concerned with the technical details of getting the procedures to be automated running on a computer. These days, with AI, that 15% figure could be reduced even further, perhaps by a factor of five or ten. In the big-iron era, programming was really that simple. The hard decisions had already been made before the first line of code was written. You may think it stodgy and inflexible to develop software this way, but that's how grown-ups did it, and studies showed that it was significantly cheaper than the scattershot, agile-like approach where the programmers where in the lead in terms of systems design.
What's happened since the 1970s is, programming has undergone prestige inflation to the point where programmers are looked to for decisions regarding the actual business procedures, and usually they just don't have the business knowledge or wherewithal to do that. The systems analyst has faded into memory. And as Milt Bryce said, "If this country built bridges the way it builds systems, we'd be a nation run by ferry-boats."
No software job I've done has come with clear, explicit requirements. Its all been a mess under the hood and half my job has been figuring out specifically what they even want
I think it's a common problem to officially have mids who are really just juniors with a modicum of time in the industry and the same goes for seniors who are really just mids.
One of the most useful properties of computers is that they enable reliable, eminently reproducible automation. Formal languages (like programming languages) not only allow to unambiguously specify the desired automation to the upmost level of precision, they also allow humans to reason about the automation with precision and confidence. Natural language is a poor substitute for that. The ground truth of programs will always be the code, and if humans want to precisely control what a program does, they’ll be best served by understanding, manipulating, and reasoning about the code.
“Manual” has a negative connotation. If I understand the article correctly, they mean “human coding remains key”. It’s not clear to me the GitHub CEO actually used the word “manual”, that would surprise me. Is there another source on this that’s either more neutral or better at choosing accurate words? The last thing we need is to put down human coding as “manual”; human coders have a large toolbox of non-AI tools to automate their coding.
Often when you're calling something "manual" you're taking something off the automated happy path to tediously and slowly wind the thing through its complex process by hand. The difference between manual coding and human coding is tedium and laboriousness. It's not laborious to program, but the phrase "manual coding" evokes that image.
Maybe that’s what they’ve been doing? No one using Vim, Emacs, or Unix as an IDE would say they do manual coding with the amount of automation that usually goes there.
From the AI overview (need to at least try that out a few times after all the talk about Google enshittification like by Cory Doctorow in this year's PyCon US keynote:
>Nemo malus nisi probetur" is a Latin legal maxim that translates to "No one is evil unless proven." It signifies that a person is presumed innocent until proven guilty in a court of law. This principle is fundamental to legal systems that value fairness and due process, ensuring that accusations are substantiated before a person is considered culpable.
Here's a breakdown of the phrase:
Nemo: No one
malus: Evil, bad, wicked
nisi: Unless
probetur: Is proven, is shown, is demonstrated
The maxim essentially means that one should not be treated as inherently bad or guilty without sufficient evidence. This principle is closely related to the concept of "presumption of innocence" and is crucial for upholding justice and protecting individual rights.
Hopefully a CEO finally tempering some expectations and the recent Apple paper bring some sanity back into the discourse around these tools.[^1]
Are they cool and useful? Yes.
Do they reason? No. (Before you complain, please first define reason).
Are they end all be all of all problem solving and the dawn of AGI? Also no.
Once we actually bring some rationality back into the radius of discourse maybe we'll actually begin to start figuring out how these things actually fit into an engineering workflow and stop throwing around ridiculous terms like vibe coding.
If you are an engineer, you are signing up to build rigorously verified and validated system, preferably with some amount of certainty about their behavior under boundary conditions. All the current hype-addled discussion around LLM seems to have had everything but correctness as it's focus.
[^1]: It shouldn't take a CEO but many people, even technologists, who should be more rational about whose opinions they deem worthy of consideration, m seem to overvalue the opinions of the csuite for some bizarre, inexplicable reason.
The recent Apple paper seemed pretty flawed. Anthropic/Open Philanthropy did a rebuttal paper, The Illusion of the Illusion of Thinking.
> Do they reason? No. (Before you complain, please first define reason).
Defining reasoning is the problem. No, they don't reason in the same way as humans. But they seem to be able to go through reasoning steps in some important way. It's like asking if submarines swim.
I completely agree. The difference is, the utility of the submarine and its sales strategy did not depend on convincing human beings that it does swim like them.
The opposite is true of LLMs. Much of the sales pitch of these companies is that these things are capable of some form of reasoning that is in 1:1 correspondence with human reason. Not true. That's what makes this whole segment of the industry snake oil. It's not complete bunk because they do have some utility, but these companies know what they are doing when they use the term reason in all their marketing and papers. They are, in fact, trying to sell you the submarine because it can "swim".
"He warned that depending solely on automated agents could lead to inefficiencies. For instance, spending too much time explaining simple changes in natural language instead of editing the code directly."
Lots of changes where describing them in English takes longer than just performing the change. I think the most effective workflow with AI agents will be a sort of active back-and-forth.
Yeah, I can’t count the number of times I’ve thought about a change, explained it in natural language, pressed enter, then realized I’ve already arrived at the exact change I need to apply just by thinking it through. Oftentimes I even beat the agent at editing it, if it’s a context-heavy change.
How active are you ok with/want? I've just joined an agent tooling startup (yesh...I wrote that huh...) - and it's something we talk a lot about internally, we're thinking it's fine to do back and forth, tell it frankly it's not doing it right, etc, but some stuff might be annoying? Do you have a sense of how this might work to your mind? Thanks! :)
AI is still not there yet. For example, I constantly have to deal with mis-referenced documents and specifications. I think part of the problem is that it was trained on outdated materials and is unable to actively update on the fly. I can get around this problem but…
The problem with today’s LLM and GI solutions is that they try to solve all n steps when solving the first i steps would be infinitely more useful for human consumption. I’ve yet to see a fully modular solution (though MCPs partly solves it), where I can just say, “Hey, using my specific coding style based on my github, solve problem x, based on resources a, b, and c and only a, b, and c.” I would also like to see a more verbose/interactive coding AI, where it will ask incremental questions as it traverses a problem tree.
It's interesting to see a CEO express thoughts on AI and coding go in a slightly different direction.
Usually the CEO or investor says 30% (or some other made up number) of all code is written by AI and the number will only increase, implying that developers will soon be obsolete.
It's implied that 30% of all code submitted and shipped to production is from AI agents with zero human interaction. But of course this is not the case, it's the same developers as before using tools to more rapidly write code.
And writing code is only one part of a developer's job in building software.
He’s probably more right than not. But he also has a vested interest in this (just like the other CEOs who say the opposite), being in the business of human-mediated code.
Presumably you're aware that the full name of Microsoft's Copilot AI code authoring tool is "GitHub Copilot", that GitHub developed it, and that he runs GitHub.
I was talking about the Microsoft CEO quote everyone is misquoting. He said something to affect of "at Microsoft we have _some_ repos where up to 30% of the code is _generated_". This could mean they have one C++ repo for one tool that has 30% generated header files without any LLM usage at all. Of course that is probably not what he meant and the least generous view, but I find it extremely suspect to believe that any large company, much less Microsoft, would have third of their code produced by LLMs. I find it hard to believe any profitable software company has that high of a percentage.
My guess is they will settle for 2x the productivity as a before-AI developer as their skill floor, but then not take a look at how long meetings and other processes take.
Why not look at Bob who takes like 2 weeks to write tickets on what they actually want in a feature? Or Alice who's really slow getting Figma designs done and validated? How nice would having a "someone's bothered a developer" metric be and having the business seek to get that to zero and talk very loudly about it as they have about developers?
Because everyone who bothers the developers is actually in charge, and they would never want to reduce their utilization, all of this removal of need to focus on the code makes them excited that you can be in even more meetings.
Too late, I am seeing developer after developer doing copy/paste from AI tools and when asked, they have no idea how the code works coz "it just works"
Google itself said 30% of their code is AI generated, and yet they had a recent outage worldwide, coincidence??
[0] A term from the book A Philosophy of Software Design - people who constantly chuck out "working" code with no design. Tactical programming vs Strategic programming
I cannot help but read this in the subtext of, “We need more training data from humans; please don’t stop uploading your code to us.”
Look, manual coding (and art, and media, and IT, and others) will always be needed. GenAI was never going to replace these jobs wholesale, or even permanently displace workers. The fact this is trending in an APAC-focused site suggests the real message is, “we don’t want our outsource farms thinking this [GenAI] will replace you.”
Prediction of tokens was never going to lead to AGI. All it’s going to accomplish is instilling a deep, traumatic hostility in the populace towards further automation right when we need it the most.
The other day we had a fairly complex conditional, modified incorrectly by AI, and it cost the company a lot of money and harmed reputation with partners.
AI just cannot reason about logical things reliably. And no one noticed because the AI had made several other sweeping changes, and the noise drowned it out.
Going by the content of the linked post, this is very much a misleading headline. There is nothing in the quotes that I would read as an endorsement of "manual coding", at least not in the sense that we have used the term "coding" for the past decades.
just wait til it starts virtue signalling and posting contrived anecdotes about b2b sales and the benefits of RTO on LinkedIn. the vibe-HR department is gonna have to rein things in fast!
Great post—Dohmke’s call to preserve hands‑on coding while leveraging AI resonates strongly. It’s not about replacing devs but enabling them to build faster while staying in control.
In practice, pure LLM suggestions often feel detached from your actual codebase—missing intent, architectural constraints, or team conventions. What helped us was adopting a repo‑aware evaluation approach with tooling that:
- Scans entire repos, generates architecture diagrams, dependency maps, and feature breakdowns.
- Surfaces AI suggestions grounded in context—so prompts don’t float in isolation.
- Supports human-in-the-loop validation, making it easy to vet AI‑generated PRs before merging.
- Tracks drift, technical debt, and cost per eval, so AI usage isn’t a black box.
The result isn’t autopilot coding—it’s contextual assistance that amplifies developer decisions. That aligns exactly with Dohmke: use AI to accelerate, but keep the engineer firmly in the driver’s seat.
Curious if others have tried similar repo‑aware AI workflows that don’t sacrifice control for speed?
Imo this is a misunderstanding of what AI companies want AI tools to be and where the industry is heading in the near future. The endgame for many companies is SWE automation, not augmentation.
To expand -
1. Models "reason" and can increasingly generate code given natural language. Its not just fancy autocomplete, its like having an intern - mid level engineer at your beck and call to implement some feature. Natural language is generally sufficient enough when I interact with other engineers, why is it not sufficient for an AI, which (in the limit), approaches an actual human engineer?
2. Business wise, companies will not settle for augmentation. Software companies pay tons of money in headcount, its probably most mid-sized companies top or second line item. The endgame for leadership at these companies is to do more with less. This necessitates automation (in addition to augmenting the remaining roles).
People need to stop thinking of LLMs as "autocomplete on steroids" and actually start thinking of them as a "24/7 junior SWE who doesn't need to eat or sleep and can do small tasks at 90% accuracy with some reasonable spec." Yeah you'll need to edit their code once in a while but they also get better and cost less than an actual person.
This sounds exactly like the late '90s all over again. All the programming jobs were going to be outsourced to other countries and you'd be lucky to make minimum wage.
And then the last 25 years happened.
Now people are predicting the same thing will happen, but with AI.
The problem then, as is now, is not that coding is hard, it's that people don't know what the hell they actually want.
Software companies make a single copy and sell it a billion times. The revenue per employee is insane. The largest companies are trying to make the best product in the world and seek out slight advantages.
The cost saving mindset you are describing is found in companies where software isn’t a core part of the business.
That is the ideal for the management types and the AI labs themselves yes. Copilots are just a way to test the market, and gain data and adoption early. I don't think it is much of a secret anymore. We even see benchmarks created (e.g. OpenAI recently did one) that are solely about taking paid work away from programmers and how many "paid tasks" it can actually do. They have a benchmark - that's their target.
As a standard pleb though I can understand why this world; where the people with connections, social standing and capital have an advantage isn't appealing to many on this forum. If anyone can do something - other advantages that aren't as easy to acquire matter more relatively.
I mean duhh? Is there anyone who denies this is what they would want to happen? That's capitalism. They'd also kill all other roles if they could - and there are other very expensive personnel like sales people, marketers, accountants etc.
Whether it's going to happen ,when , and by how much is a different matter to what they want though.
I recently started consulting for a company that's building an AI first tool.
The entire application is powered through several AI agents, I had a look at their code and had to throw up, each agent is a single Python file of over 4000 lines, you can just look at the first 100 lines and tell its all LLM generated code, the hilarious part is if I paste the code into ChatGPT to help me break it down, it hits the context window in like 1 response!
I think this is one of the main problems with AI code, 5 years ago every time I took on a project, I knew the code I was reading and diving into was written by a human, well thought and structured. These days almost all the code I see is glue code, AI has done severe damage by enabling engineers who do not understand basic structures and fundamentals write 'code that just works'.
At the same time, I don't blame just the AI, cause several times I have written code myself which is gluecode, but then asked AI to refactor it in a way I want and it is usually really good at it.
> Dohmke described an effective workflow where AI tools generate code and submit pull requests.
This is kind of vague. What kinds of contributions he's talking about? Adding features, refactoring, removing dead code, optimizing, adding new tests?
The article mentions boilerplate. Is that all current coding AIs can do?
> For instance, spending too much time explaining simple changes in natural language instead of editing the code directly.
Why not write the code directly then? Even less friction.
Again, _it all depends on the kinds of contributions AI can make_.
The fact that they're being vague about it tells me something. If you had a bot that can fix tests (or even get you 90% of the way), you'd be boasting that everywhere. It would be an extraordinary evidence and you'd be very proud of it.
If someone made a PR to my repo adding a bunch of automated boilerplate, I'd be pissed, not encouraged to make it work.
I think most programmers would agree that thinking represents the majority of our time. Writing code is no different than writing down your thoughts, and that process in itself can be immensely productive -- it can spark new ideas, grant epiphanies, or take you in an entirely new direction altogether. Writing is thinking.
I think an over-reliance, or perhaps any reliance, on AI tools will turn good programmers into slop factories, as they consistently skip over a vital part of creating high-quality software.
You could argue that the prompt == code, but then you are adding an intermediary step between you and the code, and something will always be lost in translation.
I think this misses the point. You're right that programmers still need to think. But you're wrong thinking that AI does not help with that.
With AI, instead of starting with zero and building up, you can start with a result and iterate on it straight away. This process really shines when you have a good idea of what you want to do, and how you want it implemented. In these cases, it is really easy to review the code, because you knew what you wanted it to look like. And so, it lets me implement some basic features in 15 minutes instead of an hour. This is awesome.
For more complex ideas, AI can also be a great idea sparring partner. Claude Code can take a paragraph or two from me, and then generate a 200-800 line planning document fleshing out all the details. That document: 1) helps me to quickly spot roadblocks using my own knowledge, and 2) helps me iterate quickly in the design space. This lets me spend more time thinking about the design of the system. And Claude 4 Opus is near-perfect at taking one of these big planning specifications and implementing it, because the feature is so well specified.
So, the reality is that AI opens up new possible workflows. They aren't always appropriate. Sometimes the process of writing the code yourself and iterating on it is important to helping you build your mental model of a piece of functionality. But a lot of the time, there's no mystery in what I want to write. And in these cases, AI is brilliant at speeding up design and implementation.
> So, the reality is that AI opens up new possible workflows. They aren't always appropriate. Sometimes the process of writing the code yourself and iterating on it is important to helping you build your mental model of a piece of functionality. But a lot of the time, there's no mystery in what I want to write. And in these cases, AI is brilliant at speeding up design and implementation.
I agree but I have a hunch we're all gonna be pushed by higher ups to use AI always and for everything. Headcounts will drop, the amount of work will rise and deadlines will become ever so tight. What the resulting codebases would look like years from now will be interesting.
Yeah, I am grateful that I work with a lot of other engineers and managers who care a lot about quality. If you have a manager who just cares about speed, the corner cutting that AI enables could become a nightmare.
Based on your workflow, I think there is considerable risk of you being wooed by AI into believing what you are doing is worthwhile. The plan AI offers is coherent, specific, it sounds good. It's validation. Sugar.
I know the tools and environments I am working in. I verify the implementations I make by testing them. I review everything I am generating.
The idea that AI is going to trick me is absurd. I'm a professional, not some vibe coding script kiddie. I can recognise when the AI makes mistakes.
Have the humility to see that not everyone using AI is someone who doesn't know what they are doing and just clicks accept on every idea from the AI. That's not how this works.
We're talking about software development here, not misinformation about politics or something.
Software is incredibly easy to verify compared to other domains. First, my own expertise can pick up most mistakes during review. Second, all of the automated linting, unit testing, integration testing, and manual testing is near guaranteed to pick up a problem with the functionality being wrong.
So, how exactly do you think AI is going to trick me when I'm asking it to write a new migration to add a new table, link that into a model, and expose that in an API? I have done each of these things 100 times. It is so obvious to me when it makes a mistake, because this process is so routine. So how exactly is AI going to trick me? It's an absurd notion.
AI does have risks with people being lulled into a false sense of security. But that is a concern in areas like getting it to explain how a codebase works for you, or getting it to try to teach you about technologies. Then you can end up with a false idea about how something works. But in software development itself? When I already have worked with all of these tools for years? It just isn't a big issue. And the benefits far outweigh it occasionally telling me that an API exists that actually doesn't exist, which I will realise almost immediately when the code fails to run.
People who dismiss AI because it makes mistakes are tiresome. The lack of reliability of LLMs is just another constraint to engineer around. It's not magic.
Yes, maybe using the word "verify" here is a bit confusing. The point was to compare software, where it is very easy to verify the positive case, to other domains where it is not possible to verify anything at all, and manual review is all you get.
For example, a research document could sound good, but be complete nonsense. There's no realistic way to verify that an English document is correct other than to verify it manually. Whereas, software has huge amounts of investment into testing whether a piece of software does what it should for a given environment and test cases.
Now, this is a bit different to formally verifying that the software is correct for all environments and inputs. But we definitely have a lot more verification tools at our disposal than most other domains.
More complaining & pessimism means better signal for teams building the AI coding tools! Keep it up!
The ceiling for AI is not even close to being met. We have to be practical with whats reasonable, but getting 90% complete in a few prompts is magic.
I think so many devs fail to realise that to your product manager / team lead, the interface between you and the LLM is basically the same. They write a ticket/prompt and they get back a bunch of code that undoubtedly has bugs and misinterpretations in it, will probably go through a few rounds of revisions of back and forth until its good enough to ship (ie they tested it black-box style and it worked once) then they can move on to the next thing until whatever this ticket was about rears its ugly head again at some point in the future. If you arent used to writing user stories / planning, youre really gonna be obsolete soon.
I believe it's important to learn the basics of manual programming and also figure out how to work with AI tools in a smart way. It's not just about letting AI do the coding for us. We still need to think clearly and improve our own Solving the problem skills. AI can help turn ideas into reality, but we need to grow too if we want to really make use of it.
I'm not really afraid that AI will replace programmers. What I worry about is that it might make programmers stop thinking. I've seen beginners who quickly get used to asking AI for answers and no longer try to understand how things actually work. It may feel fast at first, but over time they lose the ability to solve problems on their own.
I think in 5 years from now we will see a major software dev shortage. Mainly because of all the reports that big tech companies are replacing devs with AI which scares new students to sign up for a CS degree.
The truth is that those devs who has been replaced should not have been hired in the first place as the companies were already overstuffed.
We've generated a lot of code with claude code recently...then we've had to go back and rationalize it... :) fun times...you absolutely must have a well defined architecture established before using these tools.
It would be nice if he would back that up by increasing focus on quality of life issues on GitHub. GitHub's feature set seems to get very little attention unless it overlaps with Copilot.
I think these are coordinated posts by Microsoft execs. First their director of product, now this. Its like they're trying to calm the auto coding hype until they catchup and thus keep OpenAI from running away.
It was only 2 years ago we were still taking about GPTs making up completely nonsense, and now hallucinations are almost gone from the discussions. I assume it will get even better, but I also think there is an inherent plateau. Just like how machines solved mass manufacturing work, but we still have factory workers and overseers. Also, "manually" hand crafted pieces like fashion and watches continue to be the most expensive luxury goods. So I don't believe good design architects and consulting will ever be fully replaced.
Hallucinations are now plausibly wrong which is in some ways harder to deal with. GPT4.1 still generates Rust with imaginary crates and says “your tests passed, we can now move on” to a completely failed test run.
"hallucinations are almost gone from the discussions" because everyone now accepts that LLM hallucinate all the times, no point in mentioning it anymore.
Yawn... Epistemic standards have fallen to rock bottom levels across STEM due to metric matching, more so in the cookie-cutter jira world of soulless software factories.
That these "geniuses" think they can replace humans, not only for knowledge work, but also for labour is laughable for any one who has worked with LLMs.
For me, too. On the poorly-documented stuff that I get into, where I really need help, it flails.
I wanted some jq script and it made an incomprehensible thing that usually worked. And every fix it made broke something else. It just kept digging a deeper hole.
After a while of that, I bit the bullet and learned jq script. I wrote a solution that was more capable, easier to read, and, importantly, always worked.
The thing is, jq is completely documented. Everything I needed was online. But there just aren't many examples to for LLMs, so they choke.
Start asking it questions about complexity classes and you can get it to contradict itself in no time.
Most of the code in the world right now is very formulaic, and it's great at that. Sorry, WordPress devs.
AI tools are great for speeding up small tasks, but when it comes to debugging, refactoring, or designing anything more complex, manual coding is still essential. Especially when things break, if you do not understand the underlying logic, you cannot really fix it properly.
AI is becoming a helpful assistant, but it is still far from replacing real engineering skill.
Copying from another post. I’m very puzzled on why people don’t talk more about essential complexity of specifying systems any more:
In No Silver Bullet, Fred Brooks argues that the hard part of software engineering lies in essential complexity - understanding, specifying, and modeling the problem space - while accidental complexity like tool limitations is secondary. His point was that no tool or methodology would "magically" eliminate the difficulty of software development because the core challenge is conceptual, not syntactic. Fast forward to today: there's a lot of talk about AI agents replacing engineers by writing entire codebases from natural language prompts. But that seems to assume the specification problem is somehow solved or simplified. In reality, turning vague ideas into detailed, robust systems still feels like the core job of engineers.
If someone provides detailed specs and iteratively works with an AI to build software, aren’t they just using AI to eliminate accidental complexity—like how we moved from assembly to high-level languages? That doesn’t replace engineers; it boosts our productivity. If anything, it should increase opportunities by lowering the cost of iteration and scaling our impact.
So how do we reconcile this? If an agent writes a product from a prompt, that only works because someone else has already fully specified the system—implicitly or explicitly. And if we’re just using AI to replicate existing products, then we’re not solving technical problems anymore; we’re just competing on distribution or cost. That’s not an engineering disruption—it’s a business one.
What am I missing here?
I think the crux is that specification has been neglected since even before AI.
Stakeholders (client, managers) have been "vibe coding" all along. They send some vague descriptions and someone magically gives back a solution. Does the solution completely work? No one knows. It kinda works, but no one knows for sure.
Most of the time, it's actually the programmers' understanding of the domain that fills out the details (we all know what a correct form submission webpage looks like).
Now the other end has become AI, it remains to be seen whether this can be replicated.
What they want: Computer: Make the room a wild west bar from 1900.
What they have: An undergraduate intern who is a former used car salesperson used to BSing their way through life.
They want the Holodeck, but not the post-scarcity society that makes it possible.
of course, because theres no money in it...
just look at software: cost of duplication is basically zero and here we are paying subscriptions (to huge profits) every month for it
switching to a true post-scarcity economy is gonna take more than just technology i think...
we all know what a correct form submission webpage looks like
millions of forms around the web would like to have a word… :)
We all know. But we all have a different vision of a ‘correct’ form
with all due respect but what does this mean? we can either "all know" or we can all not have a clue and have our own "visions" of the correct form, both of these are complete opposites.
decades of building garbage-barely-working forms is a proof that we just do not know (much like we (generally) don't know how to center a div on the page so once-per-year, without fail, top story on HN is "how to center a div" :) ).
We all think we know
This is spot-on, and a comment I wish I could pin for others to see.
GenAI is such a boon at present because it occasionally delivers acceptable mediocrity to PMs and Stakeholders who will accept said mediocrity because they have no real clue what they (or their customers) actually want. It’s a system of roles and output that delivers based on patterns in incomprehensively large data sets, provided to humans who cannot hope to validate that information is accurate or legitimate (and not just random patterns in a large enough data set), but passed along as gospel from digital machinegods. To a withering empire obsessed with nostalgia and whose institutions are crumbling beneath them, GenAI appears as a savior; to those confident in their position in the world order, it is merely a thin tool in a larger toolbox, to be used toward greater ends rather than middling output.
Those who understand the specification problems are in a position to capitalize off such monumental shifts, while those blindly chasing get-rich-quick schemes, grifts, and fads will be left behind.
Can you expand into the "those who understand the specification problems are in a position to capitalize off such shifts?"
Is this just business domain knowledge and good communication?
Always has been meme
> we all know what a correct form submission webpage looks like
Obviously we don‘t as phone numbers can be split in up to 4 fields with conflicting varieties of validation or just be one field.
Also the format varies depending on region and type of connection.
Or you are in Germany and phone number have variable length. They even have the word “number street” to mean “all phone numbers starting with 0123456” for example. It’s not a block, it’s a street, which can branch out in blocks of different lengths. Completely insane.
The split between essential and incidental complexity is a really key insight for thinking about how far AI can be pushed into software development. I think it's likely the detail many developers are feeling intuitively but not able to articulate, in regards to why they won't be replaced just yet.
It's certainly how actually using AI in earnest feels, I have been doing my best to get agents like Claude to work through problems in a complex codebase defined by enormous amounts of outside business logic. This lack of ability to truly intuit the business requirements and deep context requirements means it cannot make business related code changes. But it can help with very small context code changes, ie incidental complexity unrelated to the core role of a good developer, which is translating real world requirements into a system.
But I will add that it shouldn't be underestimated how many of us are actually solving the distribution problem, not technical problems. I still would not feel confident replacing a junior with AI, the core issue being lack of self-correction. But certainly people will try, and businesses built around AI development will be real and undercut established businesses. Whether that's net good or bad will probably not matter to those who lose their jobs in the scuffle.
> What am I missing here?
A terrifyingly large percentage of people employed to write software cannot write software. Not even a little. These are the people that can be easily replaced.
In my prior line of work I wrote JavaScript for a living. There were people doing amazing, just jaw dropping astounding, things. Those people were almost exclusively hobbyists. At work most people struggled to do little more than copy/paste in a struggle just to put text on screen. Sadly, that is not an exaggeration.
Some people did what they considered to be advanced engineering against these colossal frameworks, but the result is just the same: little more than copy/paste and struggle to put text on screen. Yes, they might be solving for advanced complexity, but it is almost always completely unnecessary and frequently related to code vanity.
Virtually none of those people could write original applications, measure anything, write documentation, or do just about anything else practical.
> So how do we reconcile this?
Alienate your workforce by setting high standards, like a bar exam to become a lawyer. Fire those people that fail to rise to the occasion. Moving forward employ people who cannot meet the high standards only as juniors or apprentices, so that the next generation of developers have the opportunity to learn the craft without rewarding failure.
> Alienate your workforce by setting high standards, like a bar exam to become a lawyer ...
This would work if the world was willing to pay for software. So at the very least you'd have to outlaw the ad-based business model, or do what lawyers do: things that are absolutely critical for software development (think "program needs to be approved or it won't execute", that deep) that normal people aren't allowed ... and unable ... to do.
From a purely economic perspective its all the same whether you are paying for products or paying for people and whether your revenue comes for media or sales. Those cost/profit first concerns are entirely the wrong questions to ask though, because they limit available routes of revenue generation.
The only purpose of software is automation. All cost factors should derive from that one source of truth. As a result the only valid concerns should be:
* Lowering liabilities
* Increasing capabilities
From a business perspective that means not paying money for unintended harms, and simultaneously either taking market share from the competition or inventing new markets. If your people aren't capable of writing software or your only options are free choices provided to you then you are the mercy of catastrophic opportunity costs that even the smallest players can sprint past.
An easy answer for what's missing is that the industry isn't run by people who read "No Silver Bullet".
- Articles about tricky nature of tech debt aren't written by people who call the shots on whether the team can spend the entire next week on something that a customer can't see.
- Articles about systems architecture aren't written by people who decide how much each piece of work was significant for business.
- Books on methodologies are optional read for engineers, not essential for their job, and adoption happens only when they push it upwards.
Most of the buzz about AI replacing coding is coming from people who don't see a difference between generating a working MVP of an app, and evolving an app codebase for a decade and fixing ancient poor design choices in a spaceship which is already in flight.
I've even seen a manager who proposed allocating 33% time every day on 3 projects, and engineers had to push back. Such old and common knowledge that it doesn't work is apparently still not a job requirement in 2025. Despite that organizing and structuring project time allocation is management competency and not an engineering skill, it is de-facto entirely up to engineers to make sure it's done right. The same managers are now proud to demonstrate their "customer focus" by proposing to ask AI to resolve all the tech debt and write all the missing tests so that engineers could focus on business requests, and same engineers have to figure how to explain why it didn't just work when they tried.
To talk about complexity is to repeat the same old mistake. I am sure most engineers already know and I am yet to see an experienced engineer who believes their job will be taken by simple prompts. The problem we should be talking about should be titled something like,
"Software Engineering Has Poor Management Problem, and AI is Amplifying It"
People (especially people who don't have a lot of hands on tech experience, or students who also aren't into building things) get the sense that writing software requires learning a lot of arcane tools. And the idea is to promise that anyone who can write a specification should be able to make software (yes, handwaving away the learning to specify well, which is a real skill with many dependent skills). This was the promise of no-code, and then they realized that the no-code system (in addition to usually being limited in power) is actually complex and requires specialized learning, and more of that the more powerful the system is. The LLM will replace SWEs approach is another take on that, because you don't need to learn a system, you prompt in natural language, and the model knows how to interface with the underlying system so you don't have to. In that sense, vibe coding is already the culmination of this goal (despite weaknesses such as maintainability issues).
I've seen it written that the main reason managers tend to want to get rid of SWEs is because they don't understand how to interface with them. Using an LLM solves that problem, because you don't need a nerd to operate it.
> I've seen it written that the main reason managers tend to want to get rid of SWEs is because they don't understand how to interface with them
That’s because software is nebulous enough that you can get away with promising the moon to customers/boss, but in the next meeting, you’re given a reality check by the SWEs. And then you realize the mess you’re thrown everyone in.
Managers knows how to interface with SWEs well (people interface with professionals all the time). Most just hates going back to the engineers to get real answers when they fancy themselves as products owners.
> I've seen it written that the main reason managers tend to want to get rid of SWEs is because they don't understand how to interface with them.
SWEs are also about the most expensive kind of employee imaginable. I imagine that’s incentive enough.
> Using an LLM solves that problem, because you don't need a nerd to operate it.
Until you do. LLMs are great ar building prototypes but at some point if you don’t know what you’ll doing you’ll end up with an unmaintainable mess and you won’t have anyone to fix it.
I mean LLMs perhaps are capable of doing that too but they still need to be guided by people who are capable of understanding their output.
Being able to reduce the number of engineers that you need by e.g. 80% would still be a great deal though.
Just use LLM to interface with nerds /s
Oh god please kill me
Please step away from the lathe
I'm not sure what the answer is - but I will say that LLMs do help me wrangle with essential complexity / real-world issues too.
Most problems businesses face have been seen by other businesses; perhaps some knowledge is in the training set or perhaps some problems are so easy to reason through that a LLM can do the "reasoning" more-or-less from first principles and your problem description.
I am speculating that AI will help with both sides of the No Silver Bullet dichotomy?
So in other words it's helping you race to the median. It can give your business the advantage of moving always in a direction that's average and uninteresting. Nobody will need to lead anymore, so nobody will have the skill of a leader anymore.
It sounds to me like a corporate equivalent of a drug-fueled rager. They want everything good now while deferring all the expenses to tomorrow.
Isn't that business though? Buying power is power, selling is weakness
Yeah, I give it about two years until we get to "Hey AI, what should we do today?" "Hi, I've noticed an increase in users struggling with transactions across individual accounts that they own. It appears some aspect of multitenancy would be warmly received by a significant fraction of our userbase. I have compiled a report on the different approaches taken by medium and large tech companies in this regard, and created a summary of user feedback that I've found on each. Based on this, and with the nuance of our industry, current userbase, the future markets we want to explore, and the ability to fit it most naturally into our existing infrastructure, I have boiled it down to one of these three options. Here are detailed design docs for each, that includes all downstream services affected, all data schema changes, lists out any concerns about backwards compatibility, user interface nuances, and has all the new operational and adoption metrics that we will want to monitor. Please read these through and let me know which one to start, and if you have any questions or suggestions I'll be more than happy to take them. For the first option, I've already prepared a list of PRs that I'm ready to commit and deploy in the designated order, and have tested e2e in a test cluster of all affected services, and it is up and running in a test cluster currently if you would like to explore it. It will take me a couple hours to do the same with the other two options if you'd like. If I get the green light today, I can sequence the deployments so that they don't conflict with other projects and have it in production by the end of the week, along with communication and optional training to the users I feel would find the feature most useful. Of course any of this can be changed, postponed, or dropped if you have concerns, would like to take a different approach, or think the feature should not be pursued."
Luckily, by that point it won't just be SWEs who'll be out of a job :)
Yeah, PM, data science, compliance, accounting...all largely automatable. You just need a few directors to call the shots on big risks. But even that goes away at some point because in a few months it'll have implemented everything you were thinking about doing for the next ten years and it simply runs out of stuff for humans to do.
What happens after that, I have no idea.
Seems like OpenAI (or whoever wins) could easily just start taking over whole industries at that point, or at least those that are mostly tech based, since it can replicate anything they can do, but cheaper. By that point, probably the only tech jobs left will be building safeguards so that AI doesn't destroy the planet.
Which sounds niche, but conceivably, could be a real, thriving industry. Once AI outruns us, there'll probably be a huge catastrophe at some point, after which we'll realize we need to "dumb down" AI in order to preserve our own species. It will serve almost as a physical resource, or maybe like a giant nuclear reactor, where we mine it as needed but don't let it run unfettered. Coordinating that balance to extract maximal economic growth without blowing everything up could end up being the primary function of human intelligence in the AI age.
Whether something like that can be sustained, in a world with ten billion different opinions on how to do so, remains to be seen.
You're right but I think we will be among the first to take the hit, we don't have the regulatory protections many doctors, accountants and lawyers have.
Kind of, but the models also output really awful code, even if it appears to work, and people (especially juniors) will push that awful code into PRs and people eventually approve of it because there's engineers who don't care about the craft, only collecting a paycheck. Then when things break or slow down to a crawl, nobody has any idea how to fix it because its all AI generated goop.
I think AI also introduces a new form of accidental complexity. When using Copilot, I often find myself telling it something to the effect of, “this seems needlessly complex and confusing, is there a better way to do this, or is this level of complexity justified?” It almost always apologizes and comes back with a solution I find much more pleasing, though on rare occasions it does justify its solution as a form of the original accidental complexity you mention. The more we lean on these tools, the more this accidental complexity from the model itself compounds.
There is a lot of truth in No Silver Bullet and I had the same idea in my mind.
Downside is there is much more non essential busy work because of which people had their jobs and now loads of those people will lose the job.
People who do work on real essential complexity of systems are far and between. People who say things like "proper professionals will always have work" are utter assholes thinking mostly that "they are those proper professionals".
In reality AI will be like F1 racing team not needing pit workers and have only drivers, how many drivers are there like 20 so it is 10 teams each having 2 drivers. Each team has 300-1000 people that do all the other things.
If you go to corporate level let's say 1 person working on essential complexity requires 10-20 people doing all kinds of non essential stuff that will be taken over by AI, or to be realistic instead of 10-20 people that person will need headcount of 5.
That is still 15 people out of job - are those people able to take over some essential complexity in a different company or different area of the same company, some would but it is also if they would like to do it. So those people will be pushed around or end up jobless, bitter whatever.
That is not great future coming in.
What you are saying is true. In a way, programmers still need to think about and wrestle with architectural complexity. And I agree the biggest overall gain is adding another layer of abstraction. But combine those two things and suddenly you have junior engineers that can very quickly learn how to architect systems. Because that will be the bulk of the job and they will be doing it every day.
Once you remove all the roadblocks with syntax and language blindspots, the high cost of refactoring, the tedium of adding validation and tests, the challenges of integrating systems... suddenly, the work becomes more pure. Yes, you need to know how to do advanced structural things. But you don't need to learn very much about all the rest of it.
And we very quickly get to a point where someone who can break down problems into tidy Jira tickets is effectively programming. Programming was never really about learning languages but making computers do things, which is a transferrable skill and why so many engineers know so many languages.
I think were still far from Jira -> tickets.
Even the simplest tickets sometimes that end up requiring a one line change can require hours of investigation to fully understand/stamp the effects of that change.
And perhaps I havent used the greatest or latest, but in my experience LLMs break down hard st anything sufficiently large. They make changes and introduce new errors, they end up changing the feature, or worst case just ouright break everything.
Id never trust it unless you have an extensive amount of good tests for validation
Actually, you're not missing anything. The thing is, hype cycles are just that, cycles. They come around with a mix of genuine amnesia, convenient amnesia, and junior enthusiasm, because cycles require a society (and/or industry) both able and willing to repeat exploration and decisions, whether they end up in wins or losses. Some people start to get get the pattern after a while but they are seen as cynics. After all, the show must go on, "what if this or the next cycle is the one that leads us to tech nirvana?"
Software engineering for any non-trivial problem means a baseline level of essential complexity that isn't going away, no matter the tool, not even if we someday "code" directly from our minds in some almost-free way via parallel programming thought diffusion. That's because (1) depth and breadth of choice; and (2) coordination/socials, mostly due but not uniquely related to (1) are the real bottlenecks.
Sure, accidental complexity can shrink, if you design in a way that's aligned with the tools, but even then, the gains are often overhyped. These kinds of "developer accelerators" (IDEs, low-code platforms, etc.) are always oversold in depth and scope, LLMs included.
The promise of the "10x engineer" is always there, but the reality is more mundane. For example, IDEs and LSPs are helpful, but not really transformative. Up to a point that people are being payed right now and don't use them at all, and they still deliver in a "economically justifiable" (by someone) way.
Today it's LLMs. Tomorrow it'll be LISP Machines v2.
I thought that was Python notebooks. :)
You first start using a hammer well, and then internalizing when to use a hammer. Most are now getting excited about the new shinny hammer. Few knows hammer is not for everything. Some will never know. It has always been the case. Microservice, NoSQL, kubernetes, crypto, web3, now LLM. They range from useful some of the time to completely useless. But they surely appeared to be panacea at some time to some people.
You're missing the part where building a modern website is a huge amount of dev time for largely UI work. Also modern deployment is 100x more complicated than in Brook's day. I'd say 90% of my projects are on these two parts which really shows how productivity has gone down (and AI can fix)
This is mostly self inflicted though. We create complex deployments with the promise that the incremental savings will overtake the upfront costs when they rarely do (and the hidden complexity costs).
So it seems AI will just let us stretch further and make more accidentally complex systems.
The value of automation ("complex deployments") is not only incremental cost savings (ie because you don't need to do the work over and over), but also the reduction or outright elimination of human error, which especially in the case of security-sensitive activities like deploying software on the Internet can be orders of magnitude more costly than the time it takes to automate it.
That is a benefit of automation. But it does not appear to correlate with tool complexity, or the primary focus of commercial offerings.
E.g the most complex deployments are not the ones that are the least error prone or require the least amount of intervention.
What do you consider a complex deployment?
1. the degree to which it can prevent me from doing my job if it’s not working
2. The level of expertise and skill required to set it up and maintain
Back when IE was king and IE6 was still 10% of users, I did frontend web work. I remember sitting next to our designer with multiple browsers open playing with pixel offsets to get the design as close as practically possible to the mockups for most users and good enough for every one else. This isn't something LLMs do without a model of what looks good.
My current job involves exactly this (thanks not on IE) and AI is, as you said, absolutely bad at it.
And I’m saying this as someone who kind of adopted AI pretty early for code and who learned how to prompt it.
The best way to make AI worth your time is to make it work towards a predictable output. TDD is really good for this : you write your test cases and you make the AI do the work.
But when you want a visual result ? It will have no feedback of any clue, will always answer "Ok, I solved this" while making things worse. Even if the model is visual, giving it screenshots as feedback is useless too.
Modern development is more complex, not more complicated. We’re still using the same categories of tools. What’s changed is the tower of abstraction we put between ourselves and the problem.
Can AI fix it? Most of that complexity is from a need to stand out.
... and approvals. The fact that the vast majority of companies just don't have infrastructure. The only thing that made a dent in that is VMWare.
> aren’t they just using AI to eliminate accidental complexity
After using Claude Code to vibe code some stuff, it seems to me that AI doesn't eliminate accidental complexity, it just creates more of it and takes away some of the pain of really bad APIs.
Nothing at all. The people who could and should understand this point are indisposed towards criticizing the AI narrative.
They've started a business selling the exact opposite message to everyone who will buy it
> it should increase opportunities by lowering the cost of iteration and scaling our impact
This is very much up for debate and the weakest point of the argument I think. If developers are now 2-3x (remains to be seen..) as productive what will happen to the job market?
I suppose it depends on how much potential software is there that's not currently viable due to cost? How much would scope be increased on current products?
I agree on the essential complexity, but I think there is a missing piece that we don't really have good mental tools how to operate (compose) the SW systems with uncertainty. Something like fuzzy logic?
I think there is a promise of that in AI and LLMs (but I remain skeptical, because I it needs a formal and not ad hoc definition). The idea you can build the systems using a fuzzy human language and the things will somehow work out.
you're spot on. Building software is first and foremost making a team of person understand a problem. The fact that part of it is solved by writing code is almost a byproduct of that understanding, and certainly does not come before.
on this topic I suggest everybody who works in our industry to read Peter Naur's "Programming as Theory Building"[1] and a nice corollary from Baldur Bjarnson: "Theory-building and why employee churn is lethal to software companies"[2]
[1]: https://pages.cs.wisc.edu/~remzi/Naur.pdf [2]: https://www.baldurbjarnason.com/2022/theory-building/
i think the difference is that now someone with no coding knowledge could start describing software and make the agent build that software iteratively. so for example a mechanical engineer wants to build some simulation tool. you still need to define those requirements and understand what you want to do but the work could be (and this is the big if still, if agents become good enough for this sort of work) done by the agent not a humand programmer. i do not see that happening at the moment but still this does change the dynamic. you are right in that it is not a silver bullet and a lot of the complexity is impossible to get rid of. but i wonder if for a lot of use cases there will not be a software engineer in the loop. for bigger systems, for sure, but for a lot of smaller business software?
A mechanical engineer has a job to do. They can't all spend their time yak shaving with an AI agent building software that they then use to do their actual job. The whole point of building software is it's more efficient to build it once then use it many times. Why would a "someone with no coding knowledge" do this when someone with coding knowledge could do it?
> for a lot of smaller business software?
Small businesses often understand domain less, not more, because they cannot invest as much as big businesses in building expertise. They may achieve something within that limited understanding, but the outcome will limit their growth. Of course, AI can help with discovery, but it may overcomplicate things. Product discovery is an art of figuring out what to do without doing too much or not enough, which AI has not mastered yet.
This totally breaks due to complexity. This "works", except that AI destroys earlier functionality when adding new things. Also there is a very low level of complexity where AI just blows up and won't work anymore, not even a little bit.
(and certainly Google's newest AI model is actually a step backwards on this front)
Add to that that nothing changes for difficult work. Writing a driver still requires hardware knowledge ... of the actual hardware. Which AI doesn't have ... and doesn't make any attempt to acquire.
I've seen articles that this part can actually be fixed. If you create a loop where the AI is forced to slowly build up low-level knowledge it can actually find this sort of things. But you need 10 expert AI researchers to do anything like this.
(frankly I don't see how this part could be fixed by better AI models)
What's in danger is the coding job consisting of "write me a form with these 20 fields". The 100% repetitive ones.
Making any non trivial system with AI only highlights this problem. My repo is littered with specs the AI has to refer to to build the system. But the specs are unclear files that have been added to and grown outdated over time, so now we often end up gling back and forth without much progress.
> lowering the cost of iteration
I don't think anyone thinks engineers are going away. But companies will hire less employees to do the same amount of work, and they won't pay engineers more.
>>> "people don’t talk more about essential complexity "
That doesn't sell stock. Firing high paying employees sells a lot of stock.
… because programming languages are the right level of precision for specifying a program you want. Natural language isn’t it. Of course you need to review and edit what it generates. Of course it’s often easier to make the change yourself instead of describing how to make the change.
I wonder if the independent studies that show Copilot increasing the rate of errors in software have anything to do with this less bold attitude. Most people selling AI are predicting the obsolescence of human authors.
Transformers can be used to automate testing, create deeper and broader specification, accelerate greenfield projects, rapidly and precisely expand a developer's knowledge as needed, navigate unfamiliar APIs without relying on reference, build out initial features, do code review and so much more.
Even if code is the right medium for specifying a program, transformers act as an automated interface between that medium and natural language. Modern high-end transformers have no problem producing code, while benefiting from a wealth of knowledge that far surpasses any individual.
> Most people selling AI are predicting the obsolescence of human authors.
It's entirely possible that we do become obsolete for a wide variety of programming domains. That's simply a reality, just as weavers saw massive layoffs in the wake of the automated loom, or scribes lost work after the printing press, or human calculators became pointless after high-precision calculators became commonplace.
This replacement might not happen tomorrow, or next year, or even in the next decade, but it's clear that we are able to build capable models. What remains to be done is R&D around things like hallucinations, accuracy, affordability, etc. as well as tooling and infrastructure built around this new paradigm. But the cat's out of the bag, and we are not returning to a paradigm that doesn't involve intelligent automation in our daily work; programming is literally about automating things and transformers are a massive forward step.
That doesn't really mean anything, though; You can still be as involved in your programming work as you'd like. Whether you can find paid, professional work depends on your domain, skill level and compensation preferences. But you can always program for fun or personal projects, and decide how much or how little automation you use. But I will recommend that you take these tools seriously, and that you aren't too dismissive, or you could find yourself left behind in a rapidly evolving landscape, similarly to the advent of personal computing and the internet.
> Modern high-end transformers have no problem producing code, while benefiting from a wealth of knowledge that far surpasses any individual.
It will also still happily turn your whole codebase into garbage rather than undo the first thing it tried to try something else. I've yet to see one that can back itself out of a logical corner.
This is it for me. If you ask these models to write something new, the result can be okay.
But the second you start iterating with them... the codebase goes to shit, because they never delete code. Never. They always bolt new shit on to solve any problem, even when there's an incredibly obvious path to achieve the same thing in a much more maintainable way with what already exists.
Show me a language model that can turn rube goldberg code into good readable code, and I'll suddenly become very interested in them. Until then, I remain a hater, because they only seem capable of the opposite :)
> because they never delete code. Never.
That's not true in my experience. Several times now i've given Claude Code a too-challenging task and after trying repeatedly it eventually gave up, removing all the previous work on that subject and choosing an easier solution instead.
.. unfortunately that was not at all what i wanted lol. I had told it "implement X feature with Y library", ie specifically the implementation i wanted to make progress towards, and then after a while it just decided that was difficult and to do it differently.
You'd be surprised what a combination of structured review passes and agent rules (even simple ones such as "please consider whether old code can be phased out") might do to your agentic workflow.
> Show me a language model that can turn rube goldberg code into good readable code, and I'll suddenly become very interested in them.
They can already do this. If you have any specific code examples in mind, I can experiment for you and return my conclusions if it means you'll earnestly try out a modern agentic workflow.
> You'd be surprised
I doubt it. I've experimented with most of them extensively, and worked with people who use them. The atrocious results speak for themselves.
> They can already do this. If you have any specific code examples in mind
Sure. The bluetooth drivers in the Linux kernel contain an enormous amount of shoddy duplicated code that has amalgamated over the past decade with little oversight: https://code.wbinvd.org/cgit/linux/tree/drivers/bluetooth
An LLM which was capable of refactoring all the duplicated logic into the common core and restructuring all the drivers to be simpler would be very very useful for me. It ought to be able to remove a few thousand lines of code there.
It needs to do it iteratively, in a sting of small patches that I can review and prove to myself are correct. If it spits out a giant single patch, that's worse than nothing, because I do systems work that actually has to be 100% correct, and I can't trust it.
Show me what you can make it do :)
> It will also still happily turn your whole codebase into garbage rather than undo the first thing it tried to try something else.
That's not true at all.
...
It's only pretending to be happy.
My Claude is happy to git restore and try a different approach when it walked itself into a corner ;)
That's a combination of current context limitations and a lack of quality tooling and prompting.
A well-designed agent can absolutely roll back code if given proper context and access to tooling such as git. Even flushing context/message history becomes viable for agents if the functionality is exposed to them.
Can we demonstrate them doing that? Absolutely.
Will they fail to do it in practice once they poison their own context hallucinating libraries or functions that don’t exist? Absolutely.
That’s the tricky part of working with agents.
> It's entirely possible that we do become obsolete for a wide variety of programming domains. That's simply a reality…
It is not a reality since it has not happen. In the real world it has not happened.
There is no reason to believe that the current rate of progress will continue. Intelligence is not like the weaving machines. A software engineer is not a human calculator.
To be fair he didn't say it is the reality now, he said the possibility is a reality. At least that's how I read his sentence. And yeah, I do think it's a real possibility now.
> That's simply a reality, just as weavers saw massive layoffs in the wake of the automated loom
They didn’t just see layoffs. There were the constant wars with Napoleon and the War of 1812 causing significant economic instability along with highly variable capital investments in textile production at the time. They we’re looking at huge wealth disparity and losing their jobs for most meant losing everything.
What many Luddite supporters were asking for in many parts of England were: better working conditions, a raise to minimum wage, abolishment of child labour, etc. Sabotage was a means to make such demands from a class that held almost all of the power.
Many of those protestors were shot. Those who survived and were laid off were forced into workhouses.
The capitalists won and got to write the history and the myths. They made it about the technology and not the conditions. They told us that the displaced workers found new, better jobs elsewhere.
Programmers, while part of the labour class, have so far enjoyed a much better bargaining position and have been compensated in kind. Many of us also complain about the quality of output from AI as the textile workers complained about the poor quality of the lace. But fortunately the workhouses were shut down. Although poor quality code tends to result in people losing their life’s savings, having their identities stolen, etc. Higher stakes than cheap lace.
History is not repeating but it sure does rhyme.
> That's simply a reality, just as weavers saw massive layoffs in the wake of the automated loom, or scribes lost work after the printing press, or human calculators became pointless after high-precision calculators became commonplace.
See, this is the kind of conception of a programmer I find completely befuddling. Programming isn't like those jobs at all. There's a reason people who are overly attached to code and see their job as "writing code" are pejoratively called "code monkeys." Did CAD kill the engineer? No. It didn't. The idea is ridiculous.
> Programming isn't like those jobs at all
I'm sure you understand the analogy was about automation and reduction in workforce, and that each of these professions have both commonalities and differences. You should assume good faith and interpret comments on Hacker News in the best reasonable light.
> There's a reason people who are overly attached to code and see their job as "writing code" are pejoratively called "code monkeys."
Strange. My experience is that "code monkeys" don't give a crap about the quality of their code or its impact with regards to the product, which is why they remain programmers and don't move on to roles which incorporate management or product responsibilities. Actually, the people who are "overly attached to code" tend to be computer scientists who are deeply interested in computation and its expression.
> Did CAD kill the engineer? No. It didn't. The idea is ridiculous.
Of course not. It led to a reduction in draftsmen, as now draftsmen can work more quickly and engineers can take on work that used to be done by draftsmen. The US Bureau of Labor Statistics states[0]:
Similarly, the other professions I mentioned were absorbed into higher-level professions. It has been stated many times that the future focus of software engineers will be less about programming and more about product design and management.I saw this a decade ago at the start of my professional career and from the start have been product and design focused, using code as a tool to get things done. That is not to say that I don't care deeply about computer science, I find coding and product development to each be incredibly creatively rewarding, and I find that a comprehensive understanding of each unlocks an entirely new way to see and act on the world.
[0] https://www.bls.gov/ooh/architecture-and-engineering/drafter...
My father in law was a draftsman. Lost his job when the defense industry contracted in the '90s. When he was looking for a new job everything required CAD which he had no experience in (he also had a learning disability, it made learning CAD hard).
He couldn't land a job that paid more than minimum wage after that.
Wow, that's a sad story. It really sucks to spend your life mastering a craft and suddenly find it obsolete and your best years behind you. My heart goes out to your father.
This is a phenomenon that seems to be experienced more and more frequently as the industrial revolution continues... The craft of drafting goes back to 2000 B.C.[0] and while techniques and requirements gradually changed over thousands of years, the digital revolution suddenly changed a ton of things all at once in drafting and many other crafts. This created a literacy gap many never recovered from.
I wonder if we'll see a similar split here with engineers and developers regarding agentic and LLM literacy.
[0] https://azon.com/2023/02/16/rare-historical-photos/
> Actually, the people who are "overly attached to code" tend to be computer scientists who are deeply interested in computation and its expression.
What academics are you rubbing shoulders with? Every single computer scientist I have ever met has projects where every increment in the major version goes like:
"I was really happy with my experimental kernel, but then I thought it might be nice to have hotpatching, so I abandoned the old codebase and started over from scratch."
The more novel and cutting edge the work you do is, the more harmful legacy code becomes.
I think we are operating under different interpretations of what "overly attached to code" means, leading to a misunderstanding about my comment.
In my case, I am referring to a deep appreciation of code itself, not any particular piece of code.
"I saw this a decade ago at the start of my professional career and from the start have been product and design focused"
I have similar view of the future as you do. But I'm just curious what the quoted text here means in practice. Did you go into product management instead of software engineer for example?
I don't disagree exactly, but the AI that fully replaces all the programmers is essentially a superhuman one. It's matching human output, but will obviously be able to do some tasks like calculations much faster, and won't need a lunch break.
At that point it's less "programmers will be out of work" as "most work may cease to exist".
Not sure about this. Coding has some unique characteristics that may it easier even if from a human perspective it requires some skill:
- The cost of failure is low: Most domains (physical, compliance, etc) don't have this luxury where the cost of failure is high and so the validator has more value.
- The cost to retry/do multiple simulations is low: You can perform many experiments at once, and pick the one with the best results. If the AI hallucinates, or generates something that doesn't work the agent/tool could take that error and simulate/do multiple high probability tries until it passes. Things like unit tests, compiler errors, etc make this easier.
- There are many right answers to a problem. Good enough software is good enough for many domains (e.g. a CRUD web app). Not all software is like this but many domains in software are.
What makes something hard to disrupt won't be intellectual difficulty (e.g. software harder than compliance analyst as a made up example), it will be other bottlenecks like the physical world (energy, material costs, etc), regulation (job isn't entirely about utility/output). etc.
> The cost of failure is low: Most domains (physical, compliance, etc) don't have this luxury where the cost of failure is high and so the validator has more value.
This is not entirely sensible, some code touches the physical / compliance world. Airports, airplanes, hospitals, cranes, water systems, military they all use code to different degrees. It's true that they can perhaps afford to run experiments over landing pages, but I don't think they can simply disrupt their workers and clients on a regular basis.
I did say "not all software is like this, but many domains are". So I agree with you.
Also note unlike say for physical domains where it's expensive to "tear down" until you commit and deploy (i.e. while the code is being worked on) you can try/iterate/refine via your IDE, shell, whatever. Its just text files after all; in the end you are accountable for the final verification step before it is published. I never said we don't need a verification step; or a gate before it goes to production systems. I'm saying its easier to throw away "hallucinations" that don't work and you can work around gaps in the model with iterations/retries/multiple versions until the user is happy with it.
Conversely I couldn't have an AI build a house, I don't like it, it demolishes it and builds a slightly different one, etc etc until I say "I'm happy with this product, please proceed". The sheer amount of resource waste and time spent in doing so would be enormous. I can simulate, generate plans, etc maybe with AI but nothing beats seeing the "physical thing" for some products especially when there isn't the budget/resources to "retry/change".
TL;DR the greater the cost of iteration/failure; the less likely you can use iteration to cover up gaps in your statistical model (i.e. tail risks are more likely to bite/harder to mitigate).
Doesn't AI have diminishing returns on it's pseudo creativity? Throw all the training output of LLM into a circle. If all input comes from other LLM output, the circle never grows. Humans constantly step outside the circle.
Perhaps LLM can be modified to step outside the circle, but as of today, it would be akin to monkeys typing.
I think you're either imagining the circle too small or overestimating how often humans step outside it. The typical programming job involves lots and lots of work, and yet none of it creating wholly original computer science. Current LLMs can customize well known UI/IO/CRUD/REST patterns with little difficulty, and these make up the vast majority of commercial software development.
I agree humans only rarely step outside the circle, but I do have this intuition that some people sometimes do, whereas LLMs never do. This distinction seems important over long time horizons when thinking about LLM vs human work.
But I can't quite articulate why I believe LLMs never step outside the circle, because they are seeded with some random noise via temperature. I could just be wrong.
Frameworks and low code systems have been able to do that for years. The reason they haven’t replaced programmers is that every system eventually becomes a special unique snowflake as long as it has time and users.
I’m getting maybe a 10-20% productivity boost using AI on mature codebases. Nice but not life changing.
a 20% boost is huge, for 3 years since chatgpt. even if it stopped there, that's 20% fewer people that need to be in your role, which is at least tens of thousands of jobs
That’s far less than the productivity boost I got by building some internal tooling with phoenix liveview instead of react.
10-20% productivity posts have been happening regularly over the course of my career. They are normally either squandered by inefficient processes or we start building more complex systems.
When Rails was released, for certain types of projects, you could move 3 or 4x faster almost overnight.
If devs produce 20% more, won't companies hire more since the gain/loss equation is starting to tilt their way even more? I find it odd that people think productivity increases lead to layoffs.
Assuming there’s fixed demand. If companies can get 20% more software for the same price then there is still a lot of automation to do
> Of course you need to review and edit what it generates.
Treating LLMs as a scaffolding tool yields better results at least for me personally. I just brain dump what I'm thinking of building and ask for it to give me models, and basic controllers using said models, then I just worry about the views and business logic.
I wasn’t in the industry to see it first hand, but was this same criticism levied against higher level languages when they first hit the scene? Something to the effect of high level languages not being the right level of precision, because the programmer wanted to directly manipulate what was happening in memory, and the high level languages are not the right level of precision for that?
The issue with natural language isn’t that it’s impossible to be precise, it’s that most people aren’t, or they are precise about what they want it to do for them, but not what the computer needs to do to make it happen. This leads to a lot of guessing by engineerings as they try to translate the business requirements into code. Now the LLM is doing that guessing, often with less context about the broader business objectives, or an understanding of the people writing those requirements.
> was this same criticism levied against higher level languages when they first hit the scene?
No.
Some were concerned that the output of compilers couldn’t match the quality of what could be done by a competent programmer at the time. That was true for a time. Then compilers got better.
Nobody was concerned that compilers were going to be used by capitalists to lay them off and seize the means of producing programs by turning it into property.
In my experience the best use of AI is to stay in the flow state when you get blocked by an API you don't understand or a feature you don't want to implement for whatever reason.
Right level for exactly specifying program behavior in a global domain without context.
But once you add repo context, domain knowledge etc... programming languages are far too verbose.
AI can very efficiently apply common patterns to vast amounts of code, but it has no inherent "idea" of what it's doing.
Here's a fresh example that I stumbled upon just a few hours ago. I needed to refactor some code that first computes the size of a popup, and then separately, the top left corner.
For brevity, one part used an "if", while the other one had a "switch":
I wanted the LLM to refactor it to store the position rather than applying it immediately. Turns out, it just could not handle different things (if vs. switch) doing a similar thing. I tried several variations of prompts, but it very strongly leaning to either have two ifs, or two switches, despite rather explicit instructions not to do so.It sort of makes sense: once the model has "completed" an if, and then encounters the need for a similar thing, it will pick an "if" again, because, well, it is completing the previous tokens.
Harmless here, but in many slightly less trivial examples, it would just steamroll over nuance and produce code that appears good, but fails in weird ways.
That said, splitting tasks into smaller parts devoid of such ambiguities works really well. Way easier to say "store size in m_StateStorage and apply on render" than manually editing 5 different points in the code. Especially with stuff like Cerebras, that can chew through complex code at several kilobytes per second, expanding simple thoughts faster than you could physically type them.
[flagged]
Sweeping generalizations about how LLMs will always (someday) be able to do arbitrary X, Y, and Z don't really capture me either
[flagged]
Until the day that thermodynamics kicks in.
Or the current strategies to scale across boards instead of chips gets too expensive in terms of cost, capital, and externalities.
I mean fair enough, I probably don't know as much about hardware and physics as you
Just pointing out that there are limits and there’s no reason to believe that models will improve indefinitely at the rates we’ve seen these last couple of years.
There is reason to believe that humans will keep trying to push the limitations of computation and computer science, and that recent advancements will greatly accelerate our ability to research and develop new paradigms.
Look at how well Deepseek performed with the limited, outdated hardware available to its researchers. And look at what demoscene practitioners have accomplished on much older hardware. Even if physical breakthroughs ceased or slowed down considerably, there is still a ton left on the table in terms of software optimization and theory advancement.
And remember just how young computer science is as a field, compared to other human practices that have been around for hundreds of thousands of years. We have so much to figure out, and as knowledge begets more knowledge, we will continue to figure out more things at an increasing pace, even if it requires increasingly large amounts of energy and human capital to make a discovery.
I am confident that if it is at all possible to reach human-level intelligence at least in specific categories of tasks, we're gonna figure it out. The only real question is whether access to energy and resources becomes a bigger problem in the future, given humanity's currently extraordinarily unsustainable path and the risk of nuclear conflict or sustained supply chain disruption.
> And remember just how young computer science is as a field, compared to other human practices that have been around for hundreds of thousands of years.
How long do you think Homo sapiens have been on Earth and how long has civilization been here?
I’ve been programming since 89. I know what you can squeeze into 100k.
But you can only blast so much electricity into a dense array of transistors before it melts the whole thing and electrons jump rails. We hit that limit a while ago. We’ve done a lot of optimization of instruction caching, loading, and execution. We front loaded a ton of caching in front of the registers. We’ve designed chips specialized to perform linear algebra calculations and scaled them to their limits.
AI is built on scaling the number of chips across the board. Which has the effect of requiring massive amounts of power. And heat dissipation. That’s why we’re building out so many new data centres: each one requiring land, water, and new sources of electricity generation to maintain demand levels for other uses… those sources mostly being methane and coal plants.
Yes, we might find local optimizations in training to lower the capital cost and external costs… but they will be a drop in the bucket at the scale we’re building out this infrastructure. We’re basically brute forcing the scale up here.
And computer science might be older than you think. We just used to call it logic. It took some electrical engineering innovations to make the physical computers happen but we had the theoretical understanding of computation for quite some time before those appeared.
A young field, yes, and a long way to go… perhaps!
But let’s not believe that innovation is magic. There’s hard science and engineering here. Electrons can only travel so fast. Transistor density can only scale so much. Etc.
> How long do you think Homo sapiens have been on Earth and how long has civilization been here?
I already corrected my typo in a child comment.
> We’re basically brute forcing the scale up here
Currently, but even that will eventually hit thermodynamic and socioeconomic limits, just as single chips are.
> And computer science might be older than you think. We just used to call it logic.
In my opinion, two landmark theory developments were type theory and the lambda calculus. Type theory was conceived to get around Russell's paradox and others, which formal logic could not do on its own.
As far as hardware, sure we had mechanical calculators in the 17th century, and Babbage's analytical engine in the 19th century, and Ada Lovelace's program, but it wasn't until the mid-20th century that computer science coalesced as its own distinct field. We didn't used to call computer science logic; it's a unification of physical advancements, logic and several other domains.
> Electrons can only travel so fast.
And we have no reason to believe that current models are at all optimized on a software or theoretical level, especially since, as you say yourself, we are currently just focused on brute-forcing innovation as its the more cost-effective solution for the time being.
But as I said, once theoretical refinement becomes more cost-effective, we can look at the relatively short history of computer science to see just how much can be done on older hardware with better theory:
>> Even if physical breakthroughs ceased or slowed down considerably, there is still a ton left on the table in terms of software optimization and theory advancement.
I agree. And if human civilization survives, your concerns about energy and resources will be only short term on the scale of civilization, especially as we make models more efficient.
The human brain uses just 20 watts of power, so it seems to me like it is possible to reach human-level intelligence in principle by using much greater power and less of the evolutionary refinement over billions of years that the brain has.
* hundreds or thousands, not of
I am working on a GUI for delegating coding tasks to LLMs, so I routinely experiment with a bunch of models doing all kinds of things. In this case, Claude Sonnet 3.7 handled it just fine, while Llama-3.3-70B just couldn't get it. But that is literally the simplest example that illustrates the problem.
When I tried giving top-notch LLMs harder tasks (scan an abstract syntax tree coming from a parser in a particular way, and generate nodes for particular things) they completely blew it. Didn't even compile, let alone logical errors and missed points. But once I broke down the problem to making lists of relevant parsing contexts, and generating one wrapper class at a time, it saved me a whole ton of work. It took me a day to accomplish what would normally take a week.
Maybe they will figure it out eventually, maybe not. The point is, right now the technology has fundamental limitations, and you are better off knowing how to work around them, rather than blindly trusting the black box.
Yeah exactly.
I think it's a combination of
1) wrong level of granularity in prompting
2) lack of engineering experience
3) autistic rigidity regarding a single hallucination throwing the whole experience off
4) subconscious anxiety over the threat to their jerbs
5) unnecessary guilt over going against the tide; anything pro AI gets heavily downvoted on Reddit and is, at best, controversial as hell here
I, for one, have shipped like literally a product per day for the last month and it's amazing. Literally 2,000,000+ impressions, paying users, almost 100 sign ups across the various products. I am fucking flying. Hit the front page of Reddit and HN countless times in the last month.
Idk if I break down the prompts better or what. But this is production grade shit and I don't even remember the last time I wrote more than two consecutive lines of code.
If you are launching one product per day, you are using LLMs to convert unrefined ideas into proof-of-concept prototypes. That works really well, that's the kind of work that nobody should be doing by hand anymore.
Except, not all work is like that. Fast-forward to product version 2.34 where a particular customer needs a change that could break 5000 other customers because of non-trivial dependencies between different parts of the design, and you will be rewriting the entire thing by humans or having it collapse under its own weight.
But out of 100 products launched on the market, only 1 or 2 will ever reach that stage, and having 100 LLM prototypes followed by 2 thoughtful redesigns is way better than seeing 98 human-made products die.
Can you provide links to these 30 products you have shipped?
I keep hearing how people are so god damn productive with LLMs, but whenever I try to use them they can not reliably produce working code. Usually producing something that looks correct at first, but either doesn't work (at all or as intended).
Going over you list:
1. if the problem is that I need to be very specific with how I want LLM to fix the issue, like providing it the solution, why wouldn't I just make the change myself?
2. I don't even know how you can think that not vibe coding means you lack experience
3. Yes. If the model keeps trying to use non-existent language feature or completely made up functions/classes that is a problem and nothing to do with "autism"
4. This is what all AI maximalists want to think; that only reason why average software developer isn't knee deep in AI swamp with them is that they are luddites who are just scared for their jobs. I personally am not as I have not seen LLMs actually being useful for anything but replacing google searches.
5. I don't know why you keep bringing up Reddit so much. I also don't quite get who is going against the tide here, are you going against the tide of the downvotes or am I for not using LLMs to "fucking fly"?
>But this is production grade shit
I truly hope it is, because...
>and I don't even remember the last time I wrote more than two consecutive lines of code.
Means if there is a catastrophic error, you probably can't fix it yourself.
> if the problem is that I need to be very specific with how I want LLM to fix the issue, like providing it the solution, why wouldn't I just make the change myself?
I type 105 wpm on a bad day. Try gpt-4.1. It types like 1000 wpm. If you can formally describe your problem in English and the number of characters in the English prompt is less than whatever code you write, gpt-4.1 will make you faster.
Obviously you have to account for gpt-4.1 being wrong sometimes. Even so, if you have to run two or three prompts to get it right, it still is going to be faster.
> I don't even know how you can think that not vibe coding means you lack experience
If you lack experience, you're going to prompt the LLM to do the wrong thing and engineer yourself into a corner and waste time. Or you won't catch the mistakes it makes. Only experience and "knowing more than LLM" allows you to catch its mistakes and fix them. (Which is still faster than writing the code yourself, merely by way of it typing 1000 wpm.)
> If the model keeps trying to use non-existent language feature or completely made up functions/classes that is a problem and nothing to do with "autism"
You know that you can tell it those functions are made up and paste it the latest documentation and then it will work, right? That knee-jerk response makes it sound like you have this rigidity problem, yourself.
> I personally am not as I have not seen LLMs actually being useful for anything but replacing google searches.
Nothing really of substance here. Just because you don't know how to use this tool that doesn't mean no one does.
This is the least convincing point for me, because I come along and say "Hey! This thing has let me ship far more working code than before!" and then your response is just "I don't know how to use it." I know that it's made me more productive. You can't say anything to deny that. Do you think I have some need to lie about this? Why would I feel the need to go on the internet and reap a bunch of downvotes while peddling some lie that does stand to get me anything if I convince people of the lie?
> I also don't quite get who is going against the tide here, are you going against the tide of the downvotes
Yeah, that's what I'm saying. People will actively shame and harass you for using LLMs. It's mind boggling that a tool, a technology, that works for me and has made me more productive, would be so vehemently criticized. That's why I listed these 5 reasons, the only reasons I have thought of yet.
> Means if there is a catastrophic error, you probably can't fix it yourself.
See my point about lacking experience. If you can't do the surgery yourself every once in a while, you're going to hate these tools.
Really, you've just made a bunch of claims about me that I know are false, so I'm left unconvinced.
I'm trying to have a charitable take. I don't find joy in arguing or leaving discussions with a bitter taste. I genuinely don't know why people are so mad at me claiming that a tool has helped me be more productive. They all just don't believe me, ultimately. They all come up with some excuse as to why my personal anecdotes can be dismissed and ignored: "even though you have X, we should feel bad for you because Y!" But it's never anything of substance. Never anything that has convinced me. Because at the end of the day, I'm shipping faster. My code works. My code has stood the test of time. Insults to my engineering ability I know are demonstrably false. I hope you can see the light one day. These are extraordinary tools that are only getting better, at least by a little bit, in the foreseeable future. Why deny?
Would also love to see those daily shipped products. What I see on reddit is the same quiz done several times just for different categories and the pixel art generator. That does not look like shipping a product per day as you claim.
On my main, not gonna dox myself. Being pro AI is clearly a faux pas for personal branding.
Just a few days ago got flamed for only having 62 users on GameTorch. Now up to 91 and more paying subs. Entire thing written by LLMs and hasn't fallen over once. I'd rather be a builder than an armchair critic.
People would rather drag you down in the hole that they're in than climb out.
Not trying to drag down, genuinely interested due to the claim.
This is going to be all over the place and possibly hard to follow, I am just going to respond in "real time" as I read your comment, if you think that is too lazy to warrant reading I completely understand. I hope you have a nice day.
WPM is not my limiting factor. Maybe the difference is that I am not working on trivial software so a lot of thought goes into the work, typing is the least time consuming part. Still I don't see how your 105 wpm highly descriptive and instructive English can be faster than just fixing the thing. Even if after you prompt your LLM takes 1ms to fix the issue you have probably already wasted more time by debugging the issue and writing the prompt.
So your "you lack engineering experience" was actually "you don't know LLMs well", maybe use the words you intend and not make them into actual insults.
I am not going to be pasting in any C++ spec into an LLM.
Yet when I checked your profile you have shipped one sprite image generator website. I find all these claims so hard to believe. Everyone just keeps telling me how they are making millions off of LLMs but no one has to the recipes to show. Just makes me feel like you have stock in OpenAI or something and are trying your hardest to pump it up.
I think the shaming and harassing is mostly between your ears, at least I am not trying to shame or harass you for using LLMs, if anything I want to have superpowers too. If LLMs really work for you that is nice and you should keep doing it, I just have not seen the evidence you are talking about. I am willing to admit that it could very well be a skill issue, but I need more proof than "trust me" or "1000 wpm".
I don't think I have made any claims about you, although you have used loaded language like "autism" and "lack of engineering experience" and heavily implied that I am just too dumb to use the tools.
>I'm trying to have a charitable take.
c'mon nothing about your comments has been charitable in anyway. No one is mad at you personally. Do not take criticism of your tools as personal attacks. Maybe the tools will get good, but again my problem with LLMs and hype around them is that no one has been able to demonstrate them actually being as good as the hype suggests.
I appreciate the reply.
What is everyone working on that takes more than five minutes to think about?
For me, the work is insurmountable and infinite, while coming up with the solution is never too difficult. I'm not saying this to be cocky. I mean this:
In 99.9999999999% of the problems I encounter in software engineering, someone smarter than me has already written the battle tested solution that I should be using. Redis. Nginx. Postgres. etc. Or it's a paradigm like depth first search or breadth first search. Or just use a hash set. Sometimes it's a little crazier like Bloom filters but whatever.
Are you like constantly implementing new data structures and algorithms that only exist in research papers or in your head?
Once you've been engineering for 5 or 10 years, you've seen almost everything there is to see. Most of the solutions should be cached in your brains at that point. And the work just amounts to tedious, unimportant implementation details.
Maybe I'm forgetting that people still get bogged down in polymorphism and all that object oriented nonsense. If you just use flat structs, there's nothing too complicated that could possibly happen.
I worked in HFT, for what it's worth, and that should be considered very intense non-CRUD "true" engineering. That, I agree, LLMs might have a little more trouble with. But it's still nothing insane.
Software engineering is extremely formulaic. That's why it's so easy to statistically model it with LLMs.
I write embedded software in C++ for industrial applications. We have a lot of proprietary protocols and custom hardware. We have some initiatives to train LLMs with our protocols/products/documentation, but I have not been impressed with the results. Same goes with our end-to-end testing framework. I guess it isn't so popular so the results vary a lot.
I have been doing this for 8 year and while yes I have seen a lot you can't just copy-paste solutions due to flash, memory, and performance constraints.
Again maybe this is a skill issue and maybe I will be replaced with an LLM, but so far they seem more like cool toys. I have used LLMs to write AddOns for World of Warcraft since my Lua knowledge is mostly writing Wireshark plugins for our protocols and for that it has been nice, but it is nothing someone who actually works with Lua or with WoW API couldn't produce faster or just as fast, because I have to describe what I want and then try and see if the API the LLM provides exists and if it works as the LLM assumed it would.
Again, I appreciate the reply. I think my view on LLMs is skewed towards the positive because I've only been building CRUD apps, command line tools, and games with them. I apologize if I came off as incendiary or offensive.
If you need a model per task, we're very far from AGI.
Maybe it will improve or maybe not, I feel like we're at the same point as the first release of Cursor, in 2023
The interesting questions happen when you define X, Y and Z and time. For example, will llms be able to solve the P=NP problem in two weeks, 6 months, 5 years, a century? And then exploring why or why not
> AI can very efficiently apply common patterns to vast amounts of code, but it has no inherent "idea" of what it's doing.
AI stands for Artificial Intelligence. There are no inherent limits around what AI can and can't do or comprehend. What you are specifically critiquing is the capability of today's popular models, specifically transformer models, and accompanying tooling. This is a rapidly evolving landscape, and your assertions might no longer be relevant in a month, much less a year or five years. In fact, your criticism might not even be relevant between current models. It's one thing to speak about idiosyncrasies between models, but any broad conclusions drawn outside of a comprehensive multi-model review with strict procedure and controls is to be taken with a massive grain of salt, and one should be careful to avoid authoritative language about capabilities.
It would be useful to be precise in what you are critiquing, so that the critique actually has merit and applicability. Even saying "LLM" is a misnomer, as modern transformer models are multi-modal and trained on much more than just textual language.
I learned neural networks around 2000, and it was old technology then. The last real jump we saw was going from ChatGPT 3.5 to 4, and that is more than 2 years ago.
It seems you don't recollect how much time passed without any big revolutions in AI. Deep learning was a big jump. But when the next jump comes? Might be tomorrow, but looking at history, might be in 2035.
According to what I see, the curve has already flattened and now only a new revolution could get us to the next big step.
Since I can't seem to add an edit to my post, here's a realization:
My 2035 prediction actually seems pretty optimistic. It was more than 20 years that we haven't seen any big AI revolutions, so 2045 would be more realistic.
And it seems our current AI is also not going to get us there any faster.
Agree, the AI companies aren’t able to improve the base models so they’re pivoting to making add-ons like “agents” which seem to only be instructions atop the base models.
Progress is progress. Just as a raw base models need RL to be useful, an agentic layer allows us to put these probabilistic machines on rails.
> AI stands for Artificial Intelligence. There are no inherent limits around what AI can and can't do or comprehend.
Artificial, as in Artificial sand or artificial grass. Sure, it appears as sand or grass at first, but upon closer examination, it becomes very apparent that it's not real. Artificial is basically a similar word to magic - as in, it offers enough misdirection in order for people to think there might be intelligence, but upon closer examination, it's found lacking.
It's still impressive that it can do that, going all the way back to gaming AIs, but it's also a veil that is lifted easily.
What a ridiculous response, to scold the GP for criticising today's AI because tomorrow's might be better. Sure, it might! But it ain't here yet buddy.
Lots of us are interested in technology that's actually available, and we can all read date stamps on comments.
You're projecting that I am scolding OP, but I'm not. My language was neutral and precise. I presented no judgment, but gave OP the tools to better clarify their argument and express valid, actionable criticism instead of wholesale criticizing "AI" in a manner so imprecise as to reduce the relevance and effectiveness of their argument.
> But it ain't here yet buddy . . . we can all read date stamps on comments.
That has no bearing on the general trajectory that we are currently on in computer science and informatics. Additionally, your language is patronizing and dismissive, trading substance for insult. This is generally frowned upon in this community.
You failed to actually address my comment, both by failing to recognize that it was mainly about using the correct terminology instead of criticizing an entire branch of research that extends far beyond transformers or LLMs, and by failing to establish why a rapidly evolving landscape does not mean that certain generalizations cannot yet be made, unless they are presented with several constraints and caveats, which includes not making temporally-invariant claims about capabilities.
I would ask that you reconsider your approach to discourse here, so that we can avoid this thread degenerating into an emotional argument.
The GP was very precise in the experience they shared, and I thought it was interesting.
They were obviously not trying to make a sweeping comment about the entire future of the field.
Are you using ChatGPT to write your loquacious replies?
> They were obviously not trying to make a sweeping comment about the entire future of the field
OP said “AI can very efficiently apply common patterns to vast amounts of code, but it has no inherent "idea" of what it's doing.”
I'm not going to patronize you by explaining why this is not "very precise", or why its lack of temporal caveats is an issue, as I've already done so in an earlier comment. If you're still confused, you should read the sentence a few times until you understand. OP did not even mention which specific model they tested, and did not provide any specific prompt example.
> Are you using ChatGPT to write your loquacious replies?
If you can't handle a few short paragraphs as a reply, or find it unworthy of your time, you are free to stop arguing. The Hacker News guidelines actually encourage substantive responses.
I also assume that in the future, accusing a user of using ChatGPT will be against site guidelines, so you may as well start phasing that out of your repertoire now.
Here are some highlights from the Hacker News guidelines regarding comments:
- Don't be snarky
- Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.
- Assume good faith
- Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken.
https://news.ycombinator.com/newsguidelines.html
This is a lot of words, but does any of it contradict this:
> AI can very efficiently apply common patterns to vast amounts of code, but it has no inherent "idea" of what it's doing.”
Are you saying that AI does have an inherent idea of what it's doing or is doing more than that? Today?
We're in an informal discussion forum. I don't think the bar we're looking for is some rigorous deductive proof. The above matches my experience as well. Its a handy applied interactive version of an Internet search.
If someone has a different experience that would be interesting. But this just seems like navel-gazing over semantics.
> Are you saying that AI does have an inherent idea of what it's doing or is doing more than that?
No. I stated that OP cannot make that kind of blanket, non-temporally constrained statements about artificial intelligence.
> We're in an informal discussion forum. I don't think the bar we're looking for is some rigorous deductive proof
We're in a technology-oriented discussion forum, the minimum bar to any claim should be that it is supported by evidence, otherwise it should be presented as what it is: opinion.
> this just seems like navel-gazing over semantics.
In my opinion, conversation is much easier when we can agree that words should mean something. Imprecise language matched with an authoritative tone can mislead an audience. This topic in particular is rife with imprecise and uninformed arguments, and so we should take more care to use our words correctly, not less.
Furthermore, my argument goes beyond semantics, as it also deals with the importance of constraints when making broad, unbacked claims.
I had a fun result the other day from Claude. I opened a script in Zed and asked it to "fix the error on line 71". Claude happily went and fixed the error on line 91....
1. There was no error on line 91, it did some inconsequential formatting on that line 2. More importantly, it just ignored the very specific line I told it to go to. It's like I was playing telephone with the LLM which felt so strange with text-based communication.
This was me trying to get better at using the LLM while coding and seeing if I could "one-shot" some very simple things. Of course me doing this _very_ tiny fix myself would have been faster. Just felt weird and reinforces this idea that the LLM isn't actually thinking at all.
LLMs probably have bad awareness of line numbers
I suspect if OP highlighted line 71 and added it to chat and said fix the error, they’d get a much better response. I assume Cursor could create a tool to help it interpret line numbers, but that’s not how they expect you to use it really.
How is this better from just using a formal language again?
Who said it's better? It's a design choice. Someone can easily write an agent that takes instructions in any language you like.
The current batch of AI marketing.
That's the thing. We're expecting the tool to have a clear understanding of its own limitations by now and ask for better prompts (or say: I don't know, I can't etc). The fact it just does something wacky is not good at all to the consistency of these tools.
Not sure how tools like Cursor work under the hood, but this seems like an easy model context engineering problem to fix.
I do not code/program, but I do read thousands of fiction pages annually. LLMs (Perplexity, specifically) have been my lifetime favorite book club member — I can ask anything.
However, I can't just say "on page 123..." I've found it's better to either provide the quote, or describe the context, and then ask how it relates to [another concept]. Or I'll say "at the end of chapter 6, Bob does X, then why Y?" (perhaps this is similar to asking a coding LLM to fix a specific function instead of a specific line?).
My favorite examples of this have been sitting with living human authors and discussing their books — usually to jaw-dropped creators, particularly to Unknowns.
Works for non-fiction, too (of course). But for all those books you didn't read in HS English classes, you can somewhat recreate all that class discussion your teachers always attempted to foster — at your own discretion/direction.
> This was me trying to get better at using the LLM while coding
And now you've learned that LLMs can't count lines. Next time, try asking it to "fix the error in function XYZ" or copy/paste the line in question, and see if you get better results.
> reinforces this idea that the LLM isn't actually thinking at all.
Of course it's not thinking, how could it? It's just a (rather big) equation.
As shared by Simon in https://news.ycombinator.com/item?id=44176523, a better agent will prepend the line numbers as a workaround, e.g. Claude Code:
That’s not what he’s saying there. There’s a separate tool that adds line numbers before feeding the prompt into the LLM. It’s not the LLM doing it itself.
The separate tool is called the agent.
My understanding is that an agent is comprised of many tools that provide a harness for the LLM.
I just learnt the `nl -ba` trick from Codex. Claude Code is most likely doing the same.
In Aider, I would add a comment `fix this ai!` and Aider adds the context and updates the code. Wish it were more seamless though.
> It's just a (rather big) equation.
So are you.
ITT: people trying to use AI to code for the first time
Sounds like operator error to me.
You need to give LLMs context. Line number isn't good context.
> Line number isn't good context.
a line number is plenty of context - it's directly translatable into a range of bytes/characters in the file
It's a tool. It's not a human. A line number works great for humans. Today, they're terrible for LLMs.
I can choose to use a screwdriver to hammer in a nail and complain about how useless screwdrivers are. Or I can realize when and how to use it.
We (including marketing & execs) have made a huge mistake in anthropomorphizing these things, because then we stop treating them like tools that have specific use cases to be used in certain ways, and more like smart humans that don't need that.
Maybe one day they'll be there, but today they are screwdrivers. That doesn't make them useless.
Check the whole ecosystem around editors, grep tools, debuggers, linting and build tools. One common thing about all of this is line (and column) number so you can integrate them together if you want to automate stuff. Like jumping to errors (quickfix in vim,…), search all files and jump to the occurrences (grep mode in emacs,…), etc…
...which LLMs don't use as they use tokens instead.
So do compilers, and they don't seem to have a problem with something as basic as line numbers.
Of all the things I thought I'd read today, "Line number isn't good context" is more wild than I could possibly have imagined.
Line numbers are perfect for humans and programs reading files, but LLMs aren't really reading files.
Imagine saying to another software engineer "you only gave me the line number, that's not enough context"
You need at least also the version and the filename.
> The continued shortage of software engineers, coupled with research showing that AI tools are particularly beneficial for junior developers
Am I living in a different timeline than these guys ?
In my timeline, the tech job market is terrible, and AI is the worst for junior developers, because they aren't learning what they should by doing.
There's a shortage of software engineers, but not a shortage of people who have those job titles.
Aka, 80% of the work being done by 20% of the people. The problem is you still have to hire the other 80% of the developers to also get those 20%
Personally, I define the job of a software engineer as transform requirements into software. Software is not only code. Requirements are not only natural language. At the moment I can't manage to be faster with the AI than manually. Unless its a simple task or software. In my experience AI's are atm junior or mid-level developers. And in the last two years, they didn't get significant better.
Most of the time, the requirements are not spelled out. Nobody even knows what the business logic is supposed to be. A lot of it has to be decided by the software engineer based on available information. It sometimes involve walking around the office asking people things.
It also requires a fair bit of wisdom to know where the software is expected to grow, and how to architect for that eventuality.
I can't picture an LLM doing a fraction of that work.
I think that's my problem with AI. Let's say I have all the requirements, down to the smallest detail. Then I make my decisions at a micro level. Formulate an architecture. Take all the non-functionals into account. I would write a book as a prompt that is not able to express my thoughts as accurately as if I were writing code right away. Apart from the fact that the prompt is generally a superfluous intermediate step in which I struggle to create an exact programming language with an imprecise natural language with a result that is not reproduce-able.
AI is less useful when I'm picking through specific, careful business logic.
But we still have lots of boilerplate code that's required, and it's really good at that. If I need a reasonably good-looking front-end UI, Claude will put that together quickly for me. Or if I need it to use a common algorithm against some data, it's good at applying that.
What I like about AI is that it lets me slide along the automation-specificity spectrum as I go through my work. Sometimes it feels like I've opened up a big stretch of open highway (some standard issue UI work with structures already well-defined) and I can "goose" it. Sometimes there's some tricky logic, and I just know the AI won't do well; it takes just as long to explain the logic as to write it in code. So I hit the brakes, slow down, navigate those tricky parts.
Previously, in the prior attempt to remove the need for engineers, no-code solutions instead trapped people. They pretended like everything is open highway. It's not, which is why they fail. But here we can apply our own judgment and skill in deciding when a lot of "common-pattern" code is required versus the times where specificity and business context is required.
That's also why these LLMs get over-hyped: people over-hype them for the same reason they over-hyped no-code; they don't understand the job to be done, and because of that, they actually don't understand why this is much better than the fanciful capabilities they pretend it has ("it's like an employee and automates everything!"). The tools are much more powerful when an engineer is in the driver's seat, exercising technical judgment on where and how much to use it for every given problem to be solved.
> But we still have lots of boilerplate code that's required, and it's really good at that
Copy and paste with find and replace has never taken me that long for boilerplate though. The time saved here is razor thin imo
My strategy has almost always been to copy the code example from the docs of whatever css framework I’m using, especially for forms. Then there’s a threshold where I use the project as source instead.
This is a really good point.
At a certain point, huge prompts (which you can readily find available on Github, used by large LLM-based corps) are just....files of code? Why wouldn't I just write the code myself at that point?
Almost makes me think this "AI coding takeover" is strictly pushed by non-technical people.
Back in the day, there used to be professionals known as systems analysts whose job it was to determine the business logic. The information system went through several phases of stepwise refinement. First the requirements were determined: WHO needs WHAT information, WHERE, WHEN, and WHY. (And from WHOM do they get it?) Then, a series of procedures were developed to be implemented either manually or by computer (The "Playscript" format by Les Matthies was particularly useful for the former; standard flowcharts for the latter). Each piece of data, its type, and its purpose was also identified and registered in a standard vocabulary. The programmers only got in on it towards the end: once the major decisions had been made, they wrote the code instructing the computer on HOW to do it. Their focus was on the HOW; the WHAT was not in their job description, and was usually beyond their capability. It takes holistic, big-picture thinking and great social skills to develop an understanding of an entire business division and come up with a plan to implement an information system for that division. The programmers' work entailed about 15% of the total work, and was mainly concerned with the technical details of getting the procedures to be automated running on a computer. These days, with AI, that 15% figure could be reduced even further, perhaps by a factor of five or ten. In the big-iron era, programming was really that simple. The hard decisions had already been made before the first line of code was written. You may think it stodgy and inflexible to develop software this way, but that's how grown-ups did it, and studies showed that it was significantly cheaper than the scattershot, agile-like approach where the programmers where in the lead in terms of systems design.
What's happened since the 1970s is, programming has undergone prestige inflation to the point where programmers are looked to for decisions regarding the actual business procedures, and usually they just don't have the business knowledge or wherewithal to do that. The systems analyst has faded into memory. And as Milt Bryce said, "If this country built bridges the way it builds systems, we'd be a nation run by ferry-boats."
No software job I've done has come with clear, explicit requirements. Its all been a mess under the hood and half my job has been figuring out specifically what they even want
LLMs are nowhere near even junior level and if you really think any model is comparable to your orgs mid level developer you have a hiring problem
I think it's a common problem to officially have mids who are really just juniors with a modicum of time in the industry and the same goes for seniors who are really just mids.
I agree, but also I don't believe LLMs are on junior level. In hands of a senior LLMs might be like a summer intern level, maybe.
One of the most useful properties of computers is that they enable reliable, eminently reproducible automation. Formal languages (like programming languages) not only allow to unambiguously specify the desired automation to the upmost level of precision, they also allow humans to reason about the automation with precision and confidence. Natural language is a poor substitute for that. The ground truth of programs will always be the code, and if humans want to precisely control what a program does, they’ll be best served by understanding, manipulating, and reasoning about the code.
“Manual” has a negative connotation. If I understand the article correctly, they mean “human coding remains key”. It’s not clear to me the GitHub CEO actually used the word “manual”, that would surprise me. Is there another source on this that’s either more neutral or better at choosing accurate words? The last thing we need is to put down human coding as “manual”; human coders have a large toolbox of non-AI tools to automate their coding.
(Wow I sound triggered! sigh)
It's almost as bad as "manual" thinking!
> “Manual” has a negative connotation
Wait does it? This is a new idea to me, in what way could "manual" have a negative connotation?
Are people really that against doing things manually nowadays?
> Wow I sound triggered! sigh
this is okay! it's a sign of your humanity :)
What is the distinction between manual coding and human coding?
Often when you're calling something "manual" you're taking something off the automated happy path to tediously and slowly wind the thing through its complex process by hand. The difference between manual coding and human coding is tedium and laboriousness. It's not laborious to program, but the phrase "manual coding" evokes that image.
Maybe that’s what they’ve been doing? No one using Vim, Emacs, or Unix as an IDE would say they do manual coding with the amount of automation that usually goes there.
Indeed, if your not using butterflies to program, it's not manual, and your not a real programmer
https://xkcd.com/378/
Acoustic coding
"Authentic" maybe ?
How about “organic coding”? ;)
Analog coding
>Manual” has a negative connotation. If I understand the article correctly, they mean “human coding remains key”.
A man is a human.
Humanual coding? ;)
“Manual” comes from Latin manus, meaning “hand”: https://en.wiktionary.org/wiki/manus. It literally means “by hand”.
Nice one :)
I too can sling a bit of Latin. ;)
Here is one phrase, in which one word, malus, is like an off-by-one error from your manus word, so to speak :) :
nemo malus nisi probetur
https://www.google.com/search?q=nemo+malus+nisi+probetur
From the AI overview (need to at least try that out a few times after all the talk about Google enshittification like by Cory Doctorow in this year's PyCon US keynote:
>Nemo malus nisi probetur" is a Latin legal maxim that translates to "No one is evil unless proven." It signifies that a person is presumed innocent until proven guilty in a court of law. This principle is fundamental to legal systems that value fairness and due process, ensuring that accusations are substantiated before a person is considered culpable. Here's a breakdown of the phrase:
The maxim essentially means that one should not be treated as inherently bad or guilty without sufficient evidence. This principle is closely related to the concept of "presumption of innocence" and is crucial for upholding justice and protecting individual rights.Hopefully a CEO finally tempering some expectations and the recent Apple paper bring some sanity back into the discourse around these tools.[^1]
Are they cool and useful? Yes.
Do they reason? No. (Before you complain, please first define reason).
Are they end all be all of all problem solving and the dawn of AGI? Also no.
Once we actually bring some rationality back into the radius of discourse maybe we'll actually begin to start figuring out how these things actually fit into an engineering workflow and stop throwing around ridiculous terms like vibe coding.
If you are an engineer, you are signing up to build rigorously verified and validated system, preferably with some amount of certainty about their behavior under boundary conditions. All the current hype-addled discussion around LLM seems to have had everything but correctness as it's focus.
[^1]: It shouldn't take a CEO but many people, even technologists, who should be more rational about whose opinions they deem worthy of consideration, m seem to overvalue the opinions of the csuite for some bizarre, inexplicable reason.
The recent Apple paper seemed pretty flawed. Anthropic/Open Philanthropy did a rebuttal paper, The Illusion of the Illusion of Thinking.
> Do they reason? No. (Before you complain, please first define reason).
Defining reasoning is the problem. No, they don't reason in the same way as humans. But they seem to be able to go through reasoning steps in some important way. It's like asking if submarines swim.
I completely agree. The difference is, the utility of the submarine and its sales strategy did not depend on convincing human beings that it does swim like them.
The opposite is true of LLMs. Much of the sales pitch of these companies is that these things are capable of some form of reasoning that is in 1:1 correspondence with human reason. Not true. That's what makes this whole segment of the industry snake oil. It's not complete bunk because they do have some utility, but these companies know what they are doing when they use the term reason in all their marketing and papers. They are, in fact, trying to sell you the submarine because it can "swim".
"He warned that depending solely on automated agents could lead to inefficiencies. For instance, spending too much time explaining simple changes in natural language instead of editing the code directly."
Lots of changes where describing them in English takes longer than just performing the change. I think the most effective workflow with AI agents will be a sort of active back-and-forth.
Yeah, I can’t count the number of times I’ve thought about a change, explained it in natural language, pressed enter, then realized I’ve already arrived at the exact change I need to apply just by thinking it through. Oftentimes I even beat the agent at editing it, if it’s a context-heavy change.
Rubber duck. I’ve kept one on my desk for over a decade. It was also like a dollar, which is more than I’ve spent on LLMs. :)
https://en.m.wikipedia.org/wiki/Rubber_duck_debugging
How active are you ok with/want? I've just joined an agent tooling startup (yesh...I wrote that huh...) - and it's something we talk a lot about internally, we're thinking it's fine to do back and forth, tell it frankly it's not doing it right, etc, but some stuff might be annoying? Do you have a sense of how this might work to your mind? Thanks! :)
AI is still not there yet. For example, I constantly have to deal with mis-referenced documents and specifications. I think part of the problem is that it was trained on outdated materials and is unable to actively update on the fly. I can get around this problem but…
The problem with today’s LLM and GI solutions is that they try to solve all n steps when solving the first i steps would be infinitely more useful for human consumption. I’ve yet to see a fully modular solution (though MCPs partly solves it), where I can just say, “Hey, using my specific coding style based on my github, solve problem x, based on resources a, b, and c and only a, b, and c.” I would also like to see a more verbose/interactive coding AI, where it will ask incremental questions as it traverses a problem tree.
It's interesting to see a CEO express thoughts on AI and coding go in a slightly different direction.
Usually the CEO or investor says 30% (or some other made up number) of all code is written by AI and the number will only increase, implying that developers will soon be obsolete.
It's implied that 30% of all code submitted and shipped to production is from AI agents with zero human interaction. But of course this is not the case, it's the same developers as before using tools to more rapidly write code.
And writing code is only one part of a developer's job in building software.
He’s probably more right than not. But he also has a vested interest in this (just like the other CEOs who say the opposite), being in the business of human-mediated code.
Presumably you're aware that the full name of Microsoft's Copilot AI code authoring tool is "GitHub Copilot", that GitHub developed it, and that he runs GitHub.
Yea, which is why I was surprised too when he said this.
Copilot. Not Pilot.
Well, I suspect GitHub's income is a function of the number of developers using it so it is not surprising that he takes this position.
I love that the 30% quote is so miss used. You probably should watch that clip again and actually listen what he said.
The 30% reference wasn't referring to this article, but by other CEOs like Microsoft.
And those without understanding what the number means or how it was derived write misleading articles.
I was talking about the Microsoft CEO quote everyone is misquoting. He said something to affect of "at Microsoft we have _some_ repos where up to 30% of the code is _generated_". This could mean they have one C++ repo for one tool that has 30% generated header files without any LLM usage at all. Of course that is probably not what he meant and the least generous view, but I find it extremely suspect to believe that any large company, much less Microsoft, would have third of their code produced by LLMs. I find it hard to believe any profitable software company has that high of a percentage.
My guess is they will settle for 2x the productivity as a before-AI developer as their skill floor, but then not take a look at how long meetings and other processes take.
Why not look at Bob who takes like 2 weeks to write tickets on what they actually want in a feature? Or Alice who's really slow getting Figma designs done and validated? How nice would having a "someone's bothered a developer" metric be and having the business seek to get that to zero and talk very loudly about it as they have about developers?
Because everyone who bothers the developers is actually in charge, and they would never want to reduce their utilization, all of this removal of need to focus on the code makes them excited that you can be in even more meetings.
Too late, I am seeing developer after developer doing copy/paste from AI tools and when asked, they have no idea how the code works coz "it just works"
Google itself said 30% of their code is AI generated, and yet they had a recent outage worldwide, coincidence??
You tell me.
"How do you know it works?"
"It's got tests"
"Who wrote the tests?"
"It did. So?"
They're "tactical tornados"[0] with a jetpack
[0] A term from the book A Philosophy of Software Design - people who constantly chuck out "working" code with no design. Tactical programming vs Strategic programming
I cannot help but read this in the subtext of, “We need more training data from humans; please don’t stop uploading your code to us.”
Look, manual coding (and art, and media, and IT, and others) will always be needed. GenAI was never going to replace these jobs wholesale, or even permanently displace workers. The fact this is trending in an APAC-focused site suggests the real message is, “we don’t want our outsource farms thinking this [GenAI] will replace you.”
Prediction of tokens was never going to lead to AGI. All it’s going to accomplish is instilling a deep, traumatic hostility in the populace towards further automation right when we need it the most.
The other day we had a fairly complex conditional, modified incorrectly by AI, and it cost the company a lot of money and harmed reputation with partners.
AI just cannot reason about logical things reliably. And no one noticed because the AI had made several other sweeping changes, and the noise drowned it out.
Going by the content of the linked post, this is very much a misleading headline. There is nothing in the quotes that I would read as an endorsement of "manual coding", at least not in the sense that we have used the term "coding" for the past decades.
CEOs are possibly the last person you should listen to on any given subject.
I'm just vibe-CEOing my new company. It's amazing how productive it is!
just wait til it starts virtue signalling and posting contrived anecdotes about b2b sales and the benefits of RTO on LinkedIn. the vibe-HR department is gonna have to rein things in fast!
So do we ignore the Github CEO or all the other ones?
Great post—Dohmke’s call to preserve hands‑on coding while leveraging AI resonates strongly. It’s not about replacing devs but enabling them to build faster while staying in control.
In practice, pure LLM suggestions often feel detached from your actual codebase—missing intent, architectural constraints, or team conventions. What helped us was adopting a repo‑aware evaluation approach with tooling that: - Scans entire repos, generates architecture diagrams, dependency maps, and feature breakdowns. - Surfaces AI suggestions grounded in context—so prompts don’t float in isolation. - Supports human-in-the-loop validation, making it easy to vet AI‑generated PRs before merging. - Tracks drift, technical debt, and cost per eval, so AI usage isn’t a black box.
The result isn’t autopilot coding—it’s contextual assistance that amplifies developer decisions. That aligns exactly with Dohmke: use AI to accelerate, but keep the engineer firmly in the driver’s seat.
Curious if others have tried similar repo‑aware AI workflows that don’t sacrifice control for speed?
Imo this is a misunderstanding of what AI companies want AI tools to be and where the industry is heading in the near future. The endgame for many companies is SWE automation, not augmentation.
To expand -
1. Models "reason" and can increasingly generate code given natural language. Its not just fancy autocomplete, its like having an intern - mid level engineer at your beck and call to implement some feature. Natural language is generally sufficient enough when I interact with other engineers, why is it not sufficient for an AI, which (in the limit), approaches an actual human engineer?
2. Business wise, companies will not settle for augmentation. Software companies pay tons of money in headcount, its probably most mid-sized companies top or second line item. The endgame for leadership at these companies is to do more with less. This necessitates automation (in addition to augmenting the remaining roles).
People need to stop thinking of LLMs as "autocomplete on steroids" and actually start thinking of them as a "24/7 junior SWE who doesn't need to eat or sleep and can do small tasks at 90% accuracy with some reasonable spec." Yeah you'll need to edit their code once in a while but they also get better and cost less than an actual person.
This sounds exactly like the late '90s all over again. All the programming jobs were going to be outsourced to other countries and you'd be lucky to make minimum wage.
And then the last 25 years happened.
Now people are predicting the same thing will happen, but with AI.
The problem then, as is now, is not that coding is hard, it's that people don't know what the hell they actually want.
> Software companies pay tons of money
Software companies make a single copy and sell it a billion times. The revenue per employee is insane. The largest companies are trying to make the best product in the world and seek out slight advantages.
The cost saving mindset you are describing is found in companies where software isn’t a core part of the business.
Folks who believe this are going to lose a lot of money fixing broken software and shipping products that piss off their users.
Thought not as much as they ought to, if all their competitors jump off the same cliff to fit in. :/
Good for outsourcing companies. India used Y2K to build its IT sector and lift up its economy, hopefully Africa can do the same fixing AI slop.
That is the ideal for the management types and the AI labs themselves yes. Copilots are just a way to test the market, and gain data and adoption early. I don't think it is much of a secret anymore. We even see benchmarks created (e.g. OpenAI recently did one) that are solely about taking paid work away from programmers and how many "paid tasks" it can actually do. They have a benchmark - that's their target.
As a standard pleb though I can understand why this world; where the people with connections, social standing and capital have an advantage isn't appealing to many on this forum. If anyone can do something - other advantages that aren't as easy to acquire matter more relatively.
I mean duhh? Is there anyone who denies this is what they would want to happen? That's capitalism. They'd also kill all other roles if they could - and there are other very expensive personnel like sales people, marketers, accountants etc. Whether it's going to happen ,when , and by how much is a different matter to what they want though.
I recently started consulting for a company that's building an AI first tool.
The entire application is powered through several AI agents, I had a look at their code and had to throw up, each agent is a single Python file of over 4000 lines, you can just look at the first 100 lines and tell its all LLM generated code, the hilarious part is if I paste the code into ChatGPT to help me break it down, it hits the context window in like 1 response!
I think this is one of the main problems with AI code, 5 years ago every time I took on a project, I knew the code I was reading and diving into was written by a human, well thought and structured. These days almost all the code I see is glue code, AI has done severe damage by enabling engineers who do not understand basic structures and fundamentals write 'code that just works'.
At the same time, I don't blame just the AI, cause several times I have written code myself which is gluecode, but then asked AI to refactor it in a way I want and it is usually really good at it.
> Dohmke described an effective workflow where AI tools generate code and submit pull requests.
This is kind of vague. What kinds of contributions he's talking about? Adding features, refactoring, removing dead code, optimizing, adding new tests?
The article mentions boilerplate. Is that all current coding AIs can do?
> For instance, spending too much time explaining simple changes in natural language instead of editing the code directly.
Why not write the code directly then? Even less friction.
Again, _it all depends on the kinds of contributions AI can make_.
The fact that they're being vague about it tells me something. If you had a bot that can fix tests (or even get you 90% of the way), you'd be boasting that everywhere. It would be an extraordinary evidence and you'd be very proud of it.
If someone made a PR to my repo adding a bunch of automated boilerplate, I'd be pissed, not encouraged to make it work.
I think most programmers would agree that thinking represents the majority of our time. Writing code is no different than writing down your thoughts, and that process in itself can be immensely productive -- it can spark new ideas, grant epiphanies, or take you in an entirely new direction altogether. Writing is thinking.
I think an over-reliance, or perhaps any reliance, on AI tools will turn good programmers into slop factories, as they consistently skip over a vital part of creating high-quality software.
You could argue that the prompt == code, but then you are adding an intermediary step between you and the code, and something will always be lost in translation.
I'd say just write the code.
I think this misses the point. You're right that programmers still need to think. But you're wrong thinking that AI does not help with that.
With AI, instead of starting with zero and building up, you can start with a result and iterate on it straight away. This process really shines when you have a good idea of what you want to do, and how you want it implemented. In these cases, it is really easy to review the code, because you knew what you wanted it to look like. And so, it lets me implement some basic features in 15 minutes instead of an hour. This is awesome.
For more complex ideas, AI can also be a great idea sparring partner. Claude Code can take a paragraph or two from me, and then generate a 200-800 line planning document fleshing out all the details. That document: 1) helps me to quickly spot roadblocks using my own knowledge, and 2) helps me iterate quickly in the design space. This lets me spend more time thinking about the design of the system. And Claude 4 Opus is near-perfect at taking one of these big planning specifications and implementing it, because the feature is so well specified.
So, the reality is that AI opens up new possible workflows. They aren't always appropriate. Sometimes the process of writing the code yourself and iterating on it is important to helping you build your mental model of a piece of functionality. But a lot of the time, there's no mystery in what I want to write. And in these cases, AI is brilliant at speeding up design and implementation.
> So, the reality is that AI opens up new possible workflows. They aren't always appropriate. Sometimes the process of writing the code yourself and iterating on it is important to helping you build your mental model of a piece of functionality. But a lot of the time, there's no mystery in what I want to write. And in these cases, AI is brilliant at speeding up design and implementation.
I agree but I have a hunch we're all gonna be pushed by higher ups to use AI always and for everything. Headcounts will drop, the amount of work will rise and deadlines will become ever so tight. What the resulting codebases would look like years from now will be interesting.
Yeah, I am grateful that I work with a lot of other engineers and managers who care a lot about quality. If you have a manager who just cares about speed, the corner cutting that AI enables could become a nightmare.
Based on your workflow, I think there is considerable risk of you being wooed by AI into believing what you are doing is worthwhile. The plan AI offers is coherent, specific, it sounds good. It's validation. Sugar.
That is a very weak excuse to avoid these tools.
I know the tools and environments I am working in. I verify the implementations I make by testing them. I review everything I am generating.
The idea that AI is going to trick me is absurd. I'm a professional, not some vibe coding script kiddie. I can recognise when the AI makes mistakes.
Have the humility to see that not everyone using AI is someone who doesn't know what they are doing and just clicks accept on every idea from the AI. That's not how this works.
AI is already tricking people -- images, text, video, voice. As these tools become more advanced, so does the cost of verification.
We're talking about software development here, not misinformation about politics or something.
Software is incredibly easy to verify compared to other domains. First, my own expertise can pick up most mistakes during review. Second, all of the automated linting, unit testing, integration testing, and manual testing is near guaranteed to pick up a problem with the functionality being wrong.
So, how exactly do you think AI is going to trick me when I'm asking it to write a new migration to add a new table, link that into a model, and expose that in an API? I have done each of these things 100 times. It is so obvious to me when it makes a mistake, because this process is so routine. So how exactly is AI going to trick me? It's an absurd notion.
AI does have risks with people being lulled into a false sense of security. But that is a concern in areas like getting it to explain how a codebase works for you, or getting it to try to teach you about technologies. Then you can end up with a false idea about how something works. But in software development itself? When I already have worked with all of these tools for years? It just isn't a big issue. And the benefits far outweigh it occasionally telling me that an API exists that actually doesn't exist, which I will realise almost immediately when the code fails to run.
People who dismiss AI because it makes mistakes are tiresome. The lack of reliability of LLMs is just another constraint to engineer around. It's not magic.
> Software is incredibly easy to verify compared to other domains
This strikes me as an absurd thing to believe when there's almost no such thing as bug-free software
Yes, maybe using the word "verify" here is a bit confusing. The point was to compare software, where it is very easy to verify the positive case, to other domains where it is not possible to verify anything at all, and manual review is all you get.
For example, a research document could sound good, but be complete nonsense. There's no realistic way to verify that an English document is correct other than to verify it manually. Whereas, software has huge amounts of investment into testing whether a piece of software does what it should for a given environment and test cases.
Now, this is a bit different to formally verifying that the software is correct for all environments and inputs. But we definitely have a lot more verification tools at our disposal than most other domains.
That's fair, makes sense. Thank you for explaining further
More complaining & pessimism means better signal for teams building the AI coding tools! Keep it up! The ceiling for AI is not even close to being met. We have to be practical with whats reasonable, but getting 90% complete in a few prompts is magic.
I think so many devs fail to realise that to your product manager / team lead, the interface between you and the LLM is basically the same. They write a ticket/prompt and they get back a bunch of code that undoubtedly has bugs and misinterpretations in it, will probably go through a few rounds of revisions of back and forth until its good enough to ship (ie they tested it black-box style and it worked once) then they can move on to the next thing until whatever this ticket was about rears its ugly head again at some point in the future. If you arent used to writing user stories / planning, youre really gonna be obsolete soon.
Code monkeys that doesn't understand the limits of LLMs and can't solve problems where the LLM fails are not needed in the world of tomorrow.
Why wouldn't your boss ask ChatGPT directly?
I believe it's important to learn the basics of manual programming and also figure out how to work with AI tools in a smart way. It's not just about letting AI do the coding for us. We still need to think clearly and improve our own Solving the problem skills. AI can help turn ideas into reality, but we need to grow too if we want to really make use of it.
I'm not really afraid that AI will replace programmers. What I worry about is that it might make programmers stop thinking. I've seen beginners who quickly get used to asking AI for answers and no longer try to understand how things actually work. It may feel fast at first, but over time they lose the ability to solve problems on their own.
I think in 5 years from now we will see a major software dev shortage. Mainly because of all the reports that big tech companies are replacing devs with AI which scares new students to sign up for a CS degree.
The truth is that those devs who has been replaced should not have been hired in the first place as the companies were already overstuffed.
> In an appearance on “The MAD Podcast with Matt Turck,” Dohmke said that
> Source: The Times of India
what in the recycled content is this trash?
We've generated a lot of code with claude code recently...then we've had to go back and rationalize it... :) fun times...you absolutely must have a well defined architecture established before using these tools.
It would be nice if he would back that up by increasing focus on quality of life issues on GitHub. GitHub's feature set seems to get very little attention unless it overlaps with Copilot.
This seems to be an AI summary of a (not linked) podcast.
> GitHub CEO Thomas Dohmke
Did I miss Nat Friedman stepping down? Does the new guy think having ICE as a customer is ok, too?
I wonder how much coding he does and how does he know which code is human written and which by machine.
I get a 403 forbidden error when trying to view the page. Anyone else get that?
Amazingly, so does air and water. What AI salesman could have predicted this?
Not gonna lie, first time I've heard of manual coding.
I think these are coordinated posts by Microsoft execs. First their director of product, now this. Its like they're trying to calm the auto coding hype until they catchup and thus keep OpenAI from running away.
Microsoft is the largest shareholder in OpenAI.
That's him out the Illuminati then.
WELL YOU DONT SAY
It was only 2 years ago we were still taking about GPTs making up completely nonsense, and now hallucinations are almost gone from the discussions. I assume it will get even better, but I also think there is an inherent plateau. Just like how machines solved mass manufacturing work, but we still have factory workers and overseers. Also, "manually" hand crafted pieces like fashion and watches continue to be the most expensive luxury goods. So I don't believe good design architects and consulting will ever be fully replaced.
Hallucinations are now plausibly wrong which is in some ways harder to deal with. GPT4.1 still generates Rust with imaginary crates and says “your tests passed, we can now move on” to a completely failed test run.
"hallucinations are almost gone from the discussions" because everyone now accepts that LLM hallucinate all the times, no point in mentioning it anymore.
> The continued shortage of software engineers, coupled with research showing that AI tools are particularly beneficial for junior developers...
I stopped reading after this.
Yawn... Epistemic standards have fallen to rock bottom levels across STEM due to metric matching, more so in the cookie-cutter jira world of soulless software factories.
That these "geniuses" think they can replace humans, not only for knowledge work, but also for labour is laughable for any one who has worked with LLMs.
[dead]
No fucking shit Sherlock.
Water’s wet, fire’s hot. News at 5.
AI is good for boilerplate, suggestions, nothing more.
For you, perhaps.
For me, too. On the poorly-documented stuff that I get into, where I really need help, it flails.
I wanted some jq script and it made an incomprehensible thing that usually worked. And every fix it made broke something else. It just kept digging a deeper hole.
After a while of that, I bit the bullet and learned jq script. I wrote a solution that was more capable, easier to read, and, importantly, always worked.
The thing is, jq is completely documented. Everything I needed was online. But there just aren't many examples to for LLMs, so they choke.
Start asking it questions about complexity classes and you can get it to contradict itself in no time.
Most of the code in the world right now is very formulaic, and it's great at that. Sorry, WordPress devs.
It's a powerful tool, but it's not that powerful.
Have you tried feeding it the documentation of jq? And which LLM(s) have you tried?
I had great success with niche programming languages by feeding it the documentation and a couple of projects.
Thomas Dohmke is CEO of GitHub .
AI tools are great for speeding up small tasks, but when it comes to debugging, refactoring, or designing anything more complex, manual coding is still essential. Especially when things break, if you do not understand the underlying logic, you cannot really fix it properly.
AI is becoming a helpful assistant, but it is still far from replacing real engineering skill.