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.
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.
> 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”.
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.
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.
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.
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.
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
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 processand 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.
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.
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.
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 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.
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.
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?
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
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.
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.
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.
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.
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 :).
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.
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.
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.
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.
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?
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.
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.
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.)
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.
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).
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.
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.
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.
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.
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).
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.
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.
>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.
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..
> 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.
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.
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.
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.
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
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.
> 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.
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’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”
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 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 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.
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.
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.
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.
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.
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.
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).
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.
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. :/
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.
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.
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”.
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.
Gamedev programming probably hit a low point for me when XBox One and WiiU came around. Those were some truly awful experiences.
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.
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.
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
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.
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?
"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"
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.
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.
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.
Repeated forever, a statement always has a chance to be right.
After a point it’s going to be challenged
So people are super impressed because things just work, and they do.. Until they dont.
Just because things compile doesnt mean they're going to hold up, and most of this slop wouldn't, ive seen it first hand and you can also tell by the increased amount of outtages across different platforms.
As-is we're not going to get commercial fusion until at least what, 2040? 50?
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?
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.
I sometimes wonder if I'm a victim of gel-mann amnesia when I listen to his opinions on gamedev too :(
If there is some uncertainty in the answer, maybe you have a point. But people can just be wrong.
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 :).
Obligatory watch: https://www.youtube.com/watch?v=gWqnz-7iQbY
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.
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.
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.
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.
Gen AI does not work like how you think it does.
And very very soon you will find that you just created a self-pleasing machine not a functional system. No amount of boundaries, tests and checks can prevent that. That's just nonsense and it keeps get repeated by marketing
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”.
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.
They’ve both worked on AAA games before.
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.
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.
Not only is developing complex software intrinsically harder, there is way less (and way less public) training data for the code behind these types of systems. Probably the biggest wins right now for big dominant software systems are things like porting, paying down technical debt, raising efficiency, etc.; these are all tasks where the behavioral spec is pretty solidly defined by the existing code.
The software that is getting accelerated the most is the "not too big and complex software": web sites for niche things, mini games, ad-hoc data analysis, solving little specific problems with scripts, etc. But most of these kind of things are used by not too many people.
So, averaged over software a random person uses on a random minute, AI has not solved coding. But averaged over all the long tail of distinct (and often fairly simple) software people are building, it pretty much has.
With AI, those first 80% are now almost instant, producing flashy demos fooling us into believing that software development has been accelerated exponentially, but actually that speedup is only a very large linear multiplier that eventually gets consumed by the non-linearity.
Remind me of my manager, who likes the quote about how each 9 (as in 99.99 uptime) requires an equal amount of time to get to.
Even a one off small random program will become unusable in a few turns because 99% of people aren't reviewing things and so it'll just make false assumptions.
Seriously, the only people I hear from who think coding is solved don't seem to be very serious about their work. They're the ones who got into it for the money and never worked to improve themselves.
Running clang-scan-deps on some files takes as much time as compiling the file.
I am writing a build system that uses clang and this is just so insane if you compare it to how much other things take.
Doing the same version command on gcc takes 700 micro seconds. Even this is super slow imo but gives a perspective maybe.
[1] https://peps.python.org/pep-0810/#motivation
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..
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
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.
Ironically, software is not the same anymore, it has truly gotten worse.
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 [=
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.
It's a solution to something that shouldn't be a problem in the first place, if the OS was designed better.
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.
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!
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.
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?
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”
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.
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.
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.
Especially in The Witness where there are times where failure of a puzzle forces you to re-input previous puzzles. Or there are a couple of dozen of the same puzzle with only minor variation with the same rule. "Yes, I can draw an L", "Yes, I can draw it backwards", "Yes, I can draw it and a cube, truly a masterfully built puzzle".
Something about the lone programmer off goat-skinning every aspect of the tech stack, while telling you how you are writing software wrong...
Track record isn't everything, especially for people early in their career, but when somebody ships successful products as consistently as Jonathan has for decades, that can no longer be ascribed to luck or anything like that. There must be some far-above-average skills involved.
Legal has much more authority , and far less familiarity with the product, or even the customers. So they demand orthogonal, complicated and impractical requirements that are not even beneficial for risk mitigation. And they are slow at providing them – usually the bottleneck.
It’s not a simple LOC/day formula. If Southwest Airlines wanted to make major software improvements tomorrow, it certainly wouldn’t be the engineering team armed with Claude Code holding them back.
The people who said building software wasn't the hard part before were right, you still need interesting problems to solve to find interesting things to build. Gotta get out of the tech bubble to find those. There aren't many interesting problems left to solve for other tech bros
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).
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.
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.
there are many people to take their opinion on code seriously, and mr.Blow is certainly not one of them
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
My friend is in managment at faang and he said ai has changed how tech coders now behave at work. he is enjoying the fact that "their tails have been cut by AI". Made his management job infinitely easier.
why is this downvoted?
Manager. FAANG. Enjoys the misfortune of the people he manages. Your friend sounds like a prick to me.
We're talking about something that speculatively invalidates all digital data. All code created prior is seen with lesser value to the point of commodification because of its existence. We are past the slow erosion of trust of the photoshop or Wikipedia era. You can't trust anything digital anymore. Encryption is our last hope, and companies now join governments in the race to break it.
Perhaps a bit of a leap but based on their phrasing, I'd be very critical of a viewpoint in management who believes themselves immune from what's occurring to specialized talent across the board. We are intergalactially far away from IBM's "never let a computer make a management decision." A concerningly large number of people submit their data, thinking, and agency to these tools. The impact is real even if not personally felt or in your backyard.
Yeah, I see this attitude a lot. People seem gleeful that software devs are getting kicked in the teeth, but honestly the business practices in software already have been kicking my ass my entire career. I've never felt like a respected, valued individual at any company I've worked for. I've only ever felt like an assembly line worker and accountability sink for my bosses. Someone to pile shit on, and then blame if stuff goes wrong.
My career has been full of overtime, evenings and weekends, overnight deployments, crunch time, layoffs, and for most of it I wasn't even making lots of money. It's only a couple of years ago I started making more than six figures, and now I'm laid off again and wondering if I'm even going to manage to get another job at all, nevermind one that pays as well.
I made the wrong choice in careers twenty years ago, tell you that much. Now I don't know what to do, but people are happy my tail has been cut, as if they haven't already been kicking my ass for ages. :/
Hard to feel anything but resentment anymore
The direction was clear for last 2 decades with every little feature broken into dozens upon dozens of tickets for better management . And now with AI each JIRA story can have its own design doc, testing doc, usage guide and so on. And management does seem happy by increasing number of artifacts which implied quality work done.
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.