Rendered at 05:15:31 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Overdrivr 23 hours ago [-]
It's because the hard part of making software is not coding, but deciding what's worth building (even with LLMs), appropriately modelling the problem and designing the solution (at a conceptual, architectural level). And there has been strictly zero progress on this and IMO this isn't something LLMs are strucurally capable of doing.
glimshe 18 hours ago [-]
I remember that back in the 80s, when I was still deciding what I wanted to do when I grew up, there was a distinction between a "programmer" and a "systems analyst".
The systems analyst analyzed the problem that needed to be solved and designed a solution involving a computer, including system modules, inputs, outputs, etc.
The programmer, supposedly a lower paid profession, transformed that into Computer code. I remember someone telling me that wasn't the best choice and that I should become a "systems analyst". They wore the better suits.
My college even offered a shorter, cheaper degree for people who just wanted to be "programmers".
I think this distinction still survives in government labor statistics.
Perhaps we came full circle with LLMs partially killing the "programmer" job.
xorcist 16 hours ago [-]
We might be the same generation, I recognize the two roles. What I also remember is just empirically how much better the "programmers" were at doing the "system analysts" job. Way, way better. Then we stopped educating system analysts and now the job title is not heard of anymore.
I regularly meet (recently examined) people who are trained "software architects". Common among them is that they are often delay projects championing their pet idea, sometimes bringing negative value to the project. The best programmers are just so much better software architects also. So I expect history to repeat at this point.
EarthBlues 15 hours ago [-]
Programmers are better architects because their decisions are continually informed by experience from the "sharp end" of the system. LLMs don't really have experiences, I dont think its the same.
Our profession will likely shake out a lot of people in the coming years. What will be left may not be a classic "systems analyst" or "architect" role. I think the people who stay in this field will have to move both up and down the abstraction stack simultaneously -- our job will become a lot more "real", physical, relational, risk-oriented. I dont think there's good reason to believe LLMs can supply the need for prudence in the fields where software is deployed.
ctkhn 15 hours ago [-]
You do need to stay in touch with the sharp end to stay sharp yourself. I've had a lot of managers and directors in my career who as they have moved up in companies, longer write any code, and seem to not really get how our systems work even though they are in charge. I had a few managers in the past who were "non technical" and had never written code in their life, and they were the absolute worst of the bunch.
There is a little bit of truth to the otherwise very corny comic with the guy with an enormous head saying "at the library" when asked where he works out. https://i.pinimg.com/736x/3c/69/3a/3c693a6f9e3f6949192ce613e...
saltcured 12 hours ago [-]
In my opinion, a lot of that "no longer getting it" is because of the social/fashion trends that continually disrupt programming.
You don't forget CS concepts so easily, but all the syntactic tricks of new language variants and working set vocabulary of APIs, data formats, and frameworks keeps churning away from whatever you last had contacted in a real, hands-on way.
It is fascinating, wondering where this is going as programmers turn into their own middle managers on top of agents. Particularly, the school who claim that you don't really need to understand all the code and instead treat it like a black-box experiment. If this fad takes over the main stage, then everyone becomes one of those less technical managers.
But, in this new scenario, there is no human in the loop to inject judgement calls and "manage up" anymore. There is no programmer culture except the models and agents, which don't really have the same social connections to drive a programming culture. What will happen? A culture per agent product? Per enterprise client of the agent vendor? Per agent operator? Per codebase?
torginus 15 hours ago [-]
Weird how these fads just disappear overnight, 1984 style.
About half a year ago I noticed there were no people called 'Agile something' at our org, so I asked about it. They looked at me like I was a space alien. I remember, it was like 3 years ago that management bet the house on 'Agile transformation' talking about how Agile practices are the bread and butter of a good organization.
Now they're talking about AI the same way.
ctkhn 14 hours ago [-]
To be fair there is something to the idea of moving to agile from waterfall practices, the same way going on any diet in general makes you think about what you're eating and helps you lose weight. Unfortunately it's usually just a way for the same management (who have fostered bad practices) to hire a new set of consultants and look like they're doing something without actually fixing anything.
torginus 6 hours ago [-]
Yes, that something is about moving from a management class composed mostly of senior engineers to Agile cultists whose core tenet is that they do not know anything about engineering, and do not wish to, because as long as the principles of Agile are followed correctly, it doesn't matter if your company makes software or matresses.
somesortofthing 10 hours ago [-]
"Don't try to completely plan out huge software projects and commit to rigid delivery timelines in advance," "Split work into manageable tasks", "Run daily meetings to keep managers(and sometimes coworkers) in the decision loop and surface blockers", etc. are iron laws everyone instinctively recognizes are there for a reason. The explicit framework fell away because its principles became ubiquitous - nobody needs to hire Agile™ consultants to tell their SWEs and managers to do things the way they've been doing them for their whole career.
ElevenLathe 7 hours ago [-]
You say this like its universal, but my ostensibly Agile org is currently planning the work we will be delivering Q1 of 2028 because that is how long our [proposed work] -> [approved work] -> [finished work] pipeline runs.
The memo has NOT gotten around, though AI now makes it easier to make all the various slide decks and schedule all the 50+ person meetings that power this process.
ahartmetz 12 hours ago [-]
It's fun to remind people of past hypes and how they disappeared. Some don't seem to get the connection to the current thing. (Note, I'm not saying AI is nothing.)
derefr 12 hours ago [-]
> Common among them is that they are often delay projects championing their pet idea, sometimes bringing negative value to the project.
Negative value to the project, perhaps; but if these "software architects" are kept around despite several rounds of this, it may be because they're providing positive value to the company, in terms of producing for the company a thing whose existence (no matter how flawed) serves as collateral for:
- the executive team, to show to investors, to convince them that they're acting strategically in the market; or
- the marketing team, to get breathless puff-piece articles written about the company, in places where dumb CTOs/CIOs who make IT buying decisions will read them. (Not necessarily to then buy the specific product that came out of that project — hopefully not, in fact! — but instead to remember the company itself the next time they're comparing vendors for something else);
- or the executive team again, this time to show to a potential acquirer, to convince the acquirer that their employees have a higher asset value for having a certain skill / experience with certain paradigms, that they gained working on this project.
Companies have spent collective billions (trillions?) of dollars on projects they know will go nowhere, just to be able to say they did a project that is made a certain way or does a certain thing or has certain certifications, and to have a shitty codebase they can pull out of their back pocket if needed to back that up. In all such cases, even if they need to present the product, the product will never be evaluated for its quality or for its fit-for-purpose-ness; so it doesn't matter that the project failed to produce something of quality or that is fit-for-purpose. It just matters that the project happened.
prmph 17 hours ago [-]
Then we have/had "Software Engineer", then "Software Architect", etc.
Words are just words. In tech especially, it seems anyone can call themselves whatever they want.
Someone who chooses to call themselves "programmer" can be more engineering-minded and see the big picture better than someone that calls themselves an engineer.
retwakm4 16 hours ago [-]
I prefer to call myself a programmer because I don't think we (as a class) consistently perform a lot of the types of duties (both ethical ones and just basic job performance ones) that would be required of a lot of engineering disciplines.
I also started out in systems programming and we still call ourselves programmers there, when there is a lot of systems "engineering" (aka trying not to blow up the system with your code running in supervisor state) going on. And there, a lot more attention paid to stuff like IEEE code of ethics, professional development, rigorous designs, etc.
So I'll keep to calling myself programmer amongst my non software engineering friends. It just seems more humble.
That being said, writing the code has like others have pointed out, never been the largest part of the job in my experience. So I can see how it may be confusing to some, especially software engineers. But to non software engineers I think they mostly get it...you are a software engineer trying not to imply some some sort of unearned intellectual superiority.
ModernMech 17 hours ago [-]
It's not about what people call themselves, it appears there are actually distinct roles here, and AI is automating only one of them (for now).
bitwize 15 hours ago [-]
Programmers ysed to laugh at "software architects" for producing lots of documentation and no code.
Who's laughing now? Who still has a job now?
microtonal 17 hours ago [-]
The systems analyst analyzed the problem that needed to be solved and designed a solution involving a computer, including system modules, inputs, outputs, etc.
I think both definitions are still too narrow for what I do daily. I fully agree that we still need humans to decide what to build, how it should all fit together, etc.
But both definitions do not really take into account the huge social dimension of being a good (computer) engineer in a company. You have to translate requests from a wild variety of users into what this means for a system. You have to recognize and explain that what they need is not always what they think they need. You have to be able to say "no" to things. All these things are very hard for an LLM (reading humans, not literally following requests).
Then there are social aspects like building consensus within a project, building a user base of many people that are initially skeptical, using existing relations with people and other companies to slowly adopt what you are building, etc.
Programming used to be a large chunk of the work. I thoroughly enjoyed this aspect of the work when I was younger, but at some point I started enjoying system design and everything around it more. So in that sense, programming with LLMs is much nicer (though I still review every single line of code and often have to go through a couple of iterations because even Opus 5.5 often doesn't get it 'right' in the first take). But the remaining part of the work is extremely hard for an LLM to replace.
parasti 15 hours ago [-]
> You have to be able to say "no" to things.
How do you justify saying "no" when there is a magic machine invented 3 years ago that'll do it? Your gut says it's a maintenance nightmare, your LLM says it's already done implementing it.
derefr 13 hours ago [-]
What you're describing is an "IT systems analyst", or rather, the term "systems analyst" as it evolved into a particular niche usage within IT.
But there's a more general kind of "systems analyst" that still survives (and is mostly what the BLS stats refer to): a person whose job is to map out the current business domain of a system (consisting of not just computers, but also people, infrastructure, institutions, etc.) and identify where it will need to be modified (but not necessarily how it will need to be modified) to make it capable of being put to use in a certain way for a given plan/mission.
Systems analysts in this sense tend to be one of the actual workhorse jobs inside "management consulting" firms and "think tanks." Governments, militaries, and large bureaucracies with many independent business units (think IBM) are their customers.
Systems analysis is sometimes done structurally over an entire organization: someone at a very high level has some new vision for an initiative, and hires these companies/think-tanks to help them determine how to "align" their organizational architecture with what a military might call a new "doctrine" or a company might call a new "paradigm." In these cases, the systems analyst performs the first step of that alignment: understanding "the system as it is today", and identifying what parts of it are already aligned vs. which parts will need to change. Their output is a report to the person driving the process.
But structural analysis is more often applied to specific strategic/business units, as the result of that strategic/business unit being chosen to execute a given strategic mission, as an enablement process to get that unit into the specific shape it needs to be in to execute that mission. In this case, there is likely an assigned "mission {planner, architect}" (who may also become the mission's director; or who may hire for such a director role and then depart to go plan the next mission.) The systems analyst works for/with the mission planner as their "eyes and ears", interacting with the business unit to gather information for the planner to use.
In both the structural and strategic cases, there are usually also one or more systems engineers who determine the "how" for implementation of these changes. (A mission planner is usually a very senior systems engineer themselves.)
However, unlike the systems analyst, who is considered more trustworthy to central leadership when they exist outside of the system they're analyzing (and so mostly work for external firms like think-tanks rather than for the orgs themselves), there's much less of a motivation to separate out systems engineering in that manner. So systems engineers (including mission planners!) tend to be regular [if high-paid] career employees of the central organization. These folks are frequently "general staff" in a military (with no real analogous term, AFAIK, for the equivalent people within a conglomerate's parent company.)
Due to their value coming in part from existing in separate firms that can negotiate on their behalf, systems analysts in this sense are well-paid indeed! But also worked hard, bounced around, and signing NDAs constantly. And possibly a bit bitter, in that they often see how things are broken with no chance to be part of the fix.
rangestransform 4 hours ago [-]
Ahh the infamous “computer systems analyst” TN (NAFTA work permit) category that nobody really understands what the hell it’s supposed to be
This is not legal advice but allegedly lawyers were instructing CSA category TN applicants to never ever mention that they are “coding” or “programming”
bitwize 16 hours ago [-]
The software methodology of the future will look a lot like Milt Bryce's PRIDE.
Milt realized as early as the 1970s, if not long before, that programmers had way too much power in an organization because most organizations adopted a "tool-oriented approach" to computer technology: here's a tool, how do we make use of it? They let the programmers run wild, and the result was software that was a buggy mess. What's needed is a management-oriented approach in which the management of the company calls the shots on what's needed for the company to function.
In PRIDE, the systems analyst is centered. This is explicitly a business role, not a technical role, and their job is to understand the business in such a way that the information systems (not programs, nor apps) that drive the business can be described in diagrams and text. Only once the requirements, definitions of terms, and data definitions have been established and standardized can the implementation phase begin. Bryce estimated that if you're not spending 65% of the effort in systems analysis and only 15% of the effort in programming, you're doing it wrong.
This is how grown-ups did information systems for decades. And then the internet happened, "hacker culture" happened, and the programmers were back in the driver's seat, producing things like "Agile".
Now we have AI, and to quote another commenter elsewhere in the thread, the programmers have had their tails cut off. That 15% number asymptotically approaches zero. But the systems analysis still needs to be done, and for the foreseeable future anyway, that needs a human touch.
Become a business person, not a "software engineer". They are the ones who will drive things forward in the agentic era.
jdlshore 13 hours ago [-]
The systems analyst (and related role, business analyst) disappeared because it didn’t work. The cycle times were too long and the resulting software too poor.
Maybe that will change with LLMs, but you’ve got the causality arrow backwards. Systems analysts didn’t disappear because of Agile; Agile exists because that way of working didn’t work.
Source: I was on the front lines of the first Agile wave starting in late 1999.
(And then what people actually adopted as “Agile” generally wasn’t what was created by the first wave of the Agile community, but that’s a whole ‘nother topic.)
yasnu5 14 hours ago [-]
Sounds like I should just take a shotgun retirement
rpdillon 14 hours ago [-]
Sounds a lot like waterfall.
bitwize 13 hours ago [-]
"Waterfall" is a pastiche of mature development practices used by Agilists to sell their programmer-centric snake oil. It's basically a phased development process kinda like PRIDE, but it explicitly doesn't incorporate feedback between the phases. PRIDE explicitly allows, for instance, new requirements discovered during the design phase to feed back into the analysis phase. But it is explicitly based on the idea that "A system is a product that can be designed and manufactured, just like any other product." And that the exact same management principles from the manufacturing and construction industries apply to information systems development. It is always a phased process that starts with requirements—identifying what the needs are, followed by design—producing a blueprint of how those needs will be met. This is how bridges, buildings, cars, and consumer goods are built; why not systems? Milt Bryce used to say, "If this country built bridges the way it builds systems, we'd be a nation run by ferryboats."
A counter to this is "requirements change quickly, therefore the system needs to change quickly too." But the actual case is: most organizations don't really know how to do systems analysis. So this results in one of two scenarios: either the organization wastes a lot of time and money in the analysis phase struggling to do what they cannot, or they punt on requirements analysis altogether and wait for requirements to surface at implementation time. This is called "Agile" today, but was described by Milt in 1983: "do a superficial feasibility study, do some quick and dirty systems design, spend a lot of time in programming, install prematurely so you can irritate the users sooner, and then keep working on it till you get something accomplished."
Today, with AI, there is no reason not to do requirements analysis and design first. An implementation phase that used to take months can now be performed in weeks or even days. So an executive who observes shifting requirements can document them, work with an AI to update the design specification, and then have a swarm of agents perform the implementation work, and roll out the new system before next quarter if not next month. So Agile really isn't necessary anymore.
PRIDE is like a textbook on how to build a system, from requirements analysis through design, implementation, and maintenance. It was the first methodology for doing so, and it transformed information systems from arcane art into a proven, repeatable science. It should be the industry standard, but is now at risk of being forgotten, largely due to programmers holding the industry hostage.
AI is taking programmers out of the equation. PRIDE is relevant again.
teyc 6 hours ago [-]
That doesn’t gel with my experience. Projects have time and budget constraints, and systems have multiple lifetimes of knowledge and practices that are poorly encoded. One only has to look at ERP failures to ask what kind of system analyst is required to solve this issue and it is very hard to hire. Eg how would you know this SKU comes in packs of 50 that has particular dimensional requirements, how would better analysts save Nike from their factory optimisation dilemma? How would a team estimate the effort involved with opening a port on the firewall? Agile has a fixed budget flexible scope.
rpdillon 13 hours ago [-]
Ah, so more like spiral development. I don't think we know what development methodologies will be relevant; things are changing too quickly. Your comments come off as a bit over-confident, given the level of uncertainty about this topic, but I appreciate you mentioning the methodology, since I suspect we'll draw on those lessons as we formulate the new best practices.
locknitpicker 16 hours ago [-]
> The systems analyst analyzed the problem that needed to be solved and designed a solution involving a computer, including system modules, inputs, outputs, etc.
This is a holdout from the time when the whole software development field was still stuck with the idea that waterfall/big design up front was an adequate way of doing things.
The belief was that, like any engineering field, systems would first be designed in detail before anyone could even open an IDE.
This approach was quickly proven to be wrong, expensive, and fruitless. Agile started to emerge as an effective approach to the problem of developing and maintaining software systems. The uselessness of the system analyst role, when contrasted with the fact that mere programmers could easily implement features without guidance from an enlightened individual far removed from the problem domain, was readily noted.
bellgrove 15 hours ago [-]
Completely agree. In my experience, Claude is great at producing working code — but whether that code is readable or designed to be easily extensible still requires heavy guidance. Anecdotally, I've found several of my colleagues experience a growing fatigue with increased PR volume sent to review, reading through AI generated descriptions and design documents, and generally from having more distance from the enjoyable (subjectively) hands-on work of coding.
AI has already delivered huge productivity gains in my opinion; the whole StackOverflow/Google search part of my life is gone. Instead I get answers from Claude tailored to my specific environment, use-case, problem, etc. Writing well-defined, simple code with lots of prior art in the same repo is easily handed off. But the AI industry and a lot of leadership in big tech seems to be expecting further miracles from AI. Maybe one day a CEO or CPO will just be able to speak their thoughts and a fleet of agents will implement it flawlessly, but we are nowhere near that reality right now.
Fripplebubby 14 hours ago [-]
> In my experience, Claude is great at producing working code — but whether that code is readable or designed to be easily extensible still requires heavy guidance
I think this is a different point, though. OP is saying, we haven't really made progress on the problem of figuring out what to build (and just as importantly - what not to build) and how to convey that effectively and set up the right feedback loops to get AI to actually deliver on that. Whereas you're saying, "Yes, I agree, the code that the agent writes has flaws in readability and design". If we can get the first part actually solved (and I'm not sure what an answer looks like - other than what we have today, which is that The Market ultimately dictates whether you've built the right thing, built enough, not built too much), then nobody other than the AI agent actually cares about solving your problem (readable, maintainable code) anymore. Or to put it another way, it's only in the agent's interest to solve that problem, for the same reason that today it's in the SWE's interest to solve that problem, rather than the product manager or the business owner.
ChrisMarshallNY 18 hours ago [-]
So far, that's been my experience. My work still needs my architectural guidance, but I can rely on the LLM to do a decent (not exceptional) job on the details, as long as I am willing to break the tasks down to a small enough level.
I believe that LLMs will, eventually, reach a level where they can provide decent architecture, but I suspect that will suffer the same issues affecting code generation. It will be "decent," but not "awesome." I think exceptional people will still be able to beat LLMs at architectural design.
The issue is that the definition of "exceptional," means that it doesn't happen very often, and most people manage to convince themselves that they are the exception.
rdevilla 16 hours ago [-]
[dead]
16 hours ago [-]
moezd 18 hours ago [-]
Just because you have a CNC machine, you shouldn't run it 24/7 cutting and drilling holes into wood, that is waste.
analog31 15 hours ago [-]
The waste is letting the machine sit idle and paying interest on it. We now have the equivalent of Uber for CNC, with services such as Xometry. You send in your drawings, and the supplier farms them out to any shop that has idle capacity. This is convenient for the customer if we don't know precisely which shop has the right machine for the job (e.g., laser cutting, milling, 3d-printing, etc).
I don't know if this is a perfectly fair of their business model, but it has that feel in terms of dealing with them.
moezd 15 hours ago [-]
If you have customers who know exactly what to build, then by all means, run it 25 hours per day if you can. But this is rarely the case for the majority of the people. In the end, you just end up with too many offcuts.
analog31 13 hours ago [-]
Indeed and it also occurred to me that metal and wood don't mix in a machine shop because of the different needs for lubrication and cleaning.
amelius 13 hours ago [-]
Haha, CNC shops are actually optimizing so that they can run their machines all the time.
yasnu5 13 hours ago [-]
But if we aren't running it 24/7, we'll lose out against the shops that are!
krainboltgreene 14 hours ago [-]
That's really funny to say because being able to do that is exactly why the industrialization of society became a revolutionary force.
bob1029 19 hours ago [-]
The answer is to find a customer and to go only as quickly as they can tolerate. If the developer is deciding what to build, we've already lost the entire game. Every single ambiguity and fear that exists in software engineering evaporates if we interact with the customer regularly.
AI has absolutely nothing to do with any of this. It merely accelerates the "how". You still need a customer to determine everything else.
prmph 17 hours ago [-]
This ignores that many times you can create something the customer would never have imagined they needed, but when they see it, they want it.
The path to success in software is varied, there is no one hallowed way. Saying everything must start with talking to customers risks eliminating a whole swath of useful creative approaches. A dev slaving away for months or years on their own pet project can still come out with something that achieves major success.
christophilus 17 hours ago [-]
No it doesn’t. Frequent interaction with customers is how you arrive at good ideas and insights that the customers themselves never would have had.
jdee 16 hours ago [-]
Can I interest you in a faster horse?
aerhardt 15 hours ago [-]
If you're referring to the famous Henry Ford quote ("If I had asked people what they wanted, they would've said faster horses") I'll first note the obvious: Ford didn't invent the car.
Second, I'll concede that revolutionary innovation happens primarily top-down. Common folk don't know anything about the state of combustion engines or transformer architectures, or how those can be composed into new categories of product.
Third, odds are if you're building software, you're doing nothing of that sort, but rather dealing with infinitely more modest innovation. You would be, in fact, improving a horse, if that were at all possible.
Fourth, when improving the proverbial horse, you'd better have an outstanding sensitivity to the finer problems that customers face. Whether you develop that sensitivity by asking, or sensing in some other way is another question. But asking may not be a bad idea at all.
Fifth, I'll close with an anecdote. The worst seed-stage software startup tire-fire I've seen in the last couple of years was led by a CEO that published the Henry Ford quote, verbatim. A couple years in and they still don't have a paying customer. I'll generalize by saying that I've seen pretty much everyone around me with "the don't ask, envision" attitude fail, while the people who ask or are otherwise exceptionally attuned to the customer problem do much better on average.
skydhash 15 hours ago [-]
I believe the core drive of the automobile was to have a machine-powered carriage. No one wanted faster horses, and it would require taking care of the horses.
The quote is a great example of imagining user needs instead of just asking them.
citizenkeen 13 hours ago [-]
Faster horse, etc.
Myrmornis 18 hours ago [-]
A sample size of 1 real customer is worse than a sample of N >> 1 customers imagined by someone who knows the field.
xnx 11 hours ago [-]
> AI has absolutely nothing to do with any of this
You don't think that AI can (or soon will) be able to talk to the customer and discover what they want?
interstice 18 hours ago [-]
This assumes the customer has a clear vision and doesn't need help with not creating logical paradoxes within their own business model.
flohofwoe 18 hours ago [-]
The old gamedev wisdom is: ask your players what feels wrong, but not what the solution should be.
mpweiher 18 hours ago [-]
"Listen to your customers, but ignore what they say"
newsclues 18 hours ago [-]
I want a meal assembled by a professional chef, not a machine that chops food at my dumbass requests.
bitwize 17 hours ago [-]
Exactly how "The Homer" was developed.
qalmakka 18 hours ago [-]
This. The manpower was rarely the bottleneck. Good ideas were and still are
kylecazar 17 hours ago [-]
Personalities in tech/VC been saying the opposite for years. That ideas are cheap and execution is everything.
Now that execution is more of a commodity, everyone seems to be saying execution is cheap and ideas are everything.
I don't disagree with you. I'm just noting an observed 180.
planb 16 hours ago [-]
No. Execution isn’t just writing the code. It’s caring about the details.
kylecazar 16 hours ago [-]
That's fair. Execution is more than getting the code written.
master_crab 17 hours ago [-]
There were usually three or four startups chasing the same business case pre-AI.
I’ve never been one to trust the VC crowd without knowing where their money lay.
qalmakka 16 hours ago [-]
> That ideas are cheap and execution is everything.
Derivative ideas? Like "let's make a $thing with $variant"? Yes those are cheap, and AI made them pointless to pursue because most people can now whip up a hacked up variant of $thing with GPT and be happy with it, until they realise that it didn't add that much value to begin with.
But good, truly good ideas? Those that turn everything around? Those are cheap in the sense that your brain doesn't consume that much energy having them, but they are rare.
LLMs kind of confirmed we're indeed constrained by ideas: the homepage of HN isn't full of things like "we reimplemented X in Y" because we were full of revolutionary ideas to begin with. IMHO LLMs have further hampered the spread of truly great ideas - because nowadays if you have a truly great idea you have a fork:
- your idea can be quickly implemented by an LLM. You do it, and then everybody simply copies it using their LLM.
- your idea requires time, iterations, ... so the LLM speeds up delivering it, but only a bit. We're still on a path similar than before - even before you could just hire more people and try to deliver stuff faster, as long as you had all already clearly planned beforehand.
So yes LLM are a big boon to productivity, but IMHO cast a long shadow of "why would I do it at all" on things. In the before times, I'd spend my day coding a dumb library for fun, just to brag about it a bit on Github and HN. But given that nowadays LLMs have reduced the value of code to ~0, the one thing that still has value is the idea behind. Which now people have less incentive to put out in the first place.
aerhardt 14 hours ago [-]
I'm not going to get into the debate of ideas vs execution. It's pretty much imponderable. Both are necessary conditions, who cares in what proportion of importance.
I'll just observe that execution remains ridiculously difficult despite AI. Even building the software itself. Then there's all the other stuff, mostly relationships (with investors, customers, employees, lawmakers, society at large) to which AI contributes nearly zero or may even cause damage if used recklessly. The amount of posts I'm seeing from VCs complaining about vibeslop decks!
boringg 17 hours ago [-]
And execution of those good ideas
jstimpfle 14 hours ago [-]
To me it's been a great aid as a rubber duck and general research tool. Totally agree that it can barely help coming up with a good architecture. But it's quite capable of understanding an existing or a suggested one, even somewhat capable (though clearly not surpassing the best humans) at evaluating it.
hackeraccount 14 hours ago [-]
Such a cruel age we live in. I thought I wasn't Picasso or Shakespeare because I didn't have a sense of meter or perspective. Those things are necessary but not sufficient. I'm not those people not because I'm too lazy to learn the skills but because I've got nothing to say.
andai 13 hours ago [-]
That's half research, half experimentation. Why would llms be bad at any of that? They're already better than us at both halves.
(Well, they still need handholding and regularly demonstrate spectacular stupidity... but so do we, and we've been getting along just fine!)
13 hours ago [-]
18 hours ago [-]
ucyo 22 hours ago [-]
Do you have recommendations for this? Ideally books
neomantra 20 hours ago [-]
It is quite dated (1994), but just this week I was feeling very thankful to the authors of Taligent's Guide to Designing Programs [1], a book I read and lived. It comes from an era when software architect and programmer were different jobs (things seemed to change soon after?), which parallels modern LLM use. The C++ version there is quite old, but the concepts are timeless.
For those unfamiliar, Taligent was (among other things) a very well funded C++ app platform that never shipped, and its failures have been much analysed.
neomantra 17 hours ago [-]
Yeah, it was weird that I was reading so much about designing software in a system I could never touch. It might be part of why OSS and access to computing is important to me; we had to buy our C++ compilers then.
It was my first years of being a "software engineer", versus the solo hacker kid who liked making art of over phone lines. So I devoured books which would teach me how to make software with other people and for other people.
Books like the "BeOS Filesystem book" (Practice File System Design) was another classic from the era [1]. It was like today's LLM white papers, learning how a company did something unique, except companies seldom published them because it was a time of IP hoarding.
Unfortunately the books that eventually became the most practical were those by Sutters and Meyers; compendiums on the warts and jewels of C++ that you needed to know to be good at programming in it. Such nitty gritty, much of which was eventually fixed by language design. I really don't miss having to know all that, freeing my mind to consider architecture, design, and delivery.
If people knew what is worthwhile building, they wouldn't write a book about it. It's like writing a book on how to make money in the stock market.
phtrivier 19 hours ago [-]
Arguably, a lot of books are written about that, by two different kind of people who did made money on the market : those that made a lucky bet, beat the market, and are trying to explain how to become a young billionaire yourself (I don't have exemple in mind, because those are not worth much any way - see below); and those that just invested cautiously enough to _follow_ the market, not make anything dumb, and make enough money to be an old millionaire yourself (Charlie Munger, Mr Money mustache, etc...)
The former are fun but irreproducible ; the latter are boring (index funds, sobriety, compound interest, don't be stupid, and some luck to avoid the bad timing of the crashes) unless the author adds some snark (again, Munger)
jodrellblank 18 hours ago [-]
The latter are the former just on a longer timescale. You say "some luck to avoid bad timing" but ask yourself how many people in the 1950s - 2020s were doing what Buffet and Munger were doing, namely reading a lot of company balance sheets and announcements, trying to stick to decent and well-run companies with good business models, buying when cheap opportunities present, and waiting a lot.
I expect it will be more than 2 people trying that, and almost all of them didn't become multi-billionaires.
phtrivier 17 hours ago [-]
What I meant is that, if you you don't need to withdraw a lot from your savings exactly at the time of a crash, than "just following the market" works. And, crashes happen regularly, but scarcely enough that you may very well retire in between them.
So it's the difference between "depending on things being average" and "depending on things being exceptional".
InsidiousWombat 5 hours ago [-]
Even then we should see more improvements just by LLM ability to quickly come up with prototypes so many potential solutions can be checked quickly.
...the problem is instead of doing that people take the first prototype and ship it
mupuff1234 13 hours ago [-]
> And there has been strictly zero progress on this and IMO this isn't something LLMs are structurally capable of doing
Making architectural mistakes is now exponentially cheaper - as you can refactor the entire code base in a day.
So even if LLMs are not quite there yet in terms of architecture, they definitely lessen the time one needs to spend on making the right choices.
and in areas like FE for more internal tools design really becomes a non issue.
jmathai 22 hours ago [-]
Software I’ve written has marginally been improving both as LLMs and their tooling has improved and my ability utilize them has increased.
I think marginally is an understatement though because it feels like it is compounding. I don’t know other people’s experience but I’m building software that would not have existed before LLMs and coding agents arrived.
And this software is without a doubt better from the end users perspective. Maybe the code is crap, who knows? I don’t look at it. I judge based on 25 years of writing software by hand, deploying it to real users, and being a user myself.
I hope there is a resurgence of indie software like existed in the early 2000s.
There’s no hope for enterprise software. It will always be terrible.
matsemann 19 hours ago [-]
> Im building software that would not have existed before LLMs and coding agents arrived.
That can be a sign that what you're now building is perhaps not worth building? At least my experience from dayjob, we're building more and faster, but it's either things we really shouldn't do (stuck in backlog forever for a reason), or things that just complicate the main product when features get added willy nilly.
wongarsu 18 hours ago [-]
https://xkcd.com/1205/ applies, but five minutes of my time now goes a lot further than it went back when that comic came out. There are now a lot more cases where I can spend 5 minutes to shave a couple seconds (often minutes!) off a monthly task, or half an hour to make a task I only have to do today faster and less tedious. Changing the time invested into building a tool by an order of magnitude makes more than an order of magnitude of change in the number of tools that are suddenly worth the effort to build
Of course this calculus drastically changes when maintainability and other stakeholders come into the picture. There vision an architecture are more important than adding features. Architecture isn't too hard to solve, but sadly good product owners have always been hard to find
TobiasJacob 20 hours ago [-]
Sometimes I'm wondering if I am actually more productive or just building a lot of stuff nobody needs at home.
Yes my frontend is nicer. I do not hang myself up debugging a small issue for hours. I also don't have to search questions online, and get even complicated answers fairly quick.
But I'm not sure if I ended up being so much productive, or I'm just building a lot of open source stuff nobody needs. Last year i would have solved a narrower problem and relied on others to contribute the rest.
elvis10ten 21 hours ago [-]
> Maybe the code is crap, who knows? I don’t look at it
I implore you to look at it! I recently vibed too close to the sun: I knew at a high-level what I was doing, but never looked at the code.
Two weeks after and 50k LOC, I’m having a look and I can’t believe my eyes. There are whole failure modes that don’t need to exist. Moreover, how can I sale this software in good faith, when something happens and I’m largely a meat proxy because I don’t know how the code works?
I will go through the entirety of the code with my naked eyes, and make improvements (with AI).
But this time, I won’t fall for the illusion of “productivity”.
chamomeal 19 hours ago [-]
My main issue isn’t even the code quality. It’s that the more I vibe a codebase, the less ideas I have about how to improve it and extend it.
When you have a deep understanding of something, you just can’t help thinking about all the ways you could improve it. Maybe you realize it could be generalized, or that a different problem you’ve had could be solved with a similar technique. Sometimes you get oh “OH DUH” moment where you realize you were making the slightly wrong thing this whole time, and NOW you know EXACTLY what to make.
With LLMs I just get basically what I asked for, and then I’m done. Obviously this is sick and I love it.
But for a lot of my projects recently, I fall into this trap
- I have a problem, I think a program could help. But I want to know if there’s a viable approach before I invest a bunch of time by myself, so I boot up claude
- LLM writes the entire program, I don’t know what’s going on in there
- the program kinda solves the problem or it doesn’t. At this point I already have something that has vaguely confirmed or denied the viability of solving the problem, so I think “welp I’m not gonna spend a whole week of my life reading an LLMs output”, and that’s that
I rarely have cool insights about the problem after that. In the olden days, even if my approach didn’t work, I would come away with a new understanding of that problem, and all similar types of problems. “Oh that’s why people say cache invalidation is unsolved”. “Oh that’s why generics can’t infer xyz”
Don’t really get that when you vibecode. But the siren song of just having something that works is so sweet, and I can never ever resist it
elvis10ten 18 hours ago [-]
> the less ideas I have about how to improve it and extend it.
This! Especially this! is the real reason I started building my own commercial software again.
I’m betting that the details will still continue to matter.
whatisthiseven 20 hours ago [-]
Looking really isn't necessary.
If you get into the regular habit of having the LLM look for issues with the code base it will find them: structural, bugs, design pattern issues, duplicate code, or same functionality not sharing a single path.
Honestly it feels like working with a real codebase. Tech debt always builds up, and yes the AI does it, too. It does notice if you ask to look.
elvis10ten 18 hours ago [-]
I do this, but it’s a constant loop of liability.
When I wrote features by hand, I used to have like 2-5 bugs. Most of which were just human clumsiness.
When I started using AI and remained in the driving seat, most of the human clumsiness bugs went away.
Now, when I vibe, all I have are my verification loops and asking Opus5.5 to find and fix bugs.
Opus tells me it’s done. Only for me to start a new loop and it finds 10 more things or maybe I go in myself and it says “oh you are right”.
For me, this is not progress. I would rather spend an extra 1 or 2 hours a day in the driving seat building software that is correct and that is so simple that cost of changes is low.
elvis10ten 18 hours ago [-]
Also, LLMs don’t typically know when they are climbing a local-maxima. They would add a shit ton of changes to improve the things that you measure, while other aspects suffer.
troupo 18 hours ago [-]
> having the LLM look for issues with the code base it will find them:
It wrote them to begin with. Now you're handing of this discovery to literally the same LLMs that wrote this.
Oh, they will find some issues. Are you sure they will fix them and/or rewrite them without introducing more issues? How do you know if "looking is not necessary"?
whatisthiseven 17 hours ago [-]
I know it isn't necessary because 6 months ago it became largely redundant for me to look: there wasn't enough for me to criticize.
I have automated the entirety of testing and Claude can validate it's own inputs. I then focus on marking requirements fulfilled, or bugs found. The bugs it does find are usually on the side of incomplete requirements. The few technical ones were due to a lack of testing. And I am not perfect, so I would have made all kinds of bugs myself.
If you keep to a mindset of, and build processes for, the management of software development rather than coding, results are better. No this isn't a magic prompt like "make no mistakes".
It is approaching the project with the mindset of knowing the limitations of the tools like one would a junior/mid engineer, and then mitigating. This is dependent on the codebase, product, and desired requirements for what processes to use and to what degree.
If you find yourself still needing to look, you have insuffiently automated the creation and validation of written software.
Its solved. Adapt and learn to use them effectively or get left behind; seems to be the unfortunate reality.
elvis10ten 16 hours ago [-]
[flagged]
troupo 11 hours ago [-]
> Its solved. Adapt and learn to use them effectively or get left behind; seems to be the unfortunate reality.
Every time. Every single time. People who say they never look at code anymore always say the trite things about "management of software development", how they have no issues, and that if you have issues, it's the problem with your skills with a side of snide remarks about your intelligence.
And then you press them for details.
After a few rounds of more and more trite answers they either go away or it turns out that their "automated everything" and "processes" and "coding is solved" are:
- a bunch of "make no mistakes" aka untold numbers of random markdown files aka skills, "guidelines", "memories", "ADRs", "technical docs" etc. Which are routinely ignored by any and all models.
- a bunch of tools that can't or don't catch all the mistakes the models routinely make. E.g. there are very few tools that reliably detect code duplication (especially code duplication with subtle changes in behavior), or reliably detect bad data access patterns, or reliably detect suboptimal algorithms etc.
- an overreliance on tests. The very same tests that are written by the very same very models
Also, if the models could actually "validate inputs" and other "coding is solved" things, you wouldn't actually need dozens of tools around to catch the mistakes they do. Ironically, you need "processes" and "engineering management".
---
As a related aside.
I have multiple tools from linters to semantic analysis running as routine checks, and still. Here are the responses by Claude for some of the things I caught it doing in just the past few days:
- "The [test data] generator can sometimes fail, and create duplicated data, so I increased the number of times it runs to 100" (instead of fixing it)
- "The tests check this in an indirect way. They send megabytes of data and watch the memory of the whole VM. Unrelated processes change that number. The direct check is the number of body bytes that the server read. Do you want me to rewrite these tests" (Claude wrote all these tests to begin with)
- "The previous research covered only a few CSS files. It did not cover the design system documents, the components, or the pages that already use them." (so much for "No this isn't a magic prompt like 'make no mistakes'" as it had an explicit requirement to use the design system)
- "The too_large_message/1 helper has three copies, two of them private, with no good reason for them..."
I don't use memories, markdown files, guidelines, etc.
I design the software like I would as an principal engineer and dictate the high level requirements. Opus 5.5 really does just work. 10 months ago this wasn't quite true, it required more steering of the technical requirements.
I don't know why your results are different. I run a live multi-week long campaign game that streams updates over WSS from an Elixir app. I can literally see if Claude is doing as it claimed. It is trivial to verify when it gets it wrong.
I dunno what some others are doing to get such poor results. How much larger must my codebase become, how much more complex before those that see poor results see that it really is solved?
And if 350k LoC isn't enough for your use-case. Well, that wasn't quite achievable 12 months ago, but it was 8 months ago. In another year, I imagine if my codebase grew to 1M+ LoC, the latest models would still be keeping up.
Its solved. And the number of codebases it can't apply to shrinks every 12 months.
It doesn't have a summary of the codebase. Or at least a useful summary.
> I design the software like I would as an principal engineer and dictate the high level requirements
Let me quote myself:
--- start quote ---
And then you press them for details.
After a few rounds of more and more trite answers...
--- end quote ---
This is now your third reply with trite answers (two to me and one to a sibling comment).
> I don't know why your results are different.
Because I actually look at code it produces.
> It is trivial to verify when it gets it wrong.
Yes. Yes it is.
E.g. in my codebase it is trivial to verify that it does 15 reads from the database on a page when just 2 or 3 would be enough. How do I know it? I check the logs, or see it in the REPL (I also use Elixir).
It's also trivial to see when it does shit like "oh I didn't read the design system". Because I actually see what it's doing.
> And if 350k LoC isn't enough for your use-case. Well, that wasn't quite achievable 12 months ago, but it was 8 months ago. In another year, I imagine if my codebase grew to 1M+ LoC, the latest models would still be keeping up.
Yeah yeah. "Keeping up". Where by "keeping up" you mean "I duplicated the code 15 times, and "I didn't read even half of what is needed to do this task".
It works for you because you give it only the most superficial tests. Wouldn't surprise me if you can cut all of that code in half and raise the fps 5-fold. But for that you actually have to look at the code.
I mean. Nothing wrong with it is there? The code works. I can see it work in my browser. What other checks do I need lol.
Or "high level tasks".
Me: "Do not show invites panel if there are no invites, otherwise it shows as a horizontal line"
Claude: "The hidden card keeps its border because the box-lx { display: block; } rule overrides the browser's [hidden] style. I'm adding a primitive rule that sets display: none for hidden next"
You know, instead of not rendering it in the first place.
whatisthiseven 5 hours ago [-]
> This is now your third reply with trite answers
Have a fourth, then.
I hope you continue to ship for use-cases your users care about in your work, and continue to find satisfaction in software engineering.
I am.
skydhash 15 hours ago [-]
A lot of statements with no evidence to back them. I won’t ask for a link. But did you measure the bugs (reported by customers) and the time taken to fix them, feature usage,… Or is it self patting in the back with LoC and PR counts?
whatisthiseven 12 hours ago [-]
Yes, an entire client/server codebase written prior to AI existing has been made far better. More features that players report work (and I play it myself). Far more performance in a measurable way that is obvious to me and players. It can support larger maps, while running well in excess of 120fps when prior it couldn't get past 20fps. This was multiple performance issues that needed resolving. Not once did I look at the solutions that improved performance. I had Claude do byte and object level comparisons between versions to catch regression. I then played it myself to much joy.
When I release features, players report minor bugs, which I can fix in minutes by simply dumping their complaint into claude.
I worked on this codebase prior to LLMs and made slow progress, with many bugs. I did not know how to approach the performance problems, nor was I able to refactor the project to effectively have test and production environments reproducible. Claude did just fine.
It is 350k LoC, with over 138k as an Elixir app, 60k in tests/scripts, 65k Vue components, 45k JS, and more.
Coding is solved. Many people can't manage software engineering effectively. I don't know how much larger or how much more comparison is needed before this is accepted. Maybe it is "circular" reasoning like the dead comment says.
But it literally just works for me.
shinycode 20 hours ago [-]
I’m shipping more code in a week than I ever did in a year. It’s impossible to read it all.
But I agree that there is critical paths to analyze and decisions that are taken without our consent.
I ask the agent to document every decision he makes without my consent and write it in the PR content when he’s done. Context, ADR, rules etc makes the agent quite good at following good practices but it’s a lot of work and reviews first to build and maintain the feedback loop. Good tests help also to avoid reading code. But once in a while it’s important to read critical paths to fix deviations.
What I’m most anxious about is that, because I don’t read code, if I don’t have access to an agent for any reason I’ll have a hard time fixing a critical bug because I don’t have a mental model anymore of how things work. And that’s not professional and I can’t sell that software.
jghn 15 hours ago [-]
> I’m shipping more code in a week than I ever did in a year.
I think this is a growing problem. I pulled back. I'm much faster than I used to be. BUT, now I also forcibly insert myself into the loop so not as purely fast as I could be. I've thoroughly iterated on a design with the LLM before starting. I've personally looked at and often iterated on every line of code before merging. I regularly walk through the generated code base, both with and without LLM assistance, in order to ensure I have a solid mental picture of what's there.
This behavior has been informed by seeing things go to hell, both for myself and with other people, clients, open source projects, etc
srdjanr 19 hours ago [-]
How could you not have access to an agent that's good enough for an emergency fix? Even open source models should be good enough if OpenAI, Anthropic and Google models are all unavailable, and open source models have plenty of hosts.
rererereferred 17 hours ago [-]
Sell it as if you were Ikea selling furniture, not a craftsman selling furniture.
elvis10ten 16 hours ago [-]
Ahaha! At that point, I would rather just start making actual furniture! It wouldn’t have the same risks and I can live with myself.
KellyCriterion 17 hours ago [-]
>I implore you to look at it!
Absolutely true! Some month ago I discovered huge memleaks by coincidence because Opus nailed tons of LINQ calls together and duplicated data as hell.
thephyber 19 hours ago [-]
> There’s no hope for enterprise software. It will always be terrible.
Why hope for a resurgence of indie software without also a revolution in enterprise?
If there ever was a time for either entrenched players to improve their UI/UX (using LLMs) or for rival upstarts to build lots of feature parity, now seems like it would be the time.
Perhaps if Agents are given some autonomy to buy enterprise software trials it would be easier to break the stranglehold of the biggest vendors.
jmathai 8 hours ago [-]
I’m just not that interested in enterprise software. I had to use Concur this week and it was horrendous. The only reason I use it is because I have to. And I get paid for the hours I waste on it. My employer has deemed that to be a good use of their money. That’s fine with me.
evolve2k 20 hours ago [-]
Sounds like Technical Debt is being ignored "Because AI".
"Technical debt is a qualitative description of the cost to maintain a system that is attributable to choosing an expedient solution for its development.
While an expedited solution can accelerate development in the short term, the resulting low quality may increase future costs if left unresolved."
Except we can at this point reasonably expect future AIs to be better at solving the technical debt then people.
AI is right now buying down huge amounts of technical debt (see the flurry of CVEs). But we're already onto the self-improvement treadmill: future more capable systems will be better at solving any issues introduced today - it's literally not worth the time worrying about now (this is the same reason you don't get a cancer prognosis over a longer then 10 year time frame - the expectation is future treatments will be better).
The technical debt my code written in Opus 5.5 might have is already going to be handled by Fable 5.2, for example. It's going to be better and faster then I am. But also: if the rate of technical debt production from AI is even slightly lower, then it gets more and more manageable in a future where nothing changes but the increasing volume of AI compute is concentrated on less and less of it.
I mean certainly it would be nice if I could implement a feature without Claude finding a security bug and tripping cyber protections every couple of hours.
HowTheStoryEnds 18 hours ago [-]
But will you be able to afford the later models that absolve you of the encrued debt? That is not a given.
XorNot 15 hours ago [-]
Sure: we'll deal with it when it happens, if it happens.
But the model I buy today is cheaper in terms of capability then the one I could've bought a year ago.
But software can be "done". There isn't an endlessly acruing technical debt, the product can be finished.
troupo 18 hours ago [-]
> Except we can at this point reasonably expect future AIs to be better at solving the technical debt then people.
No, we can't. We can believe this will be the case
> The technical debt my code written in Opus 5.5 might have is already going to be handled by Fable 5.2, for example.
"Let's generate more and more garbage in hopes that there will be some magical tech that solves the issues" is not that good of a strategy.
E.g. even for the amazing magical benchmark-shattering Fable 5.5 Anthropic's guidance is still the same: your CLAUDE.md should not exceed 200 lines and claude only reads 200 lines of memory index because otherwise it quickly loses adherence.
XorNot 17 hours ago [-]
Just a year or two ago people were confidently predicting the end of transformer usefulness due to whatever the limits of the time were.
Like all problems, we'll solve them when we get there but its not like anyone has an abundance of useful alternative advice: I'm getting useful software out now, whether I have to fix it later has the same problem it has always had - when we need to, we'll do it.
troupo 17 hours ago [-]
> Like all problems, we'll solve them when we get there
It's already here. People are already producing unmaintainable slop at never-before-seen levels, and software reliability is at all-time low.
> its not like anyone has an abundance of useful alternative advice
Yes, the advice is the same: look at the code produced and understand it.
> whether I have to fix it later has the same problem it has always had - when we need to, we'll do it.
Yet you don't. You're quite literally saying "who cares some future model will solve this for me".
15 hours ago [-]
TheCapeGreek 19 hours ago [-]
Enterprise software will remain terrible for all the usual enterprise reasons, 100%.
Where I'm finding AI exceptionally useful is now being able to address tech debt and developer experience for my team WITHOUT having to argue for spots in the backlog to do it.
So, if nothing else, it sucks a lot less to work on enterprise software if you can let a team lead or principal engineer loose from the PM to just fix things.
ajasmin 19 hours ago [-]
It’s not clear to me how AI fix the technical dept problem. I’m no stranger to nonsense like review comments being ignored or technical task not making it on the agile board.
But, how is AI fixing this? Unless the perverse answer is: no one’s reviewing code anymore so I can just merge my technical fix.
dale_glass 18 hours ago [-]
You can use AI not only to write code from scratch.
So "Where does this function get called from", "What does this function do?", "Rewrite this function as-is with better variable names", "Make a document outlining the structure of this project", or "Review this PR and watch out for any places that may be lacking the fix" are all reasonable things to ask of an AI.
When you're in a big project and aren't sure where this is supposed to go or how things get A from B, AI can be extremely helpful.
curt15 16 hours ago [-]
> So "Where does this function get called from", "What does this function do?", "Rewrite this function as-is with better variable names", "Make a document outlining the structure of this project", or "Review this PR and watch out for any places that may be lacking the fix" are all reasonable things to ask of an AI.
Nit: not all of those questions require statistical language models. IDEs like IntelliJ have been adept at syntactical queries and refactors for many years using purely deterministic data structures and algorithms.
dale_glass 15 hours ago [-]
Certainly! There's more than one way to do some things. Of course things like renaming are all well supported by pre-AI tech. But you do run into situations where LLMs are very helpful.
Like if you have some code that's been intentionally obfuscated, or made by somebody who names everything "a", "b" and "c", a LLM is likely to be of at least some help.
And yeah, you can do things like finding all the places where func() is called, but a LLM can also be helpful in saying where something needs to be done, which is a much fuzzier task.
skydhash 14 hours ago [-]
> LLM can also be helpful in saying where something needs to be done
Usually, If you don’t know that, you shouldn’t modify the system either. Just because you know how to unscrew a bold, you shouldn’t go about removing the head cover of an engine. Locating the area of interest takes a lot less time than actually understanding how it integrate, the guarantees provided by other systems and the guarantees that it offers.
Modularity in software architecture. By reducing the links between parts of the code, it’s easier for someone else to navigate the system and answer these questions. But it does require careful design and caring about the code. This and other things is what the engineering is about.
dale_glass 14 hours ago [-]
Everyone's got to start somewhere. Ideally you'd want to start from documentation and a mentor explaining everything, but sometimes you don't get that. The previous dev is long gone, the docs are clearly insufficient, or it's a dead open source project you're resurrecting. Got to make do and fumble around until you get stuff working.
In my own projects I'm also quite capable of forgetting stuff. Double checking with a LLM whether I forgot about one of the more obscure corners doesn't hurt.
KellyCriterion 17 hours ago [-]
So you are uploading all the source from your "big project" into OpenAnthroogle's solutions?
In which sector is your company active where this is allowed? Or do you run on your own infra?
dale_glass 17 hours ago [-]
In a sector where the source code ends up in a public github repo anyway.
Yes, I imagine this is trickier in more sensitive applications, but I'm sure this isn't a new concern. AWS has Private Cloud, surely you can get a LLM with whatever assurances a more sensitive project needs at this point. But in my current environment that's not really a concern, so I've not personally looked into it.
le-mark 19 hours ago [-]
> I hope there is a resurgence of indie software like existed in the early 2000s.
I have the opposite view. Why would anyone build and sell software now when anyone can one shot anything? Genuinely interested in people’s thoughts.
Kiln6125 16 hours ago [-]
Have you truly one shot something you use day to day? I find that getting to the "long tail" can happen exceptionally fast these days, but I am continuously tinkering and honing (with positive results mind you) at projects that are MVP level. MVP is close to one-shot, but of course I don't think many of us tend to use "minimum" products day to day. Now the focus shifts to maintaining and building out upon that foundation.
Which is to say, the form of your statement I'd agree with is: if anyone can make an MVP in a few days, what use is an MVP?
jmathai 15 hours ago [-]
I have. Others use it every day as well. I wrote this at 45 one shot prompts but it’s now at over a hundred.
A church is going to pilot it to 450 people. Some people actually do find it useful.
That's... Not what one shot means. If you break it down like that then anything can be one shot and then it's meaningless
jmathai 15 hours ago [-]
For me, writing code was always just a means to building something. I enjoyed the intellectual challenge of coding but it wasn’t why I did it.
I agree that the ease at which it can be created feels a little…how do you say it…demoralizing.
In the long run, I don’t think this will be a net positive. But in the scope of this conversation about absolute productivity and code quality I seem to disagree with a lot of HN.
KellyCriterion 17 hours ago [-]
Because as a company you want to concentrate on your core business process and not want to become a software company:
A company usually wants support / integratoin / maintenance / updates / new features etc. - for sure there will be some companies building 100% on their own, and yes I guess this number will increase but I do not see any mid-level company or above replacing Oracle or Salesforce or Microsoft with their homegrown solution.
quantum_state 15 hours ago [-]
If technical debt is assessed and revealed as part of financial audit, it would create economic pressure for enterprises to take technical debt seriously. Given software is a key component of almost all enterprises, GAAP should be enhanced to include technical debt as a line item in the balance sheet.
mejutoco 17 hours ago [-]
Why would anyone buy bread when anyone can make bread?
Kurtz79 17 hours ago [-]
I have been struggling with the same thought for months.
The value added by commercial software will have to be much higher than what it is now, or most companies will have little reason not to code their own, fully customized to their own needs.
But it is really hard to imagine what the future of software will be, even in 2/3 years time. We live in wild times.
ModernMech 16 hours ago [-]
For a lot of software, probably that's not something you can make money on by selling it anymore.
But the fact AI has made things easier for most people doesn't mean the barrier to entry has been lowered to 0 for everyone. My mom could probably use AI to write a compiler but first she'd have to even understand what a compiler is.
And the fact that some apps can be made in one prompt doesn't mean every app can. I've been working on a fully AI generated project for 8 months, it's taken billions of tokens and continuous prompting. The amount of human time spent on this project is just as much as I'd spend before AI, just now the project is much larger in scope. So even if some people have the ability, they still might not want to spend their precious human time on it.
ngc248 21 hours ago [-]
Coding with LLMs is like what they were telling about self-driving cars, you need to keep your hands on the steering wheel always ready to take over. On one of our recent projects, we decided to allow the AI to do everything, we had setup an AI constitution, a good set of instructions etc. The code would start out good, but would veer towards a bug ridden ending, this happened 3 times. also the LLM kept saying it updated, when it hadnt etc so many issues. the best way to use these is you define the structure and skeleton yourself and ask it fill in the code. even then the code written is too complex and readability is low.
cyclopeanutopia 20 hours ago [-]
[dead]
adventured 12 hours ago [-]
There were three really hard parts to creating software for other people.
1) Knowing what to build, keeping the design appropriate, not over-engineering the spec, not prematurely optimizing, et al. Note that this is different from just having an idea about a product.
2) Making it.
3) Getting people to use it. Nobody gives a shit about your software. Getting them to even try it is extraordinarily difficult in most cases. Selling is hard work. This will get a lot more difficult.
#2 has had the difficulty dialed back in many cases. In exchange #3 will increase drastically.
Absolutely nothing has gotten easier net. If anything the total will become harder net, the difficulty of acquiring users will get harder beyond the extent to which making it gets easier - users will trust software even less in the future, and the popular AI systems (personal agents or whatever they end up being called) will reduce the amount of software the typical user ever needs across a lifetime (narrowing the market).
9rx 13 hours ago [-]
The even bigger problem is hardware constraints. We have already done just about everything the current hardware is capable of (that we can think of). Only small potato problems that we didn't consider important before remain. AI can help complete those, but it isn't going to receive much fanfare given that it wasn't considered terribly important to begin with. Unless you live deep within a niche, you're never going to notice.
When AI solves hardware design, then we might see some new room for software again.
cookiengineer 14 hours ago [-]
> And there has been strictly zero progress on this and IMO this isn't something LLMs are structurally capable of doing.
Totally agree with this.
I see the future of what an IDE is more like an "architecture designing interface" which designs tests, architectural decisions, type systems, and contracts between components. Tasks then should be delegated in their implementations to agents so they are just responsible for the "wiring parts together" tasks.
Currently I imagine it as something similar to how workflows are usually designed around strong types and schema validations in safety-critical areas like ASPICE, Ada Spark, etc.
That's mostly why I don't use existing agentic environments and started earlier this year to experiment with my own one, where I try to enforce the design and architecture related tasks through capabilities mapped on tools for each of the task-scoped roles involved.
barbariangrunge 2 days ago [-]
Blow argues software development hasn't advanced much since the early 2000s. As a game developer, I want to offer a counter point.
In the last 3 years, there have been a lot more indie games of far higher quality than we used to get. I'm thinking of the RTS space right now. The Scouring for example. We went from having nobody but Blizzard able to make something that complex to several games with outstanding performance and complexity, often with their own custom game engines that are not only working but working better than I remember wc3/sc2 working at launch.
I don't know how much of a role AI is playing in those games, but I think the performance and complexity of indie games is shooting up and we are seeing very, very small teams make things that large teams struggled with in the past. Honestly, I think indie studios are outperforming AAA in most ways besides spend and length and art budget --and yet, it's the indies who are making their own game engines these days, isn't it?
(btw, we have to also admit that many of these game engine builders look to blow for inspiration (to carmack too), and their architectures are not what you'll find at typical saas companies. Game coding is complicated in a really fun way I didn't get doing plumbing on web projects, speaking for myself)
corysama 1 days ago [-]
As far as the coding user experience that I have personally observed, game programming peaked with the team developing NBA Inside Drive 2004 for the Xbox.
Their workflow was:
1) Arrive at work. Get coffee. Fetch latest code from Visual Source Safe.
2) Turn on Xbox. Hit F5 to build, deploy and start debugging on target.
3) Edit and Continue C++ in debugger IDE all day on target without ever bothering to stop the game. (Yes, this took some coding discipline to maintain.)
4) Turn off Xbox and go home.
Between the Visual Studio debugger and the Whole Tomato coding assistance, it was easy to understand the code and the runtime behavior. For anything GPU-related, Microsoft Pix for Xbox gave you a scrubbable timeline of every action, every pixel, every register change in the GPU while drawing a frame.
The hardware capabilities, available libraries, and artist tools have increased tremendously since then. But, the coding experience has not. 20 years later, I'm outside of gaming and I find most people using re-run-and-printf debugging for professional development. Even locally. I don't know how anyone gets anything done.
The only significant improvements I've seen in 20 years (besides the occasional memory tracker or profiler tool) has been AI agents and reversible debuggers. Otherwise, it's all been downhill since 2004.
explodingwaffle 19 hours ago [-]
it drives me insane that good tracing profiler tools are basically confined to certain niche domains and/or are insanely expensive (or some weird cloud based shit). instrumenting programs (printf or otherwise) is dumb as hell when all desktop usermode (and even most embedded chips worth coding for) have the capability of instruction level trace. tools have sweet graphical timelines and stuff and it's killer.
basically, all programming should be writing requirements as a custom level for Shenzhen I/O
bob1029 18 hours ago [-]
VS 2026 can be purchased on a perpetual basis for $500. They will email you a license key you can write down on a piece of paper and use forever.
Vtune is free for personal use. Superluminal is €60 for personal use. Pix and render doc are also both free for commercial use’
More people should use them!
rererereferred 17 hours ago [-]
Maybe someone should artcraft the good debugging tools.
LugosFergus 1 days ago [-]
I haven’t used it personally, but I always heard that VSS was a complete train wreck.
Gamedev programming probably hit a low point for me when XBox One and WiiU came around. Those were some truly awful experiences.
maccard 20 hours ago [-]
We still use perforce which is a mess but the reality is that you spend 2 minutes a day interacting with the tool, it doesn’t matter if it’s shit. Even now as a lead, most of my time is in swarm (reviewing), and I don’t care about all the jank that comes with P4.
I actually think git and the DVCS madness is a good example of complexity for the sake of complexity. Ending up in a detached head state through a seemingly normal series of commands, and then being able to continue working and have a very difficult resolution (compared to how you go there in the first place) that requires you to know how git works is a perfect example.
On the flip side, again in P4, you get latest and that’s it.
clhodapp 20 hours ago [-]
Detached head is neither scary nor hard to recover from. Heck, you don't even NEED to recover from it. You can just push you HEAD straight to a remote branch.
maccard 19 hours ago [-]
In order to do that you need to know what a detached head is, what head is (and when it’s something different) and that you resolve that.
It’s just not possible to end up in that state with something like P4. My current company has >1000 people, most of whom are non-technical (artists, designers) pushing every day, and even when I worked at places with 30 people, the amount of time I spent training people on “click get latest revison, and double click to submit” was absolutely dwarfed by “I followed the git setup instructions but I can’t push my changes”
StilesCrisis 17 hours ago [-]
In 2026 none of this matters anymore. "Claude, why can't I push my changes?" "Claude, the repo is saying something about detached HEAD, how do I fix it?"
Or even: "Claude, push the PR and sync git"--it's more than happy to take that off your plate.
markus_zhang 16 hours ago [-]
This might result in some very messy situations. I never dared to ask AI to do git for me. I did ask for help but I had to double and triple check.
Most of the time I simply remove everything and start from a clean slate.
It’s not only that. You also need to understand the concept of merge, squash merge and rebase, and the difference among them.
I admit I never dabbed into the internals because I was not very interested in git. I’m interested in other stuffs such as the OS kernel.
I do think it is the wrong tool for most people out there. If you are not doing 1,000 people distributed development there should be a different tool for source control. What my team does is 95% “one developer owns the changes of one or more files and others don’t touch them” type so it is rarely a true distributed development, in the sense of multiple people touching the same systems at the same time. However, I haven’t surveyed the landscape of version control. Maybe I should at least inspect the other big names.
svnt 15 hours ago [-]
> This might result in some very messy situations.
It doesn’t. Claude is far better and faster at this than anyone I’ve met in person. And you can work in any part of the source as though you were working alone, with all the numerous benefits of git.
Why would you not just try it on a disposable repo instead of continuing in fear? The thing about git is it is actually very very hard to do something that destroys anything because it is distributed. Make a repo. Clone it to two places. Do whatever you want including things that force push and overwrite history in origin. Then restore it from the other repo you cloned.
prmph 10 hours ago [-]
> Clone it to two places.
Failing to do this is not "very, very" hard
StilesCrisis 14 hours ago [-]
If you haven't tried it, you're not in a position to speculate.
I have been letting Claude drive git/P4 for months and it does an impeccable job. With git in particular, it can't even screw up too bad; old hashes would save your bacon in a pinch, and they'd always be in the transcript, but it doesn't matter because Claude just doesn't struggle at this, not even a little bit.
6 hours ago [-]
maccard 13 hours ago [-]
I’ve not used Claude to resolve an issue with git (I use perforce) but my experience with asking Claude to resolve p4 issues is that it goes down a huge rabbit hole and doesn’t solve the problem. I think it’s an artefact of a proprietary tool though
SleepyMyroslav 10 hours ago [-]
I may offer anecdata on Claude and P4.
I asked it to prototype some code and move what it generated into separate header and source files. In the process of doing it Claude decided to move every edited file from the workspace into its own CL. Then it noticed that something was up and tried to put everything back. I found the part of the comment from Claude suggesting that I may go recheck that it managed to put everything back to be hilarious.
Just my 2c, I guess Claude is really comfy with tools that are mostly used in training and not old monster systems like P4.
jayd16 10 hours ago [-]
Git's issue is not that DVCS is bad. Its just that P4 workflows work better for binaries.
Git LFS is tacked on, Git's locking support is crap, the culture of git is not to build helper plugins like P4 so no one does it.
Distributing P4 to multiple offices is a pain in the ass and it really does need a lot of hardware to keep things going.
Maybe Epic's Lore will shake things up and we get the workflow in a nicer backend. Still, sane defaults and control is also something wanted so, to your points, Lore is not a DVCS
maccard 6 hours ago [-]
I’ve no comment on lore, I haven’t used it.
> Git’s issue is not that DVCS is bad. It’s just that P4 workflows work better for binaries
I think that git is a good DVCS, but that a DVCS is way overkill for most forms of software development. The complexity that is paid for that is paid by every single person who uses the tool. I don’t think it’s binaries, I think it’s the centralised workflow is just better for many/most teams. I can count on one hand the number of times I have worked with multiple remotes, or pulled from a teammate’s branch without going via a forge.
> Git LFS is tacked on, Git's locking support is crap, the culture of git is not to build helper plugins like P4 so no one does it
Could not agree more here.
> Distributing P4 to multiple offices is a pain in the ass and it really does need a lot of hardware to keep things going
Understatement of the decade! It’s an absolutely enormous, completely unfulfilling task. IIRC, we ran 3 edge servers and an extra pull through proxy at my last job for 100 people, and we spent about $6k/mo on the hardware alone on AWS.
haileys 18 hours ago [-]
> that requires you to know how git works
Professionals should know how their tools work.
maccard 13 hours ago [-]
A few years ago I was working in a company and I posted something like this:
I am an app developer. Our front end is a C++ application (a game), our backend is a dotnet application. We also have an admin portal. A single feature, including deployment touches C#, C++, JavaScript, opentofu, AWS, windows, Linux (maybe macOS), docker, MySQL, redis, caddy, git, bash, plus all of the libraries and individual tools they call through too. Every single one of those has its own quirks and sharp edges. If I spent my working hours (40h) knowing each of those tools to a professional level, I wouldn’t have enough time to work on the app.
vinyl7 13 hours ago [-]
That means the application in total is way too complex, and could be pared down by orders of magnitude.
maccard 12 hours ago [-]
It’s a backend, game and web portal that runs in a container with a database and a cache. Everything else is “incidental” complexity that just comes with running an app.
markus_zhang 17 hours ago [-]
Can’t delete so edit out.
mejutoco 17 hours ago [-]
Your arguments are very confusing because of the mix of some, most, and all, and the jumping between them.
> few professionals know what ALL of the tools
> developers use (some or most)
> not all of them know
If you are a professional you need to know your tools, in any discipline. It does not matter what most or not all do. If you do not know your tools, you are not very professional.
17 hours ago [-]
svnt 15 hours ago [-]
This is what argument from existential fear looks like.
mecsred 14 hours ago [-]
No its what basic professionalism looks like. No engineer is going to try and do the job of a PLC by manually switching 100s of electrical connections a second. The PLC is a useful tool. If you work with an engineer that tells you "I dont need to know how the system works, the PLC manages that" , theyre not going to be an engineer for very long.
svnt 14 hours ago [-]
Sorry I meant the argument parent was responding to and confused by, not their argument. I realize it was unclear.
mrkeen 19 hours ago [-]
Git is designed for a distributed situation. Different coders spread across time and space.
You always have the ability to try out the simple version that ignores that reality:
* Don't branch
* Always force-push to master.
maccard 19 hours ago [-]
Neither of those work if you work with one other person.
svnt 15 hours ago [-]
They work as well as perforce.
maccard 13 hours ago [-]
I disagree. Perforce requires you to be connected to the depot (ignoring reconcile offline work because that’s a break glass feature), and allows you to check in when you are not synced to latest. It forces you to deal with file level conflicts at time of update, not at the time of submission, and the intermediate state of “I have local changes that the remote/server doesn’t know about” is considered exceptional rather than the norm.
I can count on one hand the number of times I’ve had to reconcile offline work in the last 18 months, which is the equivalent of every merge commit in git.
jayd16 10 hours ago [-]
Reconcile is far heavier of an operation than a scan.
You can use Git LFS locking or other side channel things to get file status tracking to work in Git but its a slog. You can usually find something for your engine of choice though.
maccard 6 hours ago [-]
Right but reconcile is a “break glass and use in case of emergencies” tool. It’s definitely not ideal that every tool has to speak p4, but in practice that just means my editor needs a plugin.
If you use git LFS, you turn git into a centralised vcs but still pay the pride for it being a dVCS. If you use a side channel, you’ve gone way off the deep end IMO.
P4 has many problems (not least the $1700/seat/year cost) but if you can stomach that plus having someone maintain it (which is a real job, and someone has to do it), I think it’s way more suitable for pretty much every company out there, particularly in games. It’s not purely the best, technically the best, designed for modern use, but it has the best failure modes. I could (and have) sit down with someone for 15 minutes with perforce and shown them what to do and probably have them go for 2 years without another question on it, even if they’re not a programmer. It’s excel if git is a relational database.
10 hours ago [-]
jayd16 10 hours ago [-]
P4 has file locking and automatic file type locking on checkout to prevent conflicts. It honestly goes a LONG way and the games industry is built around that tooling.
barbariangrunge 1 days ago [-]
how so?
LugosFergus 1 days ago [-]
The biggest issue with XB1 is that it felt like a massive regression compared to 360 development. We were forced to use this Windows 8 stack that came with all sorts of warts: “managed” C++/CLI, confusing manifest files, complicated app lifetime rules, only push deployment initially, limited threading control.
For WiiU, Nintendo used the Green Hills compiler. Their entire toolchain was simply clunky and unstable. You had to use this MULTI debugger which often didn’t work. My favorite line from their dev docs was “c++ not fully supported”. Well, that’s an issue since we used that extensively. It wasn’t even clear what actually wasn’t supported.
flohofwoe 22 hours ago [-]
> I haven’t used it personally, but I always heard that VSS was a complete train wreck.
It was, but then it was just a version control system. Back then version control wasn't as 'intrusive' into the whole development workflow as git is today. You interacted with version control exactly twice a day: once in the morning to get the latest state, and once in the evening to commit the day's work.
mattmanser 17 hours ago [-]
You’re forgetting the running around the office trying to find the guy who’d checked out the file you desperately needed to edit.
For you young’uns, old source control used to work like that. To edit a file, you checked it out, no-one else was allowed to edit it until you’d finished.
markus_zhang 15 hours ago [-]
I read about that in Showstopper. David Cutler made a phone call to a developer who went to lunch without releasing the file he checked out.
I do need to inspect the other big names of contemporary version control tools. Maybe they are more suitable for small teams or individuals.
corysama 1 days ago [-]
Visual Source Safe was definitely an unserious source control system. That part was kindof a joke... It technically got the job done for a small local team. But, it would be laughed out of town if it was made today.
senderista 23 hours ago [-]
I certainly didn't know of anyone at MSFT who used it.
aaronbrethorst 23 hours ago [-]
I worked adjacent to the team that maintained it. they certainly didn't use it either, and were very clear-eyed about the issues with the product.
KellyCriterion 17 hours ago [-]
> Whole Tomato coding assistance
This was far before Copilot and it was the superbest extension for VC++6 & up.
skydhash 1 days ago [-]
I like REPL, but you can be quite fast with a Edit-Compile-Run cycle. But that require settings a test harness and have the run phase be a test run. It's not as fast and experimental as an REPL, but can be quite nice if you know the test cases for your code.
maccard 19 hours ago [-]
The parent and this thread are talking about game dev.
> if you know the test cases for your code
IME, most gameplay code is not tested, it’s done by feeling. Quick iteration cycles on feeling, is super important, and most of these sorts of projects have 30+ second boot times (way longer in the days of hard drives instead of SSDs)
ben_w 12 hours ago [-]
> 3) Edit and Continue C++ in debugger IDE all day on target without ever bothering to stop the game. (Yes, this took some coding discipline to maintain.)
Similar experiences but with Java and Eclipse: editing code while it's running is amazing. And yet, far too often, since moving on from Java to Swift, even with the "proper" Instruments, the actual best I've had has been debug-by-print in much slower cycles... and sometimes not even that, when things went wrong in SwiftUI I might as well have been an ancient Roman haruspex reading entrails for all the good it did.
And at the time, everyone was complaining about Eclipse.
whizzter 15 hours ago [-]
That was pretty much my experience developing a PS2/Dreamcast game in the 2000-2001 timeframe when working on the PC build, the _REASON_ I did so was because the PC port ran on 3dfx and that crashed the OS every 2nd-4th start so restarting was painful, being able to edit-continue was a godsend.
That said, still using debugger driven development and edit-continue to this day and marvel at the lack of experience of people touting Lisp or Erlang or whatever as the only places in the world with some kind of hot-code replacement.
armchairhacker 1 days ago [-]
Live coding is making a comeback. I predict it for 2027. LLMs can and have made hot code loaders for any existing language, and make trivial the nasty bugs that used to plague JIT developers (like broken stack frames).
soniczentropy 1 days ago [-]
LLM can even make its own language then hot load that one. I've been using it to build a game engine with its own scripting language for the last few weeks and the AI is absolutely astonishing at wielding it. Part of its integration testing is exporting screenshot dumps and comparing them pixel-by-pixel vs what it expected. It's been weeks since the scripting language had any issues hot reloading
sarchertech 1 days ago [-]
I think the majority of the improvements come from 3 places.
1. Hardware advancements mean that you can get the same results with less optimized code (this is what allowed 3rd party engines with GC scripting languages to become popular)
2. The proliferation of learning resources and open source code.
3. The budgets and size of indie studios as well as total time spent on the games. Seriously look at some of the games these days that get labeled indie.
Warcraft 1 (my first RTS) had just 4 programmers. And only one of them was on the project the whole time. And the entire project was only 14 months.
crabmusket 22 hours ago [-]
> having nobody but Blizzard able to make something that complex ...
> Warcraft 1 had just 4 programmers
This to me sounds like the market for games has changed, such that larger projects are now more viable. Smaller projects with a handful of people may still be viable, but look tiny in comparison.
One of my favourite games of that era, Thief, also had a very small team.
ModernMech 15 hours ago [-]
Hold it right there, taffer!
latentsea 1 days ago [-]
Warcraft 1 was one of my favourite games from my childhood. Probably took me 14 months to beat that one level I always got stuck on.
KellyCriterion 16 hours ago [-]
>Warcraft 1 (my first RTS) had just 4 programmers. And only one of them was on the project the whole time. And the entire project was only 14 months.
<
Nice but this isnt even the half of the story:
According to ChatGPT, the whole team was "32 people in professional roles", so 8x times of number of programmers.
And that ratio even became extremer in the last decades.
jarjoura 2 days ago [-]
The indie game bar being higher is the result of the tooling being easier and more common.
spankibalt 22 hours ago [-]
That and more veteran talent, including laterals, ending up in the freewheeling spaces (giconomy burnout, enough personal financial stability, crowdfunding, alternate publishing/work-life models, etc.)... including access to their knowledge and experience.
fallingbananna 1 days ago [-]
But can't we then say that software engineering *has* advanced, when the tooling has improved?
ragall 1 days ago [-]
No, because the quality of the tooling and the output they afford hasn't changed.
lukan 19 hours ago [-]
I have now a tool that can go through my codebase and find and fix bugs even without guidance. Implement any features I want, answers any high or low level questions I have about the code.
Doesn't mean the tool is flawless, but if that ain't a new quality I don't know what is.
ragall 15 hours ago [-]
It's fast crap.
lukan 13 hours ago [-]
But it works.
ragall 13 hours ago [-]
It doesn't.
lukan 7 hours ago [-]
By what metric?
Mine are (for game developement), adding new features, while FPS stays stable. Well, they even improved and the tests still passes .. so it does for me. Sad that it does not for you. But can it be, that you do not want it to work as your identity is tied to manual programming?
ragall 5 hours ago [-]
I think your identity is tied to feeling "modern".
lukan 5 hours ago [-]
Nope, it was always about getting stuff done. The programming part I sometimes enjoyed, but I never done it for the sake of it, but to produce.
But you do you.
barbariangrunge 1 days ago [-]
Yeah, the engines help a lot with rendering, physics, and scene/level building/making custom tooling, and a bunch of other things. They are honestly amazing tools.
AAA and indies now use the same engines for the most part
In game dev however, there's a lot fewer reliable open source tools around. You have a game engine, a small number of great plugins, and a lot of dodgy stuff. You have to/get to make a lot of things yourself.
The scope and complexity of indie games, even allowing for this, is still increasing staggeringly.
...and don't get me started on unreal engine physics and pathfinding issues, or rendering bugs in unity
saberience 1 days ago [-]
Yes, AI tooling.
Indie games didn't get THIS good because of Unity and Godot, if you think that you're deluding yourself.
I've done amateur and professional game-dev and Unity and Godot existing don't make making an FPS any easier than before, engines have existed for a long time.
A solo dev can create (from scratch) an FPS engine, assets, music, levels from scratch over a weekend now.
This is only possible with AI.
mjr00 1 days ago [-]
Which good indie games, specifically, are you talking about here?
There's been a lot of good indie games recently (Queen's Domain[0] being a recent example that's taken off) but I don't know of any which are using an AI-coded engine or use AI-generated assets extensively.
If we exclude AI art assets from that criteria, wasn't AI also used for coding in Mecha Chameleon, which recently achieved big success? Quite a few games have AI code in them. I know of a Korean game company too. It's just that labeling yourself as having used AI is marketing-negative, so it hasn't become widespread.
Just recently, someone used AI code to fix a Unity engine bug and hand-wrote the rest, and it still caused a huge uproar. It's a world where honestly disclosing that you used AI code is not a good idea.
mjr00 1 days ago [-]
I'm not talking about using AI to help code, which seems obvious, the parent commenter is talking about people building game engines and assets from scratch in a weekend. Meccha Chameleon was built on UE5[0], and Big Walk (the game you're talking about where the devs solved a bug using AI) is using Unity. Both of these games, I believe, took longer than a weekend to create.
This is a bottom barrel dev practice that is exacerbated by AI, not something that AI is causing. People noticed this trend over a decade ago and it's been getting worse even before AI-image generation:
>A solo dev can create (from scratch) an FPS engine, assets, music, levels from scratch over a weekend now.
What does "from scratch" even mean when using an LLM trained on existing assets, music, art and code? Why even bother with that parenthetical? No one believes an LLM creates ex nihilo like God.
Show me the AI generated game that's superior to Balatro, or Hades, Or Undertale/Deltarune? Cult of the Lamb? Expedition 33? Factorio? Kerbal Space Program? Ultrakill?
It not being easy means it requires actual effort and skill, and effort and skill are where the quality comes from. No one is ever going to care about whatever vibe-coded slopfest you had Claude shit out over a weekend. Being able to make low quality low effort shit quickly is not better.
mlinhares 1 days ago [-]
I lived through:
* before and after rails;
* before and after js UI frameworks;
* before and after scaled machine learning;
* now before and after LLMs;
And saying we haven't advanced much is wild.
pjmlp 20 hours ago [-]
When I compare Electron with Delphi and VB, we have regressed by light years.
And for the pixel perfect complaints, it only shows lack of care to not have learnt how layout managers work.
jazzypants 13 hours ago [-]
This doesn't feel like a natural comparison to me. Electron isn't completely oriented around a visual RAD builder like either of those frameworks so it kind of sounds like apples and oranges.
pjmlp 13 hours ago [-]
On the contrary, Electron is for Web developers that don't care enough to learn about native GUI coding.
Managing it would be the right meaning for fullstack.
xandrius 11 hours ago [-]
Oh yeah? However little you enjoy Electron as a philosophy, I'm not really sure you've ever had to maintain different codebases for different types of machines, let alone OSs.
Electron and you throw your website basically into anything and it works.
pjmlp 10 hours ago [-]
My dear I am into computers since 1986, we had plenty more operating systems and hardware architectures to worry about when trying to write some form of portable code.
Both ways up in snow and without boots.
flohofwoe 22 hours ago [-]
Software of the early 2000s pretty much looks the same as today, quality has typically even regressed. Busy-work around the development process doesn't automatically result in better software.
troupo 18 hours ago [-]
We have veritable supercomputers, and most software is as sluggish or more sluggish than in 2000s.
There are some local improvements, but overall software is just as shitty and buggy as 20-30 years ago, and most of it doesn't do anything different
xxs 15 hours ago [-]
The simple observation is that you're very young, if the js/rails the beginning of time.
jayd16 21 hours ago [-]
Is anything in this post based in reality? Blizzard was never the only RTS maker.
Indie games get released but how are you measuring such that they're outperforming AAA?
It sounds like you're saying more indies are in there own engine instead of Unreal or Unity or Godot or Roblox etc...
Are any of these takes sound?
kcatskcolbdi 23 hours ago [-]
SC2 worked flawlessly at launch, what are we talking about?
dustbunny 12 hours ago [-]
I'm a senior game developer at a large company. I work on the core of an extremely widely used game engine.
Jon Blow doesn't have sufficient experience in using LLMs to talk about it.
This is evidenced by his focus on individual anecdotes on AIs failure to deliver something.
I would love to talk to him about this as I have fairly concrete evidence of the insane productivity gains one can get with smart AI usage.
Also would love to hear Ryan J Fleury talk about Tim Sweeneys statements on LLMs.
How long until RADDBG is primarily used by Claude? How long until Ryan is told he must support this? How long until he claims he was never against it?
dustbunny 12 hours ago [-]
There are tons of absolutely cracked S Tier game engine engineers who are doing amazing stuff with LLMs.
Jai, zig, radbg, box3d, sokol, stb, sdl etc will simply be assimilated into the new world.
Jon can choose to stay in his shop on the corner hand crafting artisnal idealogical computer programs, or he can join us in the frontier and enjoy accelerating power over machines unlike any time in history.
That's up to him.
Old dog afraid of new tricks? A tale as old as time. Especially a well fed dog like Jon.
3 hours ago [-]
sorrywhat 6 hours ago [-]
Still waiting for any remotely tangible results from this unprecedented productivity gain.
sick_of_slop 3 hours ago [-]
[dead]
fuussssip 1 days ago [-]
Jonathan Blow is one guy. He made a couple pretty good games. He's not particularly visionary when it comes to software development. Or perhaps he is visionary but it remains to be seen if his vision for technology is really material.
He regularly denies the use of new technology that is genuinely useful, and is a fairly conservative dude (I mean in the non-political sense. I do not know his politics. He may be a conservative politically as well, but that would be independent of the point I'm making.)
I've worked with many engineers at many different scopes. Big companies, indie darlings, web services, games. Games is always the last to adapt, always the last to think that anything they didn't invent is worth their time. Blow has experience in that domain, and is colored by working in it, but I don't think he knows what's happening on the bleeding edge very well.
bellgrove 1 days ago [-]
The problem with Casey and Jon is that they have tunnel vision and can think only in terms of video games and the problems in that space. Their view is even more skewed in that they've worked in relatively small teams, to my knowledge.
ivanjermakov 18 hours ago [-]
> they have tunnel vision and can think only in terms of video games
We need more content creators focusing only on their field of expertise. I don't care what Jon and Casey think about React or big tech or coding interviews. But I find their gamedev experience and insights valuable.
bellgrove 17 hours ago [-]
I agree! They make some great arguments, but they’re also very opinionated and make a case for software engineering in general, not just video games.
Some of us have to work with several forces outside our control; a batch of new interns every summer, a tech stack you don’t get to choose or rewrite, or reorgs. Games also have a very different business model; they usually don’t have to constantly ship revenue generating features or products from early on.
I just find that many of their critiques are impractical or suboptimal applied to other industries or domains.
suoloordi 1 hours ago [-]
I think they are both brilliant programmers, but their arguments about software in large tend to be quite naive and arrogant. They do not have much knowledge on building the kinds of software outside their own domain and therefore they do not understand why they are built in the way that they are.
sarchertech 1 days ago [-]
> Their view is even more skewed in that they've worked in relatively small teams, to my knowledge.
They’ve both worked on AAA games before.
bellgrove 17 hours ago [-]
Casey has had massive impact on the AAA space, no doubt. But I think most of that comes through RAD Tools which was a relatively very small team of incredibly smart, high impact people. Blow has made some contributions on AAA titles but I think most of his career has been spent on smaller indie titles.
I’m not trying to discredit them, I’m just saying that it’s not like they’re AAA veterans who have shipped many titles from start to end, in that particular space.
sarchertech 17 hours ago [-]
Jon worked on Oddworld: Munch's Oddysee, Deus Ex: Invisible War, and Thief: Deadly Shadows.
Before that he founded a 14 person game studio in the pre dotcom era. Back then that was a decent sized team.
Casey worked on Dungeon Siege.
They were also very involved in the AAA community. And after 3 AAA games the vast majority of high impact devs would have moved into leadership roles or started their own studios.
raydev 54 minutes ago [-]
With respect to their resumes, you're saying neither has worked on a AAA game or a AAA-game-sized-team in 20+ years?
bellgrove 16 hours ago [-]
The point I was trying to communicate was that most of their career was spent operating in an environment different than what some of us operate in today. I wasn't going after the _calibre_ of games they worked on but rather the environment; team size, investor/business expectations, scale of production, etc. Having worked in games myself around this era, I've experienced first-hand how different working on a title like Oddworld or Dungeon Siege is compared to a Cyberpunk or Assassin's Creed.
sarchertech 15 hours ago [-]
> Having worked in games myself around this era, I've experienced first-hand how different working on a title like Oddworld or Dungeon Siege is compared to a Cyberpunk or Assassin's Creed.
Cyberpunk was released 20 years after Dungeon Siege, so I don’t know what you mean this era.
Also Thief Deadly shadows had close to the same size dev team as Assassin’s Creed and a similar budget.
If you’re trying to make the claim that he doesn’t have much experience in modern $500 million dollar games. Then sure because they didn’t make $500 million games 20 years ago when either one was working in AAA gams.
bellgrove 14 hours ago [-]
I worked in games from 2006 to 2014 on titles that I imagine are similar in scale & production to Oddworld or Dungeon Siege to something more like an EA or Rockstar flagship title towards the end of my career in the industry. On the latter end of my career we had dedicated build/release teams, dedicated mocap technicians, networking/multiplayer teams, international/distributed teams, finer-grained tools teams, dedicated DLC teams, etc. We had interns, we had to prepare for more media appearances, etc. It was a completely different environment. Again, I'm not trying to disparage the games they worked on, my point was the environment in which they were created.
I admittedly don't know firsthand what Thief or Dungeon Siege were like but you can see the difference on Mobygames; these both have ~250-300 credited in total versus Assassin's Creed (and "only" the 2007 version) which has ~900 — it only goes up from there. This is not a rock solid comparison but it's probably a decent proxy to describe the scale of production. You could maybe argue that a title like Assassin's Creed had a bloated team, but as an IC that's not really in my control.
But in more concrete terms what I mean is that in the Dungeon Siege/Oddword environment, sure I could have maybe said to my team — I'm going to rewrite "x" because it's not efficient enough, and then go heads down for a while and try to solve this problem. I didn't have that same luxury at the other end of the spectrum. On a smaller team I could maybe say — hey, I think we should drop C++/OOP because of "reasons", and have a somewhat realistic chance of persuading the team. This was unlikely to be taken seriously at your EA/R* type company.
Beyond the games industry I'm not going to be taken seriously suggesting to my big tech employer to rewrite everything in Rust instead of Java because OO is evil or it's non-performant or whatever. As far as polymorphism and clean code go, I sometimes find value in leveraging these if they make sense. I may anticipate some persistence-layer migration in the future or feel defensive about the next few intern project and want to try and have some sort of guardrails to limit their blast-radius. Virtual functions are non-performant, Jon or Casey may argue, and they'd be right in their respective domain — but it's not really applicable in mine; even if I were to theoretically drive _my_ service latency down to zero, my end-user would notice no difference as most of the latency is spent on downstream services. Etc, etc.
fuussssip 22 hours ago [-]
As a contractor though, yeah? At least in Jonathan's case?
sarchertech 17 hours ago [-]
Sure but I’ve worked as a contractor myself and I’ve worked with hundreds of them. In most cases there isn’t much of a meaningful difference in their experience.
fuussssip 14 hours ago [-]
Not in the AAA studios I've worked in. Contracting was a very different experience.
cma 7 hours ago [-]
If Casey can only think in terms of games, why did he end up being so right with respect to that MS Windows Terminal team? I guess games have terminals and font rendering, but shouldn't it have been their bread and butter too? They were doing something like one draw call per character or as many draw calls as a AAA game from not that long ago.
A terminal needs to be efficient for people on laptop battery power, MS's would burn your battery down fast and slow down commandline tools.
bena 1 hours ago [-]
If you look further into that, he wan't "so right". His refterm didn't even work correctly. There is no virtue in being wrong fast.
simooooo 7 hours ago [-]
Casey never stops talking. Just hot air.
vinyl7 14 hours ago [-]
The thing is, they're right in that regard. Video Games are the most complex kinds of software one can build. You have to be able to perform a significant amount of complex computations within 16ms per frame. Meanwhile, most apps take several seconds or minutes for a button action and they think it's okay, or taking several minutes for an app to open to reasonable.
So the problem is this dissonance where video games can perform complex computations in <16ms but all other apps seem to take minutes to do barely anything at all. So they are right to compare software to video games because there's no reason for everything to be as slow and bad as it is considering what video games are able to accomplish.
fuussssip 3 hours ago [-]
[dead]
gunslinger_meta 1 days ago [-]
A guy who made his own programming language because C++ sucks for game development but everyone was saying "eh, it does suck but it's the best we have", and then made a blockbuster by using said programming language, is not a software development visionary? What are you smoking?
bena 1 days ago [-]
"Blockbuster" is stretching it.
On steamdb.info, Order of the Sinking Star has 1830 players right now, 2404 over a 24 hour peak, and 8247 all-time peak last month which was when it was released.
It is just beating out Cuphead, which released in 2017.
slopinthebag 1 days ago [-]
it outsold the witness's entire launch year in a week, and holds a 96% score on steam. in terms of puzzle games it is by all accounts a blockbuster.
fuussssip 23 hours ago [-]
[dead]
thunderfork 6 hours ago [-]
I don't have a horse in this race, but I see this "ah, steamdb" thing all the time and it confounds me. Why do people refer to player count as though it's meaningful? How does bringing up the long-tail player count of a successful thing tell us anything about whether something else is successful?
We all know that games aren't priced by seat-month like JIRA, right?
bena 1 hours ago [-]
The game released just last month.
While steamdb isn't a concrete sales number, it does tell us something about the game. A game cannot have more players than sales, we know that. It can tell us how many people are playing the game, which is indicative of how many people like the game.
Estimates put it about 150K copies on the high end.
To contrast with actual blockbusters. Ocarina of Time sold 5.2 million copies in its first few days. GTAVI has already sold over 12 million copies. Meccha Chameleon is also sitting at 12 million. Balatro is also in the millions of units sold, with close to 7000 players playing it right now on Steam.
KingMob 24 hours ago [-]
How do we know the success is because of his new language?
It seems to me, Blow is a wealthy independent dev, who's talented at making games, but has little time pressure and little interop needs.
Maybe his new language brought him personal satisfaction, but had nothing to do with his game's success.
throwawaybackag 22 hours ago [-]
Excellently put. On the surface, there is absolutely no reason the game couldn't have been made in any language.
incrudible 16 hours ago [-]
Any language? Like what? C++ has terrible metaprogramming and build times. Rust has terrible build times and you need to wrap your head around it. C# has GC. C is barebones.
I firmly believe that you should settle your approach to metaprogramming first, on any major project, and for me none of the off-the-shelf solutions ever were preferable to "just generate the code" (JAI probably won't be any different here). Then, once you build all the tooling to be able to iterate as quickly, you basically have your own language and standard library anyway.
throwawaybackag 15 hours ago [-]
Yes, C#, C++, Rust. Even Javascript. They may not be perfect, they have flaws... but the game could certainly have been built in any of them. Blown just didnt want to, for ideological reasons, which is his decision. Look at the complexity and sophistication of modern AAA games... none of them "needed" a language built from scratch.
Etherlord87 5 hours ago [-]
> but the game could certainly have been built in any of them.
Of course it could, after all, it could be built in any Turing-complete programming language. But you wouldn't say that he could do it in assembler, right?
Have you played The Order of the Sinking Star? Pretty much the first thing I did in the game was inspecting how the game operates and wondering why would he need a new programming language to make it. Making something in a new programming language is by default harder, because you have no existing ecosystem (unless you can make bindings or otherwise easily port something to your language), so why even make a new programming language?
While I can imagine a piece of software where this is more clear, the ridiculous complexity of the Order of the Sinking Star is a huge hint: perhaps his language is so much better at iterative development, or level design (e.g. a level editor or a fast compilation time), or debugging, or some kind of structure defining, that achieving the same result in another, existing programming language, would only be possible theoretically, but in reality it would take more time, more workforce, or the complexity of the design, multiplied by the complexity of implementation in another programming language would produce an overall complexity too big for a single human to comprehend, requiring separating the game world into isolated parts with clearly defined, simple and boring portals between them.
I may be exaggerating, but the idea is, he was making a video game, he was annoyed with the programming language he was using, so he made a new programming language to deal with the annoyances so that the programming language helps more and gets in the way less.
You mentioned Rust, well JAI has already better game portfolio than Rust...
incrudible 8 hours ago [-]
A far worse version of that game concept could have been built in Javascript (which you can't even run at speed on consoles because they don't allow JIT), but that's not this game.
Modern "AAA games" cost 100 million dollars or more. Of course if you have an army of developers paid by the hour, maybe iteration speed doesn't matter, maybe the subjective experience of software development doesn't matter. But "AAA gaming" would never produce a game like this in the first place, so it's a moot point.
incrudible 22 hours ago [-]
I would argue that if you hate working in a certain environment, you will not do as good a job as you would have otherwise, and also that quality and success are at least tangentially related.
KingMob 18 hours ago [-]
This is very true, but it means Blow should not advise others, because most people don't hate their tooling enough to invent a new language.
incrudible 16 hours ago [-]
Clearly they hate their tooling enough that there is a proliferation of build tools, frameworks and other utilities to make work more palatable, and if you haven't at least dabbled in designing your own language, you missed some sort of crucial step in your development as a programmer. If anything, not everyone has the time and energy (and hubris) to actually follow through with it on a major project. I don't think Jon advised anyone to do what he did, it's a massive gamble. If you're that type of person - contrarian and self-directed to a fault - you can't help but do what he did, you don't need or will accept anyone else's advice.
erikpukinskis 23 hours ago [-]
He went into debt to finish Sinking Star.
KingMob 18 hours ago [-]
That's interesting to know, but doesn't say anything good about whether he needed a new language for it.
Maybe he just values doing his own thing more than money? Which is fine!... but not proof anyone else should take your advice.
Jtarii 11 hours ago [-]
>That's interesting to know, but doesn't say anything good about whether he needed a new language for it.
Some people just like making things they thing are good? He thought cpp was bad, and didn't want to program in it anymore, so he made something different.
Obviously the guy isn't optimising for making the most amount of money possible.
komatar 14 hours ago [-]
It's a simple sokoban game, based on 4 existing games. And the development took a decade and then language still isn't released. I'll believe in his vision when other developers will release games using it, or even the engine he claimed will be opensource.
duggan 20 hours ago [-]
Writing a language is one of the famous yak shaves of game development.
What’s impressive is that he succeeded despite that. The man must have a fire in him.
jayd16 21 hours ago [-]
No one uses Jai. He shipped and that's always nice but games are full of stuff people made to scratch an itch.
The difference is Blow can and does post some good flame bait.
Tiktaalik 10 hours ago [-]
It was actually also pretty common for game devs to make their own languages to make games, so it's not too remarkable. Yes usually this was for scripting but still. PS2 era Naughty Dog also wrote their own game dev language.
nnevatie 21 hours ago [-]
And where is this language for us to try out and see? Oh right, nowhere since it's not publicly released.
fuussssip 23 hours ago [-]
[dead]
Animats 1 days ago [-]
Because AI coding has only worked well in the last six months. Two years ago it sucked. A year ago it was flaky. Now, Claude nails a lot of problems routinely.
What will next year bring?
phony-account 22 hours ago [-]
What I don’t understand is how different people using the same tools - even with the same skills and codebase - can get such different results? At the company I’m at, one team has gone all-in on ‘blurring roles’ and ‘mob-programming+Claude’. The management are loving this of course - but the code they’re producing is convoluted, over-complex, spaghetti, and often even contains subtle (and not so subtle) bugs. The code smells are everywhere: it’s all very much over-eager junior level.
The changes always come in monster one-shot PRs ofc - too much for a human to read - so I just feed the branch to my Claude (identical to the one they’re working with) and after some thought it will give me 15 to 30 suggestions of what needs fixing.
I’m still not understanding why this happens?
ozgung 18 hours ago [-]
> I’m still not understanding why this happens?
Because it’s an infinite loop in essence. There are always things to improve. There are always things to fix. There are always bugs in software. There are always more cases to check. There’re always better ways to do things.
You can add new code indefinitely with diminishing returns. Each addition introduces new bugs. So after a point it may become negative returns.
As human engineers we make tradeoffs. We prefer simple and clean over more complete but bloated.
Without a stop condition Claude can “improve” the code indefinitely.
Tazerenix 17 hours ago [-]
Two different developers who are better or worse at prompting and picking up architectural or design issues mid-turn when using agents will see vastly different productivity gains and tech debt levels.
I had the same question as you but I believe the difference is within the process not the models. I used two rules that helped me a lot:
"List every file you need, read them in one pass, make all edits, run tests once."
It stopped the read,edit,read,edit loop.
The second was a stopping rule I added :
"After two failed attempts at one symptom, stop editing and get a diagnosis first"
22 hours ago [-]
cj00 15 hours ago [-]
My company just deployed Claude using Bedrock where they can see all prompts and all commits. It should be relatively easy to take that and evaluate which teams are using it successfully and who's just spinning their wheels. Hopefully some organization out there will do this not just for firing people but for some legit research.
benjiro29 17 hours ago [-]
There is this false economy with "o, LLM can not find a lot of bugs in X software, that means human code better"... Overlooking that this software may have had 10, 15, 30+ years of non-stop issue being reported and fixed, by a ton of people.
So when a LLM writes new software and the LLM sweeps keep finding a ton of issues. Yea, but the LLM wrote that code in a few hours, what may have been weeks of work. The sweeps its running is finding things, that may have taken years to remove as customers report issues.
Combined with LLMs tend to "over find" issue things that we will never bother with as human written code. We may say "too trivial to fix, not a issue", ... bla bla but for a LLM its a issue to fix, so it looks like LLM code has more issues.
And while we may pat ourselves on our back for finding X bug that created data loss or a crash, there is probably a dozen high to medium bugs hidden somewhere to be found by the customers (yikes!). Where as LLMs then to reduce that vector after a sweep to barely a few medium or low items.
This is what i always need to tell people. LLMs are not just doing the work of humans at a 10x faster speed, they are also solving bugs and other issues what may have taken years for humans to iron out, what a LLM does in maybe a 24h bug hunt session.
it’s all very much over-eager junior level.
You have not seen the over smart senior dev that tries to one-liner everything. Or that makes code so complex, that its a "job secure" feature because nobody else can figure out what the ** is going on.
I noticed that there is this perception that medium or senior devs are the panicle of coding, and good practices when most are not. A lot of are simply restrained because companies force specific coding standards and left to their own devices, they will love to run amuck. Remove those handrails and your going to see code that makes most LLMs blush. lol
after some thought it will give me 15 to 30 suggestions of what needs fixing.
That simply means that your collogues never bothered to run a bug hunt sweep after their work. If they did so, just like a human dev writing something and having the work checked by another dev, this will have been reduced a minimum. People seem to have this thinking that LLMs need to write perfect code from the start, when its trained on our human code, with all its issues. Just like if we wrote code manually, and then somebody checks the code before pushing and committing it, do the same for LLM code.
!!! LLM do not mean that good coding and deployment practices are suddenly useless !!!
10 hours ago [-]
pjmlp 20 hours ago [-]
Because they aren't producing any code, their onshore AI juniors are.
This slope is hardly any different had they gotten an offshoring team at the lowest bid.
le-mark 18 hours ago [-]
This onshore/offshore analogy also offers insight about ai adoption and effect on the economy. Offshoring wasn’t the big win many companies projected precisely because of increased oversight and rework ie “friction”. The effect on white collar jobs will be similarly hollowed out. Pundits claimed offshoring bred more higher level jobs, maybe ai will too; but they won’t replace what will be lost. Near term offshoring hubs will be most affected as the work they’re doing has already been “automated” away.
pjmlp 18 hours ago [-]
I have been involved with projects having offshoring or nearshore teams since 2010.
The only jobs that were created were at their locations, at the expense of local teams.
zelphirkalt 19 hours ago [-]
It is a split in people's ideas about quality, I guess. The mob + Claude pad themselves on the shoulders, "it's finally working!", "let's get this merged!", "what's the holdup?". The person needing to review applies hopefully their own criteria, ideas and experience to reviewing and deciding, whether what Claude tells them to fix will truly be better.
globular-toast 22 hours ago [-]
Some people aren't good at programming. Previously they were incapable of producing working code for any significantly complex feature. So there was a kind natural barrier of what could be submitted. It's similar to how I can't stand up and ask a question in a forum about micro-behaviours in albatross colonies: I have no idea what I'm talking about and this would be immediately obvious to the experts.
LLMs are designed to circumvent our ability to tell who knows what they're talking about. Our fundamental intuition about computer programs - garbage in, garbage out - has been broken. Now everyone can sound the same. But those who do know what they're talking about understand it's just a tool, those who don't think they're like Neo and just learnt kung fu.
2muchcoffeeman 21 hours ago [-]
That doesn’t really explain anything.
I recently reviewed a large PR from a decent developer. I wrote some of the requirements after meeting with stake holders and did my own investigation on potential solutions.
The PR was full of bugs, missed half the requirements and the code that was there wasn’t even fully tested.
This person has successfully delivered complex things before. So what the hell? And this is not the first time I’ve thought their usage of agents and conclusions from ai assisted explorations were not right or could be better.
There’s still some weird human element. Though I’m noticing that responses are getting better with less “prompt engineering” so maybe this will all be gone soon.
duskdozer 15 hours ago [-]
LLMs can speed up top-down thinkers, especially those who didn't later drill down to understand the details. Bottom-up thinkers are hindered because the LLM use takes away the info that actually helped them understand and solve problems. This is one source of the discrepancy of positive opinions and perceived productivity boost between some devs and especially between managerial types and devs.
Was this a developer who has been forced or pressured to use LLMs?
I know that should that time come for me, I'm not going to burn myself out wrestling to make something good.
2muchcoffeeman 8 hours ago [-]
No pressure from the company. If anything, everyone is willing to experiment with the tools. And everyone is using it slightly differently. But I may not be feeling what everyone else is feeling.
But there’s certainly no standard approach on how to use these things. It’s very much a YMMV situation.
globular-toast 21 hours ago [-]
Good developers are suffering from two things right now: pressure to "deliver" using the tools the same way as bad developers (ie. not thinking or understanding what they're doing), and depression caused by seeing their craft reduced to the skill level of a 6 year old. It's quite possible your colleague just doesn't give a crap about software any more.
grim_io 19 hours ago [-]
Maybe he phoned it in for that one PR. AI makes it easier to get a barely-pass without giving a fuck.
samat 14 hours ago [-]
Try checking with a model from a competitor, say OpenAI, they have different blind spots. Very useful
troglodytetrain 15 hours ago [-]
Generally I think this happens anytime you try to use too much compute/inference at once. It happens to me everytime a new model comes out; I get excited and want to see what it can do.
You have to carefully manage the project scope, and catch the ai getting stuck. There is a stars aligning point where you are matching the model to its scope on a clearly defined goal to iterate towards and its mind-blowing. And then if you go even a bit over that point it's perf falls off a cliff.
And it changes with each model with each new release.
For example, I wasted a bunch of usage today giving Fable 5.2 8 sub-orch opus high agents that each were given bunch of chatgpt subagents. It was fun watching all the churn, and I'm trying to find some way to use up all my openai usage.
But in the end I made much less progress/made a bunch more slop code than if I had just narrowed project scope and gave fable a smaller easier task with less agents under it. And now my weekly usage is gone in 2 days.
IshKebab 21 hours ago [-]
Maybe there is a skill in using AI? I dunno, I'm with you. It's very easy to get good results today.
christophilus 16 hours ago [-]
I think some people don’t review the code as they go along, and provide no architectural / quality guidance. That turns into a coin toss regarding whether or not you get a good solution.
My experience has been good, if I get the project off on a good path, with clear principles, patterns, and practices that I want to see enforced.
hansvm 20 hours ago [-]
> why this happens?
Different tasks, different tools, different prompts, or different ability to evaluate the results, likely some combination of all of the above.
- Tools: I can't get the ChatGPT web interface, with any prompts, any models, any amount of retries, with any combination of settings, to respond to a coding task with anything other than <snippet ignoring multiple explicit requirements for what should be a 20 SLOC task> <here's how you make it actually prod-ready (often stating that it just refused to implement something I asked for)> <paternalistic essay about how I shouldn't use my vibe-coded URL parser to send a man to the moon>. The underlying models are a fair bit better. Fully controlling the system prompt helps a lot. Agentic flows paper over a lot of those deficiencies. Anthropic models (and web interfaces) work a lot better for codegen for me out of the box. Agentic flows make that delineation much sharper.
- Tasks: I don't like the concurrent data structures LLMs write. Its opinions about the novel pseudo-probabilistic algorithms I care about are wrong. The level of hand-holding I need to get proper matrix codegen is insane. It works extremely poorly when operating at a meta-type level and trying to design a cohesive API. But, if you're not doing those things, who cares? I vibe-slopped a new programming language yesterday just to try it out with a new harness I previously vibe-slopped. At this stage, it doesn't have to be correct. If I get it kind of working just a little and think the results look promising then I can do better later if I want. A lot of companies are in (or at least think they're in -- IME this mentality bites founders much earlier than they expect much of the time) that stage.
- Prompts: LLMs are much more sensitive than you might expect to minor variations in prompts. The classic example I hope everyone knows by now: There are precious few scenarios where your interaction with an LLM should be a very long session repeatedly telling it the mistakes it's made. Almost anything else is better, up to and including (as a bad solution but still better for codegen output than the baseline) still having a very long session but asking the agent to rewrite the previous messages as if it had succeeded and then having the person manually edit the conversation.
- Evaluation Ability: Really? You thought +3k SLOC was the best way to solve that feature? I have a whole SOTA event loop and multi-processing framework in 3k SLOC, and when interacting with most companies' codebases you really ought to be deleting code with the average feature you implement, not adding code. Like you said, the code smells are everywhere. Like, slop is fine from time to time (easily 30% of the code I write for work is slop, largely because it serves one-off tasks), but some of the people pushing it just can't tell the difference. Just a month ago, somebody (outside of $WORK) was showing off a fancy new UI feature on some geo-rich project. It had a small bug. The implementor said they knew about it. The problem is that "if you know you know," and the only reasonable way the code for that kind of feature should have that kind of bug is if it has major problems which just aren't surfacing much in this particular demo. I suggested a couple alternative test cases to optimize toward, and a week and a couple rewrites later it was in a much better place. There were tens of thousands of tests before I made that suggestion, dozens of times the LLM confirmed the system was working as intended, and on and on and on. None of that matters if you need to build something that works and know that it works. The tests were all shit, as were the false assurances.
If you're looking to make it better, there are some tweaks you can make to your CLAUDE.md or what have you to help a bit. I have a lot that I do to make mine generate passable code without requiring constant human intervention, but something it responds well to is (1) pinning down what you care about re abstractions, and (2) giving it explicit permission/guidance to spawn sub-agents to make that happen. A lot of the problems with LLM-generated code are fixed if you fix the abstraction issue, and many of those fixes are relatively "mechanical" checks you can apply:
1. When reading the name of an abstraction, do you have a good idea of what it does?
2. What about the name and signature?
3. Does the implementation match that intuition?
4. Does any part of the codebase reach past the intended abstraction?
5. Does your code require nonlocal reasoning? (side-note: this is very important for humans, but it's more important for models since their harnesses aggressively try to avoid bloating context windows, so it's quite common that if you need two lines of code far apart in a file to relate to one another then you'll see downstream bugs)
6. Do all of the abstractions pull their weight? Are they all even used?
7. Is it possible to delete 80% of the suggested code and have an equivalently working product?
8. Do existing abstractions/conventions solve the problem you wrote a new abstraction for?
And so on. You obviously can't compress all good engineering judgement into a brief model context window, but you can get a lot more than you might expect. Whatever it is that you see agents doing poorly, try to come up with a general principle you think it should try to respect, and write that down for your future projects.
vmg12 1 days ago [-]
Be careful extrapolating. Do you actually understand why coding agents have gotten better?
Animats 23 hours ago [-]
Actually, I don't know why. Does anybody know why, other than the model is bigger? They've definitely improved. Throwing billions of dollars and insane amounts of compute at the problem seems to have helped. Amazingly, the "bitter lesson"
seems to continue to apply.
viraptor 23 hours ago [-]
I don't know if this is what parent alludes to, but they improved a lot from the collected exchanges. Lots of what developers have done got filtered into training data of what's expected. (That's why xai got so much better after buying Cursor... or Cursor's data to be more precise) Also a lot of synthetic tests that resemble known benchmarks.
visarga 22 hours ago [-]
Environments with millions of coding problems and graders. They solve problems to learn to code, not just learn to predict the next token as they do in pre-training.
mungaihaha 15 hours ago [-]
My experience has been that they excel at problems with solutions that are cheap to verify. Things one can unit test for example. Easier to RL. Architectural issues are harder to train for because the training data is dominated by tutorial/toy projects. There's 10,000 toy compilers for every LLVM
slopinthebag 22 hours ago [-]
agressive rlhf to bias towards massive test suites and verification loops is my guess. after literally every change claude runs the entire test suite, sometimes multiple times, and generated test code well outpaces generated impl code.
llm's are only good for closed systems with robust automated verification loops, which makes me doubt it's general applicability. at least for now, humans seem much better at navigating domains without an easy way to verify systems.
visarga 22 hours ago [-]
RLHF is only tweaking the LLM to be more "well behaved". You wanted to say RLVR (reinforcement learning from verifable rewards). I know because I am building such RL gyms for computer use.
fredoliveira 22 hours ago [-]
> RLHF is only tweaking the LLM to be more "well behaved"
Not quite right - RLHF is about aligning with human preferences (because it trains, as the name implies, on signal from humans). This does not necessarily correlate with behavior. We use RLHF across any number of domains and with any number of goals, not just alignment.
RLVR is a (more recent, better in some cases) way to automate the training loop without the human being involved, because you give the model a way to verify its own results and train on that as a signal.
slopinthebag 22 hours ago [-]
sure whatever, you get the point :)
i remember a year ago i'd have to tell the llm to use the bash tool to compile to see failures. these days, for every task it
1. throughly inspects git history
2. runs the full test suite to get a baseline
3a. for each change, runs (a subset if i'm lucky) the testsuite
3b. writes about 3 billion lines of tests, including tests to test tests
4a. uses the harness's screenshot tool to check each visual change
4b. for webapps, spends several minutes poking at it with some kind of browser devtool
5. runs the entire "smoke test" suite, which often takes several minutes and regularly interrupts my keyboard focus
6. runs the full test suite at the end
even small changes take at least 10+ minutes to complete, but with much higher accuracy than a year ago.
to me these things are dumb but persistent, useful but not intelligent.
adwn 22 hours ago [-]
> to me these things are dumb but persistent, useful but not intelligent.
Then you have a very uncommon definition of the term "intelligent", because that's roughly what I would expect an intelligent, conscientious developer to do. Many, many bugs stem from developers who believe themselves to be too "intelligent" to need an extensive test suite.
slopinthebag 21 hours ago [-]
i would expect someone who can write good code in a single pass to be more intelligent than someone who requires multiple tries.
same with anything else really. a better chef can nail a dish in one or two attempts, whereas a worse but persistent chef might take 100 attempts to achieve the same quality.
or likewise, i'm not as good as a basketball player if it takes me 100 attempts to nail a three pointer when an nba player does it 35% of the time - despite both of us eventually achieving the goal.
iainmerrick 21 hours ago [-]
I’m with you on this. LLM coding agents are incredibly fast, persistent and knowledgeable, and those are all really useful. But they still make a lot of stupid decisions. Without a feedback loop they just go wild. They write tests, which is a form of feedback, but without direction they just grow vast jungles of pointless tests, while the structure of the code itself gets more and more tangled.
dwh452 17 hours ago [-]
Maybe the LLM is smarter than you give it credit for. Maybe the LLM is intellectually humble and self-aware enough to know that even a small code change can easily break something it hadn't thought of.
program_whiz 17 hours ago [-]
The "bitter lesson" being that you need teams of dedicated scientists, engineers designing increasingly better training to squeeze more out of existing compute? I love how people think bitter lesson was just "oh we added one more GPU and now the model is better than our hand-crafted approach". When really its just the opposite -- models with better approaches were necessary, and models at 10% the size are showing nearly identical performance when some attention is paid to quality. The "savory lesson" is, don't listen to the bitter lesson, it was only true when the 'hand-crafted features' experts were using were vastly over-aligned to human superstition, but if the priors are well-aligned mathematically, it really does help to have a better strategy (and more compute may not help). The reverse-bitter-lesson every trader and investor knows: throwing more compute can often give worse results (e.g. memorization), not better.
intended 20 hours ago [-]
I wish I knew which factor had the most impact on coding performance.
The harnesses have improved and I suspect there’s a decent amount of logic pushed there.
Models are larger, so the generalization that happens is better.
Lots of effort has been put towards training on coding tasks.
ModernMech 15 hours ago [-]
As far as I can tell, a large part of that has to do with throwing them into loops with tools which give them feedback and ground them in reality. They still hallucinate but when they do, the feedback calls it out and they correct themselves quickly.
CapsAdmin 1 days ago [-]
My experience lines up with this.
Last year, the frontier llms could produce working code, but the code looked brittle and overly defensive. Earlier this year, it got better and started to take more of the codebase into account. Since Claude 5.5, the quality improved substantially.
A lot of these things could be improved with prompt engineering and steering, but much less so nowadays.
But I don't think code quality is easy to measure, so the best we have is people's experience.
chii 23 hours ago [-]
> Do you actually understand why coding agents have gotten better?
most people also dont understand why their cars are safer (over the decades). But they still know it to be the case.
Of course, back in the 50's an 60's, they extrapolated that we'd have flying cars today, so you're not wrong to be careful about extrapolating...
globular-toast 22 hours ago [-]
They haven't got significantly better since August 2025. What's happened is people's standards have gone down and brain atrophy has set in. We're just winging it now.
pmg101 23 hours ago [-]
I personally do not understand and I'd love to know.
Certainly in 2024 I did not foresee AI coding ending up as reliably good as I find it in recent months.
I'd like to have some understanding of whether this improvement is likely to continue or we've reached plateau.
latentsea 1 days ago [-]
RLVR? Next RLCR?
80fj0348i 1 days ago [-]
Do you understand why rhetorical questions make for poor commentary?
noodletheworld 1 days ago [-]
Come on, don’t be a potato just because you don’t like someones opinion. The parent posts point is obvious and not rhetorical at all.
It’s more reasonable to extrapolate based on past evidence than arbitrary conjecture.
Self driving cars are great!
…but fully autonomous (level 4+) driving turns out to be really much harder to do that the initial 6-12 of self driving demos suggested it would be.
Its always easier to get the first prototypes and demos up, and its literally ALWAYS wrong to extrapolate exponential improvement based on that initial set of results.
It should be a surprise to no one that AI coding follows a diminishing returns log curve, and that improvements are merely incremental after the initial burst of improvement.
CamperBob2 24 hours ago [-]
Coding is a technical problem. Self-driving cars are a political problem.
margalabargala 24 hours ago [-]
Right, we've had trains for over a century!
CamperBob2 10 hours ago [-]
Ironically, even self-driving trains are a political problem. How stupid is it that we still have train wrecks like this one [1] every so often? Obviously a solvable problem, but humans still insist on being involved for some reason. See also ATC.
> The parent posts point is obvious and not rhetorical at all.
I am still not sure what their opinion or point is, because they vagueposted instead of telling us.
vmg12 8 hours ago [-]
My point was that you should be careful extrapolating and that past performance and changes in performance don’t guarantee a trend. If you understand why the past improvements happened and you can explain why they will continue you can extrapolate accurately.
juped 1 days ago [-]
I consider this comment spam at this point, because it's been repeated for years.
kragen 13 hours ago [-]
It means something different when John Nagle says it than when some random person says it, but also I think your memory may be faulty.
audunw 18 hours ago [-]
I think you’re just lying. Where did you hear this? Some randos online? Years, really? Years ago LLMs couldn’t even program at all.
Every person I’m meeting in the real world who use agents have roughly the same experience. About a year ago they started working reliably and the side projects where we played around with it started seeing actual results.
About 6 months ago I started seeing colleagues and friends all around the same time saying that LLMs solve real problems for them.
For my own case, I’ve replaced years of sloppy spaghetti code in our internal tools and services, from a bunch of engineers many of which has left the company, with code that’s objectively better quality and more coherent (though docstrings and tests tend to accumulate garbage, so cleanups are necessary eventually).
DustinBrett 1 days ago [-]
So it can never be right?
jayd16 21 hours ago [-]
Maybe it can be but it seems like the it needs more substance, no?
intended 20 hours ago [-]
It means it can’t be given a free pass.
Repeated forever, a statement always has a chance to be right.
After a point it’s going to be challenged
testtestmetest 24 hours ago [-]
I think its more likely that llms got better at using harnesses, which help force them to make sure everything compiles/runs before passing back to the user. This caused people to form habits around this where they slowly stopped checking the output.
So people are super impressed because things just work, and they do.. Until they dont.
Just because things compile doesnt mean they're going to hold up, and most of this slop wouldn't, ive seen it first hand and you can also tell by the increased amount of outtages across different platforms.
RideOnTime22 15 hours ago [-]
If a boy always cries wolf, are you going to say "well there's a wolf we have to go get it."
catskull 24 hours ago [-]
We’ve been two years away from nuclear fusion for 50 years. Sure, at some point, maybe we will genuinely be two years away, but without a crystal ball it’s not much use to keep saying it.
Mawr 23 hours ago [-]
Terrible analogy, nobody thinks we're 2 years away from fusion, or ever has. 20 years, sure, maybe 10 even. But not 2.
As-is we're not going to get commercial fusion until at least what, 2040? 50?
rmbz 24 hours ago [-]
It was crap, it's good now is the positive equivalent of the boy who cried wolf. We've been hearing this bullshit so, so many times that no sane person would care to listen without some serious hard evidence and no your zero user vibe slop repo launched yesterday or "I'm so much more productive…dicking around the codebase but zero useful features to be seen by the user" doesn't cut it.
BosunoB 23 hours ago [-]
It's just obviously true if you use the models regularly. I don't know how anybody can come away feeling otherwise.
Dwelve 22 hours ago [-]
Ok, so NOW that the models are awesome, i assume you will drop a lot of impressive software, correct? You were not able to do that a year ago because they were bad, however, that bottleneck is gone NOW, so NOW you will deliver, right?
RideOnTime22 15 hours ago [-]
It's so obviously true until the next model comes out. Or until a non-American model comes out matching it, then it's "no one could using AI tools for coding until this new GPT/Claude model came out"
wolvesechoes 23 hours ago [-]
Through just using them. Some of us really have some expectations.
philipp-gayret 22 hours ago [-]
Could you share something that we can replicate, where SOTA models and harnesses, i.e. a Claude, does not work where say a junior or medior engineer new to your team would solve the problem?
skydhash 19 hours ago [-]
Do people expect an eternal junior engineer in their teams? Even with a recent hire, there’s a deadline to the onboarding and hand holding process. Generally after three months, you were expected to deliver with no oversight other than peer reviews. It was a good deal for the team. Spend three months teaching, and get a productive team member for two years or more.
Now it’s permanent baby sitting.
whoanoway 14 hours ago [-]
[dead]
hecanthearyou 1 days ago [-]
[dead]
mjburgess 1 days ago [-]
You'll note that as AI gets better what it gets better at is giving us what we already had: whiteboards with more customisation, games that ran on X device now run on Y, a website GUI for a old workflow app, a one-off script that does what we'd've used Excel for, etc.
We're accelerating our ability to produce mediocre software that solves common-place, mediocre problems, but with more "freedom", more customisation.
His Lordship Mr Blow, has something of an academic sense of what innovation means. He wants to see new problems being solved. A new O/S that is "secure by design" in throwing away old models of shared-CPU schedulers, and the like. I assume, new techniques in 3D game graphics. New ways of mixing compile-time/run-time langauges to accelerate development. And so on. New in the way that an academic research project should be new.
What we have from AI in software isnt anything new. Claude releases an office suite with AI assistance. We havent yet seen AI accelerate anything other than end-user programming, or lift-and-shift projects.
These might be very valuable, but theyre not innovative.
FranzFerdiNaN 22 hours ago [-]
Maybe because Claude 5.5 is the first model that’s close to a professional developer. He’s basically going “well the steam engine was invented six months ago, why don’t we have railroads across the country?”.
cowlevel 21 hours ago [-]
It was invented a year and a half ago
kragen 13 hours ago [-]
Opus 5.5 shipped on September 22. Of this year.
levzettelin 22 hours ago [-]
If one of the selling points of the "steam engine" is that it can build railroads in no time, then that would be a legitimate question, no?
kaashif 21 hours ago [-]
I do not think one of the selling points of AI is that it will come up with new, innovative ideas for you to implement.
Funny, because I remember being told the same thing six months ago. And more to the point: if AI coding allows you to conjure any software in no time and at almost no cost, why do we need to wait a year to see the results?
A year to ship is the old paradigm. With 100% agentic vibecoding, everything should be amazing now.
viraptor 23 hours ago [-]
> why do we need to wait a year to see the results?
If you use it internally in business, you don't need to wait. There's lots of stuff deployed every day and works really well. If you want to see results in public, you'll have to wait for reasons unrelated to the speed of coding. Does something actually solve a problem, is it interesting enough to be popular for you to find it, is it better than most other attempts happening at the same time, and all the usual questions related to the business side. It's going to take time for PoCs to get refined enough that they gain popularity. The second issue is that lots of projects need data in addition to the software - and that still needs to be produced manually. And finally, creating a proper public project takes effort - there are lots more single-user solutions now.
In other words, I've got new personal projects completed, I make new tools almost every week at work, but it's unlikely I'll ever release anything that users or even developers in public will notice as "new, different software". And for user-visible things, almost all the time is now taken by talking to people and writing documents.
timhh 21 hours ago [-]
> With 100% agentic vibecoding, everything should be amazing now.
At least in my company, it is. I have vibe coded three apps that are far better than the competition: an Xpra/Wprs alternative that's faster and much more reliable, an alternative to the VSCode Git Graph extension that is much faster and has tons more useful features (e.g. drag and drop to move/copy/rebase commits which is a feature I always wanted), and a Mac app that lets you use cheap MIDI controllers to control your screen brightness, volume, media playback etc.
I use them all every day and they're all extremely reliable, and much better than the existing tools. One was entirely vibe coded and the other two were unfinished projects that I vibe completed (probably 70% vibe code).
I suspect a mountain of people and companies have tools like these but they haven't open sourced them because a) I used company tokens so there's admin to get things open sourced, and b) it almost feels like there's no point... you can just vibe code your own version to your exact liking. Do you really want to use mine?
benjiro29 16 hours ago [-]
One major issue is also, the negative feedback loop on anything coded with a LLM.
The amount of posts when somebody introduces their program here on HN, that may have been LLM coded but that does not neglect the often massive amount of time the "dev" put into it. And yet, its all dismissed under this single negative "vibecoded" label.
I noticed that we are seeing more and more closed source programs, because people do not want to open source LLM generated code, out of fear that people start a negative PR loop against their program. And this reflects back to people not even releasing their programs into the wild.
There seem to be a inability of people to tell the difference between somebody spending a few prompts on making something, vs somebody spending months on 10.000's of prompts to make a great working program. It all gets thrown under that "vibe coded" bus. When its ironic because most code by now is LLM coded anyway. The amount of people hand coding is now probably a absolute minority.
retwakm4 16 hours ago [-]
Well, I think that's a bit of a shame but I can also come up with reasonable explanations for it...
Mostly, I think if you are promoting outside of your main area of expertise and couldn't have written it on your own, people don't want to put stuff out there and portray themselves as an expert in a subject matter that they relied heavily on AI assistance for, because it wouldn't be honest to other contributors to said project or other similar projects that were done without AI assistance. It would be a bit of a false representation of your own skills. That's why I am all for publishing, but also all for disclosures of AI assistance.
So, I think I'd be fine with taking a look at and contributing to "vibe coded" projects so long as the project leader disclosed their level of expertise on the underlying subject matter that the repo maintainer has and the extent of the AI assistance.
Then it may be a genuine learning opportunity for them (and for me) and more power to them and it's a shame if it doesn't get published, but I can see why socially there is a pressure not to do it, and get ragged on by the actual SMEs in the area that no doubt will be able to poke holes in what the AI came up with. I think we need those types of collabs though to upskill these new AI assisted coders into difficult types of programming though, so like I said, a bit of a shame if it never gets published and nobody that is an actual SME gives it the time of day.
I think that's actually a reason behind why the Linux Kernel has made decisions to allow AI assisted contributions by the way. I think they are trying to turn some of these people that want to be systems programmers (but at the moment can only do so through AI assistance) into real systems programmers by getting them involved and getting them mentorship. Which is I think a good thing. As long as Linus and other SMEs are there to keep a handle on potential actual AI slop, then it represents an opportunity to upskill interested people into a very not easy kind of programming. They just need to be treated fairly and disclose and get the mentorship they need to develop what I can only call "taste".
mannanj 12 hours ago [-]
I don't want to open source my code because thievery and entitlement and generally unfriendly culture towards one another, anti to the original spirit of open source, has become more prevalent.
how/why that has happened is another story. I don't see the value in giving away my valuable thinking and ideas when it isn't appreciated and this massive-theft-founded AI company culture of our time thinks it is entitled to everything we create.
[Controversial edit: I don't think of myself as a slave, no matter what others may try to convince me to believe.]
sampullman 24 hours ago [-]
I think the complexity of modern software, whether it's necessary or not, is often underestimated. There's still plenty of software you're not going to be able to build in a year, to a high standard of quality, no matter how many agents you throw at the problem.
But for me personally, the software I use on a day to day basis actually has changed drastically. I have lots of little apps and CLIs that speed up my workflows that I never had time to build in the past.
hobo123 20 hours ago [-]
Because it's not "in no time", nobody sane ever claimed that.
Maybe with capable agents productivity is increasing even more now, but building sw still takes time, even if only weeks or months instead of years.
0xb0565e486 1 days ago [-]
for what it's worth, i've been saying many more "thank you" to my ai
zamalek 1 days ago [-]
Good AI is like fusion, only difference is that AI receives funding.
tonyhart7 24 hours ago [-]
wtf is fusion do ???? except its just waste of money ??
just use nuclear
edit: get downvoted by chud
jwrallie 1 days ago [-]
> What will next year bring?
More availability issues with internet services.
RideOnTime22 15 hours ago [-]
Every 6 months AI coding "has only worked well in the last six months."
When the next GPT or Claude models come out, people will say that AI coding sucked "until they came out."
eddythompson80 1 days ago [-]
Come on now. It's been about 2 years since HN has been filled with "I've recreated GSuite last week and it's a skill issue if you're not getting the same result" comments. The more skeptical would put it at least at Opus 4/4.5 which end of this month would be 1.5/1 year old. If anything the rate of improvement in just models has slowed down compared to the change in tooling and techniques, but those also are slowing down. I don't like this continuous moving of the starting line. It keeps happening with every model
letrix 1 days ago [-]
I remember when line suggestions were a thing
pasportoo 23 hours ago [-]
[dead]
jonenst 19 hours ago [-]
[dead]
_aavaa_ 2 days ago [-]
The video does actually answer its own title, which is refreshing.
And I agree, it’s because organizations and people haven’t changed (yet, if you’re being positive) what it is they’re optimizing for and how they do work. AI gives you more of what you want and gives it faster, that doesn’t on its own change the culture or goals of a company.
ch4s3 2 days ago [-]
A thousand times this. A lot of people are discovering that coding was never the bottleneck in their orgs and don't know what to do differently.
phoghed 1 days ago [-]
Coding was a huge bottleneck in my bottom dollar offshore contractor infested company, the point where it would have been faster for me to solo projects than work managing a team of them. Their organizations are unfortunately highly optimized to entrench themselves, and no VP’s want to take what from their perspective is a risk to hire expensive onshore contractors or just let someone internal give it a shot.
AI has been a huge disruption to that status quo though because it enables people like me that were stuck managing these bozos to just do the thing on a timeline that wasn’t feasible before. AI also removed any excuses these people could make for never getting anything done. It exposes clearly for anyone tangentially involved in these projects that the devs often can’t even begin to understand the problems they are trying to solve.
With the level of detail that I had to specify things for them to be productive, it’s easier and more effective to just give that (often much less detail tbh) to GitHub Copilot or Claude.
It has massively changed the game for me and helps me enjoy my job quite a bit more.
em-bee 1 days ago [-]
Coding was a huge bottleneck in my bottom dollar offshore contractor infested company, the point where it would have been faster for me to solo projects than work managing a team of them.
so actually it sounds like coder management was the bottleneck, not coding itself.
phoghed 1 days ago [-]
Sure, management is always the bottleneck then. But somehow more coding productivity allowed us peons to outpace bad management and ultimately change their shitty strategy from India to Eastern Europe. Laundered through Accenture, wipro, et al still of course.
hobo123 19 hours ago [-]
Sure, quality matters. Many offshore devs would stumble over their own legs. Near shore was much better (Eastern Europe), local German devs even better, and if you got a _good_ dev, they'd easily code at 10x of an average coder.
So no wonder AI is a huge improvement over whatever most organizations did to code something up.
Corollary: this mostly affected "business" software. Anything interesting meant good devs were already gravitating to it, so the SW would be vastly higher quality (think many Silicon valley shops).
le-mark 18 hours ago [-]
> With the level of detail that I had to specify things for them to be productive,
It’s funny because when I managed an offshore team I did the same thing. And just like with llm I stopped looking at their code. It was a waste of time asking them to fix it because they’d just fix slop with slop. At least llms understand concurrency and don’t introduce data races!
bsenftner 2 days ago [-]
The communication skills to create the synchronized understandings necessary for teams of any moderate size to operate in concert is not there. Communications are everything when it comes to collaborations at any level, and we as an entire civilization are weak at this aspect. This effective communication necessity.
0xpgm 24 hours ago [-]
Many people are good at communicating. Perhaps not all, but many.
However, even less are good/interested at playing Machiavellian politics to get things done in work environments. The larger the workplace, the more at stake, the more likely this is how things are done.
coffeebeqn 2 days ago [-]
Also AI don’t seem to make communication better, worse if anything. I’m so sick of the whole team not understanding what is going on with Claude written docs and tickets
notnullorvoid 13 hours ago [-]
People with AI brain are painful to deal with. They take a small spark of an idea and feed it to an LLM to expand on it and reinforce their assumptions. When challenged on the details they don't have good arguments, because they never actually thought through the problem. If it's not in person communication you just end up debating with an LLM.
superxpro12 2 days ago [-]
a lot of what i do with ai is write (gasp) requirements. which is horrifying to engineers for some reason.
bsenftner 1 days ago [-]
I wonder how much of your requirements would / could be reinterpreted as a dependency graph of logical constraints. I think we may end up with "writing software" to end up being writing such logic + process dependency graphs in plain language. And by extension, given we're talking about people here, committees will form and hammering these out is the new politics.
sgt101 1 days ago [-]
it's good to write requirements,
but when you have requirements,
why not render the code to fulfil them?
ben_w 1 days ago [-]
> but when you have requirements,
> why not render the code to fulfil them?
Because 95% of the time the LLM can turn the requirements into code, faster, cheaper, and with fewer defects on the first attempt, than most humans.
CrimsonCape 1 days ago [-]
Your point needs to be emphasized more. Today is the worse AI will ever be, and it's still better than the average person. Recursive self-improvement will make it even better, maybe on orders of magnitude. When you task an AI, it will be able to walk upward abstractly to ask "is this even a good approach." AI's are good for compartmentalized tasks now, but the architectural tasks will probably be improved in the future.
bsenftner 1 days ago [-]
I can imagine the meltdown when AI starts telling its users "that is not how it would work best, consider this ____" and they rant on about their need for and constant use of their "I don't care, do what I say" clipboard loaded paste.
Pulcinella 16 hours ago [-]
People say AI is just stolen StackOverflow solutions, but in a few more years frontier models will truly be able to replicate the "Rather than help you, have you heard of the X/Y problem?" experience.
ben_w 13 hours ago [-]
I generally find they already do that, only they are better at understanding the question and intent and the solutions are better (or at least less often obsolete).
ben_w 1 days ago [-]
I'm not generally sold on the "worthy successor" or "human disempowerment would be good" arguments (seems like jumping straight to Hard Mode of alignment when we've not even read the tutorial) but this is one of the ways it might be best for the AI to just… disregard what we say and do something else instead.
bsenftner 1 days ago [-]
We'll get to a point where the best practices are to "tell AI what you want to do, and allow it to tell you how you're going to do it".
sick_of_slop 1 days ago [-]
[dead]
1 days ago [-]
jurgenburgen 2 days ago [-]
I love requirements. Slop, not so much.
yunwal 2 days ago [-]
Just because there's a new bottleneck now doesn't mean coding was never the bottleneck. It was for many orgs, and now it's probably not the bottleneck anywhere
ch4s3 1 days ago [-]
I meant specifically in many place that code was always delivered faster than the org could generate requirements or do anything useful with it, but now the volume make that situation impossible to ignore and slow orgs can no long blame code delivery for slow progress. This was never meant to be a universal claim.
sumtechguy 2 days ago [-]
That also is dependent on the company and who works there. Some companies are meeting heavy. A meeting for every little decision. Some are not. Some are paperwork heavy and you need to fill out the form to do anything. Coding is like the 4th or 5th on the list of things that get done. Handed to the most jr of devs to 'just figure it out'. Some companies are just not software companies but they have enough of it that they needed but do not care about it. They only care enough to get their hardware out the door. AI in this case only changes when software is done and how. Not all of that other stuff. Such as have you checked in today during your standup and that your story is progressing?
ogogmad 2 days ago [-]
The more code, the more worry; the more workers, the more theft; the more AI, the more sorcery; the more flesh, the more worms.
The ancients knew it all along!
barbariangrunge 2 days ago [-]
bottlenecks constantly change. every time you fix one, a new one emerges. coding is and isnt the bottleneck depending on your organization at that snapshot in time. It often was, and often was not
sshadmand 1 days ago [-]
[dead]
andrewstuart 2 days ago [-]
>> coding was never the bottleneck
What utter twaddle.
I’m old enough to remember pre AI programming and it very very much was the bottleneck.
ch4s3 1 days ago [-]
I've been writing code for a long time, and have seen time and again that a lot of problems get solved in code far faster than the organization can absorb the change. This is not universally true, but the number of times I built something in a few days or weeks and waited twice as long for half a dozen handoffs is quite memorable.
nathanfries 2 days ago [-]
I think it was indeed the bottleneck, however the assumption that "coding is the bottleneck" was baked into how organizations were measured, optimized, staffed for the last couple of decades.
skydhash 2 days ago [-]
From "The Mythical Man-month" (1995 ed)
For some years I have been successfully using the following rule of thumb for scheduling a software task:
l/3 planning
l/6 coding
l/4 component test and early system test
l/4 system test, all components in hand.
The separation can be blurred if you follow an iterative approach (also explained in the book), but it aligned roughly with my experience. And whenever I helped a colleague in the past, coding was not the problem. It was either the lack of planning (no data modelling, no rough algorithm design), or no test setup (trial and error coding). It was never the coding part. Syntax errors is trivial to solve (with any good editor) and most libraries have good reference docs (not learning the library is an orthogonal matter).
svachalek 1 days ago [-]
AI practically zeroes out the coding and component test part of the process and massively accelerates the system test. What's left is "planning" which under a modern iterative model apparently includes deployment/distribution and getting/understanding/incorporating feedback. With a fully optimized process, knowing what to build is nearly the entire problem.
skydhash 1 days ago [-]
> AI practically zeroes out the coding and component test part of the process and massively accelerates the system test.
Have this been measured, not comparatively, but absolutely? Where you plan, but don't code, instead leave the task to an agent (while you do something else), then test the result (maybe a quick look at the code), and ship. Is it sustainable? Or is it for greenfield setup and common ideas (things you would use tooling and snippets before)?
> What's left is "planning" which under a modern iterative model apparently includes deployment/distribution and getting/understanding/incorporating feedback.
That is not "planning" means. Planning is usually understanding, research, and design.
Supermancho 1 days ago [-]
That's nice, but not authoritative for ~20 years (since before VMs and AWS). This book was before CI was commonplace.
SoftTalker 1 days ago [-]
If anything, testing/TDD is a bigger share compared to coding than before. LLMs can write tests too, but it's still something that has to be managed.
It meshes with my experience. Coding was never the bottleneck. Understanding what the customer/business wanted or needed was always the vast majority of the time spent on a project. A developer might not have seen that, depending how the organization worked. If you got specs from a manager you might not have been aware that those were 6 months in the making. If most of what you experienced was writing code then that could feel like the bottleneck especially if your manager demanded frequent status reports.
bigstrat2003 1 days ago [-]
Doesn't matter. Nothing has fundamentally changed since he wrote it, because the book is more about how people act than technology.
k0morebi 2 days ago [-]
Say what you want about reducible fractions but that's a pretty nonintuitive way to describe how you divvy up time. Weird to not use percentages or a common denominator...
Taikonerd 1 days ago [-]
I think it would be funny if the fractions summed to more than 1. Like the old joke: "the first 80% of the project takes 80% of the time, and the last 20% of the project also takes 80% of the time."
ido 2 days ago [-]
> old enough to remember pre AI programming
So old enough the remember the ancient times back in 2023?
Exoristos 1 days ago [-]
Coding agent results only became generally acceptable sometime this year.
ido 22 hours ago [-]
I was being generous.
win311fwg 1 days ago [-]
Where did 2023 come from?
The Heuristic Compiler, dating back to the early 1960s, is generally considered the first instance of AI programming.
Maybe you mistakenly confused AI with a particular AI technology, like LLMs? But even then we had LLM-based code completion tools in 2020.
Is 2023 when you became old enough to start remembering things?
visarga 22 hours ago [-]
> it’s because organizations and people haven’t changed
First time they introduced electric motors in factories they just replaced the old central steam engine to drive the whole factory. It took four decades to figure out they could route electricity to each workstation and have many smaller motors.
__MatrixMan__ 24 hours ago [-]
It make take some time to replace the old companies with new ones that are not built around recently invalidated assumptions.
jazzypants 13 hours ago [-]
Can anyone help me understand why Jonathan Blow is considered a good source of information about anything? I tried watching his stream once and I gave up after thirty minutes of incel ranting about why girls don't talk to him.
Johanx64 10 hours ago [-]
Most indie developers make one hit game and then peter patter out of the scene.
Blow has aged, but he has made not one Hit indie game, not two, but whole whopping three indie hits that are extremely well received, critically acclaimed, and have sold very well, over the span of ... decades.
Almost every time basically going into debt to get there too.
His third game was the one where many had doubts if he's gonna make it to the other end, or will this game even sell, but apparently it does sell pretty darn well.
The guy is legitimately crazy, and I'm saying that as a compliment and highest form of praise.
John is a guy with extremely rare ability, persistance and ability to deliver and an insane work ethic to match. He's a rare gem.
This game definitely has left a mark on him, you can tell this one was tough to get through.
torlok 7 hours ago [-]
Sure, but if a guy with such work ethic managed to only deliver 3 games in the span of 20 years, then maybe he's not an authority on shipping software. Game design isn't software design. I've been following his blogs since he started on The Witness, and it's not like he delivers some revolutionary tech, or even had to deal with changing customer requirements or feature requests. Game development as a mostly solo developer is in many ways disconnected from the regular software development cycle. He's an artisan, wants to stay that way, good for him, but he's blowing hot air here.
verdverm 13 hours ago [-]
He's had some good talks and renowned games, but I would agree his unfiltered thoughts are meh on average
He has made 3 critically acclaimed video games so he is obviously allowed to have his opinion on software development taken seriously.
I'm not sure how his opinions about dating are relevant.
jazzypants 10 hours ago [-]
> I'm not sure how his opinions about dating are relevant.
That's how I felt when I was watching his "programming" stream.
Jtarii 9 hours ago [-]
I believe he can talk about various topics on his stream.
8 hours ago [-]
tracerbulletx 2 days ago [-]
Good supporting evidence for this is that it is changing your software dramatically if you're making your own personalized software to replace subscription software. That works incredibly well. Also there are some examples of companies doing huge swings they wouldn't have done without it like the AWS emulator that just came out.
clarle 2 days ago [-]
I think that's really the key for the most productive individuals I've met.
A lot of things that I've paid for subscription services in the past I've just replaced with personalized software for myself. It's not something I would ever release publicly for others to use because I'm sure there's a million edge cases that wouldn't work for a broader audience, but it's perfect for me and saves me a ton of money.
utopiah 2 days ago [-]
The most productive individuals were already doing that before, maybe they were "just" scripting, doing macros, going to training on how to extend their workflow. The most productive individuals didn't wait for AI to bother IT by explaining how THEIR very unique situation was special and they needed that one special tool nobody else wanted. They were already using FLOSS tools or heck even had a budget dedicated for a dev to help them precisely because they care. Nothing changed for them ... but for those who wanted to emulated them and never dared, maybe those do have now an excuse to try.
ImaCake 24 hours ago [-]
>The most productive individuals were already doing that before
Okay, maybe. So I am not a productive individual but now I also have all these "never bother releasing" projects because what was previously too much work is now 10 minutes of telegram messaging.
vconnor 22 hours ago [-]
How do you feel after putting 10 minutes of thumb dance into them now? Do you feel your programming skills have improved? Does your heart soar?
Accomplishment is proportional to effort. Skill building is proportional to complexity. All you have done is crossed an arbitrary item off a todo list.
ImaCake 18 hours ago [-]
It's quite fun actually. I like how the effort is in the design and thinking about what I actually want rather than on the barely relevant scripting (e.g. I know what I want when I ask for a linear model, but it's a faff to remember how to implement an lm in python when I only know the R syntax). Sometimes a PoC from an LLM is a great way to go "oh that idea sucked actually" or "oh I thought I wanted this but I really want to try this instead...". Getting to actually test my ideas instead of having them locked away because I have more pressing things to do is great.
catdog 21 hours ago [-]
I think a lot changed for them. Doing all this while often beneficial was very tedious and time consuming by itself, way easier now. Of course they profit even more because they've already got the habit.
guhidalg 2 days ago [-]
This is just like in woodworking and jig making. Sure you can buy a pre-made jig, but you can now just 3D print (vibe code) one that's good enough and is uniquely made for the way you work.
Does this mean that jig makers out there are out of business? Sort of, they need to sell jigs complex enough that you wouldn't want to / be capable of making.
visarga 22 hours ago [-]
> making your own personalized software to replace subscription software. That works incredibly well
My 8 y.o. has vibecoded 25 games in three.js. He went yesterday to the chess club, in the evening he made his chess game. He watches PowerPuff girls on TV, then makes his PP game. He is driving it all by duplex voice mode. He doesn't even know how to say "restart the service" yet he manages to do it. That was after seeing me do one vibe coded game for him a couple months ago.
11 hours ago [-]
dezsiszabi 17 hours ago [-]
I can imagine the quality of those games.
yoz-y 17 hours ago [-]
Yep. Me, and I believe many others, have rolled out a whole suite of software to get rid of subscriptions and have it really made to work the way I want.
E.g. I find it maddening that music players don’t keep the play position per-album, so I rolled out my own.
4 hours ago [-]
the_sleaze_ 2 days ago [-]
People just haven't figured out the tools yet.
I'm doing truly astounding - stupefying - levels of work. Others on my team are actively resistant to my advice but the C Suite isn't.
The numbers are shooting up and to the right but people don't want to get on board. It's too much too fast.
Edit. Consider your own reaction to my statement if down voting.
malfist 1 days ago [-]
Every engineer believes they are a 10X engineer. What makes thinking you're a 100X engineer with AI any different? Or any more accurate?
Recall the study done with open source devs, every one of them believed they were more productive with AI than without, yet the net effect of AI resulted in a 19% loss in productivity.
tracerbulletx 1 days ago [-]
Im going to be annoying and show you a free open source vibe coded project to make a point. The viewer part of this project predates AI, it took me years just to get the viewer to be great. I built this Video compositor in 2 days that does beat matching, keyframe animation, parameter automation, shader effect layers, masking with SegmentAnything, auto looping and a ton of other things I need when im video editing, cancelled my after effects account and doing this is something I do professionally. There is absolutely 0 chance of a single person doing that in a month, let alone 2 days, before Opus level models. Its not really cloned from anything other than my experiences doing video editing.
I agree with this sentiment, though it's a slightly odd future. I've been running custom forks of various open source software that I just customise through pure vibe coding testing it into a working solution for some custom thing I want to do. But it seems inefficient everyone doing that.
lilbigdoot 1 days ago [-]
This has been the thing that bugs me. I use LLMs a lot for everything except code that ends up on something I publish, I just keep getting burned enough when I try I stopped. Then people are talking about these 10x gains while the only research we have shows a negative effect.
I don't doubt people are 10x for certain things or things that used to be a ton of plumbing for the smallest stuff, but I'm easily 2-3x faster than I used to be because the rest of the process is so much faster now (finding information, libraries, getting answers to odd questions, builds, BUILDS). But I'm not seeing the software I use or posted here really change or zoom off like people say they are..
bunderbunder 16 hours ago [-]
It’s selection bias. It’s always been selection bias.
The “10x” developers I’ve known (and been) were all incredibly effective at snagging the work that they personally were most able to do quickly, and shirking the rest.
That’s not necessarily all the difference. But I’d estimate they would maybe be at most 2x developers if you remove their ability to avoid the proverbial 10% of the work that takes 90% of the effort.
AI coding intensifies this effect. And it also helps explain why people’s amazing success stories for personal projects don’t seem to translate to business ROI. For a side project I am in complete control over design and scope, have no customers or stakeholders to keep happy, etc. So I easily - and mostly unconsciously - tailor what I’m doing to what the coding agent can do well, and quietly drop the rest. I don’t have that luxury at work.
hobo123 19 hours ago [-]
I think I notice when I'm obviously making 10x progress of other devs in a project. I also notice when other devs are coding circles around me in another project.
Ok, maybe some people are incapable of reflection.
kaffekaka 21 hours ago [-]
Consider the fact "my team are actively resistant" and try to understand why they are. The actual reason, not the reason that flatters your ego.
benfortuna 1 days ago [-]
[dead]
hangrybear666 1 days ago [-]
And you're likely not reading any of the code and just making the Black box bigger, which is not a fact I'd be proud to announce publicly.
If you keep doing the black box approach you will be deskilled in the medium term and your input less valuable.
If you are reading the code, explain how you can do the claimed amount of work, since whenever I review output it's a huge bottleneck
> Consider your own reaction to my statement if down voting.
Down votes in reaction to comments like these are almost always due to there being no evidence shared when these claims are made. Share the astounding, stupefying amount of work you're getting done because you've figured out the tools and watch as your down votes magically turn to up votes.
tracerbulletx 1 days ago [-]
I shared some and got downvoted for that too. So I find that hard to believe, if someone wants to comment on why writing an After Effects replacement that does more of what I want in many ways like custom shaders in 2 days is not a suitable example by all means explain it to me, because I find it insanely valuable to be able to do that. If anything people don't really like people posting their AI built products because anyone can do it, it's not that special, so it kind of proves the point.
I wish I could collect these sentences of hyperbole in a little box, to revisit over the years and smile.
It’s a bit hard to distinguish them from that time cousin Mark took too high a dose of his ADHD medication.
halfcat 1 days ago [-]
> The numbers are shooting up and to the right but people don't want to get on board.
Revenue is one of those numbers, right? Right??
> It's too much too fast.
Yes, that’s exactly what being over-leveraged looks like.
“The number one indicator of fragility is leverage” -Nassim Taleb
We have one of you at my work. He’s a god, but for the wisdom.
the_sleaze_ 1 days ago [-]
Yes revenue is up 2x and might be 3 this coming week. Costs are down over 99% on certain tooling. Bugs are down 50%+ if not significantly more. Security is at an all time high. We are able to identify and patch holes in human logic in all aspects of the system, old and new.
I feel that there is an amount of hubris in saying "I understand this codebase". You may remember the highlights, but every company in the dozen I've worked for that was actually making money - the codebase was too large for anyone to know fully. A wizard with the wisdom as you so eloquently put me down with would leave. And guess what? Nothing would happen. It is only in your own mind that you are so important.
halfcat 1 days ago [-]
I agree, understanding the code does not save us. Knight Capital wrote every line of their code but it didn’t prevent a $440 million loss in under an hour [0].
Regarding wisdom, I do not mean knowledge of how the system works. That is a thing, too, where the person who built it is the only one who understands it. That’s not what I meant here.
In the examples of my coworkers, for example, I see at least two things:
1. The things they create are 90% well crafted, 30% well engineered. If they were building a rocket, every part would be well machined to high precision. Then when we assemble the rocket, we find out it’s too heavy to ever get off the ground. That’s a kind of wisdom gap.
2. They work in a way that excludes everyone else on the team. From their perspective, they are wondering why everyone else isn’t getting on board. But it’s a situation where one person understands it, and their deep understanding of it contributes to them moving fast, and then add AI and now the ground is shifting faster than anyone else can understand enough to contribute. This is another kind of wisdom gap, knowing how to get a team performing at a high level, versus an individual contributor performing at a high level.
This is where, from your perspective, you’re driving a speed boat as fast as you can, wondering why your coworkers aren’t on board. But from their perspective, they’re following your boat in their boats, but your boat is creating waves behind it and splashing water up, so their experience is a bumpy ride getting water splashed in their face constantly while they’re yelling “hey can you slow down up there?” From your perspective, it makes no sense to slow down. You’re not experiencing any problems. Yet both perspectives are still true.
The person who is charging forward as fast as possible also seems to be the one who has less experience operating and supporting systems, understanding how systems fail in unexpected ways, and so forth. Every week I have a conversation where someone tells me, “oh, I didn’t consider it might fail in that way”, and every time I think, yeah it would have been really nice if we’d had a 20 minute conversation 6 weeks ago when you started.
In general, it’s not that “other people just haven’t figured out the tools yet”, it’s also a significant part of who’s leading each initiative. I could absolutely do what my coworker does and setup my custom harness to pull off amazing stunts of productivity. I just think it’s irresponsible much of the time.
AI hasn’t solved coding, if anything it’s made code quality worse. But it’s made it the process of coding faster.
The latter is why managers love AI - and the former is why the general public hates it.
fhe 23 hours ago [-]
i think the point is that, code quality as we used to define it doesn't matter any more, that from here on code will be written, reviewed, tested and maintained by machines. for example, does human readability still matter? or modular design? why would functional programming still be a thing if machines can hold the entire codebase and all possible states of the program in its memory?
solid_fuel 22 hours ago [-]
> i think the point is that, code quality as we used to define it doesn't matter any more, that from here on code will be written, reviewed, tested and maintained by machines.
Code quality was never a one dimensional metric that just meant "easy for humans to read". Perhaps this distinction has been lost over time, or was never internalized by some parts of the industry, but high quality code is narrow in its function and design. It is well specified, with limited dimensions of variability - this is part of what metrics like cyclomatic complexity measure.
The reason for that is that the input space - the sheer combinations of possible input - of a piece of code grows far faster than the intended functionality of the code. Good code operates on a narrow space and that is important because it is both easier for humans to comprehend, and easier to test. Code that is easier to reason about is easier to validate - by humans, by automatic testing, and by LLMs.
Poorly written code is both harder to understand and harder to validate. An LLM is not an escape hatch that negates that.
LogicFailsMe 15 hours ago [-]
Isn't an escape hatch yet...
I think there is a huge amount of resistance to a near-term future where it's more about the ability to describe and specify a thing than it currently is to code up a thing in order to build it. And I suspect that LLMs or whatever succeeds them will continue improving from here without any of the claptrap about a near-term malevolent superintelligence that's out to kill us all.
The future IMO will be relatively efficient code with independent models reviewing for quality and security afterwards. Life continues to come at us fast.
notnullorvoid 12 hours ago [-]
Programming languages are a terse way to describe the logic we want, so if you understand what needs to be built well enough it's possible to write it out faster in code.
Natural language is more ambiguous so you often need more of it to describe something. Specifications if consistent often end up as a kind of programming language in themselves, but usually ambiguous on matters that affect performance.
I'm with you on the review side though. Even the best models of today give some nonsense in reviews, but if you understand the code it's usually easy to skim the review and skip over nonsense.
LogicFailsMe 12 hours ago [-]
I've been programming for many decades and I go all the way back to FORTRAN IV to C/C++ through CUDA. That said, there are tasks I can more easily describe than implement. I no longer bother resolving config issues on my machines, I let the coding agents do that as one example and then explain their fix to me.
But you are right about the efficiency of description given you have the 10,000+ hours into writing efficient code in the chosen language. Most do not. And they hide that by leaning on Python and its insane library toolchain which itself becomes its own skill set, but one more amenable to LLMs to master.
To be brutally efficient, one would write everything in machine code, no?
NateEag 22 hours ago [-]
Here's an opinion piece by a guy who at first predicted that software was over, and now argues based on his experience that software factories don't work long term, that agents need readable codebases, and that they slowly, inevitably tend towards chaotic, broken codebases:
As someone who's driving Claude Opus 5.5 daily, by corporate mandate, in a team that is largely aggressively fans of AI, I don't those suspicions match my experiences.
piker 18 hours ago [-]
> I don't those suspicions match my experiences
Was interested in your conclusion and left confused.
NateEag 12 hours ago [-]
Ugh, sorry - was typing on my phone and rushing.
I meant to write "Those suspicions match my experience."
Just two days ago I was in an incident where a bunch of feature flags my team controls, and that are very intentionally not automated, got flipped on by another team's automation.
I haven't seen a postmortem yet, but it smelled very much like genAI'd code that didn't get reviewed carefully enough.
...which is what all generated code in a software factory is, because the whole point is to have no idea what the hell the program will actually do - just what it has done in testing so far.
Talk about a perfect setup for backdoors - I'm sure there are already plenty of websites out there prompt-injecting agents to put backdoors into systems.
I'll quote Dijkstra yet again, though every time I do it I feel like no one listens to it, or understands what he meant:
"...program testing can be used very effectively to show the presence of bugs but never to show their absence."
Proving programs correct is very difficult, and only really effective if the programmer understands the program and the proof well - a coworker recently added a genAI TLA+ proof to one of our systems, but of course, no one's actually read it thoroughly or understood it, and sure enough, I saw a bug report the other day saying the model would need to be updated since it hadn't prevented the bug.
Deep, thorough comprehension has always been the hard part, and the LLMs do not do that, as far as I can tell.
They are amazing, and they are not trustworthy.
visarga 22 hours ago [-]
> why would functional programming still be a thing if machines can hold the entire codebase and all possible states of the program in its memory?
That is naive, have you seen coding agents write tests? They clearly walk the known patterns not imagine execution in all its intricacies. They do superficial testing, like humans.
I think it si time we returned to an old method - N-version programming - to replace "imagined execution" with "actual execution", and testing with fuzzing or passing prod data through a population of replicas. This is my take on AI code testing.
levzettelin 22 hours ago [-]
If you drive this argument to it's logical conclusion, why not let the LLM program in assembly? Why do most people still choose to have LLMs produce code in, say, Rust or Python? If programming in those high-level languages holds any sort of advantage, even for LLMs, then at least the quality of those languages (Rust vs C++?), and by extension any code, would appear to matter.
jayd16 21 hours ago [-]
> if machines can hold the entire codebase and all possible states of the program in its memory?
Gen AI does not work like how you think it does.
hollowturtle 22 hours ago [-]
> that from here on code will be written, reviewed, tested and maintained by machines
And very very soon you will find that you just created a self-pleasing machine not a functional system. No amount of boundaries, tests and checks can prevent that. That's just nonsense and it keeps get repeated by marketing
FranzFerdiNaN 22 hours ago [-]
The general public does not care about code quality. The general public hates it because it stole the collective work of humanity , because OpenAI and Anthropic can’t shut up about how dangerous AI is and how it will kill us all, how it’s linked to Trump and thus became a political wedge issue, and how plans for data centres suddenly popped up everywhere and people felt their needs were secondary.
ketzu 20 hours ago [-]
> The general public hates it
I believe the general public hates it because they are scared for their job (or social status? Life security? Don't know a good name).
The "public discourse" was full of "copyright infringement is not theft" slogans and arguments about how access to any form of art (especially video games and movies) should be free for everyone and how anyone making them gets paid was at best secondary.
But large scale changes with possibly immediate negative effects (job loss) is very scary and little is done to Adress those beyond "it will be fine somehow" (which isn't reassuring even if it was true).
pansa2 22 hours ago [-]
> The general public does not care about code quality.
Those caught up in the recent Microsoft outage would probably disagree.
Moreover, the public definitely cares about the poor quality of AI output in general - hence the most common word for it being “slop”.
kaffekaka 21 hours ago [-]
The poor quality output but even more the hype and how AI is both described as something that will take all jobs and kill humanity but for some reason still gets funded and forced upon people like there is no tomorrow (ironically, exactly the threat from AI).
klevo 23 hours ago [-]
My software is becoming radically different. I've been able to roll out so many tools to improve my workflows and remove pain points, or delight me, that otherwise would have taken months to build. The bottleneck is imagination and actually having real problems to solve, without those, your software world has no reason to change.
matthewsinclair 23 hours ago [-]
Agree. I feel like we’re in a Cambrian Explosion of software right now. To be fair, not all of it is good, that’s for sure. But some is. And I hope that some of the good stuff survives. I’ve done the same thing with my own tooling: things that I would have just put up with in the past are now nicely produced and open-sourced rust tools. It’s great. I’m also having a ton of fun with it all, too, particularly around tool building and scripting and infra config and so-on. Doing that kind of stuff manually in the past just sucked. Now i quite enjoy spinning a simple project to bottle a piece of drudgery into something tight and reusable.
_xxndn2321 12 hours ago [-]
There seems to be a theme with "i-am-10(0)x-more-productive" crowd. Which is that when they cite the productivity gains, they are mostly talking about disposable / non-essential software. The type of software that otherwise wouldn't exist because the cost / benefit didn't make sense before. Personal tools and hobby projects, rewrites from one language to another.
Ex1: you and your personal workflows - the world doesn't care
Ex2: DHH and omachy - I certainly don't care about another Linux distro
Ex3: myself - I vibe coded several tools and plugins that I will never share with anyone, because their external value is 0
Ex4: this web dev youtuber I follow who is now vibe-coding his own video game. His game is at best a "6/10, kinda works but not sure why anyone would play it when there are much better games". So he is living out his 100X productivity fantasy, while producing something of 0 value to the rest of us.
At work I am seeing a similar thing... Work on core features has not radically sped up, probably because alignment takes a while, but everyone is making their own single-use dashboards.
Anyway, maybe I am coping / ludditing / am a loser with no imagination. But my observations generally align with the complaint that AI has not resulted (yet) in an explosion of delightful software. Just toys and dashboards, and mechanical rewrites of well-specified existing systems (ex Bun).
dandersch 1 days ago [-]
This is now the second or third time that he retells his experiences with AI tools being 1) an excel script thing to export a csv or something and 2) predicting sales numbers of his game. I don't mean to discredit him based on that, but it would be much more interesting to hear about him throwing the most ambitious thing he could think of at a frontier model and how that turned out, rather than these ~2023 toy examples.
ozgrakkurt 1 days ago [-]
It can’t even write a moderate amount of code like a 500 line change in my experience
It can write it in some sense but I have to rewrite it. It is really good for exploration of ideas and code review for me though.
I am fairly sure he is a more conservative person than me so it is impossible he will find it useful for what you are describing.
latentsea 1 days ago [-]
A lot of the performance comes down to how you're holding it. I think that speaks to current limits and failure modes of the tech, but the results are definitely better the more you understand the failure modes and engineer them out.
I think humans are by and large just not great at this, especially in groups. I also think over the course of 2027 frontier labs will work on RL'ing harness engineering skills of the models themselves, so these systems treat engineering the environment in which they're engineering as a first class citizen since that's what makes a big difference.
Already they're doing RLCR to train swarms, so coordination is getting very good and this feeds into them being able to loop pretty quickly on code reviews and feedback without human input.
If your goal is verifiable and sufficiently well defined, and you have a strong deterministic set of constraints in place, then they can write a lot of code that's pretty usable.
From Nov 2025 to Nov 2026 we went from "we've only just gotten agents to work" to "we've only just gotten agents swarms to work" in publically available models. I'm rather interested to see who's still saying what in November 2027.
verifiableisabu 21 hours ago [-]
I want to push back on that a little (yes I just said that and now brace for the inevitable em-dash).
It’s common wisdom to regard programming as easily verifiable and I get it. The code itself is logical and the outputs testable. That part I don’t fight.
What I find lacking in many discussions is the fact that a stupendous amount of software engineering is not verifiable like that. Sure the bots could spit out working code a year ago already (and earlier) but there is a whole lot more going on in a code base than input-output matching.
The “taste”, the architecture, I don’t know what to call it. What you name your components, how you draw the boundaries and how you allocate resource and divide responsibilities and a whole lot more (DB design, etc). Those things cannot be “checked” to any sufficient accuracy and in my opinion they are still getting very good at it (not perfect) which makes me doubt progress is only about RLVR. There is more going on which is missed by just myopically looking at “code” and calling it “verifiable”.
This rising tide lifts all boats so to speak and I find it kind of .. concerning.
dustbunny 12 hours ago [-]
Yeah anyone who cites an individual use case as a reason AI is bad is obviously displaying their lack of experience or engagement with the tool.
I went through the same arc. I used to tell people about how AI failed on some individual task.
I have found many tasks which LLMs are at least 2 orders of magnitude faster and better at than I (or any human I've ever met). Basically debugging and analyzing an existing code base AIs are simply better at than every human.
A skilled human will write better code, but actual lines of code output in a large software project is less than 25% of the work. LLMs are better at almost everything else.
You can very easily use LLMs to automate everything you don't enjoy doing. Ie: merge conflicts, monitoring PRs, fixing CI issues, monitoring telemetry, updating jira tickets, deep debugging.
LLMs are somewhere around 100x better than humans at "here is a bug; figure it out"
21 hours ago [-]
bena 1 days ago [-]
I mean, if I'm going to be honest, I think that was the most ambitious thing he could think of.
Blow is more renown for running his mouth and shitting on other people's work rather than any of his own work.
galkk 22 hours ago [-]
Blow is a man who gives "omg, he's so smart and insightful" impression if you listen to him for 5 minutes, but "he doesn't even know how much he doesn't have a clue about things outside of his area" when you listen to him for 1 hour. His/Casey's takes on large software projects/companies are often insane and borderline "it can be written over the weekend" quality of argument.
I sometimes wonder if I'm a victim of gel-mann amnesia when I listen to his opinions on gamedev too :(
Stevvo 21 hours ago [-]
If you had worked in gamedev I doubt you would have this opinion. State of the art games are orders of magnitude more complex than any other software.
"it can be written over the weekend" is a valid argument, now that AI is literally doing that in other fields of software to games.
dustbunny 12 hours ago [-]
I am a professional game developer and Blow doesn't know what he's talking about when it comes to AI. He simply doesn't have sufficient experience using AI. And he doesn't have sufficient experience working in a project that is not his own zen garden that he is in total control of.
galkk 20 hours ago [-]
Please don't. I worked on databases, and elitism of gamedev folks often makes me smile.
People there will cheat every way possible to get their framerate/performance/cpy cycles. Yes, it's often amusing to read about really clever and interesting approaches, hacks or even framings of the problem. Like even one of Blow's presentations, where he was explaning how Braid did time reversal. Naive intuition tells: "make everything deterministic", Blow's answer: "how about just tracking state of everything".
But gamedev is not "orders of magnitude complex than any other software". State of the art databases need to be fast and correct. Even that alone makes them far more complex than "state of the art games".
And I'm sure there are many other areas who will look at databases and also rightfully tell that they are even more complex.
Stevvo 20 hours ago [-]
"make everything deterministic" is only part of a solution. You would have to resimulate everything previous from a checkpoint or initial conditions, which is potentially going to be very expensive.
That said "make everything deterministic" is a great idea in games. e.g. see Rocket League networking/physics.
mungaihaha 15 hours ago [-]
> State of the art databases need to be fast and correct
SOTA games need that too. Games need to deal with physics, audio, rendering, networking, anti-cheat etc. at the same time. All very performance sensitive
Do you think Postgres is more 'complex' than a triple A game like GTA 6?
tstack 11 hours ago [-]
I just can't let this pass... what happens if there is a bug in a game? Nothing of consequence. What happens if there is a bug in a database? Real-world consequences. A rendering glitch or an object behaving oddly in some cases is not a big deal. A database losing a record or computing something incorrectly... BIG F'ING DEAL! I cannot understand how you can even suggest these are equivalent.
> Do you think Postgres is more 'complex' than a triple A game like GTA 6?
Yes, absolutely. The postgres codebase has been around a long time and continues to be changed and accumulate functionality that all needs to work together. Just look at the details in the recent stories about all the issues that were found and the need to slip the schedule.
bena 56 minutes ago [-]
Exactly, in Fallout 3, they had to make a "train hat" because they couldn't implement vehicles properly.
Often, in video games, an acceptable resolution of a bug is "Just don't do that".
"Just don't double spend" is not a solution when dealing with financial transactions.
badpun 9 hours ago [-]
For reference, Postgres is 1.5m lines of code. Madden 2015, a 10 year old game (latest example ChatGPT found) is 10 millions line of code. Furthermore, Postgres uses C, while Madden uses C++, so it's code is probably more compact.
galkk 4 hours ago [-]
Idk, what ChatGPT commented, but I wouldn’t be surprised if someone looked there, it would be (I’m guessing here, but that is somewhat educated guess)
1. Copy paste of custom c++ stl
2. Copy paste of whatever “standard library” they are using at the company
3. Copy paste of source code of whatever engine they are using with custom ad hoc fixes and patches that never were back ported back
4. Copy paste of every third party software that is seen on games startup screen
5. All the internal tools etc
ModernMech 13 hours ago [-]
> And I'm sure there are many other areas who will look at databases and also rightfully tell that they are even more complex.
Robotics! Take all the problems of games and databases and put them on wheels.
Matl 19 hours ago [-]
> State of the art games are orders of magnitude more complex than any other software
This is an absurd claim that gamedev folk like to tell themselves. Having seen the mess of several engine codebases, incl AAA engines and the memory leaking unoptimized state of many games, I don't think so.
There's many safety critical real time systems that are both more complex and approached with a lot more thorough design. Let's just say I would not trust a Jonathan Blow to put people on the moon.
That's not to say gamedev isn't challenging, but it's not quite as complex as the industry would like to think.
18 hours ago [-]
rpdillon 13 hours ago [-]
> State of the art games are orders of magnitude more complex than any other software.
Tell that to the FAA.
slopinthebag 22 hours ago [-]
have you built anything comparable to his accomplishments?
jstummbillig 21 hours ago [-]
I think the idea is: He has not made anything comparable to the stuff he (often? sometimes?) talks about. But he thinks he has. And he makes others believe he has.
JuniperMesos 20 hours ago [-]
All of Braid, The Witness, and Order of the Sinking Star are excellent video games. Granted, that's 3 pieces of software over about 20 years (as well as his programming language, which is perhaps interesting but still unfinished and unproven), but it's still the case that Blow has actually produced valuable software artifacts I am happy to have paid money for. This isn't to say that his opinions about software are necessarily correct, especially software that isn't similar to video games; but I don't think it's fair to say that he's accomplished nothing comparable to what he talks about.
torlok 20 hours ago [-]
I learned a lot from the RAD Game Tools people about personal programming skills, however shipping 3 relatively small games in 20 years, none of which advance the field, is the opposite of credibility when it comes to large-scale software development. If everybody worked this slow, there wouldn't be much software to complain about even if it was all terrible.
slopinthebag 8 hours ago [-]
if all software was of the quality of braid, the witness, and ootss, the world would be a better place.
galkk 22 hours ago [-]
I have my fair share of crazy takes too
2muchcoffeeman 22 hours ago [-]
I can’t make professional looking cakes. I can make a regular cake. But I can sure tell you how wrong you are if you think cakes are just water, flour and eggs and shouldn’t cost $50.
hobo123 19 hours ago [-]
But they basically are, and in this household we bake a lot. It's not really on topic, but why TH should a cake cost 50 bucks? In an industrial environment they should take maybe 10 minutes of manual labor, if that much.
imdsm 22 hours ago [-]
Wait, you add flour and eggs to your cake water?
slopinthebag 21 hours ago [-]
and yet, if that same chef is an award winning baker with decades of experience producing not only elite cakes, but also the machinery to bake elite cakes, who's more likely to be correct? the amateur? nah.
kaashif 21 hours ago [-]
Yes, because the professional is saying something wrong and the amateur is saying something right.
If there is some uncertainty in the answer, maybe you have a point. But people can just be wrong.
slopinthebag 19 hours ago [-]
and yet it's the amateur claiming there is no uncertainty. no offence but i don't see why your opinion would hold any water here.
rantallion 21 hours ago [-]
I'm sure award-winning bakers produce a somewhat steady output of elite cakes, not only 2 cakes that each took a team to make, and one machine that's still just a prototype. Doesn't feel like an apt comparison here.
slopinthebag 19 hours ago [-]
that's an absurd take. Rockstar has only produced a handful of elite cakes with a massive team, are they not an elite game studio? volume isn't in question here. 3 elite cakes produced by a tiny studio is elite. braid, the witness, and ootss is an elite catalog of indie games. don't let your hate of the man blind you.
rantallion 14 hours ago [-]
I don't know the man, let alone hate him. But after reading the comments here and looking up his career, it certainly sounds like the teams he was part of built elite things, while he speaks as though he single-handledly built elite things - there's quite some difference there.
galkk 20 hours ago [-]
It's hard to argue with analogies, but I'll give you mine.
It is more like the guy who can paint very good landscapes would start criticising every oscar category from producing to sound design, telling that they have 0 idea what they are doing, and he would do it better. Because you know, lanscape painting is 2d image, and movie is also, essentially, 2d image.
"Why the credits of Transformers are 5 minutes long with hundreds of people, you don't need more than 50 people to make such movie"...
TeMPOraL 21 hours ago [-]
Probably bad example. Producing machinery to bake elite cakes would be getting as deep into artisanal crafting as you can get.
Professional cooking is not any less art (as opposed to a quality process) than amateur. I'd instead listen to the chemical process engineers in food space, who - guess what - may just say the cakes shouldn't cost anywhere near to $50 :).
swyx 21 hours ago [-]
which are... what? 2 indie games and an obscure language? why do we care exactly?
tialaramex 20 hours ago [-]
Three. Three indie games. "Braid" in 2008, "The Witness" in 2016 and "Order of the Sinking Star" in 2026.
It appears to be taking Jon longer to make each game three years to make Braid, seven years to make The Witness, more than a decade to make OOTSS, though doubtless he will say that Jai (or whatever he decides that language should be called) held up OOTSS and somehow it would simultaneously have taken longer in C++ and yet it took so long because he didn't want to use C++.
[Edited, this is still 2026 even if it doesn't always feel like it]
Sebguer 22 hours ago [-]
He gave a talk at the tech company I worked for's annual all-company gathering in ~2019, and it was basically just a speech about how we're all dumb and he's the only one who knows what he's doing. It was almost worth it to watch everyone rolling their eyes at him.
Ohhhhh, Blow's personality, at least at the time of Braid, seemed to include a desire to connect to other people but on his own terms.
le-mark 18 hours ago [-]
I was totally unaware of all that, thanks!
vasco 21 hours ago [-]
Dude mixed japanese mini game concepts with mario and thinks he is a spiritual guru.
Dave_Rosenthal 23 hours ago [-]
Since software has near zero marginal cost of distribution, people mostly use software that is the dominant version of that type of software. (Not many people use the 10th best photoshop clone.) AI isn't yet massively accelerating the development of that type of software.
Not only is developing complex software intrinsically harder, there is way less (and way less public) training data for the code behind these types of systems. Probably the biggest wins right now for big dominant software systems are things like porting, paying down technical debt, raising efficiency, etc.; these are all tasks where the behavioral spec is pretty solidly defined by the existing code.
The software that is getting accelerated the most is the "not too big and complex software": web sites for niche things, mini games, ad-hoc data analysis, solving little specific problems with scripts, etc. But most of these kind of things are used by not too many people.
So, averaged over software a random person uses on a random minute, AI has not solved coding. But averaged over all the long tail of distinct (and often fairly simple) software people are building, it pretty much has.
incrudible 23 hours ago [-]
I would say more generally, it's because software progress is non-linear. Even before AI, you could quickly whip up a greenfield project that was "80% there" in terms of functionality, but the last stretch would take at least quadratically more time. Every piece you add adds entropy, forever, even if you later remove it ("It doesn't work that way anymore"). Every piece adds implicit and explicit connections to every other piece.
With AI, those first 80% are now almost instant, producing flashy demos fooling us into believing that software development has been accelerated exponentially, but actually that speedup is only a very large linear multiplier that eventually gets consumed by the non-linearity.
EricBetts 23 hours ago [-]
> quadratically more time
Remind me of my manager, who likes the quote about how each 9 (as in 99.99 uptime) requires an equal amount of time to get to.
ashkankiani 23 hours ago [-]
Except that it hasn't solved it because I bet you that longitudinal anecdotes and studies on maintenance will make people realize they haven't solved shit.
Even a one off small random program will become unusable in a few turns because 99% of people aren't reviewing things and so it'll just make false assumptions.
Seriously, the only people I hear from who think coding is solved don't seem to be very serious about their work. They're the ones who got into it for the money and never worked to improve themselves.
ozgrakkurt 1 days ago [-]
Just for an anecdote, running “clang —-version” on my beefy desktop pc takes 8 ms on linux.
Running clang-scan-deps on some files takes as much time as compiling the file.
I am writing a build system that uses clang and this is just so insane if you compare it to how much other things take.
Doing the same version command on gcc takes 700 micro seconds. Even this is super slow imo but gives a perspective maybe.
AlotOfReading 22 hours ago [-]
That's because Clang has a mountain of sugar to sweeten the developer experience. Between invoking the program from shell and printing the version, it's executing thousands of lines that set up error handlers, initialize all of the hundreds/thousands of possible args, do basic driver setup, probe different parts of the filesystem, and so on.
21 hours ago [-]
eddythompson80 1 days ago [-]
doing `aws --version` or `az --version` takes 2 to 5 seconds for me.
catdog 21 hours ago [-]
Kind of a common issue for python CLI tools. If you use its module import system idiomatically it leads to a lot of unrelated code being executed and being loaded into memory, something lazy imports [1] aim to solve (at least partially).
It is not the same, it is worst. Nothing seems functional nowadays
LgWoodenBadger 1 days ago [-]
You can say that again. I have a recurring event in Outlook that has a reminder set. If I snooze that reminder, no matter the duration, it will never reappear.
This has been a core feature of Outlook for so long that it might as well be considered day-1 functionality. Why it breaks like this in 2026? Who knows...
jstimpfle 14 hours ago [-]
I have to use Outlook and Teams for work, and both have had a notification symbol on with "1" unread items for most of the past year, even though clearly everything has been looked at.
onlyrealcuzzo 2 days ago [-]
> Nothing seems functional nowadays
It also wasn't functional before-a-days [=
2 days ago [-]
malfist 1 days ago [-]
Now we can make even less functional code much more quickly! All it costs us is some dignity, poor people's electricity rates going up and massive, massive amounts of cash set on fire
polynomial 1 days ago [-]
Such a deal.
brink 2 days ago [-]
Now we have the added benefit of nobody understands it.
onlyrealcuzzo 1 days ago [-]
> Now we have the added benefit of nobody understands it.
You should peak inside some old COBOL codebases running some of the most important software in the world [=
ChrisLTD 2 days ago [-]
There’s AI chat bots bolted into every app now, so there’s that
hdhjsjja 15 hours ago [-]
I don't understand why people would diss Casey Murotari. That guy is totally awesome. The depth he goes to explain things and his course on performance aware programming is so mind-blowing. I am very grateful for Caseys interviews and course
Jtarii 9 hours ago [-]
hacker news people are exceptionally tribalistic and jon blow/casey are outside of that tribe, hence the hostility.
leecommamichael 9 hours ago [-]
You are only reading the headlines! Here are things he actually said in the video:
- AI can reason (with caveats)
- AI is impressive technology
- AI can code "leaf functionality" pretty well
- Modern models don't really make dumb flubs as much
He's saying modern programmer culture has turned all programming problems into "leaf functionality," the stuff which interfaces with OSes, libraries, and web services. He's saying that is the architectural decision which continues to plague us.
He's saying the way we approach "decoupling" is damaging the quality of the greater connected system in terms of correctness and performance. For example, I think most people here can all relate to the idea that lots of things are network requests which just didn't need to be, and so can fail when they don't fundamentally have to.
He's skeptical that AI can make & maintain a complex system which is correct and performs well. He gives the example of having AI generate a script to operate on an Excel sheet. That's using the API boundaries and systems we have today. He states that AI is pretty good at that, but you have to understand that; that's not what the word "programming" means to him.
In my opinion, if you can do system design, you can probably use AI to speed up that the process of implementing said system. That, I think is the more interesting discussion they could've had, because it scratches at what parts of that kind of programming are essential to be done by a person, which I assume isn't 0%. It's for this reason that I still code by hand as much as I do. How do people learn system-design? How do people learn the parts of programming which are necessary to use LLMs well?
brainzap 1 days ago [-]
He sometimes has no clue what he talks about, he spoke against Docker and other technology that makes my everyday life easier
renehsz 1 days ago [-]
Docker wouldn't be necessary if the OS beneath it wasn't so broken.
It's a solution to something that shouldn't be a problem in the first place, if the OS was designed better.
eddythompson80 24 hours ago [-]
What does this mean? Docker just orchestrates OS features that make this possible because the OS was designed to enable that.
renehsz 19 hours ago [-]
I think Blow has a different take on this, but here are my thoughts on why Docker shouldn't be necessary in the first place.
Operating systems we use today were designed in an era when security and isolation were an afterthought at best. Plenty of security features have been bolted on over time to enable what we now call containerization, such as cgroups, namespaces, seccomp-bpf, capabilities, etc. But each part was added separately with its own API and tricky edge cases. Docker is needed as a midlayer to package them up into something a normal person can use.
If, however, the OS was designed from the ground up so that every process is only handed exactly the resources it needs (files, network endpoints, device handles, ...) as capabilities, every application would simply run sandboxed by default. Instead of taking away / altering permissions from a process that starts out with all permissions, we'd only add the exact capabilities it needs via a unified and clean system API. Capabilities handle not only permissions but also make namespacing practically free. The only Docker-like thing we might still need is a way to package and distribute images, but that's a much simpler problem to solve.
This is not a new idea, Fuchsia basically implements this. seL4 provides the necessary foundation as well. Plan 9 at least has per-process namespaces, which get us most of the way there.
mike_hearn 15 hours ago [-]
Docker is a workaround for the lack of coordination that occurs when there's no ownership of things. Other operating systems have no equivalent of Docker because they don't need it.
Consider macOS. The closest equivalent to a container is the bundle. Bundles are much better that containers in several ways:
1. They're much simpler. Just directories with a special structure that's recognized by the OS.
2. They're much more efficient. A bundle ships only the program and any dependencies that sit outside the OS, but Apple invests so much in developing frameworks and in backwards compatibility, that a huge range of apps can be built that require no additional dependencies whatsoever. It's common for sophisticated Mac GUI apps to have bundle sizes in the tens of megabytes, whereas Docker images often require pulling gigabytes. Bundles are typically updated using tight per-file delta update schemes like Sparkle or the App Store, whereas Docker's delta update support is minimal (whatever was easy to implement at the time, basically).
3. They're decentralized. There is no de-facto reliance on a collection of hubs which charge lots of money for bandwidth (some companies block Docker Hub for this reason). Nor is bundle identity allocated by registries - you can create a bundle with a stable identity that survives upgrades even if you pass the bundles around on SD cards.
4. They're actually more "UNIX philosophy". You can move them around and organize them in the same way as any other kind of file or directory. You can "cd" into them from the shell, or synchronize them with Google Drive. There is no need for special servers, repositories, pulls or pushes.
5. They have much better support for sandboxing.
6. They share the same namespaces as the host, so there are no confusing path remappings going on. Despite that, sandboxed app get private areas of the user's home directory that are protected from other apps.
The underlying architecture here isn't perfect; bundles evolved over a period of decades and there's no rigid spec for the internal directory layout. The OS relies on collections of heuristics to identify bundles in a few cases. But it's architecturally much cleaner than Docker.
eddythompson80 13 hours ago [-]
First of all, macos bundles are nowhere near as flexible or "powerful" as OCI containers though. Even if you add all of docker features and knobs onto macos bundles, how do you think that's implemented? through a darwin syscall `run_bundle()`?
as for the list of points:
1. sure, though an OCI image can be exported to a flat bundle too if you don't care about layer efficiency
2. that's one of the things you don't want with docker containers. Nothing is stopping you from `-v /usr/lib:/usr/lib -v /bin:/bin` but you don't want that. Arguments about how much Apple or Windows puts into backward compatibility are moot once a minor breaking change is pushed to these machines without you knowing about it or if you want to explicitly have a different version of a platform library or dependency for one particular container
3. OCI registries are decentralized. The reliance on docker hub is just a convenance. It's like git is decentralized, the fact that everyone relies on GitHub is their own issue. If a DmgHub came up tomorrow where everyone uploads their dmg to it, and it became the socially acceptable place to always fetch dmgs from, did bundles become suddenly centralized and we need a different OS primitive to be decentralized again? the reason they are decentralized today is because no one cared to centralize them (except Apple's App Store of course)
4. You can do that with OCI images too
5. Nope. What's the bundle's equivalent of seccomp profiles? user-mode kernel/runsc? kata (VT-x or AMD-V) isolation?
6. That's a downside not an upside. You can put all your OCI files under /app, and mount the rest of the host mount namespace too. No one does that because they don't want to, not because it's not possible.
mike_hearn 12 hours ago [-]
The MacOS kernel and userspace does recognize bundles yes. If you exec() a program inside a bundle it will use the bundled frameworks (hence the name), and the OS will verify the code signature over every file, for example. Other OS services will use bundle identities for all kinds of things. That's why if you run a terminal you have to give it special access if you want to run vim on a file inside an app bundle. This is all mediated by the kernel and Mach IPC.
1. You can export images, but why is this complexity necessary in the first place? Efficiency does matter.
2. Bundles support different versions of frameworks than what comes with the system, that's not a problem. However it isn't mandatory like it is with containers. And yes, obviously you can make a container that isn't contained, but they aren't meant to be used like that - you are meant to always ship a complete userspace with the program, even if it's nothing more than a tiny script.
3. They aren't decentralized in any meaningful way. Blackhole Docker Hub on your machine and see how far you get. There's no equivalent problem for bundles.
4. Docker containers aren't natively files or directories, which is why you have to use separate commands like "docker image ls" instead of the real ls. You can turn them into files but then they aren't natively usable in that state until you import them.
5. Look into Apple's entitlements, code signing and TCC system. It's much more advanced than anything Linux has.
6. We'll just have to disagree on that. Namespacing is a crude hack that introduces many new kinds of bugs and configuration difficulties. Compared to just running the thing, it's worse.
eddythompson80 11 hours ago [-]
1. The OCI format is what gives you the efficiency. If one company is producing 10 dozen dmgs with shared library or framework in all of them, on mac today those are all not shared. With OCI those layers are shared when needed and different when needed. If you want to flatten them to tarballs, you can if you don't care about that efficiency vector.
2. They are meant to be used however you want them to be used. That was my point in their flexibility. There is literally no reason you couldn't get the same behavior of macos bundles with containers with the examples I gave if you have uniform host (like Apple gives with their macos uniform/controlled systems)
3. Docker Hub is already blackholed in most enterprise environments as you mentioned. There is literally no problem other than convenience. What possible problem could there be? Would git not work if GitHub is blackholed?
4. Again, there is literally no reason you couldn't get it to work that way. It's a very low hanging fruit that no one cares about.
5. Not true. It's more centralized and wallgardend, so it's easier to configure since there is one way of doing it which is Apple Inc way. I thought you argued against centralization. Again, how do I do user mode kernel in macos?
6. agree to disagree.
wpm 21 hours ago [-]
They added namespaces and cgroups to the kernel for fun?
mjburgess 1 days ago [-]
> Hey Windows MCP, run X on one core, run it on a linux kernel shim, isolate it from every other core, and assign it its own file system. Use a cooperative scheduler, but retain the ability to release the core. Assign 8GB RAM to be addressable by that core only. Create a virtual network adapter, and assign an IP , which uses taht reserved core and 8GB only.
We're so far away from that its absurd. Yet an O/S designed from the ground-up to be simple (on modern hardware), would make that very simple.
eddythompson80 1 days ago [-]
That's like one wslc command line on Windows. One smolvm or firecracker command on linux, or one container command on Mac.
mjburgess 24 hours ago [-]
I think you've missed the constraints I've placed on this
eddythompson80 22 hours ago [-]
It does all the constraints up until the memory only addressable by that core. Not sure if all of them support that. Also not sure where the external networking state of all 4 solutions are, but all 3 platforms are fully capable of that. So I guess what's mainly missing is the MCP? It doesn't sound like a "design an OS from the ground up" type work, more like create an MCP that can orchestrate the existing primitives to achieve that.
CrimsonCape 1 days ago [-]
Chatgpt dropped in 2022, which means LLM based AI is like 4 years old. I think it's undeniably improving constantly, in some cases noticeably so. Sure there is argument to be made over the improvement velocity (is improvement slowing?).
So what argument is there to be bearish on it when it is in infancy? If you just want to go with "the quality sucks" well, sure, but it sucked a lot more two years ago, which means it sucks a lot less today, and in 2 more years, it will suck even less. I'd use different adjectives personally, cause I find it's pretty decent now (opus 5.5) and i'm pretty optimistic about what comes next.
lionkor 22 hours ago [-]
Sucking less doesn't mean that it does engineering well enough to be used like it's used.
It still generates text and doesn't reason, doesn't reflect, in any meaningful capacity.
Not to sound cocky, but I know how to write code and design software. It's a long, complex, and difficult problem to engineer anything.
When I use frontier LLMs, the best of the best, I still have to say things like "Why did you put code that concers device configuration in a service that just keeps track of one global flag", and it'll profusely apologize, point out that it's all overengineered, that it leaked boundaries that are documented in code, in agent documentation(!), etc., and then provide a fix that is maybe a little bit better. It's such utter horseshit, most of the time.
And yet, it's worth using it, because these problems can be caught, and the few times when it cooks up something good, it saves a lot of work.
glouwbug 13 hours ago [-]
And yet these problems can only be caught if the user knows what they’re doing
ekidd 16 hours ago [-]
Well, a few things:
1. Coding isn't completely solved yet. The further you get from CRUD apps, the more a little experienced human judgement helps.
2. The most dramatic improvements happened in the last couple of months. How fast do you expect software to ship?
3. I am now running multiple really amazing TUI tools that were largely written by someone's LLMs over the last several months. My software, at least, has already started changing.
It breaks my heart, because I love writing software and I think I'm pretty good at it. But another year of progress like the last 12 months, and I fear that our profession will be cooked.
benrutter 16 hours ago [-]
> I am now running multiple really amazing TUI tools that were largely written by someone's LLMs over the last several months.
Don't leave us hanging! What TUI tools are you using and what did they replace?
glouwbug 13 hours ago [-]
Likely something similar to grep and a wrapper for git pull/branch/push
dustbunny 12 hours ago [-]
Nah its almost definitely herdr
sd9 19 hours ago [-]
I personally think Jonathan Blow is a genius and his games are incredible pieces of work which advance the medium of video games.
But if you take him just _slightly_ outside of his area of expertise - video game design and perhaps philosophy - his takes are extremely strongly held, banal, and don’t really stand up to scrutiny.
Best to admire his work but it’s pretty safe to ignore anything else he says, at least in my experience, or treat it more like an opinion from an average colleague rather than an industry expert.
Very good at what he does, poor takes in general.
Don’t even get me started on Muratori who is not even good at what he does, yet has the same strongly held takes seemingly mostly to curry favour with Blow.
Sorry if that seems a bit personal but I’ve been following him ever since Braid and I have found this to be repeatedly true, despite the self evident quality of his work.
dezsiszabi 16 hours ago [-]
Why isn't Muratori good at what he does?
glouwbug 13 hours ago [-]
He’s arguably not at blow’s level but occupies the same streaming space as blow and voice / persona as if they are
torlok 7 hours ago [-]
It's the opposite. Casey has been shipping highly regarded libraries for game developers probably before you've even touched a computer. Casey's blog posts from early 2010s, especially ones criticizing OOP, teaching library design, and promoting immediate mode concepts have been very influential on the broader industry. Jonathan Blow has nowhere near his track record.
shdh 18 hours ago [-]
This is a pretty accurate analysis of Blow
jackling 12 hours ago [-]
> Don’t even get me started on Muratori
Please get started :)
Isn't Casey quite successful as a developer from RAD and as an educator?
newsicanuse 17 hours ago [-]
[dead]
mythz 16 hours ago [-]
Well I've personally switched to PhotoCraft for my limited image editing needs on Linux. Before this I was using www.photopea.com, which is way better than I thought possible from a website, but still lacking behind a native App.
Obviously if you have time/energy invested learning a piece of software it's going to take you a minute to evaluate and learn a new alternative. But I can see vibe coded Apps fill the void when there aren't many great options.
forgotpwd16 21 hours ago [-]
Nice discussion/talk in computing evolution & programming. Mostly agree with everything said. One comment I've, is on his idea on "rule-operating AI". That's how modern agents work. They use LLMs to provide conversation/reasoning/planning but operations are performed structurally with external tools (e.g. file search with fd/rg) or accessing some execution environment (e.g. web search with some API). Another, not all programmers consider their work craftsmanship, but means to an end. Those programmers don't care about technical debt introduced by AI. (And most managers, of course.)
jFriedensreich 17 hours ago [-]
The thing that is not changing much is provided software by a company, what is important to understand is that everyone can have their own software now and these will not be visible in the same way. There are tons of people where few pieces of software are the same as before AI. I have my own browser, email client, beeper clone, agent harness, calender app, finance app, git client, file manager all bespoke my taste and how i think. Its true they are not stable for all the edge cases if they would be rolled out to thousands and I still use them alongside the old apps, but they are getting better everyday. The main limiting factors are currently:
- interaction regression test and ensuring taste, feeling of app use are consistent. agents still suck at that, especially general review agents, i hope this gets better as i introduce dedicated vision test agents for userflows but at the moment it takes about a week of usage to find the things that are wrong in subtle ways before an agent task can be accepted, if i push too fast and dont wait a week the app degrades quickly
- data layer: ui coding is largely solved apart the above but the limiting factor is the logic/state layer beteen the database and the ui, this has to be pluggable from persistence (both local and remote) and local first and reactive and be able to encapsulate the logic that would make ui components eat up complexity and slowly degrade. There are 100 local first libraries all broken in different ways or losing data in edgecases, the most promising one seems to be tanstackDB but i still dont have a setup that just fits perfect, but i am also nowhere near the level of understanding of it i would need
larodi 17 hours ago [-]
Sometimes wonder if AI did not rob everyone of their work by retelling/compressing the world of code into several gigs, but rather emerged from carefully catered input - would it matter differently then. Perhaps yes.
Coding is solved, but it got solved through a robbery of …idk… civilisational proportions. And is then (still) not even spread equally or accessible in any reasonable manner for reasons we all know about and are not in question.
The good thing about the internet, which solved so many communication challenges, was it was grown by people, started small and is still not in the hands of few companies, and even though Meta, Google and the gang are so ubiquitous.
shevy-java 17 hours ago [-]
> The thing that is not changing much is provided software by a company
I agree for the most part, but if I am the customer, and a company
produced software via AI slop, why would I have to pay a lot for it?
I'd expect the cost (for me as a buyer) to be reduced but that's not
really happening. Of course the AI companies built up the "it costs a lot of tokens so you must pay more", thus they upscale the revenue they generate as a de-facto monopoly (mostly really), which then forces downstream companies to pass on these costs as well, logically. But honestly, that seems to me more like a cartel was established here, which is controlled by the big companis on top feeding away on the others. The basic question "why do I have to pay a lot for AI slop" still remains valid in this case, if computers autogenerated the AI slop code here.
hdhjsjja 15 hours ago [-]
I love his streams. The only gripe I have is he is too strong on bringing down dev salaries. Because he can't get programmers for this game at the price he can pay. I think this is wrong, because devs get paid part of a profit so they deserve that.
Another gripe is he is willing to end privacy on internet because game piracy affects his sales.
One more thing he doesn't understand the struggles of people with kids and look down upon people with lesser talented than him. But this is okay given how much he toils to build skills and inspire others devs.
If u r reading this thanks Jonathan Blow for u r streams. You have been great inspiration.
jackling 12 hours ago [-]
Agree with everything you said except:
> One more thing he doesn't understand the struggles of people with kids and look down upon people with lesser talented than him.
What did he say to make you believe that?
Also,
> piracy affects his sales
It's a bit more serious than that. It affects his livelihood and his passion. The acceptance of piracy has caused great harm to builders.
JuniperMesos 20 hours ago [-]
I think there's a mix of good and bad ideas in this video, but one of the things that struck me was the comment by the interviewer, Wolf Tivy, that the Linux /proc filesystem as a type of perhaps-non-deliberate vendor lock-in for the Linux operating system, since it's not like how other systems operate. But /proc is famously an idea that the Plan 9 operating system innovated, and that is in some sense a purer implementation of the Unix philosophy that everything is a file than Unix itself had - and that Linux basically appropriated wholesale because it turned out to be a useful idea. There's nothing stopping any other OS from adopting /proc, just as Linux did. It doesn't accomplish vendor lock-in at all, conceptually. And it didn't seem like either Blow or Tivy understood that.
mike_hearn 16 hours ago [-]
/proc is not "everything is a file"! The things you find in those kinds of virtual filesystems are files only at the most trivial level. Consider that you can't move files around in /proc, although you can with any real file. You can't hard link them or put your own files next to them or add xattrs or change their ownership.
Procfs is basically just a crappy untyped API that requires tons of ad hoc non automated parsing code to use. Other operating systems haven't copied it because it's not a particularly good feature.
dist-epoch 16 hours ago [-]
> a purer implementation of the Unix philosophy that everything is a file than Unix itself had
which is a misguided idea. /dev/urandom was famously replaced with a function call, getrandom(), because it being a file has all kinds of problems.
MetroWind 4 hours ago [-]
Not sure. But my software are surely different. Because I've replaced a lot with my own.
PeterStuer 12 hours ago [-]
It didn't "solve" coding (yet?). But looking at my production systems it solved an enormous amount of real issues customers never knew they had. Maybe they are aware the system somehow gets better week after week, and new features seem to be released more frequently. Tbh, I'm not sure users realy notice this undeniably big shift.
happy-go-lucky 19 hours ago [-]
Productivity means creating meaningful value and maximizing quality relative to your resources rather than simply rushing through tasks as fast as possible.
asifnazeer24 21 hours ago [-]
AI is saving a lot of time in coding and making software as for my experience i have created a lot of software,apps through ai coding and sometime it gave you similar results similar results to the traditional software but mostly it solves the coding issues in seconds. the main help i get from ai is in my taxi booking app where before ai i had to manually update the routes fares and other things and now ai is scheduled to perform such tasks and i am just monitoring the system.
damowangcy 21 hours ago [-]
Not to throw shade at you individually, but updating routes fares and such should be a backend thingy, because there are so many things to optimize for (caching, realtime updates, targeted cost, etc.). Unless you don't have the volume or don't need to scale, using AI to update the pricing and stuff is suboptimal and a waste of tokens, also making the whole software on the user's end, worse not better. Of course, this piece of software might not exist without AI, so I get the point why you did this.
Ironically, software is not the same anymore, it has truly gotten worse.
iaanix 20 hours ago [-]
It is the same, but cheaper. Software is a commodity. The value of software engineering is tanking while its quality is really same as ever.
abc42 15 hours ago [-]
Is it the same? How fast do things usually completely change? It took roughly 50 years to transition from horses to cars. Our field is certainly faster than that, but the effect will still happen gradually.
maxdo 1 days ago [-]
It’s not the same , I’m sorry i literally used 20 usd subscription to build software services used to cost $10k+.
Ask any sales
Doing software sales perception of enterprise software also changed .
From magic to “maybe we can vibe code it”
grumbel 16 hours ago [-]
I'd go a step back before AI coding: LLMs solved natural language processing. That has been one of the core problems of computer science for like 70 years and LLM just solved it essentially overnight. LLMs are so good at it, that the average person doesn't even realize how much of an impossible problem it was in the first place. That by itself should have been a HUGE transformative change to how we interact with computers, games and everything. But outside of a few translation features and AI slop on social media it hasn't really changed much else. Web search is still a mess, my browser still can't spell check and talking with NPCs in a video games hasn't really made it outside the tech demo stage either.
It's not even just AI, Gaussian Splatting has a similar issue, amazing tech, amazing tech demos, but what's the modern equivalent to what Myst was using Gaussian Splatting? The tech is amazing, but somehow we seem to have a hard time making good use of it, everything is stuck in tech-demo land.
mike_hearn 15 hours ago [-]
It's partly because inferencing is expensive. Do you want your OS to cost an extra $20/month and send all your data to remote servers? If the answer is no, then the developers are limited in how much they can integrate LLMs at this stage. Microsoft keep hitting this, Apple have done a lot of work on their private compute cloud to try and solve it.
kolinko 17 hours ago [-]
Working on implementation in one institution now - the current plan is to move from legacy software to good apis and people just building their own endpoints in claude code.
Stevvo 21 hours ago [-]
You think AI should be able to write complex games, because it can write anything written at a tech company. Failing to realize that leading games are orders of magnitude more complex than anything written at a tech company.
bdparrish 15 hours ago [-]
This thread is something to behold.
1. Blow is arguing that paradigms haven't changed which means software is still being produced and delivered in the same way. How do we get beyond "Clean Code", "Gang of Four", etc.?
2. AI is trained on human code. Inherently it is going to have bugs. Proper context, concepts and design will eliminate a lot of vibe-coding and AI slop, but if you are learning from bugs, then they will be there. It will be less.
3. There is going to be chaos for a junior engineer or a fresh graduate that has not experienced and built full systems. Where do they fit in now with AI doing the perceived grunt work? How do they get mentored? There is going to be a place for hungry software engineers that are getting out there and just figuring it out with a GSD attitude.
sreekanth850 18 hours ago [-]
Ai solved coding. but coding alone is not what make useful software, you need vision, LLM cannot have vision.
pmdr 19 hours ago [-]
Because better software was never the target, just less employees.
gchamonlive 18 hours ago [-]
There's still money in knowing what and how to ask
ankit9673 17 hours ago [-]
why would every software change just because coding is easier? they only change when they have something worth building.
glennfiedler 14 hours ago [-]
Jonathan, AI is a bicycle for the mind, and not everybody who can ride a bike gets to win the Tour de France.
ozgrakkurt 1 days ago [-]
It is weird how people here are accusing Jonathan Blow of doing not much things and just talking.
While the guy created a programming language, game engine and a game. And sold thousands of copies of that game.
Is this not much compared to working at big tech to adjust a button and drinking coffee at work. Because the team is bigger and there are more customers?
sornaensis 20 hours ago [-]
It's because he behaves like he is John Carmack or somebody with foundational achievements, and because he has a habit of talking out of his depth on things that don't fit into his game development theory of software development, like pure functional programming or languages and development practices that are more suitable for large teams.
He has good points a lot of the time he just makes everything into flamebait.
ex-aws-dude 21 hours ago [-]
I think they are more just tired of the never ending negativity and shitting on other devs
Used to watch his videos but stopped because it just got tiring
Some people critique the industry in a constructive way, others do it in way that constantly positions themself as superior
Also the constant myopia of “whatever I do in gamedev world is obviously the best approach for all domains of software”
ozgrakkurt 17 hours ago [-]
I have the same perspective of him and mostly stopped watching his videos when they come up in youtube. But I am playing his last puzzle game and it is really one of the best games I have played.
It is hard to find people that are healthy and are doing something worthwhile or saying something worthwhile unfortunately.
I also used to find Casey Muratori obnoxious but there really isn't many other options to follow except these people as far as I know.
The only "healthy" programmer I watch always is Mitchell Hashimoto.
Other youtuber/programmers are just good vibest with not much substance ime.
bena 47 minutes ago [-]
Do you know why there aren't many options?
Because those who can, do. People who are doing worthwhile things don't have the time or inclination to stream it.
It's the pitfall of all content creators/streamers, eventually creating content takes over what they were creating content about.
jstimpfle 14 hours ago [-]
I have the impression he has listened to people like you and has come across significantly less negatively in the last couple years. Apart from that, there has always been a lot of substance, attesting only a superiority complex is not at all doing him justice in my opinion.
I for one love to watch and listen to him, not for the fact that I find myself agreeing to so much of what he says, but because he is able to express things in very insightful ways. And yes, I'm a sucker for that "no bullshit" attitude.
NSUserDefaults 21 hours ago [-]
Not all software will improve because not all developers use AI for improvements. Adding half baked features is still a thing.
Also, regarding Blow, let’s ask a stupid question back: if his language solved game development, why did his game take so long?
I suspect only a few people will use the language. With attitude like his, it is a risky proposition. Unreal Blueprints are gone, and that is coming from a big company. He could turn his product into a liability on a whim.
Rantenki 11 hours ago [-]
Fully anecdotal, but one piece of software that has been missing from the Open-Source landscape for a long time is a decent parametric CAD package. I am fully aware of FreeCAD, but it has long had issues with design history (google the topological naming problem), and no other competitors exist which are even close...
Until a few months ago when Solidcraft came out. It's very similar in appearance to Autodesk's Fusion360 package, and operates like a combination of Fusion360 and Solidworks. I've been trying it on every release, and it's making RAPID progress towards replacing Solidworks for my CAD workflows. I've been a Solidworks user since 1997, and I can confidently say that Solidcraft is advancing with biweekly releases which are more feature-rich than Solidworks annual releases. All of this is driven by AI/LLM development.
The tricky part here is that somebody has a good vision for the product they want to build, and they're doing it using an LLM, but not missing the jobs of product/project/engineering/release management. AI hasn't _solved_ coding, but it's reduced friction in ONE part of the development cycle. In most cases, that hasn't increased throughput very much (if at all), because it's just revealed the next slowest "rate limiting step" in the process. In cases where there is less overall business friction, and a strong vision without slow moving bureaucracy, it seems clear to me that LLMs _can_ greatly increase throughput. It also seems obvious that the advantage here lies mostly with very small teams with a great deal of experience actually delivering products. Great time for startups to do disruption, bad time for large slow-moving enterprises to get disrupted. Go capitalism or something.
iotage 22 hours ago [-]
> Why is my software still the same?
Surely, it is because AI uses the same practices and techniques used by human programmers. Despite AIs being highly capable, programmers are unable to provide structure, rules and examples of how to architect, design, write or refactor consistently better software.
Given this, it’s quite amazing that AIs do so well.
lionkor 22 hours ago [-]
They don't follow rules and guidelines once said rules are complex enough to actually describe some good practices, good architecture, etc.
robeym 16 hours ago [-]
SaaS value very quickly shifting to the second S! Have to understand the need and customer more than ever before. It's actually a great direction to go in! Make Service Great Again
jdlyga 1 days ago [-]
AI "solved" coding to the same degree that AI "solved" writing and AI "solved" creating images.
unrented7977 14 hours ago [-]
"If humans evolved from monkeys why are there still monkeys?!"
Brilliant argument as always.
8 hours ago [-]
_pdp_ 17 hours ago [-]
Just keep in mind the "better" coding models came out ~12 months ago.
polarsanel 23 hours ago [-]
Weirdly phrased question.
If (thing that is ambiguous and probably not true) why is (something ambiguous, subjective)
maxrev17 21 hours ago [-]
Your software might be the same but mine isn’t haha
dimavolo 1 days ago [-]
My software isn't the same. I recently built a Swift app: the screenshot annotation app of my dreams. I don't know Swift at all and that's fine because I saw 0 code during the build process.
And yet... the app works efficiently, has features like shape-smoothing for hand-drawn freeform annotations (I wouldn't even know where to start if I were tasked with this on macOS, for example), it's designed far more beautifully than I could have done, even after a decade of studying UI/UX, etc
Yes, AI solved coding... mostly. At least for indie devs.
slopinthebag 1 days ago [-]
there is more to software than trivial screenshot utilities...
dimavolo 20 hours ago [-]
That's true, but the trend is moving in only one direction: AI-assisted dev (read: I tell the AI what I want and then go about my day) is eating the world.
If it hasn't come for software/industry/enterprise x yet, it soon will, where "soon" = 3 ~ 18 months.
indymike 21 hours ago [-]
Operator habit explains most of it.
ellyagg 19 hours ago [-]
Because you don’t know how to use AI yet. I don’t use any of the same software I did 2 years ago.
iloveyoutwo 23 hours ago [-]
>It is not the same, it is worst. Nothing seems functional nowadays
I do think it's accelerated enshitification of closed-source software and services, but I've never used less closed source software thanks to AI, and the open source software I'm replacing it with is more secure than ever.
My average Android app has way less permissions than it used to, less or no Network permission, and is smaller. It's excellent for my privacy.
New good software:
T3 Code is the best way to interact with AI coding. Fluxer is a great Discord alternative which has excellent UX. Fuck matrix btw.
eddythompson80 22 hours ago [-]
Android doesn't have a network permission. Or rather it's granted by default to all apps and there is no way to revoke it. GrapheneOS (and maybe Calyx?) is the only flavor I'm aware of that allows you to make network permissions a thing.
> and the open source software I'm replacing it with is more secure than ever.
I'm not sure how you can be sure of that. If anything, the more code the more opportunities for issues. If you're referring to existing popular open source software that's getting aggressively scanned and pen tested, then sure. If the AI help in decreasing dependency on closed source software is mostly through new greenfield projects that are replacing them, you don't know how more secure than ever they are.
rowanG077 12 hours ago [-]
My software isn't the same. I guess people who are deep in proprietary land don't notice, but for the subset of people who embrace LLMs in the open source world stuff is moving at lightspeed.
hugodan 16 hours ago [-]
This guy talks a lot without saying anything at all. To the point where he even loses his own thread of thought…
iloveyoutwo 1 days ago [-]
I have an excellent private meditation app, excellent (closed source) habits and workout apps that now work offline. These three apps all had tons of telemetry, 10s of connections, unnecessary permissions, broke GrapheneOS exploit protections, and connected to ad networks. Now they don't even ask for the Network permission. The meditation app connects to just the public CDN for the meditation program I'm frontending.
I added self-hosted E2EE sync to the greatest (closed source) to-do app of all time (Things 3) and I'm working on an Android clone of the iOS version which is already fully functional but has quite buggy UI.
None of it is slop. I am obsessed with Android UX so I fiddle a lot. All of it has greatly picked up thanks to Opus 5.5 and Sol 6.1. Sol is good for the premium unlocking while Claude models refuse.
I haven't released any of it yet because I have to sort out my opsec for the copyright stuff although I'm not particularly worried.
The meditation app's content I've been using for years in its original closed source client. All the content is the same so what I have to work on is the UI. The closed source original one has terrible UI. It's like really outdated Android style—it still has these grey bars at the top and bottom.
For a little while I was blocking its telemetry and stuff using Rethink DNS (an Android firewall/VPN app), but it still required an account and at that point in time I was using pretty much all open source apps on my Graphene OS phone, so I wasn't very happy about it.
So in the beginning the meditation app was quite sloppy. I think I made it originally with Opus 4.8 so it must have been like spring 2026 I started.
The habits and workout apps were just oneshot with my 5 hour usage of Codex each a few weeks ago. Most of the bugs are upstream so it was actually convincing me maybe AI is making some apps slop. Not so easy to fix them though, considering they're closed source. And I think it's probably better to just keep my patches minimal with unlocking premium and making it work offline.
Things maybe a week or so longer than the Android patches. For Things 3, at first I just wanted sync between MacOS user profiles, because you know, I don't want my to-do's on someone else's server. So initially I changed the certificate to intercept the traffic so a locally hosted MacOS service could sync them. That wasn't E2EE, but it was all local, so that was fine for me. I realized that I could just have patched the app to work with my server, so that fixed the messing with certificates.
But I wanted more. One of the worst thing about switching to Android (GrapheneOS) from iOS for me was that I lost Things 3. I could still use it on my Mac, but I'd really prefer to have it sync between them.
It would have been a world of pain and insecurity to try and add end-to-end encryption to the actual Things 3 app as traditional E2EE works. So I had the idea to just add the encryption to the local server that was already getting tasks synced to it. So just add clientside encryption there. And then I hosted a sync server that would run off my mac but would only see encrypted tasks.
This is important because that way I don't have to trust my own server's security, just that the clients are secure. Also because I'm using Cloudflare tunnels so Cloudflare could spy on the traffic if I didn't use E2EE. And if anyone else wanted to use my sync server, they wouldn't have to worry about me seeing their tasks.
The three closed source apps aren't much to write home about in terms of UX like transitions, buttons, etc. They could all be improved by a solid Material 3 Expressive rewrite. And that's what I'm doing with the meditation app.
But, the good thing they all share is that they are all great ideas.
The habits app is based on Atomic Habits, and it really integrates its teachings well.
The workout app has great videos and instructions [1]. It’s a really attractive framework the way it gives so many levels starting from super easy for each exercise. It's a calisthenics app, so the final variations are extremely impressive and cool to work towards. Think one-arm pullups, and pushups at level 10.
The meditation app has best-in-class content in a course style. It's free and I liked it better than Calm or Headsapce. Its creators are frontier researchers into how meditation affects the brain. Great ideas, great content, not the best app.
[1] Bundling the videos brought the APK to 600 MB!
medellin 21 hours ago [-]
Solving coding and solving developing a good product are different spaces. One would need agi.
24 hours ago [-]
exabrial 1 days ago [-]
If AI solved coding, why the hell is iOS 27 a dumpster fire? Slow AF
speed_spread 1 days ago [-]
AI allows peope to care less about what they're selling. It used to be magic for the consumer, now the magic extends to the provider too. It lets those who are lazy, greedy and cheap get away with it even more easily. You care about quality? Sorry you're shit out of luck in this game.
polynomial 1 days ago [-]
Because we're not using "enough" AI yet, obviously.
empath75 1 days ago [-]
I think the main reason you haven't seen a lot of changes on the surface is that corporations as currently constructed largely cannot use them efficiently.
I have a personal project where I am merging 100+ PRs a week and at work I would be lucky to merge 8. I spend 20x as much time trying to get PRs merged as I do actually doing the work.
I'm on a project with 4 other people working on 4 or 5 microservices and I would get more, better, work done if I were on a team alone managing all 4 or 5 microservices myself.
keeda 1 days ago [-]
Yep, and we've known this since the Mythical Man Month, but the biggest slowdown is coordination overhead. However, if one person can do much more work, you need fewer people overall which means even lesser coordination between them, which is when broader organizational productivity gains will be unlocked.
So the answer to why we don't see AI productivity gains more broadly is, unfortunately, enough people have not been "re-orged" away.
ChrisTrenkamp 15 hours ago [-]
My experiences with LLM's and coding harnesses has improved over the past year or so, but its shortcomings has stayed the same. It produces code that's technically correct, but there's always these subtle issues that would blow up into large issues as time goes on. If an LLM generates 100 lines of code for me, I usually end up rewriting around 90 of them. I could spend my time writing skills files to tell the LLM what it should or should not do, but you run the risk of increasing the context window to the point where the LLM forgets it. At a certain point you have to ask yourself, if I know what needs to be done and how to do it, why am I spending time arguing with the LLM instead of just writing the code myself?
The part that I find extremely valuable is using LLM's as a replacement for searching code documentation. If you're new to something, you don't always know how to phrase your search query. The LLM's do an excellent job at translating your novice-level language into the precise terms you need. This saves a lot of people's times. You don't have to ask your question on a forum or to your colleague, saving not just your time, but everyone else's time. That's a big gamechanger. We can spend more time on the task you care about and not on all these tertiary side-trips.
What I find extraordinarily disappointing, however, is the industry's reaction was not "Oh wow, look at how much more productive we can make our programmers.". The industry's first reaction was to tokenmaxx and make the LLM's do everything, from writing code, submitting issues, design, etc. It leads to codebases that seem fine on the surface, but as you study the code, you find all sorts of issues. As these issues get discovered, the LLM then has to fix a bunch of different code, which leads to these infamous thousand-line PR/MR's. Even if LLM's produce code that works, remember that the quality of the LLM's output degrades when the context window reaches a certain point, which will start costing you more in terms of technical debt, bugs, and the literal token cost. It's also worth pointing out that companies that provide LLM's are still not profitable, so when the arms race between Google, OpenAI, and Anthropic settles, we're going to see the real cost to run these LLM code harnesses, and it just might make you pause and think before reaching for the LLM again. On the other hand, if the cost of hardware finally comes down, running your models locally would be a viable option, so you only have to worry about the upfront costs and the electricity bill.
With all that said, I think there's a bright future with LLM's. They are extremely good at pattern matching, and I think the real business value is in the use-cases that fits cleanly into that role. LLM's might not be the best at writing code, but they're exceptional at finding issues with your code. Case in point, OpenAI recently published a ton of fixes for root privilege exploits in the Linux kernel. I think spending our time constructing and training LLM's on how to discover issues for your particular domain will provide far more value that simply having the LLM write code for you.
larsfaye 8 hours ago [-]
Great comment. Similar experience here, although I wouldn't say I rewrite the code I receive from LLMs. I tend to delegate work that is specific enough and has enough existing patterns to follow that they end up producing nearly identical code to what I would have manually produced.
datadrivenangel 2 days ago [-]
I find Jonathon Blow to be insufferable, but this is a good talk with good opinions.
gunslinger_meta 1 days ago [-]
Is it because he's not a leftist or some other reason/s? If the latter I would like to hear it.
biophysboy 1 days ago [-]
The issue is not so much that he’s “not a leftist” as it is his arrogance. He thinks his knowledge extends well beyond his very real skill at game development (the witness is a great game!). One example is his very confident takes on “lab leak” that have not held up.
(HN is also a very big fan of this hypothesis, without realizing it has gotten weaker with time. In their defense, I don’t think anyone wants to think about COVID anymore)
1 days ago [-]
saberience 1 days ago [-]
He's possibly the most arrogant person I've ever encountered in real life.
He thinks he's the foremost expert on basically any topic, from literature to politics, to science, to videogames etc.
biophysboy 1 days ago [-]
Elaborate on this real life encounter! I am curious.
NSUserDefaults 1 days ago [-]
You do not talk about Fight Club..
KingMob 23 hours ago [-]
Way too many techies believe they're secretly Renaissance polymaths.
Domain expertise rarely transfers to other domains. You, the random developer, are not going to have brilliant insights on the law, environment, consciousness, politics, or even another area of tech you don't use, by thinking about it for 5 minutes from "first principles" before commenting.
bena 1 days ago [-]
Does he have game development skill? Or did he get lucky with Braid?
Because the Witness is a tedious slog, as is Order of the Tediously Long Title.
The hardest part of the Witness is the fact you aren’t told the rules of the line-drawing puzzle you’re presented. But often, they’re not that hard to discover. It’s not half as clever as Blow thinks it is. It’s essentially “what number am I thinking of”? Then being called a fool when you didn’t guess 12,859,155. Cool.
renehsz 1 days ago [-]
What you're calling the hardest part is precisely what makes Blow's games so amazing: The Eureka moment of understanding the concepts behind a puzzle is incredibly satisfying.
Why would you want to be told how a puzzle works if you can discover it yourself? Tutorials are boring, discovery through trial and error is exciting.
This doesn't just apply on the level of raw puzzles, but also on a meta level where you start understanding the ideas and concepts behind the puzzles, and then the absolute best part when you understand how these ideas and concepts interconnect (or are related or mirror each other, no pun intended).
Also, I find that his games aren't tedious at all. Sure, you might get stuck on a puzzle occasionally. But then you just go somewhere else and come back later. Or you go to sleep, gain the critical insight in your dreams, and then solve the puzzle. (I'm not kidding about that! It works wonders to sleep over a puzzle.)
I have not experienced any other games that's are as enjoyable as Blow's, not even close. But of course different people have different preferences.
If you don't enjoy the thinking and figuring things out, then maybe these games aren't for you. But every curious individual who loves playing with and enhancing one's mental understanding of abstract ideas, should absolutely play Blow's games.
bena 1 days ago [-]
In the very next sentence I say that they’re often not hard to figure out.
I get more of a “Ah, ok” rather than a “satisfying eureka moment”.
All through your post you are assuming I’m getting stuck or “don’t enjoy figuring things out”, which I find presumptuous and condescending. Because, I’ve not had much problem with the figuring things out. It’s more with the repetition. You get a rule, then you get a couple dozen puzzles with slight variations of that rule. It’s tedium.
And Order is sokoban. Just, like, a lot of it. And even what you could claim is clever gameplay in it is just cribbed from the games he implemented.
They’re average games. They’re ok. They are not mind-expanding journeys into the very nature of the meaning of puzzles.
renehsz 20 hours ago [-]
> All through your post you are assuming I’m getting stuck or “don’t enjoy figuring things out”
I should have made it clear that I was referring to the generic/impersonal "you", the HN readers, not "you" as in the specific account I was replying to. Sorry about that! I should have worded it more precisely. It certainly wasn't meant to be condescending.
Re puzzle difficulty in The Witness, this is the part of your previous comment that confuses me:
> The hardest part of the Witness is the fact you aren’t told the rules of the line-drawing puzzle you’re presented. But often, they’re not that hard to discover. It’s not half as clever as Blow thinks it is. It’s essentially “what number am I thinking of”? Then being called a fool when you didn’t guess 12,859,155.
I might have misunderstood this paragraph the first time I read it and wrote my reply. But now that I've read it about ten times, I still don't understand what exactly you're referring to.
On the one hand, you say that the rules often aren't that hard to discover. Fair enough. On the other hand, you compare it to guessing the number 12,859,155. I took that to mean the rules are very hard (take a lot of tries) to guess correctly.
I don't remember the latter being true at all. There is some guesswork initially to discover the rules, but those rules then apply to a lot of puzzles, and different rules combine to form larger and more interesting puzzles.
What I personally found most satisfying was eventually gaining a meta-understanding of how the rules are structured, and sometimes being able to predict what the new rules for a set of puzzles will be, taking away the guesswork completely.
(Granted, it's been a long time since I played the game at release, so maybe I'm misremembering things or viewing them through a lens of nostalgia.)
> And Order is sokoban. Just, like, a lot of it. [...] They are not mind-expanding journeys into the very nature of the meaning of puzzles.
For me personally, Blow's games have been mind-expanding. But I rarely play puzzle games. If I did, I might already be familiar with a lot of these ideas and find the puzzles boring. For me, the difficulty was just right. But I can imagine that people who play a lot of puzzle games need more to find something interesting, and that's fine.
So if your criticisim is that the puzzle rules aren't interesting or sophisticated enough for some people, then fair enough. They are interesting enough for me, though, and judging by sales and reviews, a lot of other people feel the same.
Either way, none of this is meant personally, I just enjoy talking about these games. Also, I can't speak to Blow's politics or other opinions people have brought up elsewhere in this discussion. All I can say for sure is that I've really enjoyed his games, and other people might too.
tialaramex 18 hours ago [-]
> you compare it to guessing the number 12,859,155. I took that to mean the rules are very hard (take a lot of tries) to guess correctly.
The puzzles in The Witness can be obvious from a certain perspective and so then if you have that perspective there's only one answer, why can't everybody see that. But if you lack that perspective, or worse, have slightly different perspective which you have falsely believed to be correct, you struggle.
If I know every US sports team's nickname then a Connections solution which hinges on knowing New York's team names seems obvious. If I didn't even know who the "Yankees" are then I'm going to find that particular connection hard to understand. Likewise if you know Lead's atomic symbol is Pb then you're going to more easily see that the letters PB might be related to a clue you had previously thought was about the verb "lead" not the noun.
tialaramex 19 hours ago [-]
So, two things can be true simultaneously.
That "Eureka" moment you describe is what puzzle makers are striving for, which is why e.g. Portal 2 has a hack where either portal button will save you in a situation where players may realise "Oh! A portal can save me!" but forget which end they need - just dying because you picked wrong isn't satisfying. This isn't Wolverine - if you just stubbornly don't use a portal you will die - but if you flail and pick orange when you needed blue the game has mercy on you.
However, Blow doesn't seem to have yet understood that the skill isn't in making the puzzle difficult and having a "Eureka" moment for some players but in designing your game to maximise this experience for the most players.
You can learn about this more easily playing "Zendo" https://en.wikipedia.org/wiki/Zendo_(game). A master who invents a rule their player cannot discover isn't a good master, that's just frustrating for everybody, there is skill in choosing a rule that will give your players the "Eureka" moment.
Two recent-ish video games stick out in my mind for delivering on this in very different ways. The first is Blue Prince. Blue Prince really wants you to figure out what's going on and have those Eureka moments. I have seen one gamer go "Bridge. Bride. OK I see what we're doing here" in their first five minutes of the game. I have seen a different gamer go "Yes, yes, a map of the house and more riddles, but what does it all mean?" while standing in the Study still not having understood the exact same puzzle... Tonda designed the game to be enjoyable for both players.
Secondly, Fleb's games, most obviously "20 Small Mazes" and its sequal "20 More Somehow Even Smaller Mazes". This time rather than offering many, many clues, the game delivers Eureka at pace by not forcing you to solve increasingly complicated versions of the same puzzle as "The Witness" does but instead you go from not understanding to then figuring it out and at about the time you go "Eureka!" the maze is solved and the next one is different.
That meta-stuff you mention leaves me cold because it's just introspection and I can do that without a video game. If the video game needs to fit in a Commodore Vic 20 (a machine with 4096 bytes of RAM, yes I said bytes) then sure there's no room to do more, giving me pause to reflect on my own beliefs is maybe the best you can do. But games like Animal Well show that in a modern video game you can, and I argue you should, actually put more game in the game, not just sit back and tell players their thoughts are part of your game. "The Witness" has moments where you think "Ooh, maybe there's more game in this game" but no, Jon couldn't be bothered to deliver more game, that's really your job apparently.
dsego 17 hours ago [-]
It was masterfully analyzed in a youtube video review titled "The Witness - A Great Game That You Shouldn't Play"
https://youtu.be/KZokQov_aH0
gunslinger_meta 1 days ago [-]
The Witness & Order of the Sinking Star are great games, the fact that you personally do not like them does not take away anything skill-wise from him.
bena 1 days ago [-]
They are not great games.
Especially in The Witness where there are times where failure of a puzzle forces you to re-input previous puzzles. Or there are a couple of dozen of the same puzzle with only minor variation with the same rule. "Yes, I can draw an L", "Yes, I can draw it backwards", "Yes, I can draw it and a cube, truly a masterfully built puzzle".
dezsiszabi 16 hours ago [-]
They are great games. I win.
gunslinger_meta 1 days ago [-]
Tell me you haven’t played a game without actually telling me you haven’t played it.
bena 1 days ago [-]
Because I have a different opinion I couldn’t have played the game?
biophysboy 1 days ago [-]
Respectfully disagree! I really enjoyed discovering the rules in each biome. even if it led to some tedious trial and error now and then
patrec 1 days ago [-]
So, I generally like Jon, but he can be an ignorant blowhard and this typically does not diminish his supreme self-confidence or rudeness (see e.g. https://x.com/stylewarning/status/2028976562544988476). I don't think this is the only instance where he blocked someone who politely pointed out a technical error either.
swiftcoder 1 days ago [-]
I found his tech opinions pretty insufferable well before he started mixing politics in.
Something about the lone programmer off goat-skinning every aspect of the tech stack, while telling you how you are writing software wrong...
1 days ago [-]
biophysboy 1 days ago [-]
People say that failure tests your character, but I think success is the bigger test. Jonathan thinks that because he made some genuinely excellent games, we should also listen up when he has some new renegade opinion. We shouldn’t!
lofaszvanitt 1 days ago [-]
What, Braid? That was a clownfest.
dezsiszabi 16 hours ago [-]
Well, the majority disagrees with you. I think it was great.
lofaszvanitt 3 hours ago [-]
Big ego, slim creativity. That's JB.
renehsz 1 days ago [-]
Alright, let's listen to all the people who have never successfully shipped a product instead! /s
Track record isn't everything, especially for people early in their career, but when somebody ships successful products as consistently as Jonathan has for decades, that can no longer be ascribed to luck or anything like that. There must be some far-above-average skills involved.
rixed 24 hours ago [-]
That's not how statistics work.
threethirtytwo 1 days ago [-]
It didn’t solve coding, it solved humans lol.
tonymet 1 days ago [-]
It takes an entire business to publish a software product, not just engineers. It’s been a misdirection to blame engineering for productivity issues. If anything, the legal team contributes much more of the sloth, complexity and lethargy than the engineering team.
Legal has much more authority , and far less familiarity with the product, or even the customers. So they demand orthogonal, complicated and impractical requirements that are not even beneficial for risk mitigation. And they are slow at providing them – usually the bottleneck.
It’s not a simple LOC/day formula. If Southwest Airlines wanted to make major software improvements tomorrow, it certainly wouldn’t be the engineering team armed with Claude Code holding them back.
anfilt 1 days ago [-]
That's not every business though, but I do agree for businesses like airlines, banks etc...
tonymet 1 days ago [-]
tech is smothered by legal too.
kylehotchkiss 1 days ago [-]
Imagination crisis. The people who understand how to architect software are spending their free time on social media saying "%%% IS INSANE" or something about "I one-shotted this %existing thing%".
The people who said building software wasn't the hard part before were right, you still need interesting problems to solve to find interesting things to build. Gotta get out of the tech bubble to find those. There aren't many interesting problems left to solve for other tech bros
pton_xd 1 days ago [-]
Yeah, all of this power at our fingertips and all I see is "look I ported this 20 year old game to WebGL, and added Mario!" and other such unimaginative projects. There's very few actually novel / interesting things being built right now, as far as I can tell. For once I think you can blame our collective imagination rather than a lack of capability. Apparently creativity has not been solved yet, and being creative is still hard. And most people aren't up for it, which is the same state of affairs as before AI.
Crabber 1 days ago [-]
I would say that a lot of creativity comes from mulling over an idea in your head for several days, which AI completely eliminates.
kaffekaka 21 hours ago [-]
Very much this. AI removes obstacles and gets you unstuck, but this is a curse as well as a blessing.
dennisy 1 days ago [-]
I would also argue we are becoming less creative, due to our over-consumption of AI generated content. So many startups look the same nowadays.
shevy-java 17 hours ago [-]
This is a strange take though, because ... if AI can
produce working software, such as a linux kernel
replacement or a replacement for MS office, why would
any human be required? And if it does not work right
now, what if in 5 years?
Quality may be an issue but one could assume that any
models will be improved. Complexity in the software
itself is not really a huge issue for any good LLMs,
so I don't understand this take he presents as "humans
will always be better". It's like standing on the Titanic
and saying "nothing to see here" while it is sinking, just
as in the old movie Naked Gun (https://www.youtube.com/watch?v=NuAKnbIr6TE).
saberience 1 days ago [-]
The thing with Jonathan Blow is this, it's incredibly easy to tell ahead of time what he will think about any particular subject.
Anything that makes code more available to "normies" is something Jonathan Blow will absolutely hate. Why? Because Jonathan Blow HAS to be the smartest guy in the room, if he's somehow not the smartest guy in the room, there is something wrong with the room, nothing is ever wrong with Jonathan Blow.
So of course, Jonathan Blow thinks AI coding is terrible, only Jonathan Blow can be the best coder in the world, anyone who thinks otherwise is a total moron.
If you don't hand-roll your own programming language and game engine to make your own game, you're a moron. Hell, he even has a video where he basically says if you don't make your own version of JSON and associated parser, you're a fucking idiot.
What I'm saying is this, Jonathan Blow's ego only sustains itself on the idea that he is right about everything and the smartest person on any given topic. The idea that AI might be better at coding than him causes him to implode in a narcissistic rage.
pzski 1 days ago [-]
Accurate evaluation. People like JB are hit the hardest by AI revolution imo. I also think that it is understated just how many people in academia or in other fields care only about their ego and that they might do something they are going to be remembered forever for aka have a legacy.
dgellow 1 days ago [-]
He was already arguing the same before the AI developments. His position has little to do with agentic evolution
rixed 24 hours ago [-]
You might be right about some of these things, but you made this guy sounds sympathetic to me.
This industry has been disparaging quality and efficiency in favor of servile laziness and cheap ignorance for so long, and it feels refreshing to hear that some people are still fighting against that trend, risking going too far like this article certainly does.
Yes, of course, if you are using json in a data pipeline then you may not be a moron but in that moment you are doing something idiotic. Yes of course sometime the right decision is to create a language specific for a given task, and if you have never considered it you should question why.
Dezvous 1 days ago [-]
You're not alone, I find him to be completely insufferable.
jojva 1 days ago [-]
Funny, I independently arrived at the exact same conclusion. He's incredibly easy to read and predict because every single opinion he holds is based on his ego.
Like for example, when people ask him why he developed his own engine for his games, he'll answer that it's because other devs take shortcuts and he doesn't. But dude, the entire point of not making your own engine or language is not because anyone's lazy, but because it allows you to focus your precious time on more important stuff like the actual gameplay, the story, etc. Maybe then it wouldn't take more than 10 years to release a video game.
benjiro29 16 hours ago [-]
The thing is, making your own game engine can be beneficial because a lot of engines are so general that you may lose a lot of performance benefits. We have seen this issue with how custom engines pushed the boundaries of games to a extreme, but when games moved to cookie cutter engines because it was cheaper (well, that has changed also), but in return they ran into issues with limitations on the engines or performance issues.
Now with LLMs the entire "make your own engine that is optimized for your game" is ironically back. But people like Blow balk at the idea that a LLM can make a game engine.
dezsiszabi 16 hours ago [-]
I don't really care why he does his own engine or language. "Because I wanted to" would be a sufficient amswer to me.
nsagent 1 days ago [-]
If he was honest with himself, he would rightly say he did those things for his own edification. If you have the time and ability. As someone who also cares deeply about his craft and spends more effort than I probably should improving my personal tooling, I'm clearly all for it.
Is it strictly necessary? Most certainly not. I've met equally dedicated and talented individuals who are fine adapting to existing tooling and working around idiosyncrasies rather than improving the tooling. That personally drives me batshit, but I can stomach it if required.
willdr 21 hours ago [-]
He also decided to wield this new language that is God’s gift to game programming to build… a block-pushing game?
djaro 14 hours ago [-]
That's the confusing thing to me. At least with a game like Factorio they made their own engine because they had to simulate thousands of machines and millions of items moving around each tick. But a sokoban-type game with cartoony graphics, that would be fine on off-the-shelf Unity or even something like Godot. Like, I've played HTML5 games with more demanding graphics.
dezsiszabi 16 hours ago [-]
A very good and large Sokoban game though. I've been playing it since release and still only at 460 puzzles. The counter goes up to 920 as far as I know.
It's also very well designed in my opinion. Love the way the ideas are introduced and built on top of each other.
bena 1 days ago [-]
And he likely spent a good portion of those 10 years making sure it had "most pzzles evar" as if the only difference between quantity and quality was spelling.
CountingCount 1 days ago [-]
Having played his game with the "most pzzles evar" I do think many of them are also consistently high quality. That said 10 years for this game does seem excessive.
KingMob 23 hours ago [-]
Writing your own language/engine is the province of wealthy dilettantes and those with day jobs.
Blow can afford to work on his lang and game for 10 years, but most people can't.
ModernMech 14 hours ago [-]
This is why he's refused to publicly release Jai despite it being in a working condition. As long as he holds it behind a gate, people say "Jai is an interesting and mysterious language". He can talk about it and share what he wants on his own terms, it a control thing. As soon as he releases it, it gets benchmarked and compared against everything else on everyone else's terms.
superkuh 24 hours ago [-]
My daily home desktop use involves a handful of Perl Gtk2/3 programs "I" vibe coded over the last year or two. And even some android programs for my dumbphone. But Jonathan Blow doesn't know about those programs because they're for me alone and they're not for profit at some corporation.
This is one of big changes with useful coding LLMS: each human person can have their own software to scratch their own itches. Corporations don't need to provide them. It's okay if they only work for me on my machine because they're only for me. They can be slop and still fulfill their much more limited goal(s).
jdw64 1 days ago [-]
I'm not sure if the software is really the same, but there are a lot of AI slop games, and also a lot of well-made AI games. The graphical improvement in recently successful indie games is astonishing. Realistically speaking, in the past there were many cases where people weren't good at shaders, but there are also many points where optimization has improved. At the art asset level, even if AI isn't used, there are many cases where the code is now far better optimized than before. When I decompile the recent code of indie games whose animation implementation was terrible in the past, I often find it genuinely impressive.
Realistically speaking, AI raised the average quality. Among today's AI slop games, there are many that would have been "at this level of quality, this game could succeed" in the past.
Realistically, that's how it is. So there will be many people telling bad-luck stories like "ever since AI came out, GitHub has stalled," but I think that's closer to the opposite — AI increased production so much that the supply chain itself can't keep up.
The thing is, I can't really agree with the claim that software is the same. I don't know about open source, but when I think about the state of code in code delivered to clients, I think there has been a dramatic rise. Separately from that, because products are pouring out, I think consumers' quality demands are rising far faster than production. Comparing early smartphone games with today's AI slop games makes this even more palpable.
dominotw 2 days ago [-]
I was talking to my friend yesterday about what exactly has AI changed for us. Our lives are still the same( actually worse from job loss anxiety). If this tech is so revolutionary how come nothing in my life has changed positively.
My friend is in managment at faang and he said ai has changed how tech coders now behave at work. he is enjoying the fact that "their tails have been cut by AI". Made his management job infinitely easier.
why is this downvoted?
switchbak 1 days ago [-]
> he is enjoying the fact that "their tails have been cut by AI"
Manager. FAANG. Enjoys the misfortune of the people he manages. Your friend sounds like a prick to me.
ramity 1 days ago [-]
Because improvement in human QoL is not a requirement for a revolutionary technology. Nuclear weapons come to mind.
We're talking about something that speculatively invalidates all digital data. All code created prior is seen with lesser value to the point of commodification because of its existence. We are past the slow erosion of trust of the photoshop or Wikipedia era. You can't trust anything digital anymore. Encryption is our last hope, and companies now join governments in the race to break it.
Perhaps a bit of a leap but based on their phrasing, I'd be very critical of a viewpoint in management who believes themselves immune from what's occurring to specialized talent across the board. We are intergalactially far away from IBM's "never let a computer make a management decision." A concerningly large number of people submit their data, thinking, and agency to these tools. The impact is real even if not personally felt or in your backyard.
yesb 2 days ago [-]
I think that has more to do with the job market than "AI". All my coworkers have become yes-men due to perceived job insecurity. Not sure this is a positive thing even if it's superficially appealing to a middle-manager.
bluefirebrand 1 days ago [-]
> My friend is in managment at faang and he said ai has changed how tech coders now behave at work. he is enjoying the fact that "their tails have been cut by AI". Made his management job infinitely easier
Yeah, I see this attitude a lot. People seem gleeful that software devs are getting kicked in the teeth, but honestly the business practices in software already have been kicking my ass my entire career. I've never felt like a respected, valued individual at any company I've worked for. I've only ever felt like an assembly line worker and accountability sink for my bosses. Someone to pile shit on, and then blame if stuff goes wrong.
My career has been full of overtime, evenings and weekends, overnight deployments, crunch time, layoffs, and for most of it I wasn't even making lots of money. It's only a couple of years ago I started making more than six figures, and now I'm laid off again and wondering if I'm even going to manage to get another job at all, nevermind one that pays as well.
I made the wrong choice in careers twenty years ago, tell you that much. Now I don't know what to do, but people are happy my tail has been cut, as if they haven't already been kicking my ass for ages. :/
Hard to feel anything but resentment anymore
geodel 1 days ago [-]
Agree. And this is the change I more or less expected. Living to the full potential of anxiety, job loss, further loss of autonomy at work for code types like me.
The direction was clear for last 2 decades with every little feature broken into dozens upon dozens of tickets for better management . And now with AI each JIRA story can have its own design doc, testing doc, usage guide and so on. And management does seem happy by increasing number of artifacts which implied quality work done.
XorNot 19 hours ago [-]
I think even the zany pro-AI types usually come up with "the motorized horse" rather then the automobile.
We've had a lot of hype cycles, but I'm honestly of the opinion that at least in terms of coding, this is somewhat like the consequences of if we invented say, the Star Trek Transporter.
That show notoriously struggles to really show that device at it's full power (because it was invented to solve a budget problem) - whereas if you think about it, the Transporter basically should've been THE reason the Federation had the power it did.
drcongo 2 days ago [-]
So your friend's life is not still the same?
fasterik 2 days ago [-]
>If this tech is so revolutionary how come nothing in my life has changed positively.
That's a bit of a myopic view. Imagine someone asking the same question a few years after the invention of the printing press.
It's not hard to find examples of how AI is changing things. To take just one example, look at how it's revolutionizing research in science and mathematics. I wouldn't expect this to change the average person's life overnight, but there are absolutely going to be huge breakthroughs in the next few decades.
shooly 19 hours ago [-]
Most of average person's life struggles are not a result of lack of breakthroughs in science or mathematics. Similarly, most of problems with modern digital services or products are also not caused by lack of breakthroughs in engineering or technology.
We already know solutions to many current problems, and we knew them before AI - but those solutions are not being applied by people who are in charge. AI won't change those peoples' incentives.
fasterik 10 hours ago [-]
Almost all of the improvements in standard of living over the past 400 years have come from scientific breakthroughs. Newton's laws probably seemed like an abstract mathematical puzzle at the time, but we wouldn't have steam turbines or skyscrapers or modern transportation without them. There are similar stories for advances in agriculture, medicine, energy distribution, communications, and the list goes on.
Most jobs that people do today in advanced economies wouldn't exist without science and technology. It's bewildering that this needs to be explained on HN of all places.
shooly 7 hours ago [-]
It's bewildering that you cannot even read the entire comment before you reply.
fasterik 6 hours ago [-]
I did read it, and I responded to the specific claim you made about the extent to which scientific breakthroughs affect day to day life. It's pretty obvious that scientific progress does in fact change many aspects of life, including how long people live, the conditions they live in, and the kinds of work they can do to make a living. For the rest, I'm not sure what to respond to, since there are no specifics or examples given, just vague platitudes. On the other hand, you haven't responded to any of the specific points I've made, so I could just as easily claim that you haven't read my posts.
ReDress 17 hours ago [-]
[dead]
matthiasforstr 15 hours ago [-]
[flagged]
imranjavaid 16 hours ago [-]
[flagged]
alazsolutions 18 hours ago [-]
[flagged]
BuildPeter 17 hours ago [-]
[dead]
mollyrasmussen 20 hours ago [-]
[dead]
LdBaringSwallow 1 days ago [-]
We did have 30 years of software advancement; LLM are the next step. I would argue what we didn't have was 30 years of hardware advancement as everyone bought x86_64
Blow and coders have a hammer so all they see is nails; it didn't "solve coding" AI solved "machine state management". Totally different; human tagging/coding will still exist just at the presentation layer cause we don't need a bunch of syntax like:
def sumAllCustomerAccounts() {
Some desired physical state of machine based on mathematical axioms
}
AI solved naming that function (the coding with human context part) with
f() { generate a function to add all customer balances}
We moving on from 1960s and 70s machine state management, pushing context coding to the presentation layer
Blow is just doing that thing humans do where they wrap their entire identity up in who they were 30 years ago and still think that's who they are today and will be tomorrow; rotary phone companies, bowling alley equipment manufacturers... new generations are superseding them... circle of life Simba
Not really gonna put Blow and Carmack on a pedestal; they never invented computers or software dev. They came along in the middle of the hype. The read the manual for old machines. We're just moving on to new kinds of machines.
People flipped out over the printing press too. Nothing to see here; it's just the upper bound of the middle age generation having a mid-life crisis
cmrdporcupine 15 hours ago [-]
The HW advancement was much actually stronger than the sw advancement, very clearly so. It just happened behind the facade of the x86_64 and ARM64 ISAs so it was partially "invisible" to software developers.
movzart 1 days ago [-]
Machine code -> assembly -> C -> Python -> plain English. AI might be the highest-level language yet. The catch is it’s the first one that isn’t deterministic.
ares623 24 hours ago [-]
Wake me up when you push markdown files and let Jenkins re-generate your program on each push to master.
blini-kot 1 days ago [-]
because you are an internet clown and not the messiah of software you think you are?
there are many people to take their opinion on code seriously, and mr.Blow is certainly not one of them
The systems analyst analyzed the problem that needed to be solved and designed a solution involving a computer, including system modules, inputs, outputs, etc.
The programmer, supposedly a lower paid profession, transformed that into Computer code. I remember someone telling me that wasn't the best choice and that I should become a "systems analyst". They wore the better suits.
My college even offered a shorter, cheaper degree for people who just wanted to be "programmers".
I think this distinction still survives in government labor statistics.
Perhaps we came full circle with LLMs partially killing the "programmer" job.
I regularly meet (recently examined) people who are trained "software architects". Common among them is that they are often delay projects championing their pet idea, sometimes bringing negative value to the project. The best programmers are just so much better software architects also. So I expect history to repeat at this point.
You don't forget CS concepts so easily, but all the syntactic tricks of new language variants and working set vocabulary of APIs, data formats, and frameworks keeps churning away from whatever you last had contacted in a real, hands-on way.
It is fascinating, wondering where this is going as programmers turn into their own middle managers on top of agents. Particularly, the school who claim that you don't really need to understand all the code and instead treat it like a black-box experiment. If this fad takes over the main stage, then everyone becomes one of those less technical managers.
But, in this new scenario, there is no human in the loop to inject judgement calls and "manage up" anymore. There is no programmer culture except the models and agents, which don't really have the same social connections to drive a programming culture. What will happen? A culture per agent product? Per enterprise client of the agent vendor? Per agent operator? Per codebase?
About half a year ago I noticed there were no people called 'Agile something' at our org, so I asked about it. They looked at me like I was a space alien. I remember, it was like 3 years ago that management bet the house on 'Agile transformation' talking about how Agile practices are the bread and butter of a good organization.
Now they're talking about AI the same way.
The memo has NOT gotten around, though AI now makes it easier to make all the various slide decks and schedule all the 50+ person meetings that power this process.
Negative value to the project, perhaps; but if these "software architects" are kept around despite several rounds of this, it may be because they're providing positive value to the company, in terms of producing for the company a thing whose existence (no matter how flawed) serves as collateral for:
- the executive team, to show to investors, to convince them that they're acting strategically in the market; or
- the marketing team, to get breathless puff-piece articles written about the company, in places where dumb CTOs/CIOs who make IT buying decisions will read them. (Not necessarily to then buy the specific product that came out of that project — hopefully not, in fact! — but instead to remember the company itself the next time they're comparing vendors for something else);
- or the executive team again, this time to show to a potential acquirer, to convince the acquirer that their employees have a higher asset value for having a certain skill / experience with certain paradigms, that they gained working on this project.
Companies have spent collective billions (trillions?) of dollars on projects they know will go nowhere, just to be able to say they did a project that is made a certain way or does a certain thing or has certain certifications, and to have a shitty codebase they can pull out of their back pocket if needed to back that up. In all such cases, even if they need to present the product, the product will never be evaluated for its quality or for its fit-for-purpose-ness; so it doesn't matter that the project failed to produce something of quality or that is fit-for-purpose. It just matters that the project happened.
Words are just words. In tech especially, it seems anyone can call themselves whatever they want.
Someone who chooses to call themselves "programmer" can be more engineering-minded and see the big picture better than someone that calls themselves an engineer.
I also started out in systems programming and we still call ourselves programmers there, when there is a lot of systems "engineering" (aka trying not to blow up the system with your code running in supervisor state) going on. And there, a lot more attention paid to stuff like IEEE code of ethics, professional development, rigorous designs, etc.
So I'll keep to calling myself programmer amongst my non software engineering friends. It just seems more humble.
That being said, writing the code has like others have pointed out, never been the largest part of the job in my experience. So I can see how it may be confusing to some, especially software engineers. But to non software engineers I think they mostly get it...you are a software engineer trying not to imply some some sort of unearned intellectual superiority.
Who's laughing now? Who still has a job now?
I think both definitions are still too narrow for what I do daily. I fully agree that we still need humans to decide what to build, how it should all fit together, etc.
But both definitions do not really take into account the huge social dimension of being a good (computer) engineer in a company. You have to translate requests from a wild variety of users into what this means for a system. You have to recognize and explain that what they need is not always what they think they need. You have to be able to say "no" to things. All these things are very hard for an LLM (reading humans, not literally following requests).
Then there are social aspects like building consensus within a project, building a user base of many people that are initially skeptical, using existing relations with people and other companies to slowly adopt what you are building, etc.
Programming used to be a large chunk of the work. I thoroughly enjoyed this aspect of the work when I was younger, but at some point I started enjoying system design and everything around it more. So in that sense, programming with LLMs is much nicer (though I still review every single line of code and often have to go through a couple of iterations because even Opus 5.5 often doesn't get it 'right' in the first take). But the remaining part of the work is extremely hard for an LLM to replace.
How do you justify saying "no" when there is a magic machine invented 3 years ago that'll do it? Your gut says it's a maintenance nightmare, your LLM says it's already done implementing it.
But there's a more general kind of "systems analyst" that still survives (and is mostly what the BLS stats refer to): a person whose job is to map out the current business domain of a system (consisting of not just computers, but also people, infrastructure, institutions, etc.) and identify where it will need to be modified (but not necessarily how it will need to be modified) to make it capable of being put to use in a certain way for a given plan/mission.
Systems analysts in this sense tend to be one of the actual workhorse jobs inside "management consulting" firms and "think tanks." Governments, militaries, and large bureaucracies with many independent business units (think IBM) are their customers.
Systems analysis is sometimes done structurally over an entire organization: someone at a very high level has some new vision for an initiative, and hires these companies/think-tanks to help them determine how to "align" their organizational architecture with what a military might call a new "doctrine" or a company might call a new "paradigm." In these cases, the systems analyst performs the first step of that alignment: understanding "the system as it is today", and identifying what parts of it are already aligned vs. which parts will need to change. Their output is a report to the person driving the process.
But structural analysis is more often applied to specific strategic/business units, as the result of that strategic/business unit being chosen to execute a given strategic mission, as an enablement process to get that unit into the specific shape it needs to be in to execute that mission. In this case, there is likely an assigned "mission {planner, architect}" (who may also become the mission's director; or who may hire for such a director role and then depart to go plan the next mission.) The systems analyst works for/with the mission planner as their "eyes and ears", interacting with the business unit to gather information for the planner to use.
In both the structural and strategic cases, there are usually also one or more systems engineers who determine the "how" for implementation of these changes. (A mission planner is usually a very senior systems engineer themselves.)
However, unlike the systems analyst, who is considered more trustworthy to central leadership when they exist outside of the system they're analyzing (and so mostly work for external firms like think-tanks rather than for the orgs themselves), there's much less of a motivation to separate out systems engineering in that manner. So systems engineers (including mission planners!) tend to be regular [if high-paid] career employees of the central organization. These folks are frequently "general staff" in a military (with no real analogous term, AFAIK, for the equivalent people within a conglomerate's parent company.)
Due to their value coming in part from existing in separate firms that can negotiate on their behalf, systems analysts in this sense are well-paid indeed! But also worked hard, bounced around, and signing NDAs constantly. And possibly a bit bitter, in that they often see how things are broken with no chance to be part of the fix.
This is not legal advice but allegedly lawyers were instructing CSA category TN applicants to never ever mention that they are “coding” or “programming”
Milt realized as early as the 1970s, if not long before, that programmers had way too much power in an organization because most organizations adopted a "tool-oriented approach" to computer technology: here's a tool, how do we make use of it? They let the programmers run wild, and the result was software that was a buggy mess. What's needed is a management-oriented approach in which the management of the company calls the shots on what's needed for the company to function.
In PRIDE, the systems analyst is centered. This is explicitly a business role, not a technical role, and their job is to understand the business in such a way that the information systems (not programs, nor apps) that drive the business can be described in diagrams and text. Only once the requirements, definitions of terms, and data definitions have been established and standardized can the implementation phase begin. Bryce estimated that if you're not spending 65% of the effort in systems analysis and only 15% of the effort in programming, you're doing it wrong.
This is how grown-ups did information systems for decades. And then the internet happened, "hacker culture" happened, and the programmers were back in the driver's seat, producing things like "Agile".
Now we have AI, and to quote another commenter elsewhere in the thread, the programmers have had their tails cut off. That 15% number asymptotically approaches zero. But the systems analysis still needs to be done, and for the foreseeable future anyway, that needs a human touch.
Become a business person, not a "software engineer". They are the ones who will drive things forward in the agentic era.
Maybe that will change with LLMs, but you’ve got the causality arrow backwards. Systems analysts didn’t disappear because of Agile; Agile exists because that way of working didn’t work.
Source: I was on the front lines of the first Agile wave starting in late 1999.
(And then what people actually adopted as “Agile” generally wasn’t what was created by the first wave of the Agile community, but that’s a whole ‘nother topic.)
A counter to this is "requirements change quickly, therefore the system needs to change quickly too." But the actual case is: most organizations don't really know how to do systems analysis. So this results in one of two scenarios: either the organization wastes a lot of time and money in the analysis phase struggling to do what they cannot, or they punt on requirements analysis altogether and wait for requirements to surface at implementation time. This is called "Agile" today, but was described by Milt in 1983: "do a superficial feasibility study, do some quick and dirty systems design, spend a lot of time in programming, install prematurely so you can irritate the users sooner, and then keep working on it till you get something accomplished."
Today, with AI, there is no reason not to do requirements analysis and design first. An implementation phase that used to take months can now be performed in weeks or even days. So an executive who observes shifting requirements can document them, work with an AI to update the design specification, and then have a swarm of agents perform the implementation work, and roll out the new system before next quarter if not next month. So Agile really isn't necessary anymore.
PRIDE is like a textbook on how to build a system, from requirements analysis through design, implementation, and maintenance. It was the first methodology for doing so, and it transformed information systems from arcane art into a proven, repeatable science. It should be the industry standard, but is now at risk of being forgotten, largely due to programmers holding the industry hostage.
AI is taking programmers out of the equation. PRIDE is relevant again.
This is a holdout from the time when the whole software development field was still stuck with the idea that waterfall/big design up front was an adequate way of doing things.
The belief was that, like any engineering field, systems would first be designed in detail before anyone could even open an IDE.
This approach was quickly proven to be wrong, expensive, and fruitless. Agile started to emerge as an effective approach to the problem of developing and maintaining software systems. The uselessness of the system analyst role, when contrasted with the fact that mere programmers could easily implement features without guidance from an enlightened individual far removed from the problem domain, was readily noted.
AI has already delivered huge productivity gains in my opinion; the whole StackOverflow/Google search part of my life is gone. Instead I get answers from Claude tailored to my specific environment, use-case, problem, etc. Writing well-defined, simple code with lots of prior art in the same repo is easily handed off. But the AI industry and a lot of leadership in big tech seems to be expecting further miracles from AI. Maybe one day a CEO or CPO will just be able to speak their thoughts and a fleet of agents will implement it flawlessly, but we are nowhere near that reality right now.
I think this is a different point, though. OP is saying, we haven't really made progress on the problem of figuring out what to build (and just as importantly - what not to build) and how to convey that effectively and set up the right feedback loops to get AI to actually deliver on that. Whereas you're saying, "Yes, I agree, the code that the agent writes has flaws in readability and design". If we can get the first part actually solved (and I'm not sure what an answer looks like - other than what we have today, which is that The Market ultimately dictates whether you've built the right thing, built enough, not built too much), then nobody other than the AI agent actually cares about solving your problem (readable, maintainable code) anymore. Or to put it another way, it's only in the agent's interest to solve that problem, for the same reason that today it's in the SWE's interest to solve that problem, rather than the product manager or the business owner.
I believe that LLMs will, eventually, reach a level where they can provide decent architecture, but I suspect that will suffer the same issues affecting code generation. It will be "decent," but not "awesome." I think exceptional people will still be able to beat LLMs at architectural design.
The issue is that the definition of "exceptional," means that it doesn't happen very often, and most people manage to convince themselves that they are the exception.
I don't know if this is a perfectly fair of their business model, but it has that feel in terms of dealing with them.
AI has absolutely nothing to do with any of this. It merely accelerates the "how". You still need a customer to determine everything else.
The path to success in software is varied, there is no one hallowed way. Saying everything must start with talking to customers risks eliminating a whole swath of useful creative approaches. A dev slaving away for months or years on their own pet project can still come out with something that achieves major success.
Second, I'll concede that revolutionary innovation happens primarily top-down. Common folk don't know anything about the state of combustion engines or transformer architectures, or how those can be composed into new categories of product.
Third, odds are if you're building software, you're doing nothing of that sort, but rather dealing with infinitely more modest innovation. You would be, in fact, improving a horse, if that were at all possible.
Fourth, when improving the proverbial horse, you'd better have an outstanding sensitivity to the finer problems that customers face. Whether you develop that sensitivity by asking, or sensing in some other way is another question. But asking may not be a bad idea at all.
Fifth, I'll close with an anecdote. The worst seed-stage software startup tire-fire I've seen in the last couple of years was led by a CEO that published the Henry Ford quote, verbatim. A couple years in and they still don't have a paying customer. I'll generalize by saying that I've seen pretty much everyone around me with "the don't ask, envision" attitude fail, while the people who ask or are otherwise exceptionally attuned to the customer problem do much better on average.
The quote is a great example of imagining user needs instead of just asking them.
You don't think that AI can (or soon will) be able to talk to the customer and discover what they want?
Now that execution is more of a commodity, everyone seems to be saying execution is cheap and ideas are everything.
I don't disagree with you. I'm just noting an observed 180.
I’ve never been one to trust the VC crowd without knowing where their money lay.
Derivative ideas? Like "let's make a $thing with $variant"? Yes those are cheap, and AI made them pointless to pursue because most people can now whip up a hacked up variant of $thing with GPT and be happy with it, until they realise that it didn't add that much value to begin with.
But good, truly good ideas? Those that turn everything around? Those are cheap in the sense that your brain doesn't consume that much energy having them, but they are rare.
LLMs kind of confirmed we're indeed constrained by ideas: the homepage of HN isn't full of things like "we reimplemented X in Y" because we were full of revolutionary ideas to begin with. IMHO LLMs have further hampered the spread of truly great ideas - because nowadays if you have a truly great idea you have a fork:
- your idea can be quickly implemented by an LLM. You do it, and then everybody simply copies it using their LLM.
- your idea requires time, iterations, ... so the LLM speeds up delivering it, but only a bit. We're still on a path similar than before - even before you could just hire more people and try to deliver stuff faster, as long as you had all already clearly planned beforehand.
So yes LLM are a big boon to productivity, but IMHO cast a long shadow of "why would I do it at all" on things. In the before times, I'd spend my day coding a dumb library for fun, just to brag about it a bit on Github and HN. But given that nowadays LLMs have reduced the value of code to ~0, the one thing that still has value is the idea behind. Which now people have less incentive to put out in the first place.
I'll just observe that execution remains ridiculously difficult despite AI. Even building the software itself. Then there's all the other stuff, mostly relationships (with investors, customers, employees, lawmakers, society at large) to which AI contributes nearly zero or may even cause damage if used recklessly. The amount of posts I'm seeing from VCs complaining about vibeslop decks!
(Well, they still need handholding and regularly demonstrate spectacular stupidity... but so do we, and we've been getting along just fine!)
[1] https://root.cern.ch/TaligentDocs/TaligentOnline/DocumentRoo...
It was my first years of being a "software engineer", versus the solo hacker kid who liked making art of over phone lines. So I devoured books which would teach me how to make software with other people and for other people.
Books like the "BeOS Filesystem book" (Practice File System Design) was another classic from the era [1]. It was like today's LLM white papers, learning how a company did something unique, except companies seldom published them because it was a time of IP hoarding.
Unfortunately the books that eventually became the most practical were those by Sutters and Meyers; compendiums on the warts and jewels of C++ that you needed to know to be good at programming in it. Such nitty gritty, much of which was eventually fixed by language design. I really don't miss having to know all that, freeing my mind to consider architecture, design, and delivery.
[1] https://www.nobius.org/dbg/practical-file-system-design.pdf
The former are fun but irreproducible ; the latter are boring (index funds, sobriety, compound interest, don't be stupid, and some luck to avoid the bad timing of the crashes) unless the author adds some snark (again, Munger)
I expect it will be more than 2 people trying that, and almost all of them didn't become multi-billionaires.
So it's the difference between "depending on things being average" and "depending on things being exceptional".
...the problem is instead of doing that people take the first prototype and ship it
Making architectural mistakes is now exponentially cheaper - as you can refactor the entire code base in a day.
So even if LLMs are not quite there yet in terms of architecture, they definitely lessen the time one needs to spend on making the right choices.
and in areas like FE for more internal tools design really becomes a non issue.
I think marginally is an understatement though because it feels like it is compounding. I don’t know other people’s experience but I’m building software that would not have existed before LLMs and coding agents arrived.
And this software is without a doubt better from the end users perspective. Maybe the code is crap, who knows? I don’t look at it. I judge based on 25 years of writing software by hand, deploying it to real users, and being a user myself.
I hope there is a resurgence of indie software like existed in the early 2000s.
There’s no hope for enterprise software. It will always be terrible.
That can be a sign that what you're now building is perhaps not worth building? At least my experience from dayjob, we're building more and faster, but it's either things we really shouldn't do (stuck in backlog forever for a reason), or things that just complicate the main product when features get added willy nilly.
Of course this calculus drastically changes when maintainability and other stakeholders come into the picture. There vision an architecture are more important than adding features. Architecture isn't too hard to solve, but sadly good product owners have always been hard to find
Yes my frontend is nicer. I do not hang myself up debugging a small issue for hours. I also don't have to search questions online, and get even complicated answers fairly quick.
But I'm not sure if I ended up being so much productive, or I'm just building a lot of open source stuff nobody needs. Last year i would have solved a narrower problem and relied on others to contribute the rest.
I implore you to look at it! I recently vibed too close to the sun: I knew at a high-level what I was doing, but never looked at the code.
Two weeks after and 50k LOC, I’m having a look and I can’t believe my eyes. There are whole failure modes that don’t need to exist. Moreover, how can I sale this software in good faith, when something happens and I’m largely a meat proxy because I don’t know how the code works?
I will go through the entirety of the code with my naked eyes, and make improvements (with AI).
But this time, I won’t fall for the illusion of “productivity”.
When you have a deep understanding of something, you just can’t help thinking about all the ways you could improve it. Maybe you realize it could be generalized, or that a different problem you’ve had could be solved with a similar technique. Sometimes you get oh “OH DUH” moment where you realize you were making the slightly wrong thing this whole time, and NOW you know EXACTLY what to make.
With LLMs I just get basically what I asked for, and then I’m done. Obviously this is sick and I love it.
But for a lot of my projects recently, I fall into this trap
- I have a problem, I think a program could help. But I want to know if there’s a viable approach before I invest a bunch of time by myself, so I boot up claude
- LLM writes the entire program, I don’t know what’s going on in there
- the program kinda solves the problem or it doesn’t. At this point I already have something that has vaguely confirmed or denied the viability of solving the problem, so I think “welp I’m not gonna spend a whole week of my life reading an LLMs output”, and that’s that
I rarely have cool insights about the problem after that. In the olden days, even if my approach didn’t work, I would come away with a new understanding of that problem, and all similar types of problems. “Oh that’s why people say cache invalidation is unsolved”. “Oh that’s why generics can’t infer xyz”
Don’t really get that when you vibecode. But the siren song of just having something that works is so sweet, and I can never ever resist it
This! Especially this! is the real reason I started building my own commercial software again.
I’m betting that the details will still continue to matter.
If you get into the regular habit of having the LLM look for issues with the code base it will find them: structural, bugs, design pattern issues, duplicate code, or same functionality not sharing a single path.
Honestly it feels like working with a real codebase. Tech debt always builds up, and yes the AI does it, too. It does notice if you ask to look.
When I wrote features by hand, I used to have like 2-5 bugs. Most of which were just human clumsiness.
When I started using AI and remained in the driving seat, most of the human clumsiness bugs went away.
Now, when I vibe, all I have are my verification loops and asking Opus5.5 to find and fix bugs.
Opus tells me it’s done. Only for me to start a new loop and it finds 10 more things or maybe I go in myself and it says “oh you are right”.
For me, this is not progress. I would rather spend an extra 1 or 2 hours a day in the driving seat building software that is correct and that is so simple that cost of changes is low.
It wrote them to begin with. Now you're handing of this discovery to literally the same LLMs that wrote this.
Oh, they will find some issues. Are you sure they will fix them and/or rewrite them without introducing more issues? How do you know if "looking is not necessary"?
I have automated the entirety of testing and Claude can validate it's own inputs. I then focus on marking requirements fulfilled, or bugs found. The bugs it does find are usually on the side of incomplete requirements. The few technical ones were due to a lack of testing. And I am not perfect, so I would have made all kinds of bugs myself.
If you keep to a mindset of, and build processes for, the management of software development rather than coding, results are better. No this isn't a magic prompt like "make no mistakes".
It is approaching the project with the mindset of knowing the limitations of the tools like one would a junior/mid engineer, and then mitigating. This is dependent on the codebase, product, and desired requirements for what processes to use and to what degree.
If you find yourself still needing to look, you have insuffiently automated the creation and validation of written software.
Its solved. Adapt and learn to use them effectively or get left behind; seems to be the unfortunate reality.
Every time. Every single time. People who say they never look at code anymore always say the trite things about "management of software development", how they have no issues, and that if you have issues, it's the problem with your skills with a side of snide remarks about your intelligence.
And then you press them for details.
After a few rounds of more and more trite answers they either go away or it turns out that their "automated everything" and "processes" and "coding is solved" are:
- a bunch of "make no mistakes" aka untold numbers of random markdown files aka skills, "guidelines", "memories", "ADRs", "technical docs" etc. Which are routinely ignored by any and all models.
- a bunch of tools that can't or don't catch all the mistakes the models routinely make. E.g. there are very few tools that reliably detect code duplication (especially code duplication with subtle changes in behavior), or reliably detect bad data access patterns, or reliably detect suboptimal algorithms etc.
- an overreliance on tests. The very same tests that are written by the very same very models
Also, if the models could actually "validate inputs" and other "coding is solved" things, you wouldn't actually need dozens of tools around to catch the mistakes they do. Ironically, you need "processes" and "engineering management".
---
As a related aside.
I have multiple tools from linters to semantic analysis running as routine checks, and still. Here are the responses by Claude for some of the things I caught it doing in just the past few days:
- "The [test data] generator can sometimes fail, and create duplicated data, so I increased the number of times it runs to 100" (instead of fixing it)
- "The tests check this in an indirect way. They send megabytes of data and watch the memory of the whole VM. Unrelated processes change that number. The direct check is the number of body bytes that the server read. Do you want me to rewrite these tests" (Claude wrote all these tests to begin with)
- "The previous research covered only a few CSS files. It did not cover the design system documents, the components, or the pages that already use them." (so much for "No this isn't a magic prompt like 'make no mistakes'" as it had an explicit requirement to use the design system)
- "The too_large_message/1 helper has three copies, two of them private, with no good reason for them..."
And that's just some I documented for myself.
I don't use memories, markdown files, guidelines, etc.
I design the software like I would as an principal engineer and dictate the high level requirements. Opus 5.5 really does just work. 10 months ago this wasn't quite true, it required more steering of the technical requirements.
I don't know why your results are different. I run a live multi-week long campaign game that streams updates over WSS from an Elixir app. I can literally see if Claude is doing as it claimed. It is trivial to verify when it gets it wrong.
I dunno what some others are doing to get such poor results. How much larger must my codebase become, how much more complex before those that see poor results see that it really is solved?
And if 350k LoC isn't enough for your use-case. Well, that wasn't quite achievable 12 months ago, but it was 8 months ago. In another year, I imagine if my codebase grew to 1M+ LoC, the latest models would still be keeping up.
Its solved. And the number of codebases it can't apply to shrinks every 12 months.
It doesn't have a summary of the codebase. Or at least a useful summary.
> I design the software like I would as an principal engineer and dictate the high level requirements
Let me quote myself:
--- start quote ---
And then you press them for details.
After a few rounds of more and more trite answers...
--- end quote ---
This is now your third reply with trite answers (two to me and one to a sibling comment).
> I don't know why your results are different.
Because I actually look at code it produces.
> It is trivial to verify when it gets it wrong.
Yes. Yes it is.
E.g. in my codebase it is trivial to verify that it does 15 reads from the database on a page when just 2 or 3 would be enough. How do I know it? I check the logs, or see it in the REPL (I also use Elixir).
It's also trivial to see when it does shit like "oh I didn't read the design system". Because I actually see what it's doing.
It's trivial to see a bunch of other issues it routinely produces because tools like these exist: https://github.com/elixir-vibe/ex_dna and https://github.com/Cinderella-Man/credence (or even my own vibe-coded https://github.com/dmitriid/llamex and https://github.com/dmitriid/ex_css_analyzer)
> And if 350k LoC isn't enough for your use-case. Well, that wasn't quite achievable 12 months ago, but it was 8 months ago. In another year, I imagine if my codebase grew to 1M+ LoC, the latest models would still be keeping up.
Yeah yeah. "Keeping up". Where by "keeping up" you mean "I duplicated the code 15 times, and "I didn't read even half of what is needed to do this task".
It works for you because you give it only the most superficial tests. Wouldn't surprise me if you can cut all of that code in half and raise the fps 5-fold. But for that you actually have to look at the code.
----
BTW lol at the tests. Literally 10 minutes ago it produced this amazing test: https://x.com/dmitriid/status/2121723533567115357
I mean. Nothing wrong with it is there? The code works. I can see it work in my browser. What other checks do I need lol.
Or "high level tasks".
Me: "Do not show invites panel if there are no invites, otherwise it shows as a horizontal line"
Claude: "The hidden card keeps its border because the box-lx { display: block; } rule overrides the browser's [hidden] style. I'm adding a primitive rule that sets display: none for hidden next"
You know, instead of not rendering it in the first place.
Have a fourth, then.
I hope you continue to ship for use-cases your users care about in your work, and continue to find satisfaction in software engineering.
I am.
When I release features, players report minor bugs, which I can fix in minutes by simply dumping their complaint into claude.
I worked on this codebase prior to LLMs and made slow progress, with many bugs. I did not know how to approach the performance problems, nor was I able to refactor the project to effectively have test and production environments reproducible. Claude did just fine.
It is 350k LoC, with over 138k as an Elixir app, 60k in tests/scripts, 65k Vue components, 45k JS, and more.
Coding is solved. Many people can't manage software engineering effectively. I don't know how much larger or how much more comparison is needed before this is accepted. Maybe it is "circular" reasoning like the dead comment says.
But it literally just works for me.
What I’m most anxious about is that, because I don’t read code, if I don’t have access to an agent for any reason I’ll have a hard time fixing a critical bug because I don’t have a mental model anymore of how things work. And that’s not professional and I can’t sell that software.
I think this is a growing problem. I pulled back. I'm much faster than I used to be. BUT, now I also forcibly insert myself into the loop so not as purely fast as I could be. I've thoroughly iterated on a design with the LLM before starting. I've personally looked at and often iterated on every line of code before merging. I regularly walk through the generated code base, both with and without LLM assistance, in order to ensure I have a solid mental picture of what's there.
This behavior has been informed by seeing things go to hell, both for myself and with other people, clients, open source projects, etc
Absolutely true! Some month ago I discovered huge memleaks by coincidence because Opus nailed tons of LINQ calls together and duplicated data as hell.
Why hope for a resurgence of indie software without also a revolution in enterprise?
If there ever was a time for either entrenched players to improve their UI/UX (using LLMs) or for rival upstarts to build lots of feature parity, now seems like it would be the time.
Perhaps if Agents are given some autonomy to buy enterprise software trials it would be easier to break the stranglehold of the biggest vendors.
"Technical debt is a qualitative description of the cost to maintain a system that is attributable to choosing an expedient solution for its development.
While an expedited solution can accelerate development in the short term, the resulting low quality may increase future costs if left unresolved."
source: https://en.wikipedia.org/wiki/Technical_debt
AI is right now buying down huge amounts of technical debt (see the flurry of CVEs). But we're already onto the self-improvement treadmill: future more capable systems will be better at solving any issues introduced today - it's literally not worth the time worrying about now (this is the same reason you don't get a cancer prognosis over a longer then 10 year time frame - the expectation is future treatments will be better).
The technical debt my code written in Opus 5.5 might have is already going to be handled by Fable 5.2, for example. It's going to be better and faster then I am. But also: if the rate of technical debt production from AI is even slightly lower, then it gets more and more manageable in a future where nothing changes but the increasing volume of AI compute is concentrated on less and less of it.
I mean certainly it would be nice if I could implement a feature without Claude finding a security bug and tripping cyber protections every couple of hours.
But the model I buy today is cheaper in terms of capability then the one I could've bought a year ago.
But software can be "done". There isn't an endlessly acruing technical debt, the product can be finished.
No, we can't. We can believe this will be the case
> The technical debt my code written in Opus 5.5 might have is already going to be handled by Fable 5.2, for example.
"Let's generate more and more garbage in hopes that there will be some magical tech that solves the issues" is not that good of a strategy.
E.g. even for the amazing magical benchmark-shattering Fable 5.5 Anthropic's guidance is still the same: your CLAUDE.md should not exceed 200 lines and claude only reads 200 lines of memory index because otherwise it quickly loses adherence.
Like all problems, we'll solve them when we get there but its not like anyone has an abundance of useful alternative advice: I'm getting useful software out now, whether I have to fix it later has the same problem it has always had - when we need to, we'll do it.
It's already here. People are already producing unmaintainable slop at never-before-seen levels, and software reliability is at all-time low.
> its not like anyone has an abundance of useful alternative advice
Yes, the advice is the same: look at the code produced and understand it.
> whether I have to fix it later has the same problem it has always had - when we need to, we'll do it.
Yet you don't. You're quite literally saying "who cares some future model will solve this for me".
Where I'm finding AI exceptionally useful is now being able to address tech debt and developer experience for my team WITHOUT having to argue for spots in the backlog to do it.
So, if nothing else, it sucks a lot less to work on enterprise software if you can let a team lead or principal engineer loose from the PM to just fix things.
But, how is AI fixing this? Unless the perverse answer is: no one’s reviewing code anymore so I can just merge my technical fix.
So "Where does this function get called from", "What does this function do?", "Rewrite this function as-is with better variable names", "Make a document outlining the structure of this project", or "Review this PR and watch out for any places that may be lacking the fix" are all reasonable things to ask of an AI.
When you're in a big project and aren't sure where this is supposed to go or how things get A from B, AI can be extremely helpful.
Nit: not all of those questions require statistical language models. IDEs like IntelliJ have been adept at syntactical queries and refactors for many years using purely deterministic data structures and algorithms.
Like if you have some code that's been intentionally obfuscated, or made by somebody who names everything "a", "b" and "c", a LLM is likely to be of at least some help.
And yeah, you can do things like finding all the places where func() is called, but a LLM can also be helpful in saying where something needs to be done, which is a much fuzzier task.
Usually, If you don’t know that, you shouldn’t modify the system either. Just because you know how to unscrew a bold, you shouldn’t go about removing the head cover of an engine. Locating the area of interest takes a lot less time than actually understanding how it integrate, the guarantees provided by other systems and the guarantees that it offers.
Modularity in software architecture. By reducing the links between parts of the code, it’s easier for someone else to navigate the system and answer these questions. But it does require careful design and caring about the code. This and other things is what the engineering is about.
In my own projects I'm also quite capable of forgetting stuff. Double checking with a LLM whether I forgot about one of the more obscure corners doesn't hurt.
In which sector is your company active where this is allowed? Or do you run on your own infra?
Yes, I imagine this is trickier in more sensitive applications, but I'm sure this isn't a new concern. AWS has Private Cloud, surely you can get a LLM with whatever assurances a more sensitive project needs at this point. But in my current environment that's not really a concern, so I've not personally looked into it.
I have the opposite view. Why would anyone build and sell software now when anyone can one shot anything? Genuinely interested in people’s thoughts.
Which is to say, the form of your statement I'd agree with is: if anyone can make an MVP in a few days, what use is an MVP?
A church is going to pilot it to 450 people. Some people actually do find it useful.
https://jaisenmathai.com/articles/sojourn-for-ios-was-45-one...
I agree that the ease at which it can be created feels a little…how do you say it…demoralizing.
In the long run, I don’t think this will be a net positive. But in the scope of this conversation about absolute productivity and code quality I seem to disagree with a lot of HN.
A company usually wants support / integratoin / maintenance / updates / new features etc. - for sure there will be some companies building 100% on their own, and yes I guess this number will increase but I do not see any mid-level company or above replacing Oracle or Salesforce or Microsoft with their homegrown solution.
The value added by commercial software will have to be much higher than what it is now, or most companies will have little reason not to code their own, fully customized to their own needs.
But it is really hard to imagine what the future of software will be, even in 2/3 years time. We live in wild times.
But the fact AI has made things easier for most people doesn't mean the barrier to entry has been lowered to 0 for everyone. My mom could probably use AI to write a compiler but first she'd have to even understand what a compiler is.
And the fact that some apps can be made in one prompt doesn't mean every app can. I've been working on a fully AI generated project for 8 months, it's taken billions of tokens and continuous prompting. The amount of human time spent on this project is just as much as I'd spend before AI, just now the project is much larger in scope. So even if some people have the ability, they still might not want to spend their precious human time on it.
1) Knowing what to build, keeping the design appropriate, not over-engineering the spec, not prematurely optimizing, et al. Note that this is different from just having an idea about a product.
2) Making it.
3) Getting people to use it. Nobody gives a shit about your software. Getting them to even try it is extraordinarily difficult in most cases. Selling is hard work. This will get a lot more difficult.
#2 has had the difficulty dialed back in many cases. In exchange #3 will increase drastically.
Absolutely nothing has gotten easier net. If anything the total will become harder net, the difficulty of acquiring users will get harder beyond the extent to which making it gets easier - users will trust software even less in the future, and the popular AI systems (personal agents or whatever they end up being called) will reduce the amount of software the typical user ever needs across a lifetime (narrowing the market).
When AI solves hardware design, then we might see some new room for software again.
Totally agree with this.
I see the future of what an IDE is more like an "architecture designing interface" which designs tests, architectural decisions, type systems, and contracts between components. Tasks then should be delegated in their implementations to agents so they are just responsible for the "wiring parts together" tasks.
Currently I imagine it as something similar to how workflows are usually designed around strong types and schema validations in safety-critical areas like ASPICE, Ada Spark, etc.
That's mostly why I don't use existing agentic environments and started earlier this year to experiment with my own one, where I try to enforce the design and architecture related tasks through capabilities mapped on tools for each of the task-scoped roles involved.
In the last 3 years, there have been a lot more indie games of far higher quality than we used to get. I'm thinking of the RTS space right now. The Scouring for example. We went from having nobody but Blizzard able to make something that complex to several games with outstanding performance and complexity, often with their own custom game engines that are not only working but working better than I remember wc3/sc2 working at launch.
I don't know how much of a role AI is playing in those games, but I think the performance and complexity of indie games is shooting up and we are seeing very, very small teams make things that large teams struggled with in the past. Honestly, I think indie studios are outperforming AAA in most ways besides spend and length and art budget --and yet, it's the indies who are making their own game engines these days, isn't it?
(btw, we have to also admit that many of these game engine builders look to blow for inspiration (to carmack too), and their architectures are not what you'll find at typical saas companies. Game coding is complicated in a really fun way I didn't get doing plumbing on web projects, speaking for myself)
Their workflow was:
1) Arrive at work. Get coffee. Fetch latest code from Visual Source Safe.
2) Turn on Xbox. Hit F5 to build, deploy and start debugging on target.
3) Edit and Continue C++ in debugger IDE all day on target without ever bothering to stop the game. (Yes, this took some coding discipline to maintain.)
4) Turn off Xbox and go home.
Between the Visual Studio debugger and the Whole Tomato coding assistance, it was easy to understand the code and the runtime behavior. For anything GPU-related, Microsoft Pix for Xbox gave you a scrubbable timeline of every action, every pixel, every register change in the GPU while drawing a frame.
The hardware capabilities, available libraries, and artist tools have increased tremendously since then. But, the coding experience has not. 20 years later, I'm outside of gaming and I find most people using re-run-and-printf debugging for professional development. Even locally. I don't know how anyone gets anything done.
The only significant improvements I've seen in 20 years (besides the occasional memory tracker or profiler tool) has been AI agents and reversible debuggers. Otherwise, it's all been downhill since 2004.
basically, all programming should be writing requirements as a custom level for Shenzhen I/O
https://www.microsoft.com/en-us/d/visual-studio-professional...
More people should use them!
Gamedev programming probably hit a low point for me when XBox One and WiiU came around. Those were some truly awful experiences.
I actually think git and the DVCS madness is a good example of complexity for the sake of complexity. Ending up in a detached head state through a seemingly normal series of commands, and then being able to continue working and have a very difficult resolution (compared to how you go there in the first place) that requires you to know how git works is a perfect example.
On the flip side, again in P4, you get latest and that’s it.
It’s just not possible to end up in that state with something like P4. My current company has >1000 people, most of whom are non-technical (artists, designers) pushing every day, and even when I worked at places with 30 people, the amount of time I spent training people on “click get latest revison, and double click to submit” was absolutely dwarfed by “I followed the git setup instructions but I can’t push my changes”
Or even: "Claude, push the PR and sync git"--it's more than happy to take that off your plate.
Most of the time I simply remove everything and start from a clean slate.
It’s not only that. You also need to understand the concept of merge, squash merge and rebase, and the difference among them.
I admit I never dabbed into the internals because I was not very interested in git. I’m interested in other stuffs such as the OS kernel.
I do think it is the wrong tool for most people out there. If you are not doing 1,000 people distributed development there should be a different tool for source control. What my team does is 95% “one developer owns the changes of one or more files and others don’t touch them” type so it is rarely a true distributed development, in the sense of multiple people touching the same systems at the same time. However, I haven’t surveyed the landscape of version control. Maybe I should at least inspect the other big names.
It doesn’t. Claude is far better and faster at this than anyone I’ve met in person. And you can work in any part of the source as though you were working alone, with all the numerous benefits of git.
Why would you not just try it on a disposable repo instead of continuing in fear? The thing about git is it is actually very very hard to do something that destroys anything because it is distributed. Make a repo. Clone it to two places. Do whatever you want including things that force push and overwrite history in origin. Then restore it from the other repo you cloned.
Failing to do this is not "very, very" hard
I have been letting Claude drive git/P4 for months and it does an impeccable job. With git in particular, it can't even screw up too bad; old hashes would save your bacon in a pinch, and they'd always be in the transcript, but it doesn't matter because Claude just doesn't struggle at this, not even a little bit.
Git LFS is tacked on, Git's locking support is crap, the culture of git is not to build helper plugins like P4 so no one does it.
Distributing P4 to multiple offices is a pain in the ass and it really does need a lot of hardware to keep things going.
Maybe Epic's Lore will shake things up and we get the workflow in a nicer backend. Still, sane defaults and control is also something wanted so, to your points, Lore is not a DVCS
> Git’s issue is not that DVCS is bad. It’s just that P4 workflows work better for binaries
I think that git is a good DVCS, but that a DVCS is way overkill for most forms of software development. The complexity that is paid for that is paid by every single person who uses the tool. I don’t think it’s binaries, I think it’s the centralised workflow is just better for many/most teams. I can count on one hand the number of times I have worked with multiple remotes, or pulled from a teammate’s branch without going via a forge.
> Git LFS is tacked on, Git's locking support is crap, the culture of git is not to build helper plugins like P4 so no one does it
Could not agree more here.
> Distributing P4 to multiple offices is a pain in the ass and it really does need a lot of hardware to keep things going
Understatement of the decade! It’s an absolutely enormous, completely unfulfilling task. IIRC, we ran 3 edge servers and an extra pull through proxy at my last job for 100 people, and we spent about $6k/mo on the hardware alone on AWS.
Professionals should know how their tools work.
I am an app developer. Our front end is a C++ application (a game), our backend is a dotnet application. We also have an admin portal. A single feature, including deployment touches C#, C++, JavaScript, opentofu, AWS, windows, Linux (maybe macOS), docker, MySQL, redis, caddy, git, bash, plus all of the libraries and individual tools they call through too. Every single one of those has its own quirks and sharp edges. If I spent my working hours (40h) knowing each of those tools to a professional level, I wouldn’t have enough time to work on the app.
> few professionals know what ALL of the tools
> developers use (some or most)
> not all of them know
If you are a professional you need to know your tools, in any discipline. It does not matter what most or not all do. If you do not know your tools, you are not very professional.
You always have the ability to try out the simple version that ignores that reality:
* Don't branch
* Always force-push to master.
I can count on one hand the number of times I’ve had to reconcile offline work in the last 18 months, which is the equivalent of every merge commit in git.
You can use Git LFS locking or other side channel things to get file status tracking to work in Git but its a slog. You can usually find something for your engine of choice though.
If you use git LFS, you turn git into a centralised vcs but still pay the pride for it being a dVCS. If you use a side channel, you’ve gone way off the deep end IMO.
P4 has many problems (not least the $1700/seat/year cost) but if you can stomach that plus having someone maintain it (which is a real job, and someone has to do it), I think it’s way more suitable for pretty much every company out there, particularly in games. It’s not purely the best, technically the best, designed for modern use, but it has the best failure modes. I could (and have) sit down with someone for 15 minutes with perforce and shown them what to do and probably have them go for 2 years without another question on it, even if they’re not a programmer. It’s excel if git is a relational database.
For WiiU, Nintendo used the Green Hills compiler. Their entire toolchain was simply clunky and unstable. You had to use this MULTI debugger which often didn’t work. My favorite line from their dev docs was “c++ not fully supported”. Well, that’s an issue since we used that extensively. It wasn’t even clear what actually wasn’t supported.
It was, but then it was just a version control system. Back then version control wasn't as 'intrusive' into the whole development workflow as git is today. You interacted with version control exactly twice a day: once in the morning to get the latest state, and once in the evening to commit the day's work.
For you young’uns, old source control used to work like that. To edit a file, you checked it out, no-one else was allowed to edit it until you’d finished.
I do need to inspect the other big names of contemporary version control tools. Maybe they are more suitable for small teams or individuals.
This was far before Copilot and it was the superbest extension for VC++6 & up.
> if you know the test cases for your code
IME, most gameplay code is not tested, it’s done by feeling. Quick iteration cycles on feeling, is super important, and most of these sorts of projects have 30+ second boot times (way longer in the days of hard drives instead of SSDs)
Similar experiences but with Java and Eclipse: editing code while it's running is amazing. And yet, far too often, since moving on from Java to Swift, even with the "proper" Instruments, the actual best I've had has been debug-by-print in much slower cycles... and sometimes not even that, when things went wrong in SwiftUI I might as well have been an ancient Roman haruspex reading entrails for all the good it did.
And at the time, everyone was complaining about Eclipse.
That said, still using debugger driven development and edit-continue to this day and marvel at the lack of experience of people touting Lisp or Erlang or whatever as the only places in the world with some kind of hot-code replacement.
1. Hardware advancements mean that you can get the same results with less optimized code (this is what allowed 3rd party engines with GC scripting languages to become popular)
2. The proliferation of learning resources and open source code.
3. The budgets and size of indie studios as well as total time spent on the games. Seriously look at some of the games these days that get labeled indie.
Warcraft 1 (my first RTS) had just 4 programmers. And only one of them was on the project the whole time. And the entire project was only 14 months.
> Warcraft 1 had just 4 programmers
This to me sounds like the market for games has changed, such that larger projects are now more viable. Smaller projects with a handful of people may still be viable, but look tiny in comparison.
One of my favourite games of that era, Thief, also had a very small team.
Nice but this isnt even the half of the story: According to ChatGPT, the whole team was "32 people in professional roles", so 8x times of number of programmers. And that ratio even became extremer in the last decades.
Doesn't mean the tool is flawless, but if that ain't a new quality I don't know what is.
Mine are (for game developement), adding new features, while FPS stays stable. Well, they even improved and the tests still passes .. so it does for me. Sad that it does not for you. But can it be, that you do not want it to work as your identity is tied to manual programming?
AAA and indies now use the same engines for the most part
In game dev however, there's a lot fewer reliable open source tools around. You have a game engine, a small number of great plugins, and a lot of dodgy stuff. You have to/get to make a lot of things yourself.
The scope and complexity of indie games, even allowing for this, is still increasing staggeringly.
...and don't get me started on unreal engine physics and pathfinding issues, or rendering bugs in unity
Indie games didn't get THIS good because of Unity and Godot, if you think that you're deluding yourself.
I've done amateur and professional game-dev and Unity and Godot existing don't make making an FPS any easier than before, engines have existed for a long time.
A solo dev can create (from scratch) an FPS engine, assets, music, levels from scratch over a weekend now.
This is only possible with AI.
There's been a lot of good indie games recently (Queen's Domain[0] being a recent example that's taken off) but I don't know of any which are using an AI-coded engine or use AI-generated assets extensively.
[0] https://store.steampowered.com/app/1799840/Queens_Domain/
Just recently, someone used AI code to fix a Unity engine bug and hand-wrote the rest, and it still caused a huge uproar. It's a world where honestly disclosing that you used AI code is not a good idea.
[0] https://www.unrealengine.com/developer-interviews/meccha-cha...
And when they do, this is what we get:
https://i.imgur.com/w25SmDR.jpeg
https://www.gamedeveloper.com/business/why-do-strategy-game-... (2015)
https://www.ranker.com/list/clash-of-clans-screaming-dudes-k... (2020)
We haven't seen any such enablement for quality games.
What does "from scratch" even mean when using an LLM trained on existing assets, music, art and code? Why even bother with that parenthetical? No one believes an LLM creates ex nihilo like God.
Show me the AI generated game that's superior to Balatro, or Hades, Or Undertale/Deltarune? Cult of the Lamb? Expedition 33? Factorio? Kerbal Space Program? Ultrakill?
It not being easy means it requires actual effort and skill, and effort and skill are where the quality comes from. No one is ever going to care about whatever vibe-coded slopfest you had Claude shit out over a weekend. Being able to make low quality low effort shit quickly is not better.
* before and after rails;
* before and after js UI frameworks;
* before and after scaled machine learning;
* now before and after LLMs;
And saying we haven't advanced much is wild.
And for the pixel perfect complaints, it only shows lack of care to not have learnt how layout managers work.
Managing it would be the right meaning for fullstack.
Electron and you throw your website basically into anything and it works.
Both ways up in snow and without boots.
There are some local improvements, but overall software is just as shitty and buggy as 20-30 years ago, and most of it doesn't do anything different
Indie games get released but how are you measuring such that they're outperforming AAA?
It sounds like you're saying more indies are in there own engine instead of Unreal or Unity or Godot or Roblox etc...
Are any of these takes sound?
Jon Blow doesn't have sufficient experience in using LLMs to talk about it.
This is evidenced by his focus on individual anecdotes on AIs failure to deliver something.
I would love to talk to him about this as I have fairly concrete evidence of the insane productivity gains one can get with smart AI usage.
Also would love to hear Ryan J Fleury talk about Tim Sweeneys statements on LLMs.
How long until RADDBG is primarily used by Claude? How long until Ryan is told he must support this? How long until he claims he was never against it?
Jai, zig, radbg, box3d, sokol, stb, sdl etc will simply be assimilated into the new world.
Jon can choose to stay in his shop on the corner hand crafting artisnal idealogical computer programs, or he can join us in the frontier and enjoy accelerating power over machines unlike any time in history.
That's up to him.
Old dog afraid of new tricks? A tale as old as time. Especially a well fed dog like Jon.
He regularly denies the use of new technology that is genuinely useful, and is a fairly conservative dude (I mean in the non-political sense. I do not know his politics. He may be a conservative politically as well, but that would be independent of the point I'm making.)
I've worked with many engineers at many different scopes. Big companies, indie darlings, web services, games. Games is always the last to adapt, always the last to think that anything they didn't invent is worth their time. Blow has experience in that domain, and is colored by working in it, but I don't think he knows what's happening on the bleeding edge very well.
We need more content creators focusing only on their field of expertise. I don't care what Jon and Casey think about React or big tech or coding interviews. But I find their gamedev experience and insights valuable.
Some of us have to work with several forces outside our control; a batch of new interns every summer, a tech stack you don’t get to choose or rewrite, or reorgs. Games also have a very different business model; they usually don’t have to constantly ship revenue generating features or products from early on.
I just find that many of their critiques are impractical or suboptimal applied to other industries or domains.
They’ve both worked on AAA games before.
I’m not trying to discredit them, I’m just saying that it’s not like they’re AAA veterans who have shipped many titles from start to end, in that particular space.
Before that he founded a 14 person game studio in the pre dotcom era. Back then that was a decent sized team.
Casey worked on Dungeon Siege.
They were also very involved in the AAA community. And after 3 AAA games the vast majority of high impact devs would have moved into leadership roles or started their own studios.
Cyberpunk was released 20 years after Dungeon Siege, so I don’t know what you mean this era.
Also Thief Deadly shadows had close to the same size dev team as Assassin’s Creed and a similar budget.
If you’re trying to make the claim that he doesn’t have much experience in modern $500 million dollar games. Then sure because they didn’t make $500 million games 20 years ago when either one was working in AAA gams.
I admittedly don't know firsthand what Thief or Dungeon Siege were like but you can see the difference on Mobygames; these both have ~250-300 credited in total versus Assassin's Creed (and "only" the 2007 version) which has ~900 — it only goes up from there. This is not a rock solid comparison but it's probably a decent proxy to describe the scale of production. You could maybe argue that a title like Assassin's Creed had a bloated team, but as an IC that's not really in my control.
But in more concrete terms what I mean is that in the Dungeon Siege/Oddword environment, sure I could have maybe said to my team — I'm going to rewrite "x" because it's not efficient enough, and then go heads down for a while and try to solve this problem. I didn't have that same luxury at the other end of the spectrum. On a smaller team I could maybe say — hey, I think we should drop C++/OOP because of "reasons", and have a somewhat realistic chance of persuading the team. This was unlikely to be taken seriously at your EA/R* type company.
Beyond the games industry I'm not going to be taken seriously suggesting to my big tech employer to rewrite everything in Rust instead of Java because OO is evil or it's non-performant or whatever. As far as polymorphism and clean code go, I sometimes find value in leveraging these if they make sense. I may anticipate some persistence-layer migration in the future or feel defensive about the next few intern project and want to try and have some sort of guardrails to limit their blast-radius. Virtual functions are non-performant, Jon or Casey may argue, and they'd be right in their respective domain — but it's not really applicable in mine; even if I were to theoretically drive _my_ service latency down to zero, my end-user would notice no difference as most of the latency is spent on downstream services. Etc, etc.
A terminal needs to be efficient for people on laptop battery power, MS's would burn your battery down fast and slow down commandline tools.
So the problem is this dissonance where video games can perform complex computations in <16ms but all other apps seem to take minutes to do barely anything at all. So they are right to compare software to video games because there's no reason for everything to be as slow and bad as it is considering what video games are able to accomplish.
On steamdb.info, Order of the Sinking Star has 1830 players right now, 2404 over a 24 hour peak, and 8247 all-time peak last month which was when it was released.
It is just beating out Cuphead, which released in 2017.
We all know that games aren't priced by seat-month like JIRA, right?
While steamdb isn't a concrete sales number, it does tell us something about the game. A game cannot have more players than sales, we know that. It can tell us how many people are playing the game, which is indicative of how many people like the game.
Estimates put it about 150K copies on the high end.
To contrast with actual blockbusters. Ocarina of Time sold 5.2 million copies in its first few days. GTAVI has already sold over 12 million copies. Meccha Chameleon is also sitting at 12 million. Balatro is also in the millions of units sold, with close to 7000 players playing it right now on Steam.
It seems to me, Blow is a wealthy independent dev, who's talented at making games, but has little time pressure and little interop needs.
Maybe his new language brought him personal satisfaction, but had nothing to do with his game's success.
I firmly believe that you should settle your approach to metaprogramming first, on any major project, and for me none of the off-the-shelf solutions ever were preferable to "just generate the code" (JAI probably won't be any different here). Then, once you build all the tooling to be able to iterate as quickly, you basically have your own language and standard library anyway.
Of course it could, after all, it could be built in any Turing-complete programming language. But you wouldn't say that he could do it in assembler, right?
Have you played The Order of the Sinking Star? Pretty much the first thing I did in the game was inspecting how the game operates and wondering why would he need a new programming language to make it. Making something in a new programming language is by default harder, because you have no existing ecosystem (unless you can make bindings or otherwise easily port something to your language), so why even make a new programming language?
While I can imagine a piece of software where this is more clear, the ridiculous complexity of the Order of the Sinking Star is a huge hint: perhaps his language is so much better at iterative development, or level design (e.g. a level editor or a fast compilation time), or debugging, or some kind of structure defining, that achieving the same result in another, existing programming language, would only be possible theoretically, but in reality it would take more time, more workforce, or the complexity of the design, multiplied by the complexity of implementation in another programming language would produce an overall complexity too big for a single human to comprehend, requiring separating the game world into isolated parts with clearly defined, simple and boring portals between them.
I may be exaggerating, but the idea is, he was making a video game, he was annoyed with the programming language he was using, so he made a new programming language to deal with the annoyances so that the programming language helps more and gets in the way less.
You mentioned Rust, well JAI has already better game portfolio than Rust...
Modern "AAA games" cost 100 million dollars or more. Of course if you have an army of developers paid by the hour, maybe iteration speed doesn't matter, maybe the subjective experience of software development doesn't matter. But "AAA gaming" would never produce a game like this in the first place, so it's a moot point.
Maybe he just values doing his own thing more than money? Which is fine!... but not proof anyone else should take your advice.
Some people just like making things they thing are good? He thought cpp was bad, and didn't want to program in it anymore, so he made something different.
Obviously the guy isn't optimising for making the most amount of money possible.
What’s impressive is that he succeeded despite that. The man must have a fire in him.
The difference is Blow can and does post some good flame bait.
What will next year bring?
The changes always come in monster one-shot PRs ofc - too much for a human to read - so I just feed the branch to my Claude (identical to the one they’re working with) and after some thought it will give me 15 to 30 suggestions of what needs fixing.
I’m still not understanding why this happens?
Because it’s an infinite loop in essence. There are always things to improve. There are always things to fix. There are always bugs in software. There are always more cases to check. There’re always better ways to do things.
You can add new code indefinitely with diminishing returns. Each addition introduces new bugs. So after a point it may become negative returns.
As human engineers we make tradeoffs. We prefer simple and clean over more complete but bloated.
Without a stop condition Claude can “improve” the code indefinitely.
https://blog.jmccarthy.au/post/time-horizon-scaling
"List every file you need, read them in one pass, make all edits, run tests once." It stopped the read,edit,read,edit loop.
The second was a stopping rule I added : "After two failed attempts at one symptom, stop editing and get a diagnosis first"
So when a LLM writes new software and the LLM sweeps keep finding a ton of issues. Yea, but the LLM wrote that code in a few hours, what may have been weeks of work. The sweeps its running is finding things, that may have taken years to remove as customers report issues.
Combined with LLMs tend to "over find" issue things that we will never bother with as human written code. We may say "too trivial to fix, not a issue", ... bla bla but for a LLM its a issue to fix, so it looks like LLM code has more issues.
And while we may pat ourselves on our back for finding X bug that created data loss or a crash, there is probably a dozen high to medium bugs hidden somewhere to be found by the customers (yikes!). Where as LLMs then to reduce that vector after a sweep to barely a few medium or low items.
This is what i always need to tell people. LLMs are not just doing the work of humans at a 10x faster speed, they are also solving bugs and other issues what may have taken years for humans to iron out, what a LLM does in maybe a 24h bug hunt session.
it’s all very much over-eager junior level.
You have not seen the over smart senior dev that tries to one-liner everything. Or that makes code so complex, that its a "job secure" feature because nobody else can figure out what the ** is going on.
I noticed that there is this perception that medium or senior devs are the panicle of coding, and good practices when most are not. A lot of are simply restrained because companies force specific coding standards and left to their own devices, they will love to run amuck. Remove those handrails and your going to see code that makes most LLMs blush. lol
after some thought it will give me 15 to 30 suggestions of what needs fixing.
That simply means that your collogues never bothered to run a bug hunt sweep after their work. If they did so, just like a human dev writing something and having the work checked by another dev, this will have been reduced a minimum. People seem to have this thinking that LLMs need to write perfect code from the start, when its trained on our human code, with all its issues. Just like if we wrote code manually, and then somebody checks the code before pushing and committing it, do the same for LLM code.
!!! LLM do not mean that good coding and deployment practices are suddenly useless !!!
This slope is hardly any different had they gotten an offshoring team at the lowest bid.
The only jobs that were created were at their locations, at the expense of local teams.
LLMs are designed to circumvent our ability to tell who knows what they're talking about. Our fundamental intuition about computer programs - garbage in, garbage out - has been broken. Now everyone can sound the same. But those who do know what they're talking about understand it's just a tool, those who don't think they're like Neo and just learnt kung fu.
I recently reviewed a large PR from a decent developer. I wrote some of the requirements after meeting with stake holders and did my own investigation on potential solutions.
The PR was full of bugs, missed half the requirements and the code that was there wasn’t even fully tested.
This person has successfully delivered complex things before. So what the hell? And this is not the first time I’ve thought their usage of agents and conclusions from ai assisted explorations were not right or could be better.
There’s still some weird human element. Though I’m noticing that responses are getting better with less “prompt engineering” so maybe this will all be gone soon.
Was this a developer who has been forced or pressured to use LLMs?
I know that should that time come for me, I'm not going to burn myself out wrestling to make something good.
But there’s certainly no standard approach on how to use these things. It’s very much a YMMV situation.
You have to carefully manage the project scope, and catch the ai getting stuck. There is a stars aligning point where you are matching the model to its scope on a clearly defined goal to iterate towards and its mind-blowing. And then if you go even a bit over that point it's perf falls off a cliff.
And it changes with each model with each new release.
For example, I wasted a bunch of usage today giving Fable 5.2 8 sub-orch opus high agents that each were given bunch of chatgpt subagents. It was fun watching all the churn, and I'm trying to find some way to use up all my openai usage.
But in the end I made much less progress/made a bunch more slop code than if I had just narrowed project scope and gave fable a smaller easier task with less agents under it. And now my weekly usage is gone in 2 days.
My experience has been good, if I get the project off on a good path, with clear principles, patterns, and practices that I want to see enforced.
Different tasks, different tools, different prompts, or different ability to evaluate the results, likely some combination of all of the above.
- Tools: I can't get the ChatGPT web interface, with any prompts, any models, any amount of retries, with any combination of settings, to respond to a coding task with anything other than <snippet ignoring multiple explicit requirements for what should be a 20 SLOC task> <here's how you make it actually prod-ready (often stating that it just refused to implement something I asked for)> <paternalistic essay about how I shouldn't use my vibe-coded URL parser to send a man to the moon>. The underlying models are a fair bit better. Fully controlling the system prompt helps a lot. Agentic flows paper over a lot of those deficiencies. Anthropic models (and web interfaces) work a lot better for codegen for me out of the box. Agentic flows make that delineation much sharper.
- Tasks: I don't like the concurrent data structures LLMs write. Its opinions about the novel pseudo-probabilistic algorithms I care about are wrong. The level of hand-holding I need to get proper matrix codegen is insane. It works extremely poorly when operating at a meta-type level and trying to design a cohesive API. But, if you're not doing those things, who cares? I vibe-slopped a new programming language yesterday just to try it out with a new harness I previously vibe-slopped. At this stage, it doesn't have to be correct. If I get it kind of working just a little and think the results look promising then I can do better later if I want. A lot of companies are in (or at least think they're in -- IME this mentality bites founders much earlier than they expect much of the time) that stage.
- Prompts: LLMs are much more sensitive than you might expect to minor variations in prompts. The classic example I hope everyone knows by now: There are precious few scenarios where your interaction with an LLM should be a very long session repeatedly telling it the mistakes it's made. Almost anything else is better, up to and including (as a bad solution but still better for codegen output than the baseline) still having a very long session but asking the agent to rewrite the previous messages as if it had succeeded and then having the person manually edit the conversation.
- Evaluation Ability: Really? You thought +3k SLOC was the best way to solve that feature? I have a whole SOTA event loop and multi-processing framework in 3k SLOC, and when interacting with most companies' codebases you really ought to be deleting code with the average feature you implement, not adding code. Like you said, the code smells are everywhere. Like, slop is fine from time to time (easily 30% of the code I write for work is slop, largely because it serves one-off tasks), but some of the people pushing it just can't tell the difference. Just a month ago, somebody (outside of $WORK) was showing off a fancy new UI feature on some geo-rich project. It had a small bug. The implementor said they knew about it. The problem is that "if you know you know," and the only reasonable way the code for that kind of feature should have that kind of bug is if it has major problems which just aren't surfacing much in this particular demo. I suggested a couple alternative test cases to optimize toward, and a week and a couple rewrites later it was in a much better place. There were tens of thousands of tests before I made that suggestion, dozens of times the LLM confirmed the system was working as intended, and on and on and on. None of that matters if you need to build something that works and know that it works. The tests were all shit, as were the false assurances.
If you're looking to make it better, there are some tweaks you can make to your CLAUDE.md or what have you to help a bit. I have a lot that I do to make mine generate passable code without requiring constant human intervention, but something it responds well to is (1) pinning down what you care about re abstractions, and (2) giving it explicit permission/guidance to spawn sub-agents to make that happen. A lot of the problems with LLM-generated code are fixed if you fix the abstraction issue, and many of those fixes are relatively "mechanical" checks you can apply:
1. When reading the name of an abstraction, do you have a good idea of what it does?
2. What about the name and signature?
3. Does the implementation match that intuition?
4. Does any part of the codebase reach past the intended abstraction?
5. Does your code require nonlocal reasoning? (side-note: this is very important for humans, but it's more important for models since their harnesses aggressively try to avoid bloating context windows, so it's quite common that if you need two lines of code far apart in a file to relate to one another then you'll see downstream bugs)
6. Do all of the abstractions pull their weight? Are they all even used?
7. Is it possible to delete 80% of the suggested code and have an equivalently working product?
8. Do existing abstractions/conventions solve the problem you wrote a new abstraction for?
And so on. You obviously can't compress all good engineering judgement into a brief model context window, but you can get a lot more than you might expect. Whatever it is that you see agents doing poorly, try to come up with a general principle you think it should try to respect, and write that down for your future projects.
llm's are only good for closed systems with robust automated verification loops, which makes me doubt it's general applicability. at least for now, humans seem much better at navigating domains without an easy way to verify systems.
Not quite right - RLHF is about aligning with human preferences (because it trains, as the name implies, on signal from humans). This does not necessarily correlate with behavior. We use RLHF across any number of domains and with any number of goals, not just alignment.
RLVR is a (more recent, better in some cases) way to automate the training loop without the human being involved, because you give the model a way to verify its own results and train on that as a signal.
i remember a year ago i'd have to tell the llm to use the bash tool to compile to see failures. these days, for every task it
1. throughly inspects git history
2. runs the full test suite to get a baseline
3a. for each change, runs (a subset if i'm lucky) the testsuite
3b. writes about 3 billion lines of tests, including tests to test tests
4a. uses the harness's screenshot tool to check each visual change
4b. for webapps, spends several minutes poking at it with some kind of browser devtool
5. runs the entire "smoke test" suite, which often takes several minutes and regularly interrupts my keyboard focus
6. runs the full test suite at the end
even small changes take at least 10+ minutes to complete, but with much higher accuracy than a year ago.
to me these things are dumb but persistent, useful but not intelligent.
Then you have a very uncommon definition of the term "intelligent", because that's roughly what I would expect an intelligent, conscientious developer to do. Many, many bugs stem from developers who believe themselves to be too "intelligent" to need an extensive test suite.
same with anything else really. a better chef can nail a dish in one or two attempts, whereas a worse but persistent chef might take 100 attempts to achieve the same quality.
or likewise, i'm not as good as a basketball player if it takes me 100 attempts to nail a three pointer when an nba player does it 35% of the time - despite both of us eventually achieving the goal.
The harnesses have improved and I suspect there’s a decent amount of logic pushed there.
Models are larger, so the generalization that happens is better.
Lots of effort has been put towards training on coding tasks.
Last year, the frontier llms could produce working code, but the code looked brittle and overly defensive. Earlier this year, it got better and started to take more of the codebase into account. Since Claude 5.5, the quality improved substantially.
A lot of these things could be improved with prompt engineering and steering, but much less so nowadays.
But I don't think code quality is easy to measure, so the best we have is people's experience.
most people also dont understand why their cars are safer (over the decades). But they still know it to be the case.
Of course, back in the 50's an 60's, they extrapolated that we'd have flying cars today, so you're not wrong to be careful about extrapolating...
Certainly in 2024 I did not foresee AI coding ending up as reliably good as I find it in recent months.
I'd like to have some understanding of whether this improvement is likely to continue or we've reached plateau.
It’s more reasonable to extrapolate based on past evidence than arbitrary conjecture.
Self driving cars are great!
…but fully autonomous (level 4+) driving turns out to be really much harder to do that the initial 6-12 of self driving demos suggested it would be.
Its always easier to get the first prototypes and demos up, and its literally ALWAYS wrong to extrapolate exponential improvement based on that initial set of results.
It should be a surprise to no one that AI coding follows a diminishing returns log curve, and that improvements are merely incremental after the initial burst of improvement.
1: https://en.wikipedia.org/wiki/2017_Washington_train_derailme...
I am still not sure what their opinion or point is, because they vagueposted instead of telling us.
Every person I’m meeting in the real world who use agents have roughly the same experience. About a year ago they started working reliably and the side projects where we played around with it started seeing actual results.
About 6 months ago I started seeing colleagues and friends all around the same time saying that LLMs solve real problems for them.
For my own case, I’ve replaced years of sloppy spaghetti code in our internal tools and services, from a bunch of engineers many of which has left the company, with code that’s objectively better quality and more coherent (though docstrings and tests tend to accumulate garbage, so cleanups are necessary eventually).
Repeated forever, a statement always has a chance to be right.
After a point it’s going to be challenged
So people are super impressed because things just work, and they do.. Until they dont.
Just because things compile doesnt mean they're going to hold up, and most of this slop wouldn't, ive seen it first hand and you can also tell by the increased amount of outtages across different platforms.
As-is we're not going to get commercial fusion until at least what, 2040? 50?
Now it’s permanent baby sitting.
We're accelerating our ability to produce mediocre software that solves common-place, mediocre problems, but with more "freedom", more customisation.
His Lordship Mr Blow, has something of an academic sense of what innovation means. He wants to see new problems being solved. A new O/S that is "secure by design" in throwing away old models of shared-CPU schedulers, and the like. I assume, new techniques in 3D game graphics. New ways of mixing compile-time/run-time langauges to accelerate development. And so on. New in the way that an academic research project should be new.
What we have from AI in software isnt anything new. Claude releases an office suite with AI assistance. We havent yet seen AI accelerate anything other than end-user programming, or lift-and-shift projects.
These might be very valuable, but theyre not innovative.
Acceleration due to AI is still described as a "time warp" not an ability to come up with ideas you wouldn't have come up with before, e.g. https://www.planned-obsolescence.org/p/ai-is-dramatically-ac...
A year to ship is the old paradigm. With 100% agentic vibecoding, everything should be amazing now.
If you use it internally in business, you don't need to wait. There's lots of stuff deployed every day and works really well. If you want to see results in public, you'll have to wait for reasons unrelated to the speed of coding. Does something actually solve a problem, is it interesting enough to be popular for you to find it, is it better than most other attempts happening at the same time, and all the usual questions related to the business side. It's going to take time for PoCs to get refined enough that they gain popularity. The second issue is that lots of projects need data in addition to the software - and that still needs to be produced manually. And finally, creating a proper public project takes effort - there are lots more single-user solutions now.
In other words, I've got new personal projects completed, I make new tools almost every week at work, but it's unlikely I'll ever release anything that users or even developers in public will notice as "new, different software". And for user-visible things, almost all the time is now taken by talking to people and writing documents.
At least in my company, it is. I have vibe coded three apps that are far better than the competition: an Xpra/Wprs alternative that's faster and much more reliable, an alternative to the VSCode Git Graph extension that is much faster and has tons more useful features (e.g. drag and drop to move/copy/rebase commits which is a feature I always wanted), and a Mac app that lets you use cheap MIDI controllers to control your screen brightness, volume, media playback etc.
I use them all every day and they're all extremely reliable, and much better than the existing tools. One was entirely vibe coded and the other two were unfinished projects that I vibe completed (probably 70% vibe code).
I suspect a mountain of people and companies have tools like these but they haven't open sourced them because a) I used company tokens so there's admin to get things open sourced, and b) it almost feels like there's no point... you can just vibe code your own version to your exact liking. Do you really want to use mine?
The amount of posts when somebody introduces their program here on HN, that may have been LLM coded but that does not neglect the often massive amount of time the "dev" put into it. And yet, its all dismissed under this single negative "vibecoded" label.
I noticed that we are seeing more and more closed source programs, because people do not want to open source LLM generated code, out of fear that people start a negative PR loop against their program. And this reflects back to people not even releasing their programs into the wild.
There seem to be a inability of people to tell the difference between somebody spending a few prompts on making something, vs somebody spending months on 10.000's of prompts to make a great working program. It all gets thrown under that "vibe coded" bus. When its ironic because most code by now is LLM coded anyway. The amount of people hand coding is now probably a absolute minority.
Mostly, I think if you are promoting outside of your main area of expertise and couldn't have written it on your own, people don't want to put stuff out there and portray themselves as an expert in a subject matter that they relied heavily on AI assistance for, because it wouldn't be honest to other contributors to said project or other similar projects that were done without AI assistance. It would be a bit of a false representation of your own skills. That's why I am all for publishing, but also all for disclosures of AI assistance.
So, I think I'd be fine with taking a look at and contributing to "vibe coded" projects so long as the project leader disclosed their level of expertise on the underlying subject matter that the repo maintainer has and the extent of the AI assistance.
Then it may be a genuine learning opportunity for them (and for me) and more power to them and it's a shame if it doesn't get published, but I can see why socially there is a pressure not to do it, and get ragged on by the actual SMEs in the area that no doubt will be able to poke holes in what the AI came up with. I think we need those types of collabs though to upskill these new AI assisted coders into difficult types of programming though, so like I said, a bit of a shame if it never gets published and nobody that is an actual SME gives it the time of day.
I think that's actually a reason behind why the Linux Kernel has made decisions to allow AI assisted contributions by the way. I think they are trying to turn some of these people that want to be systems programmers (but at the moment can only do so through AI assistance) into real systems programmers by getting them involved and getting them mentorship. Which is I think a good thing. As long as Linus and other SMEs are there to keep a handle on potential actual AI slop, then it represents an opportunity to upskill interested people into a very not easy kind of programming. They just need to be treated fairly and disclose and get the mentorship they need to develop what I can only call "taste".
how/why that has happened is another story. I don't see the value in giving away my valuable thinking and ideas when it isn't appreciated and this massive-theft-founded AI company culture of our time thinks it is entitled to everything we create.
[Controversial edit: I don't think of myself as a slave, no matter what others may try to convince me to believe.]
But for me personally, the software I use on a day to day basis actually has changed drastically. I have lots of little apps and CLIs that speed up my workflows that I never had time to build in the past.
Maybe with capable agents productivity is increasing even more now, but building sw still takes time, even if only weeks or months instead of years.
just use nuclear
edit: get downvoted by chud
More availability issues with internet services.
When the next GPT or Claude models come out, people will say that AI coding sucked "until they came out."
And I agree, it’s because organizations and people haven’t changed (yet, if you’re being positive) what it is they’re optimizing for and how they do work. AI gives you more of what you want and gives it faster, that doesn’t on its own change the culture or goals of a company.
AI has been a huge disruption to that status quo though because it enables people like me that were stuck managing these bozos to just do the thing on a timeline that wasn’t feasible before. AI also removed any excuses these people could make for never getting anything done. It exposes clearly for anyone tangentially involved in these projects that the devs often can’t even begin to understand the problems they are trying to solve.
With the level of detail that I had to specify things for them to be productive, it’s easier and more effective to just give that (often much less detail tbh) to GitHub Copilot or Claude.
It has massively changed the game for me and helps me enjoy my job quite a bit more.
so actually it sounds like coder management was the bottleneck, not coding itself.
So no wonder AI is a huge improvement over whatever most organizations did to code something up.
Corollary: this mostly affected "business" software. Anything interesting meant good devs were already gravitating to it, so the SW would be vastly higher quality (think many Silicon valley shops).
It’s funny because when I managed an offshore team I did the same thing. And just like with llm I stopped looking at their code. It was a waste of time asking them to fix it because they’d just fix slop with slop. At least llms understand concurrency and don’t introduce data races!
However, even less are good/interested at playing Machiavellian politics to get things done in work environments. The larger the workplace, the more at stake, the more likely this is how things are done.
but when you have requirements,
why not render the code to fulfil them?
> why not render the code to fulfil them?
Because 95% of the time the LLM can turn the requirements into code, faster, cheaper, and with fewer defects on the first attempt, than most humans.
The ancients knew it all along!
What utter twaddle.
I’m old enough to remember pre AI programming and it very very much was the bottleneck.
Have this been measured, not comparatively, but absolutely? Where you plan, but don't code, instead leave the task to an agent (while you do something else), then test the result (maybe a quick look at the code), and ship. Is it sustainable? Or is it for greenfield setup and common ideas (things you would use tooling and snippets before)?
> What's left is "planning" which under a modern iterative model apparently includes deployment/distribution and getting/understanding/incorporating feedback.
That is not "planning" means. Planning is usually understanding, research, and design.
It meshes with my experience. Coding was never the bottleneck. Understanding what the customer/business wanted or needed was always the vast majority of the time spent on a project. A developer might not have seen that, depending how the organization worked. If you got specs from a manager you might not have been aware that those were 6 months in the making. If most of what you experienced was writing code then that could feel like the bottleneck especially if your manager demanded frequent status reports.
So old enough the remember the ancient times back in 2023?
The Heuristic Compiler, dating back to the early 1960s, is generally considered the first instance of AI programming.
Maybe you mistakenly confused AI with a particular AI technology, like LLMs? But even then we had LLM-based code completion tools in 2020.
Is 2023 when you became old enough to start remembering things?
First time they introduced electric motors in factories they just replaced the old central steam engine to drive the whole factory. It took four decades to figure out they could route electricity to each workstation and have many smaller motors.
Blow has aged, but he has made not one Hit indie game, not two, but whole whopping three indie hits that are extremely well received, critically acclaimed, and have sold very well, over the span of ... decades.
Almost every time basically going into debt to get there too.
His third game was the one where many had doubts if he's gonna make it to the other end, or will this game even sell, but apparently it does sell pretty darn well.
The guy is legitimately crazy, and I'm saying that as a compliment and highest form of praise.
John is a guy with extremely rare ability, persistance and ability to deliver and an insane work ethic to match. He's a rare gem.
This game definitely has left a mark on him, you can tell this one was tough to get through.
https://www.youtube.com/watch?v=ZSRHeXYDLko
There is also https://news.ycombinator.com/item?id=50496921 at work
I'm not sure how his opinions about dating are relevant.
That's how I felt when I was watching his "programming" stream.
A lot of things that I've paid for subscription services in the past I've just replaced with personalized software for myself. It's not something I would ever release publicly for others to use because I'm sure there's a million edge cases that wouldn't work for a broader audience, but it's perfect for me and saves me a ton of money.
Okay, maybe. So I am not a productive individual but now I also have all these "never bother releasing" projects because what was previously too much work is now 10 minutes of telegram messaging.
Accomplishment is proportional to effort. Skill building is proportional to complexity. All you have done is crossed an arbitrary item off a todo list.
Does this mean that jig makers out there are out of business? Sort of, they need to sell jigs complex enough that you wouldn't want to / be capable of making.
My 8 y.o. has vibecoded 25 games in three.js. He went yesterday to the chess club, in the evening he made his chess game. He watches PowerPuff girls on TV, then makes his PP game. He is driving it all by duplex voice mode. He doesn't even know how to say "restart the service" yet he manages to do it. That was after seeing me do one vibe coded game for him a couple months ago.
E.g. I find it maddening that music players don’t keep the play position per-album, so I rolled out my own.
I'm doing truly astounding - stupefying - levels of work. Others on my team are actively resistant to my advice but the C Suite isn't.
The numbers are shooting up and to the right but people don't want to get on board. It's too much too fast.
Edit. Consider your own reaction to my statement if down voting.
Recall the study done with open source devs, every one of them believed they were more productive with AI than without, yet the net effect of AI resulted in a 19% loss in productivity.
https://lowkeyviewer.com/studio/
I don't doubt people are 10x for certain things or things that used to be a ton of plumbing for the smallest stuff, but I'm easily 2-3x faster than I used to be because the rest of the process is so much faster now (finding information, libraries, getting answers to odd questions, builds, BUILDS). But I'm not seeing the software I use or posted here really change or zoom off like people say they are..
The “10x” developers I’ve known (and been) were all incredibly effective at snagging the work that they personally were most able to do quickly, and shirking the rest.
That’s not necessarily all the difference. But I’d estimate they would maybe be at most 2x developers if you remove their ability to avoid the proverbial 10% of the work that takes 90% of the effort.
AI coding intensifies this effect. And it also helps explain why people’s amazing success stories for personal projects don’t seem to translate to business ROI. For a side project I am in complete control over design and scope, have no customers or stakeholders to keep happy, etc. So I easily - and mostly unconsciously - tailor what I’m doing to what the coding agent can do well, and quietly drop the rest. I don’t have that luxury at work.
Ok, maybe some people are incapable of reflection.
If you keep doing the black box approach you will be deskilled in the medium term and your input less valuable.
If you are reading the code, explain how you can do the claimed amount of work, since whenever I review output it's a huge bottleneck
> Consider your own reaction to my statement if down voting.
Down votes in reaction to comments like these are almost always due to there being no evidence shared when these claims are made. Share the astounding, stupefying amount of work you're getting done because you've figured out the tools and watch as your down votes magically turn to up votes.
I wish I could collect these sentences of hyperbole in a little box, to revisit over the years and smile.
It’s a bit hard to distinguish them from that time cousin Mark took too high a dose of his ADHD medication.
Revenue is one of those numbers, right? Right??
> It's too much too fast.
Yes, that’s exactly what being over-leveraged looks like.
“The number one indicator of fragility is leverage” -Nassim Taleb
We have one of you at my work. He’s a god, but for the wisdom.
I feel that there is an amount of hubris in saying "I understand this codebase". You may remember the highlights, but every company in the dozen I've worked for that was actually making money - the codebase was too large for anyone to know fully. A wizard with the wisdom as you so eloquently put me down with would leave. And guess what? Nothing would happen. It is only in your own mind that you are so important.
Regarding wisdom, I do not mean knowledge of how the system works. That is a thing, too, where the person who built it is the only one who understands it. That’s not what I meant here.
In the examples of my coworkers, for example, I see at least two things:
1. The things they create are 90% well crafted, 30% well engineered. If they were building a rocket, every part would be well machined to high precision. Then when we assemble the rocket, we find out it’s too heavy to ever get off the ground. That’s a kind of wisdom gap.
2. They work in a way that excludes everyone else on the team. From their perspective, they are wondering why everyone else isn’t getting on board. But it’s a situation where one person understands it, and their deep understanding of it contributes to them moving fast, and then add AI and now the ground is shifting faster than anyone else can understand enough to contribute. This is another kind of wisdom gap, knowing how to get a team performing at a high level, versus an individual contributor performing at a high level.
This is where, from your perspective, you’re driving a speed boat as fast as you can, wondering why your coworkers aren’t on board. But from their perspective, they’re following your boat in their boats, but your boat is creating waves behind it and splashing water up, so their experience is a bumpy ride getting water splashed in their face constantly while they’re yelling “hey can you slow down up there?” From your perspective, it makes no sense to slow down. You’re not experiencing any problems. Yet both perspectives are still true.
The person who is charging forward as fast as possible also seems to be the one who has less experience operating and supporting systems, understanding how systems fail in unexpected ways, and so forth. Every week I have a conversation where someone tells me, “oh, I didn’t consider it might fail in that way”, and every time I think, yeah it would have been really nice if we’d had a 20 minute conversation 6 weeks ago when you started.
In general, it’s not that “other people just haven’t figured out the tools yet”, it’s also a significant part of who’s leading each initiative. I could absolutely do what my coworker does and setup my custom harness to pull off amazing stunts of productivity. I just think it’s irresponsible much of the time.
[0] https://en.wikipedia.org/wiki/Knight_Capital_Group
The latter is why managers love AI - and the former is why the general public hates it.
Code quality was never a one dimensional metric that just meant "easy for humans to read". Perhaps this distinction has been lost over time, or was never internalized by some parts of the industry, but high quality code is narrow in its function and design. It is well specified, with limited dimensions of variability - this is part of what metrics like cyclomatic complexity measure.
The reason for that is that the input space - the sheer combinations of possible input - of a piece of code grows far faster than the intended functionality of the code. Good code operates on a narrow space and that is important because it is both easier for humans to comprehend, and easier to test. Code that is easier to reason about is easier to validate - by humans, by automatic testing, and by LLMs.
Poorly written code is both harder to understand and harder to validate. An LLM is not an escape hatch that negates that.
I think there is a huge amount of resistance to a near-term future where it's more about the ability to describe and specify a thing than it currently is to code up a thing in order to build it. And I suspect that LLMs or whatever succeeds them will continue improving from here without any of the claptrap about a near-term malevolent superintelligence that's out to kill us all.
The future IMO will be relatively efficient code with independent models reviewing for quality and security afterwards. Life continues to come at us fast.
Natural language is more ambiguous so you often need more of it to describe something. Specifications if consistent often end up as a kind of programming language in themselves, but usually ambiguous on matters that affect performance.
I'm with you on the review side though. Even the best models of today give some nonsense in reviews, but if you understand the code it's usually easy to skim the review and skip over nonsense.
But you are right about the efficiency of description given you have the 10,000+ hours into writing efficient code in the chosen language. Most do not. And they hide that by leaning on Python and its insane library toolchain which itself becomes its own skill set, but one more amenable to LLMs to master.
To be brutally efficient, one would write everything in machine code, no?
https://github.com/humanlayer/advanced-context-engineering-f...
As someone who's driving Claude Opus 5.5 daily, by corporate mandate, in a team that is largely aggressively fans of AI, I don't those suspicions match my experiences.
Was interested in your conclusion and left confused.
I meant to write "Those suspicions match my experience."
Just two days ago I was in an incident where a bunch of feature flags my team controls, and that are very intentionally not automated, got flipped on by another team's automation.
I haven't seen a postmortem yet, but it smelled very much like genAI'd code that didn't get reviewed carefully enough.
...which is what all generated code in a software factory is, because the whole point is to have no idea what the hell the program will actually do - just what it has done in testing so far.
Talk about a perfect setup for backdoors - I'm sure there are already plenty of websites out there prompt-injecting agents to put backdoors into systems.
I'll quote Dijkstra yet again, though every time I do it I feel like no one listens to it, or understands what he meant:
"...program testing can be used very effectively to show the presence of bugs but never to show their absence."
Proving programs correct is very difficult, and only really effective if the programmer understands the program and the proof well - a coworker recently added a genAI TLA+ proof to one of our systems, but of course, no one's actually read it thoroughly or understood it, and sure enough, I saw a bug report the other day saying the model would need to be updated since it hadn't prevented the bug.
Deep, thorough comprehension has always been the hard part, and the LLMs do not do that, as far as I can tell.
They are amazing, and they are not trustworthy.
That is naive, have you seen coding agents write tests? They clearly walk the known patterns not imagine execution in all its intricacies. They do superficial testing, like humans.
I think it si time we returned to an old method - N-version programming - to replace "imagined execution" with "actual execution", and testing with fuzzing or passing prod data through a population of replicas. This is my take on AI code testing.
Gen AI does not work like how you think it does.
And very very soon you will find that you just created a self-pleasing machine not a functional system. No amount of boundaries, tests and checks can prevent that. That's just nonsense and it keeps get repeated by marketing
I believe the general public hates it because they are scared for their job (or social status? Life security? Don't know a good name).
The "public discourse" was full of "copyright infringement is not theft" slogans and arguments about how access to any form of art (especially video games and movies) should be free for everyone and how anyone making them gets paid was at best secondary.
But large scale changes with possibly immediate negative effects (job loss) is very scary and little is done to Adress those beyond "it will be fine somehow" (which isn't reassuring even if it was true).
Those caught up in the recent Microsoft outage would probably disagree.
Moreover, the public definitely cares about the poor quality of AI output in general - hence the most common word for it being “slop”.
Ex1: you and your personal workflows - the world doesn't care
Ex2: DHH and omachy - I certainly don't care about another Linux distro
Ex3: myself - I vibe coded several tools and plugins that I will never share with anyone, because their external value is 0
Ex4: this web dev youtuber I follow who is now vibe-coding his own video game. His game is at best a "6/10, kinda works but not sure why anyone would play it when there are much better games". So he is living out his 100X productivity fantasy, while producing something of 0 value to the rest of us.
At work I am seeing a similar thing... Work on core features has not radically sped up, probably because alignment takes a while, but everyone is making their own single-use dashboards.
Anyway, maybe I am coping / ludditing / am a loser with no imagination. But my observations generally align with the complaint that AI has not resulted (yet) in an explosion of delightful software. Just toys and dashboards, and mechanical rewrites of well-specified existing systems (ex Bun).
It can write it in some sense but I have to rewrite it. It is really good for exploration of ideas and code review for me though.
I am fairly sure he is a more conservative person than me so it is impossible he will find it useful for what you are describing.
I think humans are by and large just not great at this, especially in groups. I also think over the course of 2027 frontier labs will work on RL'ing harness engineering skills of the models themselves, so these systems treat engineering the environment in which they're engineering as a first class citizen since that's what makes a big difference.
Already they're doing RLCR to train swarms, so coordination is getting very good and this feeds into them being able to loop pretty quickly on code reviews and feedback without human input.
If your goal is verifiable and sufficiently well defined, and you have a strong deterministic set of constraints in place, then they can write a lot of code that's pretty usable.
From Nov 2025 to Nov 2026 we went from "we've only just gotten agents to work" to "we've only just gotten agents swarms to work" in publically available models. I'm rather interested to see who's still saying what in November 2027.
It’s common wisdom to regard programming as easily verifiable and I get it. The code itself is logical and the outputs testable. That part I don’t fight.
What I find lacking in many discussions is the fact that a stupendous amount of software engineering is not verifiable like that. Sure the bots could spit out working code a year ago already (and earlier) but there is a whole lot more going on in a code base than input-output matching.
The “taste”, the architecture, I don’t know what to call it. What you name your components, how you draw the boundaries and how you allocate resource and divide responsibilities and a whole lot more (DB design, etc). Those things cannot be “checked” to any sufficient accuracy and in my opinion they are still getting very good at it (not perfect) which makes me doubt progress is only about RLVR. There is more going on which is missed by just myopically looking at “code” and calling it “verifiable”.
This rising tide lifts all boats so to speak and I find it kind of .. concerning.
I went through the same arc. I used to tell people about how AI failed on some individual task.
I have found many tasks which LLMs are at least 2 orders of magnitude faster and better at than I (or any human I've ever met). Basically debugging and analyzing an existing code base AIs are simply better at than every human.
A skilled human will write better code, but actual lines of code output in a large software project is less than 25% of the work. LLMs are better at almost everything else.
You can very easily use LLMs to automate everything you don't enjoy doing. Ie: merge conflicts, monitoring PRs, fixing CI issues, monitoring telemetry, updating jira tickets, deep debugging.
LLMs are somewhere around 100x better than humans at "here is a bug; figure it out"
Blow is more renown for running his mouth and shitting on other people's work rather than any of his own work.
I sometimes wonder if I'm a victim of gel-mann amnesia when I listen to his opinions on gamedev too :(
People there will cheat every way possible to get their framerate/performance/cpy cycles. Yes, it's often amusing to read about really clever and interesting approaches, hacks or even framings of the problem. Like even one of Blow's presentations, where he was explaning how Braid did time reversal. Naive intuition tells: "make everything deterministic", Blow's answer: "how about just tracking state of everything".
But gamedev is not "orders of magnitude complex than any other software". State of the art databases need to be fast and correct. Even that alone makes them far more complex than "state of the art games".
And I'm sure there are many other areas who will look at databases and also rightfully tell that they are even more complex.
SOTA games need that too. Games need to deal with physics, audio, rendering, networking, anti-cheat etc. at the same time. All very performance sensitive
Do you think Postgres is more 'complex' than a triple A game like GTA 6?
> Do you think Postgres is more 'complex' than a triple A game like GTA 6?
Yes, absolutely. The postgres codebase has been around a long time and continues to be changed and accumulate functionality that all needs to work together. Just look at the details in the recent stories about all the issues that were found and the need to slip the schedule.
Often, in video games, an acceptable resolution of a bug is "Just don't do that".
"Just don't double spend" is not a solution when dealing with financial transactions.
1. Copy paste of custom c++ stl
2. Copy paste of whatever “standard library” they are using at the company
3. Copy paste of source code of whatever engine they are using with custom ad hoc fixes and patches that never were back ported back
4. Copy paste of every third party software that is seen on games startup screen
5. All the internal tools etc
Robotics! Take all the problems of games and databases and put them on wheels.
This is an absurd claim that gamedev folk like to tell themselves. Having seen the mess of several engine codebases, incl AAA engines and the memory leaking unoptimized state of many games, I don't think so.
There's many safety critical real time systems that are both more complex and approached with a lot more thorough design. Let's just say I would not trust a Jonathan Blow to put people on the moon.
That's not to say gamedev isn't challenging, but it's not quite as complex as the industry would like to think.
Tell that to the FAA.
If there is some uncertainty in the answer, maybe you have a point. But people can just be wrong.
It is more like the guy who can paint very good landscapes would start criticising every oscar category from producing to sound design, telling that they have 0 idea what they are doing, and he would do it better. Because you know, lanscape painting is 2d image, and movie is also, essentially, 2d image.
"Why the credits of Transformers are 5 minutes long with hundreds of people, you don't need more than 50 people to make such movie"...
Professional cooking is not any less art (as opposed to a quality process) than amateur. I'd instead listen to the chemical process engineers in food space, who - guess what - may just say the cakes shouldn't cost anywhere near to $50 :).
It appears to be taking Jon longer to make each game three years to make Braid, seven years to make The Witness, more than a decade to make OOTSS, though doubtless he will say that Jai (or whatever he decides that language should be called) held up OOTSS and somehow it would simultaneously have taken longer in C++ and yet it took so long because he didn't want to use C++.
[Edited, this is still 2026 even if it doesn't always feel like it]
Obligatory watch: https://www.youtube.com/watch?v=gWqnz-7iQbY
Not only is developing complex software intrinsically harder, there is way less (and way less public) training data for the code behind these types of systems. Probably the biggest wins right now for big dominant software systems are things like porting, paying down technical debt, raising efficiency, etc.; these are all tasks where the behavioral spec is pretty solidly defined by the existing code.
The software that is getting accelerated the most is the "not too big and complex software": web sites for niche things, mini games, ad-hoc data analysis, solving little specific problems with scripts, etc. But most of these kind of things are used by not too many people.
So, averaged over software a random person uses on a random minute, AI has not solved coding. But averaged over all the long tail of distinct (and often fairly simple) software people are building, it pretty much has.
With AI, those first 80% are now almost instant, producing flashy demos fooling us into believing that software development has been accelerated exponentially, but actually that speedup is only a very large linear multiplier that eventually gets consumed by the non-linearity.
Remind me of my manager, who likes the quote about how each 9 (as in 99.99 uptime) requires an equal amount of time to get to.
Even a one off small random program will become unusable in a few turns because 99% of people aren't reviewing things and so it'll just make false assumptions.
Seriously, the only people I hear from who think coding is solved don't seem to be very serious about their work. They're the ones who got into it for the money and never worked to improve themselves.
Running clang-scan-deps on some files takes as much time as compiling the file.
I am writing a build system that uses clang and this is just so insane if you compare it to how much other things take.
Doing the same version command on gcc takes 700 micro seconds. Even this is super slow imo but gives a perspective maybe.
[1] https://peps.python.org/pep-0810/#motivation
This has been a core feature of Outlook for so long that it might as well be considered day-1 functionality. Why it breaks like this in 2026? Who knows...
It also wasn't functional before-a-days [=
You should peak inside some old COBOL codebases running some of the most important software in the world [=
- AI can reason (with caveats)
- AI is impressive technology
- AI can code "leaf functionality" pretty well
- Modern models don't really make dumb flubs as much
He's saying modern programmer culture has turned all programming problems into "leaf functionality," the stuff which interfaces with OSes, libraries, and web services. He's saying that is the architectural decision which continues to plague us.
He's saying the way we approach "decoupling" is damaging the quality of the greater connected system in terms of correctness and performance. For example, I think most people here can all relate to the idea that lots of things are network requests which just didn't need to be, and so can fail when they don't fundamentally have to.
He's skeptical that AI can make & maintain a complex system which is correct and performs well. He gives the example of having AI generate a script to operate on an Excel sheet. That's using the API boundaries and systems we have today. He states that AI is pretty good at that, but you have to understand that; that's not what the word "programming" means to him.
In my opinion, if you can do system design, you can probably use AI to speed up that the process of implementing said system. That, I think is the more interesting discussion they could've had, because it scratches at what parts of that kind of programming are essential to be done by a person, which I assume isn't 0%. It's for this reason that I still code by hand as much as I do. How do people learn system-design? How do people learn the parts of programming which are necessary to use LLMs well?
It's a solution to something that shouldn't be a problem in the first place, if the OS was designed better.
Operating systems we use today were designed in an era when security and isolation were an afterthought at best. Plenty of security features have been bolted on over time to enable what we now call containerization, such as cgroups, namespaces, seccomp-bpf, capabilities, etc. But each part was added separately with its own API and tricky edge cases. Docker is needed as a midlayer to package them up into something a normal person can use.
If, however, the OS was designed from the ground up so that every process is only handed exactly the resources it needs (files, network endpoints, device handles, ...) as capabilities, every application would simply run sandboxed by default. Instead of taking away / altering permissions from a process that starts out with all permissions, we'd only add the exact capabilities it needs via a unified and clean system API. Capabilities handle not only permissions but also make namespacing practically free. The only Docker-like thing we might still need is a way to package and distribute images, but that's a much simpler problem to solve.
This is not a new idea, Fuchsia basically implements this. seL4 provides the necessary foundation as well. Plan 9 at least has per-process namespaces, which get us most of the way there.
Consider macOS. The closest equivalent to a container is the bundle. Bundles are much better that containers in several ways:
1. They're much simpler. Just directories with a special structure that's recognized by the OS.
2. They're much more efficient. A bundle ships only the program and any dependencies that sit outside the OS, but Apple invests so much in developing frameworks and in backwards compatibility, that a huge range of apps can be built that require no additional dependencies whatsoever. It's common for sophisticated Mac GUI apps to have bundle sizes in the tens of megabytes, whereas Docker images often require pulling gigabytes. Bundles are typically updated using tight per-file delta update schemes like Sparkle or the App Store, whereas Docker's delta update support is minimal (whatever was easy to implement at the time, basically).
3. They're decentralized. There is no de-facto reliance on a collection of hubs which charge lots of money for bandwidth (some companies block Docker Hub for this reason). Nor is bundle identity allocated by registries - you can create a bundle with a stable identity that survives upgrades even if you pass the bundles around on SD cards.
4. They're actually more "UNIX philosophy". You can move them around and organize them in the same way as any other kind of file or directory. You can "cd" into them from the shell, or synchronize them with Google Drive. There is no need for special servers, repositories, pulls or pushes.
5. They have much better support for sandboxing.
6. They share the same namespaces as the host, so there are no confusing path remappings going on. Despite that, sandboxed app get private areas of the user's home directory that are protected from other apps.
The underlying architecture here isn't perfect; bundles evolved over a period of decades and there's no rigid spec for the internal directory layout. The OS relies on collections of heuristics to identify bundles in a few cases. But it's architecturally much cleaner than Docker.
as for the list of points:
1. sure, though an OCI image can be exported to a flat bundle too if you don't care about layer efficiency
2. that's one of the things you don't want with docker containers. Nothing is stopping you from `-v /usr/lib:/usr/lib -v /bin:/bin` but you don't want that. Arguments about how much Apple or Windows puts into backward compatibility are moot once a minor breaking change is pushed to these machines without you knowing about it or if you want to explicitly have a different version of a platform library or dependency for one particular container
3. OCI registries are decentralized. The reliance on docker hub is just a convenance. It's like git is decentralized, the fact that everyone relies on GitHub is their own issue. If a DmgHub came up tomorrow where everyone uploads their dmg to it, and it became the socially acceptable place to always fetch dmgs from, did bundles become suddenly centralized and we need a different OS primitive to be decentralized again? the reason they are decentralized today is because no one cared to centralize them (except Apple's App Store of course)
4. You can do that with OCI images too
5. Nope. What's the bundle's equivalent of seccomp profiles? user-mode kernel/runsc? kata (VT-x or AMD-V) isolation?
6. That's a downside not an upside. You can put all your OCI files under /app, and mount the rest of the host mount namespace too. No one does that because they don't want to, not because it's not possible.
1. You can export images, but why is this complexity necessary in the first place? Efficiency does matter.
2. Bundles support different versions of frameworks than what comes with the system, that's not a problem. However it isn't mandatory like it is with containers. And yes, obviously you can make a container that isn't contained, but they aren't meant to be used like that - you are meant to always ship a complete userspace with the program, even if it's nothing more than a tiny script.
3. They aren't decentralized in any meaningful way. Blackhole Docker Hub on your machine and see how far you get. There's no equivalent problem for bundles.
4. Docker containers aren't natively files or directories, which is why you have to use separate commands like "docker image ls" instead of the real ls. You can turn them into files but then they aren't natively usable in that state until you import them.
5. Look into Apple's entitlements, code signing and TCC system. It's much more advanced than anything Linux has.
6. We'll just have to disagree on that. Namespacing is a crude hack that introduces many new kinds of bugs and configuration difficulties. Compared to just running the thing, it's worse.
2. They are meant to be used however you want them to be used. That was my point in their flexibility. There is literally no reason you couldn't get the same behavior of macos bundles with containers with the examples I gave if you have uniform host (like Apple gives with their macos uniform/controlled systems)
3. Docker Hub is already blackholed in most enterprise environments as you mentioned. There is literally no problem other than convenience. What possible problem could there be? Would git not work if GitHub is blackholed?
4. Again, there is literally no reason you couldn't get it to work that way. It's a very low hanging fruit that no one cares about.
5. Not true. It's more centralized and wallgardend, so it's easier to configure since there is one way of doing it which is Apple Inc way. I thought you argued against centralization. Again, how do I do user mode kernel in macos?
6. agree to disagree.
We're so far away from that its absurd. Yet an O/S designed from the ground-up to be simple (on modern hardware), would make that very simple.
So what argument is there to be bearish on it when it is in infancy? If you just want to go with "the quality sucks" well, sure, but it sucked a lot more two years ago, which means it sucks a lot less today, and in 2 more years, it will suck even less. I'd use different adjectives personally, cause I find it's pretty decent now (opus 5.5) and i'm pretty optimistic about what comes next.
It still generates text and doesn't reason, doesn't reflect, in any meaningful capacity.
Not to sound cocky, but I know how to write code and design software. It's a long, complex, and difficult problem to engineer anything.
When I use frontier LLMs, the best of the best, I still have to say things like "Why did you put code that concers device configuration in a service that just keeps track of one global flag", and it'll profusely apologize, point out that it's all overengineered, that it leaked boundaries that are documented in code, in agent documentation(!), etc., and then provide a fix that is maybe a little bit better. It's such utter horseshit, most of the time.
And yet, it's worth using it, because these problems can be caught, and the few times when it cooks up something good, it saves a lot of work.
1. Coding isn't completely solved yet. The further you get from CRUD apps, the more a little experienced human judgement helps.
2. The most dramatic improvements happened in the last couple of months. How fast do you expect software to ship?
3. I am now running multiple really amazing TUI tools that were largely written by someone's LLMs over the last several months. My software, at least, has already started changing.
It breaks my heart, because I love writing software and I think I'm pretty good at it. But another year of progress like the last 12 months, and I fear that our profession will be cooked.
Don't leave us hanging! What TUI tools are you using and what did they replace?
But if you take him just _slightly_ outside of his area of expertise - video game design and perhaps philosophy - his takes are extremely strongly held, banal, and don’t really stand up to scrutiny.
Best to admire his work but it’s pretty safe to ignore anything else he says, at least in my experience, or treat it more like an opinion from an average colleague rather than an industry expert.
Very good at what he does, poor takes in general.
Don’t even get me started on Muratori who is not even good at what he does, yet has the same strongly held takes seemingly mostly to curry favour with Blow.
Sorry if that seems a bit personal but I’ve been following him ever since Braid and I have found this to be repeatedly true, despite the self evident quality of his work.
Please get started :)
Isn't Casey quite successful as a developer from RAD and as an educator?
Obviously if you have time/energy invested learning a piece of software it's going to take you a minute to evaluate and learn a new alternative. But I can see vibe coded Apps fill the void when there aren't many great options.
- interaction regression test and ensuring taste, feeling of app use are consistent. agents still suck at that, especially general review agents, i hope this gets better as i introduce dedicated vision test agents for userflows but at the moment it takes about a week of usage to find the things that are wrong in subtle ways before an agent task can be accepted, if i push too fast and dont wait a week the app degrades quickly
- data layer: ui coding is largely solved apart the above but the limiting factor is the logic/state layer beteen the database and the ui, this has to be pluggable from persistence (both local and remote) and local first and reactive and be able to encapsulate the logic that would make ui components eat up complexity and slowly degrade. There are 100 local first libraries all broken in different ways or losing data in edgecases, the most promising one seems to be tanstackDB but i still dont have a setup that just fits perfect, but i am also nowhere near the level of understanding of it i would need
Coding is solved, but it got solved through a robbery of …idk… civilisational proportions. And is then (still) not even spread equally or accessible in any reasonable manner for reasons we all know about and are not in question.
The good thing about the internet, which solved so many communication challenges, was it was grown by people, started small and is still not in the hands of few companies, and even though Meta, Google and the gang are so ubiquitous.
I agree for the most part, but if I am the customer, and a company produced software via AI slop, why would I have to pay a lot for it? I'd expect the cost (for me as a buyer) to be reduced but that's not really happening. Of course the AI companies built up the "it costs a lot of tokens so you must pay more", thus they upscale the revenue they generate as a de-facto monopoly (mostly really), which then forces downstream companies to pass on these costs as well, logically. But honestly, that seems to me more like a cartel was established here, which is controlled by the big companis on top feeding away on the others. The basic question "why do I have to pay a lot for AI slop" still remains valid in this case, if computers autogenerated the AI slop code here.
Another gripe is he is willing to end privacy on internet because game piracy affects his sales.
One more thing he doesn't understand the struggles of people with kids and look down upon people with lesser talented than him. But this is okay given how much he toils to build skills and inspire others devs.
If u r reading this thanks Jonathan Blow for u r streams. You have been great inspiration.
> One more thing he doesn't understand the struggles of people with kids and look down upon people with lesser talented than him.
What did he say to make you believe that?
Also,
> piracy affects his sales
It's a bit more serious than that. It affects his livelihood and his passion. The acceptance of piracy has caused great harm to builders.
Procfs is basically just a crappy untyped API that requires tons of ad hoc non automated parsing code to use. Other operating systems haven't copied it because it's not a particularly good feature.
which is a misguided idea. /dev/urandom was famously replaced with a function call, getrandom(), because it being a file has all kinds of problems.
Ironically, software is not the same anymore, it has truly gotten worse.
It's not even just AI, Gaussian Splatting has a similar issue, amazing tech, amazing tech demos, but what's the modern equivalent to what Myst was using Gaussian Splatting? The tech is amazing, but somehow we seem to have a hard time making good use of it, everything is stuck in tech-demo land.
1. Blow is arguing that paradigms haven't changed which means software is still being produced and delivered in the same way. How do we get beyond "Clean Code", "Gang of Four", etc.?
2. AI is trained on human code. Inherently it is going to have bugs. Proper context, concepts and design will eliminate a lot of vibe-coding and AI slop, but if you are learning from bugs, then they will be there. It will be less.
3. There is going to be chaos for a junior engineer or a fresh graduate that has not experienced and built full systems. Where do they fit in now with AI doing the perceived grunt work? How do they get mentored? There is going to be a place for hungry software engineers that are getting out there and just figuring it out with a GSD attitude.
While the guy created a programming language, game engine and a game. And sold thousands of copies of that game.
Is this not much compared to working at big tech to adjust a button and drinking coffee at work. Because the team is bigger and there are more customers?
He has good points a lot of the time he just makes everything into flamebait.
Used to watch his videos but stopped because it just got tiring
Some people critique the industry in a constructive way, others do it in way that constantly positions themself as superior
Also the constant myopia of “whatever I do in gamedev world is obviously the best approach for all domains of software”
It is hard to find people that are healthy and are doing something worthwhile or saying something worthwhile unfortunately.
I also used to find Casey Muratori obnoxious but there really isn't many other options to follow except these people as far as I know.
The only "healthy" programmer I watch always is Mitchell Hashimoto.
Other youtuber/programmers are just good vibest with not much substance ime.
Because those who can, do. People who are doing worthwhile things don't have the time or inclination to stream it.
It's the pitfall of all content creators/streamers, eventually creating content takes over what they were creating content about.
I for one love to watch and listen to him, not for the fact that I find myself agreeing to so much of what he says, but because he is able to express things in very insightful ways. And yes, I'm a sucker for that "no bullshit" attitude.
Also, regarding Blow, let’s ask a stupid question back: if his language solved game development, why did his game take so long?
I suspect only a few people will use the language. With attitude like his, it is a risky proposition. Unreal Blueprints are gone, and that is coming from a big company. He could turn his product into a liability on a whim.
Until a few months ago when Solidcraft came out. It's very similar in appearance to Autodesk's Fusion360 package, and operates like a combination of Fusion360 and Solidworks. I've been trying it on every release, and it's making RAPID progress towards replacing Solidworks for my CAD workflows. I've been a Solidworks user since 1997, and I can confidently say that Solidcraft is advancing with biweekly releases which are more feature-rich than Solidworks annual releases. All of this is driven by AI/LLM development.
The tricky part here is that somebody has a good vision for the product they want to build, and they're doing it using an LLM, but not missing the jobs of product/project/engineering/release management. AI hasn't _solved_ coding, but it's reduced friction in ONE part of the development cycle. In most cases, that hasn't increased throughput very much (if at all), because it's just revealed the next slowest "rate limiting step" in the process. In cases where there is less overall business friction, and a strong vision without slow moving bureaucracy, it seems clear to me that LLMs _can_ greatly increase throughput. It also seems obvious that the advantage here lies mostly with very small teams with a great deal of experience actually delivering products. Great time for startups to do disruption, bad time for large slow-moving enterprises to get disrupted. Go capitalism or something.
Surely, it is because AI uses the same practices and techniques used by human programmers. Despite AIs being highly capable, programmers are unable to provide structure, rules and examples of how to architect, design, write or refactor consistently better software.
Given this, it’s quite amazing that AIs do so well.
Brilliant argument as always.
If (thing that is ambiguous and probably not true) why is (something ambiguous, subjective)
And yet... the app works efficiently, has features like shape-smoothing for hand-drawn freeform annotations (I wouldn't even know where to start if I were tasked with this on macOS, for example), it's designed far more beautifully than I could have done, even after a decade of studying UI/UX, etc
Yes, AI solved coding... mostly. At least for indie devs.
If it hasn't come for software/industry/enterprise x yet, it soon will, where "soon" = 3 ~ 18 months.
I do think it's accelerated enshitification of closed-source software and services, but I've never used less closed source software thanks to AI, and the open source software I'm replacing it with is more secure than ever.
My average Android app has way less permissions than it used to, less or no Network permission, and is smaller. It's excellent for my privacy.
New good software:
T3 Code is the best way to interact with AI coding. Fluxer is a great Discord alternative which has excellent UX. Fuck matrix btw.
> and the open source software I'm replacing it with is more secure than ever.
I'm not sure how you can be sure of that. If anything, the more code the more opportunities for issues. If you're referring to existing popular open source software that's getting aggressively scanned and pen tested, then sure. If the AI help in decreasing dependency on closed source software is mostly through new greenfield projects that are replacing them, you don't know how more secure than ever they are.
I added self-hosted E2EE sync to the greatest (closed source) to-do app of all time (Things 3) and I'm working on an Android clone of the iOS version which is already fully functional but has quite buggy UI.
None of it is slop. I am obsessed with Android UX so I fiddle a lot. All of it has greatly picked up thanks to Opus 5.5 and Sol 6.1. Sol is good for the premium unlocking while Claude models refuse.
I haven't released any of it yet because I have to sort out my opsec for the copyright stuff although I'm not particularly worried.
I did release the best way to make a dumbphone on Android: https://beeswax.getflourish.org
For a little while I was blocking its telemetry and stuff using Rethink DNS (an Android firewall/VPN app), but it still required an account and at that point in time I was using pretty much all open source apps on my Graphene OS phone, so I wasn't very happy about it.
So in the beginning the meditation app was quite sloppy. I think I made it originally with Opus 4.8 so it must have been like spring 2026 I started.
The habits and workout apps were just oneshot with my 5 hour usage of Codex each a few weeks ago. Most of the bugs are upstream so it was actually convincing me maybe AI is making some apps slop. Not so easy to fix them though, considering they're closed source. And I think it's probably better to just keep my patches minimal with unlocking premium and making it work offline.
Things maybe a week or so longer than the Android patches. For Things 3, at first I just wanted sync between MacOS user profiles, because you know, I don't want my to-do's on someone else's server. So initially I changed the certificate to intercept the traffic so a locally hosted MacOS service could sync them. That wasn't E2EE, but it was all local, so that was fine for me. I realized that I could just have patched the app to work with my server, so that fixed the messing with certificates.
But I wanted more. One of the worst thing about switching to Android (GrapheneOS) from iOS for me was that I lost Things 3. I could still use it on my Mac, but I'd really prefer to have it sync between them.
It would have been a world of pain and insecurity to try and add end-to-end encryption to the actual Things 3 app as traditional E2EE works. So I had the idea to just add the encryption to the local server that was already getting tasks synced to it. So just add clientside encryption there. And then I hosted a sync server that would run off my mac but would only see encrypted tasks.
This is important because that way I don't have to trust my own server's security, just that the clients are secure. Also because I'm using Cloudflare tunnels so Cloudflare could spy on the traffic if I didn't use E2EE. And if anyone else wanted to use my sync server, they wouldn't have to worry about me seeing their tasks.
The three closed source apps aren't much to write home about in terms of UX like transitions, buttons, etc. They could all be improved by a solid Material 3 Expressive rewrite. And that's what I'm doing with the meditation app.
But, the good thing they all share is that they are all great ideas.
The habits app is based on Atomic Habits, and it really integrates its teachings well.
The workout app has great videos and instructions [1]. It’s a really attractive framework the way it gives so many levels starting from super easy for each exercise. It's a calisthenics app, so the final variations are extremely impressive and cool to work towards. Think one-arm pullups, and pushups at level 10.
The meditation app has best-in-class content in a course style. It's free and I liked it better than Calm or Headsapce. Its creators are frontier researchers into how meditation affects the brain. Great ideas, great content, not the best app.
[1] Bundling the videos brought the APK to 600 MB!
I have a personal project where I am merging 100+ PRs a week and at work I would be lucky to merge 8. I spend 20x as much time trying to get PRs merged as I do actually doing the work.
I'm on a project with 4 other people working on 4 or 5 microservices and I would get more, better, work done if I were on a team alone managing all 4 or 5 microservices myself.
So the answer to why we don't see AI productivity gains more broadly is, unfortunately, enough people have not been "re-orged" away.
The part that I find extremely valuable is using LLM's as a replacement for searching code documentation. If you're new to something, you don't always know how to phrase your search query. The LLM's do an excellent job at translating your novice-level language into the precise terms you need. This saves a lot of people's times. You don't have to ask your question on a forum or to your colleague, saving not just your time, but everyone else's time. That's a big gamechanger. We can spend more time on the task you care about and not on all these tertiary side-trips.
What I find extraordinarily disappointing, however, is the industry's reaction was not "Oh wow, look at how much more productive we can make our programmers.". The industry's first reaction was to tokenmaxx and make the LLM's do everything, from writing code, submitting issues, design, etc. It leads to codebases that seem fine on the surface, but as you study the code, you find all sorts of issues. As these issues get discovered, the LLM then has to fix a bunch of different code, which leads to these infamous thousand-line PR/MR's. Even if LLM's produce code that works, remember that the quality of the LLM's output degrades when the context window reaches a certain point, which will start costing you more in terms of technical debt, bugs, and the literal token cost. It's also worth pointing out that companies that provide LLM's are still not profitable, so when the arms race between Google, OpenAI, and Anthropic settles, we're going to see the real cost to run these LLM code harnesses, and it just might make you pause and think before reaching for the LLM again. On the other hand, if the cost of hardware finally comes down, running your models locally would be a viable option, so you only have to worry about the upfront costs and the electricity bill.
With all that said, I think there's a bright future with LLM's. They are extremely good at pattern matching, and I think the real business value is in the use-cases that fits cleanly into that role. LLM's might not be the best at writing code, but they're exceptional at finding issues with your code. Case in point, OpenAI recently published a ton of fixes for root privilege exploits in the Linux kernel. I think spending our time constructing and training LLM's on how to discover issues for your particular domain will provide far more value that simply having the LLM write code for you.
(HN is also a very big fan of this hypothesis, without realizing it has gotten weaker with time. In their defense, I don’t think anyone wants to think about COVID anymore)
He thinks he's the foremost expert on basically any topic, from literature to politics, to science, to videogames etc.
Domain expertise rarely transfers to other domains. You, the random developer, are not going to have brilliant insights on the law, environment, consciousness, politics, or even another area of tech you don't use, by thinking about it for 5 minutes from "first principles" before commenting.
Because the Witness is a tedious slog, as is Order of the Tediously Long Title.
The hardest part of the Witness is the fact you aren’t told the rules of the line-drawing puzzle you’re presented. But often, they’re not that hard to discover. It’s not half as clever as Blow thinks it is. It’s essentially “what number am I thinking of”? Then being called a fool when you didn’t guess 12,859,155. Cool.
Why would you want to be told how a puzzle works if you can discover it yourself? Tutorials are boring, discovery through trial and error is exciting.
This doesn't just apply on the level of raw puzzles, but also on a meta level where you start understanding the ideas and concepts behind the puzzles, and then the absolute best part when you understand how these ideas and concepts interconnect (or are related or mirror each other, no pun intended).
Also, I find that his games aren't tedious at all. Sure, you might get stuck on a puzzle occasionally. But then you just go somewhere else and come back later. Or you go to sleep, gain the critical insight in your dreams, and then solve the puzzle. (I'm not kidding about that! It works wonders to sleep over a puzzle.)
I have not experienced any other games that's are as enjoyable as Blow's, not even close. But of course different people have different preferences.
If you don't enjoy the thinking and figuring things out, then maybe these games aren't for you. But every curious individual who loves playing with and enhancing one's mental understanding of abstract ideas, should absolutely play Blow's games.
I get more of a “Ah, ok” rather than a “satisfying eureka moment”.
All through your post you are assuming I’m getting stuck or “don’t enjoy figuring things out”, which I find presumptuous and condescending. Because, I’ve not had much problem with the figuring things out. It’s more with the repetition. You get a rule, then you get a couple dozen puzzles with slight variations of that rule. It’s tedium.
And Order is sokoban. Just, like, a lot of it. And even what you could claim is clever gameplay in it is just cribbed from the games he implemented.
They’re average games. They’re ok. They are not mind-expanding journeys into the very nature of the meaning of puzzles.
I should have made it clear that I was referring to the generic/impersonal "you", the HN readers, not "you" as in the specific account I was replying to. Sorry about that! I should have worded it more precisely. It certainly wasn't meant to be condescending.
Re puzzle difficulty in The Witness, this is the part of your previous comment that confuses me:
> The hardest part of the Witness is the fact you aren’t told the rules of the line-drawing puzzle you’re presented. But often, they’re not that hard to discover. It’s not half as clever as Blow thinks it is. It’s essentially “what number am I thinking of”? Then being called a fool when you didn’t guess 12,859,155.
I might have misunderstood this paragraph the first time I read it and wrote my reply. But now that I've read it about ten times, I still don't understand what exactly you're referring to.
On the one hand, you say that the rules often aren't that hard to discover. Fair enough. On the other hand, you compare it to guessing the number 12,859,155. I took that to mean the rules are very hard (take a lot of tries) to guess correctly.
I don't remember the latter being true at all. There is some guesswork initially to discover the rules, but those rules then apply to a lot of puzzles, and different rules combine to form larger and more interesting puzzles.
What I personally found most satisfying was eventually gaining a meta-understanding of how the rules are structured, and sometimes being able to predict what the new rules for a set of puzzles will be, taking away the guesswork completely.
(Granted, it's been a long time since I played the game at release, so maybe I'm misremembering things or viewing them through a lens of nostalgia.)
> And Order is sokoban. Just, like, a lot of it. [...] They are not mind-expanding journeys into the very nature of the meaning of puzzles.
For me personally, Blow's games have been mind-expanding. But I rarely play puzzle games. If I did, I might already be familiar with a lot of these ideas and find the puzzles boring. For me, the difficulty was just right. But I can imagine that people who play a lot of puzzle games need more to find something interesting, and that's fine.
So if your criticisim is that the puzzle rules aren't interesting or sophisticated enough for some people, then fair enough. They are interesting enough for me, though, and judging by sales and reviews, a lot of other people feel the same.
Either way, none of this is meant personally, I just enjoy talking about these games. Also, I can't speak to Blow's politics or other opinions people have brought up elsewhere in this discussion. All I can say for sure is that I've really enjoyed his games, and other people might too.
The puzzles in The Witness can be obvious from a certain perspective and so then if you have that perspective there's only one answer, why can't everybody see that. But if you lack that perspective, or worse, have slightly different perspective which you have falsely believed to be correct, you struggle.
If I know every US sports team's nickname then a Connections solution which hinges on knowing New York's team names seems obvious. If I didn't even know who the "Yankees" are then I'm going to find that particular connection hard to understand. Likewise if you know Lead's atomic symbol is Pb then you're going to more easily see that the letters PB might be related to a clue you had previously thought was about the verb "lead" not the noun.
That "Eureka" moment you describe is what puzzle makers are striving for, which is why e.g. Portal 2 has a hack where either portal button will save you in a situation where players may realise "Oh! A portal can save me!" but forget which end they need - just dying because you picked wrong isn't satisfying. This isn't Wolverine - if you just stubbornly don't use a portal you will die - but if you flail and pick orange when you needed blue the game has mercy on you.
However, Blow doesn't seem to have yet understood that the skill isn't in making the puzzle difficult and having a "Eureka" moment for some players but in designing your game to maximise this experience for the most players.
You can learn about this more easily playing "Zendo" https://en.wikipedia.org/wiki/Zendo_(game). A master who invents a rule their player cannot discover isn't a good master, that's just frustrating for everybody, there is skill in choosing a rule that will give your players the "Eureka" moment.
Two recent-ish video games stick out in my mind for delivering on this in very different ways. The first is Blue Prince. Blue Prince really wants you to figure out what's going on and have those Eureka moments. I have seen one gamer go "Bridge. Bride. OK I see what we're doing here" in their first five minutes of the game. I have seen a different gamer go "Yes, yes, a map of the house and more riddles, but what does it all mean?" while standing in the Study still not having understood the exact same puzzle... Tonda designed the game to be enjoyable for both players.
Secondly, Fleb's games, most obviously "20 Small Mazes" and its sequal "20 More Somehow Even Smaller Mazes". This time rather than offering many, many clues, the game delivers Eureka at pace by not forcing you to solve increasingly complicated versions of the same puzzle as "The Witness" does but instead you go from not understanding to then figuring it out and at about the time you go "Eureka!" the maze is solved and the next one is different.
That meta-stuff you mention leaves me cold because it's just introspection and I can do that without a video game. If the video game needs to fit in a Commodore Vic 20 (a machine with 4096 bytes of RAM, yes I said bytes) then sure there's no room to do more, giving me pause to reflect on my own beliefs is maybe the best you can do. But games like Animal Well show that in a modern video game you can, and I argue you should, actually put more game in the game, not just sit back and tell players their thoughts are part of your game. "The Witness" has moments where you think "Ooh, maybe there's more game in this game" but no, Jon couldn't be bothered to deliver more game, that's really your job apparently.
Especially in The Witness where there are times where failure of a puzzle forces you to re-input previous puzzles. Or there are a couple of dozen of the same puzzle with only minor variation with the same rule. "Yes, I can draw an L", "Yes, I can draw it backwards", "Yes, I can draw it and a cube, truly a masterfully built puzzle".
Something about the lone programmer off goat-skinning every aspect of the tech stack, while telling you how you are writing software wrong...
Track record isn't everything, especially for people early in their career, but when somebody ships successful products as consistently as Jonathan has for decades, that can no longer be ascribed to luck or anything like that. There must be some far-above-average skills involved.
Legal has much more authority , and far less familiarity with the product, or even the customers. So they demand orthogonal, complicated and impractical requirements that are not even beneficial for risk mitigation. And they are slow at providing them – usually the bottleneck.
It’s not a simple LOC/day formula. If Southwest Airlines wanted to make major software improvements tomorrow, it certainly wouldn’t be the engineering team armed with Claude Code holding them back.
The people who said building software wasn't the hard part before were right, you still need interesting problems to solve to find interesting things to build. Gotta get out of the tech bubble to find those. There aren't many interesting problems left to solve for other tech bros
Quality may be an issue but one could assume that any models will be improved. Complexity in the software itself is not really a huge issue for any good LLMs, so I don't understand this take he presents as "humans will always be better". It's like standing on the Titanic and saying "nothing to see here" while it is sinking, just as in the old movie Naked Gun (https://www.youtube.com/watch?v=NuAKnbIr6TE).
Anything that makes code more available to "normies" is something Jonathan Blow will absolutely hate. Why? Because Jonathan Blow HAS to be the smartest guy in the room, if he's somehow not the smartest guy in the room, there is something wrong with the room, nothing is ever wrong with Jonathan Blow.
So of course, Jonathan Blow thinks AI coding is terrible, only Jonathan Blow can be the best coder in the world, anyone who thinks otherwise is a total moron.
If you don't hand-roll your own programming language and game engine to make your own game, you're a moron. Hell, he even has a video where he basically says if you don't make your own version of JSON and associated parser, you're a fucking idiot.
What I'm saying is this, Jonathan Blow's ego only sustains itself on the idea that he is right about everything and the smartest person on any given topic. The idea that AI might be better at coding than him causes him to implode in a narcissistic rage.
This industry has been disparaging quality and efficiency in favor of servile laziness and cheap ignorance for so long, and it feels refreshing to hear that some people are still fighting against that trend, risking going too far like this article certainly does.
Yes, of course, if you are using json in a data pipeline then you may not be a moron but in that moment you are doing something idiotic. Yes of course sometime the right decision is to create a language specific for a given task, and if you have never considered it you should question why.
Now with LLMs the entire "make your own engine that is optimized for your game" is ironically back. But people like Blow balk at the idea that a LLM can make a game engine.
Is it strictly necessary? Most certainly not. I've met equally dedicated and talented individuals who are fine adapting to existing tooling and working around idiosyncrasies rather than improving the tooling. That personally drives me batshit, but I can stomach it if required.
It's also very well designed in my opinion. Love the way the ideas are introduced and built on top of each other.
Blow can afford to work on his lang and game for 10 years, but most people can't.
This is one of big changes with useful coding LLMS: each human person can have their own software to scratch their own itches. Corporations don't need to provide them. It's okay if they only work for me on my machine because they're only for me. They can be slop and still fulfill their much more limited goal(s).
Realistically speaking, AI raised the average quality. Among today's AI slop games, there are many that would have been "at this level of quality, this game could succeed" in the past.
Realistically, that's how it is. So there will be many people telling bad-luck stories like "ever since AI came out, GitHub has stalled," but I think that's closer to the opposite — AI increased production so much that the supply chain itself can't keep up.
The thing is, I can't really agree with the claim that software is the same. I don't know about open source, but when I think about the state of code in code delivered to clients, I think there has been a dramatic rise. Separately from that, because products are pouring out, I think consumers' quality demands are rising far faster than production. Comparing early smartphone games with today's AI slop games makes this even more palpable.
My friend is in managment at faang and he said ai has changed how tech coders now behave at work. he is enjoying the fact that "their tails have been cut by AI". Made his management job infinitely easier.
why is this downvoted?
Manager. FAANG. Enjoys the misfortune of the people he manages. Your friend sounds like a prick to me.
We're talking about something that speculatively invalidates all digital data. All code created prior is seen with lesser value to the point of commodification because of its existence. We are past the slow erosion of trust of the photoshop or Wikipedia era. You can't trust anything digital anymore. Encryption is our last hope, and companies now join governments in the race to break it.
Perhaps a bit of a leap but based on their phrasing, I'd be very critical of a viewpoint in management who believes themselves immune from what's occurring to specialized talent across the board. We are intergalactially far away from IBM's "never let a computer make a management decision." A concerningly large number of people submit their data, thinking, and agency to these tools. The impact is real even if not personally felt or in your backyard.
Yeah, I see this attitude a lot. People seem gleeful that software devs are getting kicked in the teeth, but honestly the business practices in software already have been kicking my ass my entire career. I've never felt like a respected, valued individual at any company I've worked for. I've only ever felt like an assembly line worker and accountability sink for my bosses. Someone to pile shit on, and then blame if stuff goes wrong.
My career has been full of overtime, evenings and weekends, overnight deployments, crunch time, layoffs, and for most of it I wasn't even making lots of money. It's only a couple of years ago I started making more than six figures, and now I'm laid off again and wondering if I'm even going to manage to get another job at all, nevermind one that pays as well.
I made the wrong choice in careers twenty years ago, tell you that much. Now I don't know what to do, but people are happy my tail has been cut, as if they haven't already been kicking my ass for ages. :/
Hard to feel anything but resentment anymore
The direction was clear for last 2 decades with every little feature broken into dozens upon dozens of tickets for better management . And now with AI each JIRA story can have its own design doc, testing doc, usage guide and so on. And management does seem happy by increasing number of artifacts which implied quality work done.
We've had a lot of hype cycles, but I'm honestly of the opinion that at least in terms of coding, this is somewhat like the consequences of if we invented say, the Star Trek Transporter.
That show notoriously struggles to really show that device at it's full power (because it was invented to solve a budget problem) - whereas if you think about it, the Transporter basically should've been THE reason the Federation had the power it did.
That's a bit of a myopic view. Imagine someone asking the same question a few years after the invention of the printing press.
It's not hard to find examples of how AI is changing things. To take just one example, look at how it's revolutionizing research in science and mathematics. I wouldn't expect this to change the average person's life overnight, but there are absolutely going to be huge breakthroughs in the next few decades.
We already know solutions to many current problems, and we knew them before AI - but those solutions are not being applied by people who are in charge. AI won't change those peoples' incentives.
Most jobs that people do today in advanced economies wouldn't exist without science and technology. It's bewildering that this needs to be explained on HN of all places.
Blow and coders have a hammer so all they see is nails; it didn't "solve coding" AI solved "machine state management". Totally different; human tagging/coding will still exist just at the presentation layer cause we don't need a bunch of syntax like:
def sumAllCustomerAccounts() { Some desired physical state of machine based on mathematical axioms }
AI solved naming that function (the coding with human context part) with
f() { generate a function to add all customer balances}
We moving on from 1960s and 70s machine state management, pushing context coding to the presentation layer
Blow is just doing that thing humans do where they wrap their entire identity up in who they were 30 years ago and still think that's who they are today and will be tomorrow; rotary phone companies, bowling alley equipment manufacturers... new generations are superseding them... circle of life Simba
Not really gonna put Blow and Carmack on a pedestal; they never invented computers or software dev. They came along in the middle of the hype. The read the manual for old machines. We're just moving on to new kinds of machines.
People flipped out over the printing press too. Nothing to see here; it's just the upper bound of the middle age generation having a mid-life crisis
there are many people to take their opinion on code seriously, and mr.Blow is certainly not one of them