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.
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.
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.
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.
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.
> 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.
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
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.
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.
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.
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.
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.
> 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.
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.
> 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”.
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.
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.
> 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"?
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
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.
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.
> 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.
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.
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.
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)
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.
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".
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)
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.
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
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.
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.
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”
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.
> 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.
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.
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.
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)
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).
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
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.
> 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.
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.
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.
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
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.
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.
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.
>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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
> 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.
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.
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.
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.
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.
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.
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).
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.
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.
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?
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?
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.
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.
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.
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?”.
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.
> 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.
> 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?
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.
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
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.
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.
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.
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.
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).
> 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!
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.
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.
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
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.
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.
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.
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.
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
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.
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?
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
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.
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.
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).
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.
> 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.
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.
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...
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."
> 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.
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.
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.
> 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.
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.
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?
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.
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.
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 :(
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.
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.
"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.
> 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.
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.
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.
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.
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.
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.
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.
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"...
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.
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.
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 :).
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]
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.
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?
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.
> 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.
> 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.
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.
> 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
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.
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).
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).
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, but 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.
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.
> 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.
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.
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.
>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.
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.
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.
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.
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.
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.
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.
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..
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.
> 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 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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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
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.)
Productivity means creating meaningful value and maximizing quality relative to your resources rather than simply rushing through tasks as fast as possible.
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.
> 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.
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.
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.
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.
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.
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.
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.
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!
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?
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.
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.
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.
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.
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”
>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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
> 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.
> 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.
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.
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".
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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).
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.
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
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.
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.
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.
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.
> 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. :/
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.
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.
>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.
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.
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 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.
AI has absolutely nothing to do with any of this. It merely accelerates the "how". You still need a customer to determine everything else.
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.
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.
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.
"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.
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.
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”.
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"?
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.
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.
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.
[1] https://root.cern.ch/TaligentDocs/TaligentOnline/DocumentRoo...
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".
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...
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.
Professionals should know how their tools work.
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”
You always have the ability to try out the simple version that ignores that reality:
* Don't branch
* Always force-push to master.
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.
> 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)
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.
Doesn't mean the tool is flawless, but if that ain't a new quality I don't know what is.
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
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.
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?
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.
"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"
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.
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.
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.
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.
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.
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.
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).
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.
Repeated forever, a statement always has a chance to be right.
After a point it’s going to be challenged
Now it’s permanent baby sitting.
As-is we're not going to get commercial fusion until at least what, 2040? 50?
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?
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.
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.
just use nuclear
edit: get downvoted by chud
More availability issues with internet services.
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.
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.
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.
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.
Maybe he just values doing his own thing more than money? Which is fine!... but not proof anyone else should take your advice.
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.
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.
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.
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.
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
The latter is why managers love AI - and the former is why the general public hates it.
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.
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.
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.
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
Gen AI does not work like how you think it does.
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”.
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, but 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.
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.
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.
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..
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
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
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.
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.
Blow is more renown for running his mouth and shitting on other people's work rather than any of his own work.
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 [=
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.
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.
Ironically, software is not the same anymore, it has truly gotten worse.
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!
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.
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.
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.
If (thing that is ambiguous and probably not true) why is (something ambiguous, subjective)
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.
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 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.
(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.
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.
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.
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.
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.
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.
Blow can afford to work on his lang and game for 10 years, but most people can't.
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
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.
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
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
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.
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.
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.