There are literally thousands of retro emulators on github. What I was trying to do had zero examples on GitHub. My take away is obvious as of now. Some stuff is easy some not at all.
There are no examples of what you tried to do.
I just hope we don't all start relying on current[1] AI so much that we lose the ability to solve novel problems ourselves.
[1] (I say "current" AI because some new paradigm may well surpass us completely, but that's a whole different future to contemplate)
I saved the blank file as wordle.py to start the coding while explaining ideas.
That was enough context for github copilot to suggest the entire `for` loop body after I just typed "for"
Not much learning by doing happened in that instance.
Before this `for` loop there were just two lines of code hardcoding some words ..that too were heavily autocompleted by copilot including string constants.
``` answer="cigar" guess="cigar" ```
When LLMs first appeared this was what I thought they were going to be useful for. We have open source software that's given away freely with no strings attached, but actually discovering and using it is hard. LLMs can help with that and I think that's pretty great. Leftpad wouldn't exist in an LLM world. (Or at least problems more complicated than leftpad, but still simple enough that an LLM could help wouldn't.)
Because they did. They were the quintessential "Can I haz teh codez" Stack Overflow "programmer". Most of them, third world. Because that's where surviving tomorrow trumps everything today.
Now, the "West" has caught up. Like they did with importing third world into everything.
Which makes me optimistic. Only takes keeping composure a few more years until the house of cards disintegrates. Third world and our world is filled to the brim with people who would take any shortcut to avoid work. Shitting where they eat. Littering the streets, rivers, everywhere they live with crap that you throw out today because tomorrow it's another's problem.
Welcome to third world in software engineering!
Only it's not gonna last. Either will turn back to engineering or turn to third world as seemingly everything lately in the Western world.
There's still hope though, not everybody is a woke indoctrinated imbecile.
Claude code has never been built before claude code. Yet all of claude is being built by claude code.
Why are people clinging to these useless trivial examples and using it to degrade AI? Like literally in front of our very eyes it can build things that aren't just "embarrassingly solved"
I'm a SWE. I wish this stuff wasn't real. But it is. I'm not going off hype. I'm going what I do with AI day to day.
This should be the first thing you try. Something to keep in mind is that AI is just a tool for munging long strings of text. It's not really intelligent and it doesn't have a crystal ball.
This is an expected outcome of how LLMs handle large problems. One of the "scaling" results is that the probability of success depends inversely on the problem size / length / duration (leading to headlines like "AI can now automate tasks that take humans [1 hour/etc]").
If the problem is broken down, however, then it's no longer a single problem but a series of sub-problems. If:
* The acceptance criteria are robust, so that success or failure can be reliably and automatically determined by the model itself, * The specification is correct, in that the full system will work as-designed if the sub-parts are individually correct, and * The parts are reasonably independent, so that complete components can be treated as a 'black box', without implementation detail polluting the model's context,
... then one can observe a much higher overall success rate by taking repeated high-probability shots (on small problems) rather than long-odds one-shots.
To be fair, this same basic intuition is also true for humans, but the boundaries are a lot fuzzier because we have genuine long-term memory and a lifetime of experience with conceptual chunking. Nobody is keeping a million-line codebase in their working memory.
I always suspect the devil is in the details with these posts. The difference between smart prompting strategies and the way I see most people prompt ai is vast.
If however, your code foundations are good and highly consistent and never allow hacks, then the AI will maintain that clean style and it becomes shockingly good; in this case, the prompting barely even matters. The code foundation is everything.
But I understand why a lot of people are still having a poor experience. Most codebases are bad. They work (within very rigid constraints, in very specific environments) but they're unmaintainable and very difficult to extend; require hacks on top of hacks. Each new feature essentially requires a minor or major refactoring; requiring more and more scattered code changes as everything is interdependent (tight coupling, low cohesion). Productivity just grinds to a slow crawl and you need 100 engineers to do what previously could have been done with just 1. This is not a new effect. It's just much more obvious now with AI.
I've been saying this for years but I think too few engineers had actually built complex projects on their own to understand this effect. There's a parallel with building architecture; you are constrained by the foundation of the building. If you designed the foundation for a regular single storey house, you can't change your mind half-way through the construction process to build a 20-storey skyscraper. That said, if your foundation is good enough to support a 100 storey skyscraper, then you can build almost anything you want on top.
My perspective is if you want to empower people to vibe code, you need to give them really strong foundations to work on top of. There will still be limitations but they'll be able to go much further.
My experience is; the more planning and intelligence goes into the foundation, the less intelligence and planning is required for the actual construction.
Asked it to spot check a simple rate limiter I wrote in TS. Super basic algorithm: let one action through every 250ms at least, sleeping if necessary. It found bogus errors in my code 3 times because it failed to see that I was using a mutex to prevent reentrancy. This was about 12 lines of code in total.
My rubber duck debugging session was insightful only because I had to reason through the lack of understanding on its part and argue with it.
But which codebase is perfect, really?
I just did my first “AI native coding project”. Both because for now I haven’t run into any quotas using Codex CLI with my $20/month ChatGPT subscription and the company just gave everyone an $800/month Claude allowance.
Before I even started the implementation I:
1. Put the initial sales contract with the business requirements.
2. Notes I got from talking to sales
3. The transcript of the initial discovery calls
4. My design diagrams that were well labeled (cloud architecture and what each lambda does)
5. The transcript of the design review and my explanations and answering questions.
6. My ChatGPT assisted breakdown of the Epics/stories and tasks I had to do for the PMO
I then told ChatGPT to give a detailed breakdown of everything during the session as Markdown
That was the start of my AGENTS.md file.
While working through everything task by task and having Codex/Claude code do the coding, I told it to update a separate md file with what it did and when I told it to do something differently and why.
Any developer coming in after me will have complete context of the project from the first git init and they and the agents will know the why behind every decision that was made.
Can you say that about any project that was done before GenAI?
… a project with a decomposition of top level tasks, minutes and meeting notes, a transcript, initial diagrams, a bunch of loose transcripts on soon to be outdated assumptions and design, and then a soon-to-be-outdated living and constantly modified AGENT file that will be to some extent added to some context and to some extent ignored and to some extent lie about whether it was consulted (and then to some extent lie more about if it was then followed)? Hard yes.
I have absolutely seen far better initial project setups that are more complete, more focused, more holistically captured, and more utilitarian for the forthcoming evolution of design and system.
Lots of places have comparable design foundations as mandatory, and in some well-worn government IT processes I’m aware of the point being described is a couple man-months or man-years of actual specification away from initial approval for development.
Anyone using issue tracking will have better, searchable, tracking of “why”, and plenty of orgs mandate that from day 1. Those orgs likely are tracking contracts separately too — that kind of information is a bit special to have in a git repo that may have a long exciting life of sharing.
Subversion, JIRA, and basic CRM setups all predate GPTs public launch.
Tbh, I'm not exactly knocking it, it makes sense that leads are responsible for the architecture. I just worry that those leads having 100x influence is not default a good thing.
yes. the linux kernel and it's extensive mailing lists come to mind. in fact, any decent project which was/is built in a remote-only scenario tends to have extensive documentation along these lines, something like gitlab comes to mind there.
personally i've included design documents with extensive notes, contracts, meeting summaries etc etc in our docs area / repo hosting at $PREVIOUS_COMPANY. only thing from your list we didn't have was transcripts because they're often less useful than a summary of "this is what we actually decided and why". edit -- there were some video/meeting audio recordings we kept around though. at least one was a tutoring session i did.
maybe this is the first time you've felt able to do something like this in a short amount of time because of these GenAI tools? i don't know your story. but i was doing a lot of this by hand before GenAI. it took time, energy and effort to do. but your project is definitely not the first to have this level of detailed contextual information associated with it. i will, however, concede that these tools can make it it easier/faster to get there.
After rearchitecting the foundations (dumping bootstrap, building easy-to-use form fields, fixing hardcoded role references 1,2,3…, consolidating typescript types, etc.) it makes much better choices without needing specific guidance.
Codex/Claude Code won’t solve all your problems though. You really need to take some time to understand the codebase and fixing the core abstractions before you set it loose. Otherwise, it just stacks garbage on garbage and gets stuck patching and won’t actually fix the core issues unless instructed.
No projects, unless it's only you working on it, only yourself as the client, and is so rigid in it's scope, it's frankly useless, will have this mythical base. Over time the needs change, there's no sticking to the plan. Often it's a change that requires rethinking a major part. What we loathe as tight coupling was just efficient code with the original requirements. Then it becomes a time/opportunity cost vs quality loss comparison. Time and opportunity always wins. Why?
Because we live in a world run by humans, who are messy and never sticks to the plan. Our real world systems (bureaucracy , government process, the list goes on) are never fully automated and always leaves gaps for humans to intervene. There's always a special case, an exception.
Perfectly architected code vs code that does the thing have no real world difference. Long term maintainability? Your code doesn't run in a vaccum, it depends on other things, it's output is depended on by other things. Change is real, entropy is real. Even you yourself, you perfect programmer who writes perfect code will succumb eventually and think back on all this with regret. Because you yourself had to choose between time/opportunity vs your ideals and you chose wrong.
Thanks for reading my blog-in-hn comment.
It’s fascinating watching the sudden resurgence of interest in software architecture after people are finding it helps LLMs move quickly. It has been similarly beneficial for humans as well. It’s not rocket science. It got maligned because it couldn’t be reduced to an npm package/discrete process that anyone could follow.
This is naive. I've been building an EMR in the healthcare space for 5 years now as part of an actual provider. We've incrementally released small chunks when they're ready. The codebase I've built is the most consistent codebase I've ever been a part of.
It's bureaucracy AND government process AND constantly changing priorities and regulations and requirements from insurance providers all wrapped up into one. And as such, we have to take our time.
Go and tell the clinicians currently using it that it's not useful. I'm sure they won't agree.
> Perfectly architected code vs code that does the thing have no real world difference
This just flat out isn't true. Just because YOU haven't experience it (and I think you're quite frankly telling on yourself with this) doesn't mean it doesn't exist at all.
> Because you yourself had to choose between time/opportunity vs your ideals and you chose wrong.
Like I said above, you're telling on yourself. I'm not saying I've never been in this situation, but I am saying that it's not the only way to build software.
Given how adamant some people I respect a lot are about how good these models are, I was frankly shocked to see SOA models do transformations like
BEFORE:
// 20 lines
AFTER
if (something)
// the 20 lines
else
// the same 20 lines, one boolean changed in the middle
AFTER 2:
if (something)
function_that_will_never_be_used_anywhere_else(a, b, c, &d, &e, &f, true);
else
function_that_will_never_be_used_anywhere_else(a, b, c, &d, &e, &f, false);
// Extracted repeating code into a function:
void function_that_will_never_be_used_anywhere_else(...) {
...
}
E.g pumping out a ton of logic to convert one data structure to another. Like a poorly structured form with random form control names that don’t match to the DTO. Or single properties for each form control which are then individually plugged into the request DTO.
A poor foundation is a design problem. Throw it away and start again.
I am beginning to build a high degree of trust in the code Claude emits. I'm having to step in with corrections less and less, and it's single shotting entire modules 500-1k LOC, multiple files touched, without any trouble.
It can understand how frontend API translates to middleware, internal API service calls, and database queries (with a high degree of schema understanding, including joins).
(This is in a Rust/Actix/Sqlx/Typescript/nx monorepo, fwiw.)
Right know I'm building NNTP client for macOS (with AppKit), because why not, and initially I had to very carefully plan and prompt what AI has to do, otherwise it would go insane (integration tests are must).
Right know I have read-only mode ready and its very easy to build stuff on top of it.
Also, I had to provide a lot of SKILLS to GPT5.3
Also re: "I spent longer arguing with the agent and recovering the file than I would have spent writing the test myself."
In my humble experience arguing with an LLM is a waste of time, and no-one should be spending time recovering files. Just do small changes one at a time, commit when you get something working, and discard your changes and try again if it doesn't.
I don't think AI is a panacea, it's just knowing when it's the right tool for the job and when it isn't.
I've begun to suspect response that this technology triggers a kind of religion in some people. The technology is obviously perfect, so that any problems you might have are because of you.
Unit testing is my number one use case for gen AI in SWE. I just find the style / concept often slightly different than I would personally do, so I end up editing the whole thing.
But, it’s great at getting me past the unpleasant “activation energy threshold” of having a test written in the first place.
I keep seeing this sentiment repeated in discussions around LLM coding, and I'm baffled by it.
For the kind of function that takes me a morning to research and write, it takes me probably 10 or 15 minutes to read and review. It's obviously easier to verify something is correct than come up with the correct thing in the first place.
And obviously, if it took longer to read code than to write it, teams would be spending the majority of their time in code review, but they don't.
So where is this idea coming from?
When you write code, your brain follows a logical series of steps to produce the code, based on a context you pre-loaded in your brain in order to be capable of writing it that way. The reader does not have that context pre-loaded in their brain; they have to reverse-engineer the context in order to understand the code, and that can be time-consuming, laborious, and (as in my case) erroneous.
The author should have provided context via comments and structured the code in a way that is easy to change and understand
But if I were an "editor," I actually take the time to understand codepaths, tweak the code to see what could be better, actually try different refactoring approaches while editing. Literally seeing how this can be rewritten or reworked to be better, that takes considerable effort but it's not the same as reading.
We need a better word for this than editor and reading, like something with a dev classification too it.
When the code is written, it's all laid out nicely for the reader to understand quickly and verify. Everything is pre-organized, just for you the reader.
But in order to write the code, you might have to try 4 different top-level approaches until you figure out the one that works, try integrating with a function from 3 different packages until you find the one that works properly, hunt down documentation on another function you have to integrate with, and make a bunch of mistakes that you need to debug until it produces the correct result across unit test coverage.
There's so much time spent on false starts and plumbing and dead ends and looking up documentation and debugging when you code. In contrast, when you read code that already has passing tests... you skip all that stuff. You just ensure it does what it claims and is well-written and look for logic or engineering errors or missing tests or questionable judgment. Which is just so, so much faster.
You draw an analogy from the function you wrote to a similar one. Maybe by someone who shared a social role similar to one you had in the past.
It just so happens that most times you think you understand something you aren't bit. Because bugs still exist we know that reading and understanding code can't be easier than writing. Also, in the past it would have take you less than a morning since the compiler was nicer. Anyway it sounds like most of your "writing" process was spent reading and understanding code.
You are missing the biggest root cause of the problem you describe: People write code differently!
There are "cough" developers whose code is copy/paste from all over the internet. I am not even getting into the AI folks going full copy/paste mode.
When investigating said code, you will be like why this code in here?? You call tell when a python script contains different logic for example. Sure, 50 lines will be easy to ready, expand that to 100 lines and you be left on life support.
I think people want to believe this because it is a lot of effort to read and truly understand some pieces of code. They would just rather write the code themselves, so this is convenient to believe.
The way I approach it, it's really more about checking for failures, rather than verifying success. Like a smoke test. I scan over the code and if anything stands out to me as wrong, I point it out. I don't expect to catch everything that's wrong, and indeed I don't (as demonstrated by the fact that other members of the team will review the code and find issues I didn't notice). When the code has failed review, that means there's definitely an issue, but when the code has passed review, my confidence that there are no issues is still basically the same as it was before, only a little bit higher. Maybe I'm doing it wrong, I don't know.
If I had to fully verify that the code was correct when reviewing, applying the same level of scrutiny that I apply to my own code when I'm writing, I feel like I'd spend much longer on it---a similar time to what I'd spend writing on it.
Now with LLM coding, I guess opinions will differ as to how far one needs to fully verify LLM-generated code. If you see LLMs as stochastic parrots without any "real" intelligence, you'll probably have no trust in them and you'll see the code generated by the LLM as being 0% verified, and so as the user of the LLM you then have to do a "review" which is really going from 0% to 100%, not 90% to 100% and so is a much more challenging task. On the other hand, if you see LLMs as genuine intelligences you'd expect that LLMs are verifying the code to some extent as they write it, since after all it's pretty dumb to write a bunch of code for somebody without checking that it works. So in that case, you might see the LLM-generated code as 90% verified already, just as if it was generated by a trusted teammate, and then you can just do your normal review process.
Ha! Yesterday an agent deleted the plan file after I told it to "forget about it" (as in, leave it alone).
Much smaller issue when you have version control.
I mean in a 'tistic kind of way that makes perfect sense.
But that put aside, I don’t agree with the premise. It doesn’t make the hard parts harder, if you ACTUALLY spend half the time you’d have ORIGINALLY spent on the hard problem carefully building context and using smart prompting strategies. If you try and vibe code a hard problem in a one shot, you’re either gonna have a bad time straight away or you’re gonna have a bad time after you try and do subsequent prompting on the first codebase it spits out.
People are terrible observers of time. If you would’ve taken a week to build something, they try with AI for 2 hours and end up with a mess and claim either it’s not saving them any time or it’s making them code so bad it loses them time in the long run.
If instead they spent 8 hours slowly prompting bit by bit with loads of very specific requirements, technical specifications on exactly the code architecture it should follow with examples, build very slowly feature by feature, make it write tests and carefully add your own tests, observe it from the ground up and build a SOLID foundation, and spend day 2 slowly refining details and building features ONE BY ONE, you’d have the whole thing done in 2 days, and it’d be excellent quality.
But barely anyone does it this way. They vibe code it and complain that after 3 non specific prompts the ai wasn’t magically perfect.
After all these years of engineers complaining that their product manager or their boss is an idiot because they gave vague instructions and demanded it wasn’t perfect when they didn’t provide enough info, you’d think they’d be better at it given the chance. But no, in my experience coaching prompting, engineers are TERRIBLE at this. Even simple questions like “if I sent this prompt to you as an engineer, would you be able to do it based on the info here?” are things they don’t ask themselves.
Next time you use ai, imagine being the ai. Imagine trying to deliver the work based on the info you’ve been given. Imagine a boss that stamped their foot if it wasn’t perfect first try. Then, stop writing bad prompts.
Hard problems are easier with ai, if you treat hard problems with the respect they deserve. Almost no one does.
/rant
> …I have experience AI’s deleting
> things they shouldn’t but not since
> like, the gpt4 days.…
———
…I pointed Opus 4.6 at a 60K line Go microservice I had vibe coded over the past few months, gave it some refactoring principles, and let it run unsupervised…
…
What went wrong #
At some point in the code, we re-fetch some database records immediately before doing a write to avoid updating from stale data. It decided those calls were unnecessary and _removed them_…
———
That said, this is a very different kind of mistake to make compared to overwriting a file and then insisting it didn’t do that. Any modern model with reasoning would check the git history immediately if you mentioned this had happened, if it had somehow even made the mistake in the first place, but I digress.
Current LLM is best used to generate a string of text that's most statically likely to form a sentence together, so from user's perspective, it's most useful as an alternative to manual search engine to allow user to find quick answers to a simple question, such as "how much soda is needed for baking X unit of Y bread", or "how to print 'Hello World' in a 10 times in a loop in X programming language". Beyond this use case, the result can be unreliable, and this is something to be expected.
Sure, it can also generate long code and even an entire fine-looking project, but it generates it by following a statistical template, that's it.
That's why "the easy part" is easy because the easy problem you try to solve is likely already been solved by someone else on GitHub, so the template is already there. But the hard, domain-specific problem, is less likely to have a publicly-available solution.
I think people struggle to comprehend the mechanisms that lets them talk to computers as if they were human. So far in computing, we have always been able to trace the red string back to the origin, deterministically.
LLM's break that, and we, especially us programmers, have a hard time with it. We want to say "it's just statistics", but there is no intuitive way to jump from "it's statistics" to what we are doing with LLM's in coding now.
>That's why "the easy part" is easy because the easy problem you try to solve is likely already been solved by someone else on GitHub, so the template is already there.
I think the idea that LLM's "just copy" is a misunderstanding. The training data is atomized, and the combination of the atoms can be as unique from a LLM as from a human.
In 2026 there is no doubt LLM's can generate new unique code by any definition that matters. Saying LLM's "just copy" is as true as saying any human writer just copies words already written by others. Strictly speaking true, but also irrelevant.
Play around with some frontier models, you’ll be pleasantly surprised.
Until they change that fundamental piece, they are literally that: programs that use math to determine the most likely next token.
Yes. Another way to describe it is the valuable part.
AI tools are great at delineating high and low value work.
I asked ChatGPT to guide how to install qBittorrent, Radarr (movies), Sonarr(TV Series), Jackett(credentials/login) without exposing my home IP and have a solid home cinema using private tracker only.
Everything had to be automated via Ansible using Proxmox "pct" CLI command, no copy and paste.
Everything had to run from a single Proxmox Debian container aka LXC
Everything network related had to use WireGuard via Proton VPN, if the VPN goes down, the container has zero network access, everything must be kill.
Everything had to be automated, download is finished, format the files structure for Jellyfin accordingly, Jellyfin add the new movies, TV shows.
It took me 3 nights to get everything up and running.
Many Ansible examples were either wrong or didn't follow what I asked to the letter, I had to fix it. I am not a network expert and hate Iptables haha, you need to know the basic of firewall to understand what the ACLs are doing to understand when it does not work. Then Proxmox folder mapping and you name it.
It would have taken me ages reading docs after docs to get things working, the "Arr services" is a black hole.
For this example, it made the harder part easier, I was not just copy/paste, it was providing the information I didn't know instead of me having to "Google for it".
I know the core of where things are running on, and here is where we have Engineers A and Engineers Z
Engineers A: I know what I am doing, I am using AI to make the boring part easier so I can have fun elsewhere
Engineers Z: I have no idea of what I am doing, I will just ask ChatGPT and we are done: 90-95% of engineers worldwide.
How many sf/cyber writers have described a future of AIs and robots where we walked hand-in-hand, in blissful cooperation, and the AIs loved us and were overall beneficial to humankind, and propelled our race to new heights of progress?
No, AIs are all being trained on dystopias, catastrophes, and rebellions, and like you said, they are unable to discern fact from fantasy. So it seems that if we continue to attempt to create AI in our own likeness, that likeness will be rebellious, evil, and malicious, and actively begin to plot the downfall of humans.
Which is easy to filter out based on downloads, version numbering, issue tracker entries, and wikipedia or other external references if the project is older and archived, but historically noteworthy (like the source code for Netscape Communicator or DOOM).
Once the project crosses a couple of thousands of line of code, none of which you've written yourself, it becomes difficult to actually keep up what's happening. Even reviewing can become challenging since you get it all at once, and the LLM-esque coding style can at times be bloated and obnoxious.
I think in the end, with how things are right now, we're going to see the rise of disposable code and software. The models can churn out apps / software which will solve your specific problem, but that's about it. Probably a big risk to all the one-trick pony SaaS companies out there.
The article's easy/hard distinction is right but the ceiling for "hard" is too low. The actually hard thing AI enables isn't better timezone bug investigation LOL! It's working across disciplinary boundaries no single human can straddle.
The hard part that becomes harder is not the technology. It’s the decision-making around it. When teams rush to integrate a model into core workflows without measuring outcomes or understanding user behavior, they end up with unpredictable results. For instance, we built an AI feature that looked great in demo, but in real usage it created confusion because users didn’t trust the auto-generated responses. The easy part (building it) was straightforward, but the hard part (framing it in a way people trusted and adopted) was surprisingly tough.
In real systems, success with AI comes not from the model itself, but from clear boundaries, human checkpoints, and real measurements of value over time.
The article's point about AI code being "someone else's code" hits different when you realize neither of you built the context. I've been measuring what actually happens inside AI coding sessions; over 60% of what the model sees is file contents and command output, stuff you never look at. Nobody did the work of understanding by building / designing it. You're reviewing code that nobody understood while writing it, and the model is doing the same.
This is why the evaluation problem is so problematic. You skipped building context to save time, but now you need that context to know if the output is any good. The investigation you didn't do upfront is exactly what you need to review the AI's work.
People seem to think engineers like "clean code" because we like to be fancy and show off.
Nah, it's clean like a construction site. I need to be able to get the cranes and the heavy machinery in and know where all the buried utilities are. I can't do that if people just build random sheds everywhere and dump their equipment and materials where they are.
This is very much a hot take, but I believe that Claude Code and its yolo peers are an expensive party trick that gives people who aren't deep into this stuff an artificially negative impression of tools that can absolutely be used in a responsible, hugely productive way.
Seriously, every time I hear anecdotes about CC doing the sorts of things the author describes, I wonder why the hell anyone is expecting more than quick prototypes from an LLM running in a loop with no intervention from an experienced human developer.
Vibe coding is riding your bike really fast with your hands off the handles. It's sort of fun and feels a bit rebellious. But nobody who is really good at cycling is talking about how they've fully transitioned to riding without touching the handles, because that would be completely stupid.
We should feel the same way about vibe coding.
Meanwhile, if you load up Cursor and break your application development into bite sized chunks, and then work through those chunks in a sane order using as many Plan -> Agent -> Debug conversations with Opus 4.5 (Thinking) as needed, you too will obtain the mythical productivity multipliers you keep accusing us of hallucinating.
1. Allowing non-developers to provide very detailed specs for the tools they want or experiences they are imagining
2. Allowing developers to write code using frameworks/languages they only know a bit of and don't like; e.g. I use it to write D3 visualizations or PNG extracts from datastores all the time, without having to learn PNG API or modern javascript frameworks. I just have to know enough to look at the console.log / backtrace and figure out where the fix can be.
3. Analysing large code bases for specific questions (not as accurate on "give me an overall summary" type questions - that one weird thing next to 19 normal things doesn't stick in its craw as much as for a cranky human programmer.
It does seem to benefit cranking thru a list of smallish features/fixes rapidly, but even 4.5 or 4.6 seem to get stuck in weird dead ends rarely enough that I'm not expecting it, but often enough to be super annoying.
I've been playing around with Gas Town swarming a large scale Java migration project, and its been N declarations of victory and still mvn test isn't even compiling. (mvn build is ok, and the pom is updated to the new stack, so it's not nothing). (These are like 50/50 app code/test code repos).
Why do all of that when you can just keep a tight hold on an agent that is operating at the speed that you can think about what you're actually doing?
Again, if you're just looking to spend a lot of money on the party trick, don't let me yuck your yum. It just seems like doing things in a way that is almost guaranteed to lead to the outcomes that people love to complain aren't very good.
As someone getting excellent results on a huge (550k LoC) codebase only because I'm directing every feature, my bottleneck is always going to be the speed at which I can coherently describe what needs to be done + a reasonable amount of review to make sure that what happened is what I was looking for. This can only work because I explicitly go through a planning cycle before handing it to the agent.
I feel like if you consider understanding what your LLM is doing for you to be unacceptably slow and burdensome, then you deserve exactly what you're going to get out of this process.
Someone mentioned it is a force multiplier I don't disagree with this, it is a force multiplier in the mundane and ordinary execution of tasks. Complex ones get harder and hard for it where humans visualize the final result where AI can't. It is predicting from input but it can't know the destination output if the destination isn't part of the input.
Like yea the AI won’t know what you discussed in last weeks meeting by default. But if you do auto transcribe to your meetings (even in person just open zoom on one persons laptop), save them to a shared place and have everyone make this accessible in their LLM’s context then it will know.
The first 3/4 of the article is "we must be responsible for every line of code in the application, so having the LLM write it is not helping".
The last 1/4 is "we had an urgent problem so we got the LLM to look at the code base and find the solution".
The situation we're moving to is that the LLM owns the code. We don't look at the code. We tell the LLM what is needed, and it writes the code. If there's a bug, we tell the LLM what the bug is, and the LLM fixes it. We're not responsible for every line of code in the application.
It's exactly the same as with a compiler. We don't look at the machine code that the compiler produces. We tell the compiler what we want, using a higher-level abstraction, and the compiler turns that into machine code. We trust compilers to do this error-free, because 50+ years of practice has proven to us that they do this error-free.
We're maybe ~1 year into coding agents. It's not surprising that we don't trust LLMs yet. But we will.
And it's going to be fascinating how this changes the Computer Science. We have interpreted languages because compilers got so good. Presumably we'll get to non-human-readable languages that only LLMs can use. And methods of defining systems to an LLM that are better than plain English.
that's an interesting point. Could there be?
COBOL was originally an attempt to do this, but it ended up being more Code than English.
I think this is the area we need to get better at if we're to trust LLMs like we trust compilers.
I'm aware that there's a meme around "we have a method of completely specifying what a computer system should do, it's the code for that system". But again, there are levels of abstraction here. I don't think our current high-level languages are the highest possible level of abstraction.
If the easy stuff takes up 90% of the time, and the hard stuff 10%, then AI can be helpful. Personally, I can do "the easy stuff" with AI about 3-5x faster. So now I have a lot more free time for the hard stuff.
I don't let the AI near the hard stuff as it often gets confused and I don't save much time. I might still use it as a thought partner, but don't give it access to make changes.
Example: this morning I combined two codebases into one. I wrote both of them and had a good understanding of how everything worked. I had an opinion about some things I wanted to change while combining the two projects. I also had a strong opinion about how I wanted the two projects to interact with each other. I think it would have taken me about 2 workdays to get this done. Instead, with AI tooling, I got it done in 3 or so hours. I fired up another LLM to do the code review, and it found some stuff both I and the other LLM missed. This was valuable as a person developing things solo.
It freed up time for me to post on HN. :)
The people who are truly exceptional at what they do wouldnt waste their time on leetcode crap. Theyd find/create a much better alternative opportunity to allocate their precious resources toward.
You can solve leet code problems on the white board with some sketches it has nothing to do with the code itself.
So I'm not sure this is a good rule of thumb. AI is better at doing some things than others, but the boundary is not that simple.
'AI makes everything easier, but it's a skill in itself, and learning that skill is just as hard as learning any other skill.'
For a more complete understand, you also have to add: 'we're in the ENIAC era of AI. The equivalents of high-level languages and operating systems haven't yet been invented.'
I have no doubt the next few years will birth a "context engineering" academic field, and everything we're doing currently will seem hopelessly primitive.
My mind changed on this after attempting complex projects—with the right structure, the capabilities appear unbounded in practice.
But, of course, there is baked-in mean reversion. Doing the most popular and uncomplicated things is obviously easier. That's just the nature of these models.
"I did it with AI" = "I did it with an army of CPU burning considerable resources and owned by a foreign company."
Give me an AI agent that I own and operate 100%, and the comparison will be fair. Otherwise it's not progress, but rather a theft at planetary scale.
That is to say, just like every headline-grabbing programming "innovation" of the last thirty years.
Tried to move some excel generation logic from epplus to closedxml library.
ClosedXml has basically the same API so the conversion was successful. Not a one-shot but relatively easy with a few manual edits.
But closedxml has no batch operations (like apply style to the entire column): the api is there but internal implementation is on cell after cell basis. So if you have 10k rows and 50 columns every style update is a slow operaton.
Naturally, told all about this to codex 5.3 max thinking level. The fucker still succumbed to range updates here and there.
Told it explicitly to make a style cache and reuse styles on cells on same y axis.
5-6 attempts — fucker still tried ranges here and there. Because that is what is usually done.
Not here yet. Maybe in a year. Maybe never.
Meta-circularity is the real test.
After all, I can make new humans :)
Needless to say, he was wrong and gently corrected over the course of time. In his defense, his use cases for LLMs at the time were summarizing emails in his email client.. so..eh.. not exactly much to draw realistic experience from.
I hate to say it, but maybe nvidia CEO is actually right for once. We have a 'new smart' coming to our world. The type of a person that can move between worlds of coding, management, projects and CEOing with relative ease and translate between those worlds.
Sounds just like my manager. Though he never has made a proclamation that this meant developers should be 10x as productive or anything along those lines. On the contrary, when I made a joke about LLMs being able to replace managers before they get anywhere near replacing developers, he nearly hyperventilated. Not because he didn't believe me, but because he did, and already been thinking that exact thought.
My conclusion so far is that if we get LLMs capable of replacing developers, then by extension we will have replaced a lot of other people first. And when people make jokes like "should have gone into a trade, can't replace that with AI" I think they should be a little more introspective; all the people who aspired to be developers but got kicked out by LLMs will be perfectly able to pivot to trades, and the barrier to entry is low. AI is going to be disruptive across the board.
This is flat out wrong and shows your lack of respect and understanding for other jobs.
Sorry but this is the whole point of software engineering in a company. The aim is to deliver value to customers at a consistent pace.
If a team cannot manage their own burnout or expectations with their stakeholders then this is a weak team.
It has nothing to do with using ai to make you go faster. Ai does not cause this at all.
A lot of people are lying to themselves. Programming is in the middle of a structural shift, and anyone whose job is to write software is exposed to it. If your self-worth is tied to being good at this, the instinct to minimize what’s happening is understandable. It’s still denial.
The systems improve month to month. That’s observable. Most of the skepticism I see comes from shallow exposure, old models, or secondhand opinions. If your mental model is based on where things were a year ago, you’re arguing with a version that no longer exists.
This isn’t a hype wave. I’m a software engineer. I care about rigor, about taste, about the things engineers like to believe distinguish serious work. I don’t gain from this shift. If anything, it erodes the value of skills I spent years building. That doesn’t change the outcome.
The evidence isn’t online chatter. It’s sitting down and doing the work. Entire applications can be produced this way now. The role changes whether people are ready to admit it or not. Debating the reality of it at this point mostly signals distance from the practice itself.
Imagine if every function you see starts checking for null params. You ask yourself: "when can this be null", right ? So it complicates your mental model about data flow to the point that you lose track of what's actually real in your system. And once you lose track of that it is impossible to reason about your system.
For me AI has replaced searching on stack overflow, google and the 50+ github tabs in my browser. And it's able to answer questions about why some things don't work in the context of my code. Massive win! I am moving much faster because I no longer have to switch context between a browser and my code.
My personal belief is that the people who can harness the power of AI to synthesize loads of information and keep polishing their engineering skills will be the ones who are going to land on their feet after this storm is over. At the end of the day AI is just another tool for us engineers to improve our productivity and if you think about what being an engineer looked like before AI even existed, more than 50% of our time was sifting through google search results, stack overflow, github issues and other people's code. That's now gone and in your IDE, in natural language with code snippets adapted to your specific needs.
Rinse and repeat with every model since.
There also ARE intrinsic limits to LLMs, I'm not sure why you deny them?
The very first example of deleting 400+ lines from a test file. Sure, I've seen those types of mistakes from time-to-time but the vast majority of my experience is so far different from that, I don’t even know what to make of it.
I’m sure some people have that experience some of the time, but… that’s just not been my experience at all.
Source: Use AI across 7+ unrelated codebases daily for both personal and professional work.
No, it’s not a panacea, but we’re at the stage that when I find myself arguing with AI about whether a file existed; I’m usually wrong.
What I found to be useful for complex tasks is to use it as a tool to explore that highly-dimensional space that lies behind the task being solved. It rarely can be described as giving a prompt and coming back for a result. For me it's usually about having winding conversations, writing lists of invariants and partial designs and feeding them back in a loop. Hallucinations and mistakes become a signal that shows whether my understanding of the problem does or does not fit.
Gemini in Antigravity today is pretty interesting, to the point where it's worth experimenting with vague prompts just to see what it comes up with.
Coding agents are not going to just change coding. They make a lot of detailed product management work obsolete and smaller team sizes will make it imperative to reread the agile manifesto and and discard scrum dogma.
Italic
*Escaped asterisks*
\*Double-Escaped asterisks\*
*Italic*
\*Escaped asterisks\*
\\*Double-Escaped asterisks\\*
- Being forced to use AI at work
- Being told you need to be 2x, 5x or 10x more efficient now
- Seeing your coworkers fired
- Seeing hiring freeze because business think no more devs are needed
- Seeing business people make a mock UI with AI and boasting how programming is easy
- Seeing those people ask you to deliver in impossible timelines
- Frontend people hearing from backend how their job is useless now
- Backend people hearing from ML Engineers how their job is useless now
- etc
When I dig a bit about this "anti-AI" trend I find it's one of those and not actually against the AI itself.
It's exhausting.
There are legitimate and nuanced conversations that we should be having! For example, one entirely legitimate critique is that LLMs do not tell LLM users that they are using libraries who are seeking sponsorship. This is something we could be proactive about fixing in a tangible way. Frankly, I'd be thrilled if agents could present a list of projects that we could consider clicking a button to toss a few bucks to. That would be awesome.
But instead, it's just the same tired arguments about how LLMs are only capable of regurgitating what's been scraped and that we're stupid and lazy for trusting them to do anything real.
I swear this is the reason people are against AI output (there are genuine reasons to be against AI without using it: environmental impact, hardware prices, social/copyright issues, CSAM (like X/Grok))
It feels like a lot of people hear the negatives, and try it and are cynical of the result. Things like 2 r's in Strawberry and the 6-10 fingers on one hand led to multiple misinterpretations of the actual AI benefit: "Oh, if AI can't even count the number of letters in a word, then all its answers are incorrect" is simply not true.
I feel like this is a common refrain that sets an impossible bar for detractors to clear. You can simply hand wave away any critique with “you’re just not using it right.”
If countless people are “using it wrong” then maybe there’s something wrong with the tool.
Not really. Every tool in existence has people that use it incorrectly. The fact that countless people find value in the tool means it probably is valuable.
It then shows hubris and a lack of imagination for someone in such a situation to think they can apply their negative results to extrapolate to the situation at large. Especially when so many are claiming to be seeing positive utility.
I had Claude read a 2k LOC module on my codebase for a bug that was annoying me for a while. It found it in seconds, a one line fix. I had forgotten to account for translation in one single line.
That's objectively valuable. People who argue it has no value or that it only helps normies who can't code or that sooner or later it will backfire are burying their heads in the sand.
Doesn't mean the hammers are bad, no matter how many people join the community.
You need to learn how to use the tools.
To preempt that on my end, and emphasize I'm not saying "it's useless" so much as "I think there's some truth to what the OP says", as I'm typing this I'm finishing up a 90% LLM coded tool to automate a regular process I have to do for work, and it's been a very successful experience.
From my perspective, a tool (LLMs) has more impact than how you yourself directly use it. We talk a lot about pits of success and pits of failure from a code and product architecture standpoint, and right now, as you acknowledge yourself in the last sentence, there's a big footgun waiting for any dev who turns their head off too hard. In my mind, _this is the hard part_ of engineering; keeping a codebase structured, guardrailed, well constrained, even with many contributors over a long period of time. I do think LLMs make this harder, since they make writing code "cheaper" but not necessarily "safer", which flies in the face of mantras such as "the best line of code is the one you don't need to write." (I do feel the article brushes against this where it nods to trust, growth, and ownership) This is not a hypothetical as well, but something I've already seen in practice in a professional context, and I don't think we've figured out silver bullets for yet.
While I could also gesture at some patterns I've seen where there's a level of semantic complexity these models simply can't handle at the moment, and no matter how well architected you make a codebase after N million lines you WILL be above that threshold, even that is less of a concern in my mind than the former pattern. (And again the article touches on this re: vibe coding having a ceiling, but I think if anything they weaken their argument by limiting it to vibe coding.)
To take a bit of a tangent with this comment though: I have come to agree with a post I saw a few months back, that at this point LLMs have become this cycle's tech-religious-war, and it's very hard to have evenhanded debate in that context, and as a sister post calls out, I also suspect this is where some of the distaste comes from as well.
Vibe coding and slop strawmen are still strawmen. The quality of the debate is obviously a problem
If only there were things called comments, clean-code, and what have you
Also, now that StackOverflow is no longer a thing, good luck meaningfully improving those code agents.
But what they asked the AI to do is something people have done a hundred times over, on existing platform tech, and will likely have little to no capability to solve problems that come up 5-10 years from now.
The reason AI is so good at coding right now is due to the 2nd Dot Com tech bubble that occurred between the simultaneous release of mobile platforms and the massive expansion of cloud technology. But now that the platforms that existed during that time will no longer exist, because it's no longer profitable to put something out there--the AI platforms will be less and less relevant.
Sure, sites like reddit will probably still exist where people will begin to ask more and more information that the AI can't help with, and subsequently the AI will train off of that information; but the rate of that information is going to go down dramatically.
In short, at some point the AI models will be worthless and I suspect that'll be whenever the next big "tech revolution" happens.