The part of Brooks that still holds for me as a solo developer is that the cost sits in coordination and understanding, not typing. AI makes producing code cheaper, but reviewing it, keeping the design coherent, and remembering why things were done still takes the same attention. I have found small, well-bounded tasks with tests work well, while open-ended changes across many files create review work that cancels the speedup. So the useful question is how much of a change I can verify quickly.
I think it takes MORE attention and thought. I feel like a rope being pulled tight and fraying in the middle. Working with these things is very addictive and interesting but it is cognitively exhausting long term, even if invigorating in the short term.
It does require that the human driver knows what they are doing. It captures the pre-AI developer mindset of developing a mental model along side writing the code. This has always been iterative, in discovering the model that results in high cohesion and low coupling.
That doesn't work if the driver cannot steer properly. It's the main issue with vibe-coded one-shotted solutions, that might look impressive until you peek underneath and it's all a mess.
I get a feeling that the best way we currently know how to use these tools is to not read their code at all. Models code and models review. Humans just ask questions and guide. Claude Code has no code editor on purpose.
As long as you are accountable, you need to understand the code. There’s just no way “But I told the LLM to make the code secure” is an acceptable explanation for a security breach.
You might be surprised to learn that yes, regularly pointing a tool at the codebase and seeing it found no issues is indeed enough to claim compliance with cybersecurity regulations.
While we may use deterministic tools like static code analysis, dependency scanners and similar today, people are already replacing/augmenting them with LLMs.
While every breach will trigger a root cause analysis process in a compliant environment, the solution is never going to be "all code in a deployment was manually reviewed by someone at the company" because this would extend to tooling (like compilers, scanners but also packaging and deployment tools) and all dependencies.
So I am pretty sure your example is already used in a number of places especially with "LLMs are better at security than humans" marketing being pushed around — this really makes it easy to sell that excuse to the gullible management who wants to believe this.
That depends on (A) verification being very low cost and (B) being able to infer the right answer based on wrong ones.
Those aren't always true. Sometimes it takes a while to see the fatal flaw in an approach, and sometimes having a bunch of failed attempts isn't enough to make the right way obvious, and thinking is still required.
What's even more surprising is that it can be given a grafana API key and reason about bugs from the hints of patterns in the logs even with pretty sketchy and inconsistent logging in places.
It can then raise, investigate and resolve those problems while also patching up and rationalising logging to improve future work.
The AI deniers have their heads in the sands at this point and are demonstrating they simply haven't tried a modern agent. ( Or perhaps are forced onto copilot? )
> The AI deniers have their heads in the sands at this point and are demonstrating they simply haven't tried a modern agent. ( Or perhaps are forced onto copilot? )
Could be either, but also the free version of ChatGPT seems rather braindead compared to the paid version, or to the free version of Claude.
Again, no, "what to build" is the humans input, but it's not just grunt work that modern AI tooling is good at... Architecture and what to avoid are also strengths of AI.
> Architecture and what to avoid are also strengths of AI.
Absolutely not at all. Every single day that I work with Claude, there is abundant evidence that AI sucks at these. Ask me for examples if you need them.
The first links shows a basic failure of reasoning, which would have gone unnoticed if I was just vibe-coding.
The second link shows weak architectural sense and an inability to see the big picture.
The last link in particular is telling: the agents worked with me (over weeks to months) to implement a db abstraction layer without ever bringing up the fact that as it stands, that would have never worked with any indexes at all. I did not constrain them to my choices, but they never stopped me with that design. It took my eagle-eyed attention to their offhand comments to notice this problem, which then required a lot of rework to fix.
Unfortunately, all three comments have apparently been flagged by somebody for some reason and I can't read them. This is my least favorite aspect of hacker news. It's exhausting, honestly.
Like a sibling comment replied, you can set "showdead" to "yes" on your profile and click update" so see flagged comments. Not sure why they were flagged.
I'm writing a unique MUD, and It was surprising to me when I posted some bug reports I'd made and it identified things I didn't complain about. "User had trouble with X" and then suggested mitigations for those problems. I ended up rejecting a lot of them because I knew I had different mitigations coming eventually, or it was working that way for a reason...
But it was pretty eye-opening to see how good it was at watching a user struggle and identifying possible fixes.
Using the "let run multiple agents run amok" approach you surely get a lot of "i don't like that part"-feature requests, yes.
In my opinion, a good engineer is not good because he understands every single obscure technical detail, but because he can build solutions that the people using his technology actually want. The list of things they don't want on the other hand is endless.
Personally at some points (like frontend design) I just ask the agent for 16 options with a convenient comparison system and just yeet designs until I’m happy, guiding it along in a very uncommitted way. “Quantity has its own quality”
> 2. A one-shotted POC in the span of an hour with $4 of tokens that is clearly wrong in 20 different ways?
Definitely this. I've had plenty of useless meetings with no helpful outcomes that lasted an hour with 6 or more people in them, and a few of them will have had more than $4 spent on snacks, let alone everyone's wages.
That said, poor communication will always get you no matter what: had one day spent going back and forth with a client, they kept saying they wanted a button "wider" each time around, I ended up making it full screen width and they still said "wider", asked them to draw a picture and they finally said "wider vertically". That may or may not have been faster with an LLM, depending on if the LLM ever thought to ask the client to draw what they meant, but fundamentally would have been exactly the same problem.
It goes beyond this, the job is to understand the underlying need. When a clients asks for a button to be bigger, what's in their head is they fear it's not visible enough. Many times the client was happy when I implemented something unrelated but that solved the issue, like changing the colours to increase the contrast between the background and the button, adding space around, etc. so that it pops out more.
> 2. A one-shotted POC in the span of an hour with $4 of tokens that is clearly wrong in 20 different ways?
A meeting between all the stakeholders to agree on requirements easily runs $1,000/hour. Taking your $4 functional PoC into that meeting is going to save so much time...
I used to spend an hour throwing a PoC together with PHP (or sometimes in MS Access) because hey you can throw shit together real fast, and because I used either a shitty language or a toy tool they were treated as throwaway.
Now LLMs make that easier to do with a larger scope.
Draw outlines, or use graphics, wire up clickable areas, and interaction flows, and you’ve got a presentable “live” demo that doesn’t run afoul of issues presenting demo sites to non-techies (placeholder text, ugly buttons, test domains, colours, etc).
> A meeting between all the stakeholders to agree on requirements easily runs $1,000/hour. Taking your $4 functional PoC into that meeting is going to save so much time..
It is though! Because previously your have the meeting last 4x as long to end up with a list of notes that you already knew.
Now you can generate the PoC, showcase it during the meeting and leave with actionable changes in project direction.
I had to re-read parent's comment over and over, because I simply was not sure if he was being ironic, facetious, or just had trouble expressing his point.. and, honestly, I am still not sure.
Not everyone in meeting will be the same person you are. Visuals help. Prototypes help. They certainly can save us from vague ideas and unclear language, because at least someone can point to the big button at the bottom and say:
"Can I have this in cornflower blue?"
It is useful, simply because it makes it more concrete.
Will it change? Is the pope catholic?
I was being entirely serious. Even at $400 of tokens it would probably still be worth it to take a functioning prototype into the discussion. At $4 it is a steal
Obviously "a blank sheet of paper" here is meaning thinking about the problem deeply. I'm surprised how dismissive people are to using brainpower whatsoever. I get that juxtaposing paper to LLMs might have triggered some people though.
As a counterpoint, bringing a one-shotted POC without thought may actually do have a shock and awe sort of effect, dazzling the stakeholders to go down the wrong path since the AI prototype was so easy.
Sure, the concept of a _Vomit Draft_ is not new, but the ability to come up with one quickly is.
It plays into the generalisation that people aren't good about saying what is the right way to do something, but much more open to saying what something is doing the wrong way.
In a previous job we used to do prototypes in languages like Perl because we couldn't ship them and knocking something non-production ready was easy. We were able to quickly come up with the PoC, iterate on it, and then plan and write the whole thing in $LANGUAGE_OF_CHOICE.
A one-shotted POC can also put you straight into the very wrong direction, with a very high degree of certainty.
I also prefer doing a POC, but it's not without risk, especially if your stakeholders are just a bit too eager. Another problem I've seen is that a POC can hide complexity, so a lot of weight is on you as the author to do the due diligence before and bring that along.
This is an often underrated problem. I used to work at a company where we would hold demos every other friday, with drinks and nibbles. We would put a lot of thoughts into what we were going to present, and were really careful about the messaging, because execs and sales were watching.
The last thing we wanted was for an "Isn't it neat?!" hacked-together demo to be mistaken for something shippable, if workable at all.
I was talking about it for a while with colleagues. AI besides other benefits, needs to be treated as great interface for discovery, you have your features baked in, AI uses it via your users and MCP, then you figure out what are actual flows of my users and then you build it
Not if you turn off your brain. Never actually stop to question the path you're going down, because the speed is making you blind. Which is what I feel I see more and more. Or how do you even know it's the wrong answer if you didn't think it through before starting?
One example: setting the agent ablaze on some task, keeping it going, and after a few days of working with the agent you have a feature. But it's not what you were supposed to make. The agent didn't have all the context and made something slightly off, and you never internalized the problem enough to even spot it. If you actually stopped to think a bit on how the feature would have to work to tie it in with everything else, like you would have done before, you would've spotted it.
Second example: something wasn't feasible to do before, due to not being worth the time investment. Like a feature that would need a bigger architectural change to implement. You and the agent take a crack at it, and rewrite huge parts of the code, and it seems to work. But now no one understands how, and it might have been the wrong way to solve it, you just went with it. Before, you would've sat down and discussed and thought about the architectural tradeoffs. Now one decision was just made with little thought.
> Or how do you even know it's the wrong answer if you didn't think it through before starting?
Real life is full of unknown unknowns, AI risks putting you on the wrong path without you even realizing it.
It doesn't help a bit that (almost? I'd say all) AI products are very confident while they're guiding you on that unknown unknown path, so of course that you don't realize soon enough the epistemological situation said AI product has driven you into.
Counter argument is you rarely hear of sunk-cost fallacy coming into play.
I used to do the same thing without AI, I'd spend a week working on a task and only realizing at the end it was wrong, but because I spend so much time on it, I was incentived more to keep going and ignoring sunk-cost.
Now I don't care, it only takes me a an hour and I have no problems throwing it away and trying something else.
> Now one decision was just made with little thought.
I've seen the same behavior using AI. They just keep double it down without seeking human feedback nor asking themselves if there's prior art tackling the same problem. At the end, they don't only get into sunk cost fallacy but also go into a shadow IT journey achieving generational tech debt in a few weeks.
If you didn't allow yourself for a feedback loop venue and constructive feedback from peers, AI will not solve that issue.
This feels even more true working with a team. I have a harder job convincing a team member who spent several days manually coding something that they’ve headed in the wrong direction compared to one who built it with AI. The person doesn’t have a personal attachment to the AI written code. Of course that also means they don’t understand every line like they would if they wrote it manually, but the lack of attachment is certainly a benefit.
> I have a harder job convincing a team member who spent several days manually coding something that they’ve headed in the wrong direction compared to one who built it with AI. The person doesn’t have a personal attachment to the AI written code. Of course that also means they don’t understand every line like they would if they wrote it manually, but the lack of attachment is certainly a benefit.
If the situation that you have to convince a programmer to stop working on something is something that happens more often than very rarely is in my opinion a strong sign of bad leadership. These are people who are really in love with what they are doing and are thus so attached to it, and you want to cast out this love for working?
So, the moral that I can only get from your post is:
- AI can be used as a mitigation for bad leadership.
- Programmers should care much less about the work that they do.
It’s much harder when team dynamics start coming into play. Maybe this is something where the norms will change, but for now, it’s still much harder to stop someone from shipping something they have built than to offer corrections to what they’re going to build.
And how do you think many of those managers come up with the ideas nowadays?:) There's no human in the loop anywhere at FAANGs. I see it first hand. LLM ideas, LLM docs, LLM coding, LLM launch announcements...
I’ll claim the ones in the end that will have that responsibility will be engineers. LLMs add the ability for engineered to build quickly enough that there’ll be enough of them to morph into product roles as well. I trust us/them much more than product owners who use models to code.
Much easier to engineers to move to product than product to move to engineers. Or at least the minimum amount needed to fill all product roles. I’m seeing we can do that now and it’s _much_ more efficient to not have to have back and forth communication as in the past with that communication being by far the slowest part of build processes.
> I’ll claim the ones in the end that will have that responsibility [to figure out if you're building the right thing] will be engineers.
One can have this stance. But in practice, programmers who have strong opinions on this topic that is not aligned to the management wishes will commonly become personae non gratae in the company, and are thus commonly on the brink of getting fired.
So, in the end, the incentives that exist in most companies are strongly biased towards the position that figuring out if you're building the right thing is the job of the managers and product owners. :-(
I can agree with this as well. But I'll do a follow along for who says management has the best and correctly decided plans for the company? What if in the future, engineers become product, and those then become management because who's to say that's more difficult?
For the way orgs are currently set up, yes, conflict between engineers and management can cause issues. I'd put somewhat of a bet that those types of org setups won't be the way in the future.
If the engineer is told to build a bridge that is virtually guaranteed to collapse, then it a reasonable person ( ideally, same person as engineer ) would note that particular risk.
It may not be engineer's responsibility to build the exact right thing, but it sure is their responsibility to build it right without having the bridge to collapse the moment someone stands on it.
Otherwise, the person building the bridge is not an engineer.
> Otherwise, the person building the bridge is not an engineer.
One is likely not an engineer if one does not notice the risk. But in practice, managers commonly desire docile subordinates, so the only thing an engineer can do in such a situation is to ensure that a paper trail gets generated that will be capable of breaking the manager's neck once the disaster has occurred. :-(
If you don't understand what you are building, chances are you'll take suboptimal decisions or even come up with a solution that completely misses the point.
To properly understand what you are going to build, it's not enough to read specifications from some manager as gospel. You need to ask questions, and challenge the requirements sometimes, to make them your own.
>
To properly understand what you are going to build, it's not enough to read specifications from some manager as gospel. You need to ask questions, and challenge the requirements sometimes, to make them your own.
Or, you don’t even realize it’s not really what you wanted. Once you have a nicely polished product, it’s hard to compare it to the fuzzy idea that you had in the first place.
I feel like going slower gives you time to let the details form the solution. You think “hm maybe that doesn’t make as much sense as I thought, maybe there’s a better way to frame the issue…”. If you don’t let a problem really soak in, you don’t get the “hammock driven development” that Rich Hickey talks about.
Of course some problems don’t need to soak in. A lot of problems just need code to be cranked out. I love slopping together a monster script that solves exactly one problem perfectly
It’s like discussing a fully rendered concept art. You will get lost in the picture. And there’s always the slight suggestion “it’s already looking so nice, why think harder”. Which is why sketches and roughly painted thumbnails are best for brainstorming. Easier to think out of the box that way.
Same with demo. Do a rough wireframe or something with default bootstrap style and it’s way easier to target the meat of the problem. Not so much on a full site
I dunno. You've heard of "build one to throw away", right?
Always easier to discuss what the client actually wants if you've got a demo on the table.
I'm doing short feedback loops with product owners more and more - sometimes within the same sprint. I'm not even getting bikeshedding back, but that might be because we have some fairly solid design guidelines.
> The thing is it gets you the wrong answer so fast it’s now the best way to figure out the right requirements.
I guess that’s just the old “Build One To Throw Away” in a modern light, where prototyping more freely is now actually feasible. I think if you apply the good engineering ideas of the past decades to AI, the results can be really good!
Except I’d also add a lot of testing to the prototype, to bring up as many edge cases as possible.
> The thing is it gets you the wrong answer so fast
If oftentimes happens that you don't know that that's the wrong answer, or you don't realize it right away, for that matter, and hence that's I think that AI is a new (and very big and important) source of information entropy.
Just a recent personal example, yesterday I was curious about the historical figure that was present in an online photo taken in 1930s Romania. Google's Gemini was very quick to point out that that was (military dictator) Ion Antonescu [1], which it was obvious that he wasn't. I wrote down that that wasn't in fact Ion Antonescu, at which point Gemini was very quickly and very surely providing me the info that that guy indeed wasn't Ion Antonescu, but (former Foreign Affairs) minister Manoilescu. At this point I wasn't so sure myself, I don't have a visual image of Manoilescu in my head, so (ironically) I had to AI-dumb google for Manoilescu's available online images and it seemed like Gemini had been wrong a second time. I didn't bother asking it for a third time.
Just to put things into perspective, here in Romania it is illegal to mention Ion Antonescu's name (and propaganda image) in a positive matter, as in one risks prison for doing that, now, just imagine that the political powers that be here decide to use an AI-tool like Gemini in order to identify potential law-breakers in that respect. People would risk going to jail just because Google's Gemini was completely wrong in identifying a WW2 military dictator. Absolutely atrocious product(s).
The thing is, AI is generating sooo fast so many outputs, its hard to review and evaluate all of them:
Very often I encounter in design/architecture questions a situation where the model suggests 2 - 3 alternatives approaches,then asking a little bit and there you are with 30+ pages of content etc.
I agree with both you and matsemann. Getting the requirements right by conducting a cheap POC is a good approach. Matsemann is highlighting the failure that creeps in when the POC is shipped as if it meets the requirements.
Someone has to sign off on the requirements and also what is released. So, two approval steps by a person. The first approval is for a plan and the acceptance criteria. The second approval is a check against the plan. The agents can do all the work of taking the plan, breaking it down into tasks, building, and then verifying it. A good orchestrator will include people in the workflow at the points where their decisions matter and maintain a record of it.
It is an anti-pattern that predates AI. Tester-driven development maybe.
The idea is that instead doing things correctly, you do "something", then, if it fails (it will), you change some random stuff until it passes. It typically results in code no one understands and that fails each time something unexpected happens.
AI makes the process much faster, but just as wrong.
Yeah, this is a succinct way to describe a very important dynamic in software engineering that is usually unfamiliar to most inexperienced developers but a central facet of most experienced developers.
Software engineering is almost always a process of iteration. The better you get at iterating, the better you are at engineering. This can take on a lot of forms (my old manager would constantly repeat the mantra "don't let perfect be the enemy of good," which is arguably a recognition of the same dynamic), but at the end of the day, if you expect to "one-shot" a complex implementation and you build a process around that assumption, then you will fail. Almost ironically, the best way to avoid that issue is to assume you will fail (potentially multiple times) and to build a process around that assumption.
Interestingly, it seems like a lot of experienced engineers I work with have just forgotten this concept in the world of AI. They expect AI to just get things perfect in one-shot and are dismayed when it fails. There's a lot of discussion around how we handle code reviews because some developers are just letting AI one-shot a solution then sending it to review. It boggles my mind that competent engineers aren't allowing their AI to fail, so to speak, and are instead wasting cycles trying to figure out how to get AI to produce the perfect solution the first time.
To me, it's obvious that there's just a fundamental gap in alignment that prevents a consistent "perfect one-shot" to probably ever be possible (at least, within the current paradigm of development). I can spend an hour writing a spec and try to include every little detail of context I can think of, but in what world could we expect anyone, let alone an AI, to be able to envision the solution the same way we can? We just lose way too much information through communication for that to ever be possible. Yet I see people very dismissive of the capabilities of AI because it's not literally magic.
> nine agents still can’t deliver a baby in one month.
Very weird way to say this. Like it holds true for biological beings because pregnancy by default has a fixed timeline. But how does this apply to AI? Also what even is an "agent"? Are they distinct worker units on a program or the same worker unit split into multiple instances?
Why are we assuming agent = man when its a computer program?
It's a weird way to express that concept, in fact I don't think it ever appeared like this in the book (it has been a while).
It would be something like "nine women cannot deliver a baby in one month", which can be more easily transposed to "adding resources to a SW project does not make it faster".
The agrument is that adding people increase coordination and communication overhead, which gets bigger as the team grows. Moreover, some tasks cannot be parallelized that easily and create dependencies.
I have only worked with agents for personal projects, but I cannot say that explicity dividing the work between multiple agents and asking them to coordinate is inherently faster than having a single agent work on it (of course the single agent will spawn subagents in rencent harnesses.)
I always thought it meant 9 women would take 9 months to create 9 babies because a baby takes 9 months to grow with the bottleneck being biology. And yes what you said applies to people but I don't get the whole "throw 9 agents into it" when it is possible to just see it as 1 agent doing 9 things? With people, yes everyone has a distinct way of doing things etc but all agents can be homogenious fully and completely sync up without any overload theoritically no?
To whit, 13,000 women can make a baby in one month. If you hire that many women, by the statistics, that's how many it takes for one of them to be 8 months pregnant.
Agents still have to communicate using tokens (for now). There are more advanced mechanisms being proposed, but for now, and until proven otherwise, the same scaling problems apply to agents communicating as humans, it just happens a bit faster, and with no HR issues because someone slept with the wrong person. Mesh networking, and thus agents too, are beholden to Gupta-Kumar scaling law.
Right, the key being a fast feedback loop. I have full confidence that the same LLMs that can do these crazy math proofs could also do crazy biology, even cancer research, but they simply don’t have the cycle time low enough because they require actual physical experiments, often on living things, often over long time horizons. Even if you perfectly automated a lab, made thousands of them, you’d still be unable to match the speed of iteration that one gets with pure math and computing problems.
"You're absolutely right, that drug was lethal and that's on me. I'll add a note to check human toxicity for all compounds in the future. To verify the safe dosage, I'll administer a high dose and then check smaller doses until the patient survives — not guesswork, grounded, load-bearing experiments."
What gives you full confidence? The human body/biology has basically nothing to do with math or writing code. This doesnt translate in any way. There isnt a single biotech expert on earth that agrees with you.
Has nothing to do with knowing the answer, and everything to do with infinite persistence. I believe any current-generation LLM can, given an environment where it can experiment rapidly, do anything.
There is a difference between building a product and building a product that sells. So, which one are we talking about here? In my opinion MMM talks about the latter
If you can vibecode a product that sells, I can vibecode a free open source one just as easily, probably even easier since I can just ask the AI to copy the existing one. Software is trending towards being free and open source.
Unclear if this is that. If someone makes their own FOSS Photoshop, that's not piracy, it's GIMP. Training a AI on things that one otherwise has lawful access to (and not, e.g., pirating the material which Meta is being sued over and Anthropic settled over) has been ruled lawful.
Is asking an LLM to "make an open-source Photoshop clone" more like GIMP, or more like opening someone else's photo in Photoshop and clicking the menu option for the filter to make it look like a stained glass window and claiming the stained glass window version is your own IP that doesn't need permission from the original creator?
We may need new IP laws. Or, to the horror of many software developers 20 years ago, software patents.
And "new IP laws" doesn't mean "stronger": the justification for giving creators a monopoly on their works (the right to copy, or copyright) is to encourage more. If we've got a machine to automate this, there's suddenly no reason to encourage more.
That’s only really done for video games where you want an identical clone. The vibecoded photoshops aren’t decomps. They are just asking LLMs to build photoshop from scratch in rust.
Half of the value in open source was that it was used by lots of people and all of the nasty edge cases and bugs have been ironed out.
If LLMs were performing according to hype then yes, virtually all paid software would be gone by now and there would be a high quality FOSS equivalent of all of it.
I mean, you can also use agents to listen to users and handle issues automatically.
But I guess you mean the discovery part? Yea, agents are not going to totally replace that anytime soon. Though, Claude voice mode is pretty good these days, so I’m sure it’s on their mind.
Not sure what you mean by “stay the course.” I think the winners will be those with the most effective marketing strategies. Surely that will require automation.
Case in point: I am building a digital files archive organizer platform.
This is simply not the kind of product you do a quick prototype of, get it to market quickly, and iterate on based on any failures or issues.
There are an almost infinite number of ways to get the product wrong, in a technical, architectural, and business/market sense. It requires a lot of deep thinking and internal prototyping to even get at what would actually be useful and address the walled-content-silos problem tech vendors love to foist on us. it requires careful implementation to not mess up user data. It requires a ton of architectural and UX design to get a performant product that is easy to understand. I have mulled over architectural decisions for months and thrown them out totally after mounting evidence they were not right, without a single user yet (except myself).
Just quickly coding up the first ideas that come to mind in this space is almost guaranteed to be wasted effort, because I could try a 100 approaches in the market and all could be bad. Do not let the users do your work for you. Make sure you actually understand what you are building and why it is important. Then let the user's experiences tell you how to tweak it to be better.
And yet here I am, playing a full-fledged first-person shooter written from scratch by an LLM as a proof of concept. It has enemies I sketched on paper, everything else is 100% procedurally generated in code. In what way does it not work? It's not very good, it's not optimized for maintenance or extension (that would take a complete rework which is also cheaper with it), but it does work and is not broken because the agent tested the most obvious scenarios. It took it a few hours.
As soon as your spec has a clearly defined reachable goal and non-contradictory constraints, and doesn't require taste or judgement, current agents are pretty good at reaching it, because it's all they're optimized for. Writing that spec in a non-contradictory manner is not trivial, though.
Also, FPS is a done to death concept that has plenty of repos for LLMs to take snippets from. A better test would be trying to vibe-coding an original game (e.g. something like Miegacure) and see how well LLM does, even when you give it well-defined goal and constraints. My guess is that would fail miserably.
I am "creating", at least designing, games with my kids. It's not that I couldn't possibly do it before, but I certainly would never have the time to.
I explored frameworks and engines, and landed on Bevy, I asked for a rudimentary arena, isometric perspective, 4 players, xinput support, portable desktop and wasm targets.
After that part done we've made the characters into chickens using no assets, only primitive mesh, having a trail of feathers, flapping wings on jump/double jump as well as gliding, picking animation, bite/grab, zenith shadows on characters (despite being unrealistic, in favor of platforming), physics objects, a few game modes like soccer, bowling, etc.
Each of these were iterative additions, so it's like previous development, only the coding/debugging time is largely removed. Is there bloat? Absolutely. But it still works, and while it's not a "real" game yet, I do believe it's original, it's certainly evolving exactly to our design, however confused it is.
How do you do that? If I let just 2 agents work in parallel they keep stepping on each other, waiting for each other and the perf tests become super noisy (because they run them in parallel)
Stepping on each other how? I find each agent needs to spin up N worktrees for each task, and I use hooks to prevent them working on the same substrait.
You’re not running tests in CI? The agent should only run the minimum tests necessary and then idle and wait for feedback from a CI run.
Most people have no view on that, or dismiss it either as a cultish/outlandish topic or something so far into the future it's not worth discussing. The author most likely falls into these categories otherwise his point would be mute.
If you use AI then that is not going to be your bottleneck. So if a project is late one of the options on the table is still to add manpower to "help".
So nothing has changed fundamentally, only perhaps superficially.
Here's a question, to people who delegate all their coding to AI agents now: What are you doing to keep your mind exercised in all this suddenly new free time you have? Personally I find talking with agents extremely tedious and unrewarding; I would rather just write the code, even if it's simply because it's more interesting than playing Sudoku or whatever the fuck you do when you have nothing to do with your brain.
And talking to AI agents is not the same as using your brain. It's frustrating, it seems to be intelligent, you think you're using reason with them, but it rapidly degrades your ability to reason. It encourages you to accept answers without checking them thoroughly. So much for the skills of accuracy and integrity you built up. It's a sugar rush.
OK, so I'm still very low on the spectrum of "I just command it and sit back", but I think the final toolbox will at least include adversarial questioning of the bot. For example, "Why does that code do A, wouldn't B be better?" or "Would this code break if a C event occurred?"
Sometimes it reveals a bug or a questionable implicit assumption, other times it leads me to see another part of the code, and sometimes the thing just lies at me... But it does help you keep some critical-thinking practice.
Another task might be to find and refactor/rename parts of the code that are just... not easy for humans to grasp. Some readers are thinking: "No, the next edit will be by LLM anyway, leave it so the bot understands", however I think that's short-sighted: Either these things are going to become good-enough that they should cater to human comprehension, or else they've reached a plateau and we'll want something that can resist the chaos-rot.
I think I'm where you are. Reading all the code it spits out, and then a lot of adversarial questioning. (This is what I mean about "talking to the AI", which was brushed off by another commenter). Naming conventions, decisions about classes or inline code, all these things I would not do.
So then I spend all this time getting a mental map of the code it wrote, and making my own decisions about that code. Then I ask it to rearrange it in consistent ways. Then I find bugs or oversights. Etc.
What I'm trying to say is that while all of that process with the LLM is modestly intellectually stimulating, it's not as stimulating as just writing the code myself, and it's also incredibly frustrating to have to go through the agent. And yes, I could just rewrite the functions my own way, but once I'm in a project that's LLM-driven, the temptation is to make the LLM fix it instead of fixing it myself. Whereas in a project that I'm writing from scratch, I wouldn't make those mistakes or have to think about those stylistic things, I would have already seen the bugs that it missed before I wrote the code, and I would be using my mind to its fullest potential instead of delegating my thinking to a stupid robot.
That doesn't work if the driver cannot steer properly. It's the main issue with vibe-coded one-shotted solutions, that might look impressive until you peek underneath and it's all a mess.
Is this sustainable? I've got no idea.
While we may use deterministic tools like static code analysis, dependency scanners and similar today, people are already replacing/augmenting them with LLMs.
While every breach will trigger a root cause analysis process in a compliant environment, the solution is never going to be "all code in a deployment was manually reviewed by someone at the company" because this would extend to tooling (like compilers, scanners but also packaging and deployment tools) and all dependencies.
So I am pretty sure your example is already used in a number of places especially with "LLMs are better at security than humans" marketing being pushed around — this really makes it easy to sell that excuse to the gullible management who wants to believe this.
The thing is it gets you the wrong answer so fast it’s now the best way to figure out the right requirements.
Those aren't always true. Sometimes it takes a while to see the fatal flaw in an approach, and sometimes having a bunch of failed attempts isn't enough to make the right way obvious, and thinking is still required.
1. A blank sheet of paper
2. A one-shotted POC in the span of an hour with $4 of tokens that is clearly wrong in 20 different ways?
Not quite as shocking as the original InstructGPT video, but surprising.
It can then raise, investigate and resolve those problems while also patching up and rationalising logging to improve future work.
The AI deniers have their heads in the sands at this point and are demonstrating they simply haven't tried a modern agent. ( Or perhaps are forced onto copilot? )
Could be either, but also the free version of ChatGPT seems rather braindead compared to the paid version, or to the free version of Claude.
What some of us are saying is that AI is poor at figuring out what to build, how best to architecture it, and what to avoid.
Absolutely not at all. Every single day that I work with Claude, there is abundant evidence that AI sucks at these. Ask me for examples if you need them.
https://news.ycombinator.com/item?id=50220976
https://news.ycombinator.com/item?id=50165791
https://news.ycombinator.com/item?id=50159827
The first links shows a basic failure of reasoning, which would have gone unnoticed if I was just vibe-coding.
The second link shows weak architectural sense and an inability to see the big picture.
The last link in particular is telling: the agents worked with me (over weeks to months) to implement a db abstraction layer without ever bringing up the fact that as it stands, that would have never worked with any indexes at all. I did not constrain them to my choices, but they never stopped me with that design. It took my eagle-eyed attention to their offhand comments to notice this problem, which then required a lot of rework to fix.
But it was pretty eye-opening to see how good it was at watching a user struggle and identifying possible fixes.
In my opinion, a good engineer is not good because he understands every single obscure technical detail, but because he can build solutions that the people using his technology actually want. The list of things they don't want on the other hand is endless.
Definitely this. I've had plenty of useless meetings with no helpful outcomes that lasted an hour with 6 or more people in them, and a few of them will have had more than $4 spent on snacks, let alone everyone's wages.
That said, poor communication will always get you no matter what: had one day spent going back and forth with a client, they kept saying they wanted a button "wider" each time around, I ended up making it full screen width and they still said "wider", asked them to draw a picture and they finally said "wider vertically". That may or may not have been faster with an LLM, depending on if the LLM ever thought to ask the client to draw what they meant, but fundamentally would have been exactly the same problem.
A meeting between all the stakeholders to agree on requirements easily runs $1,000/hour. Taking your $4 functional PoC into that meeting is going to save so much time...
Now LLMs make that easier to do with a larger scope.
Draw outlines, or use graphics, wire up clickable areas, and interaction flows, and you’ve got a presentable “live” demo that doesn’t run afoul of issues presenting demo sites to non-techies (placeholder text, ugly buttons, test domains, colours, etc).
It is though! Because previously your have the meeting last 4x as long to end up with a list of notes that you already knew.
Now you can generate the PoC, showcase it during the meeting and leave with actionable changes in project direction.
Not everyone in meeting will be the same person you are. Visuals help. Prototypes help. They certainly can save us from vague ideas and unclear language, because at least someone can point to the big button at the bottom and say:
"Can I have this in cornflower blue?"
It is useful, simply because it makes it more concrete. Will it change? Is the pope catholic?
As a counterpoint, bringing a one-shotted POC without thought may actually do have a shock and awe sort of effect, dazzling the stakeholders to go down the wrong path since the AI prototype was so easy.
Scrooge McDuck lived by the credo: "Work smarter; not harder."
But for many people, smarter is harder.
It plays into the generalisation that people aren't good about saying what is the right way to do something, but much more open to saying what something is doing the wrong way.
In a previous job we used to do prototypes in languages like Perl because we couldn't ship them and knocking something non-production ready was easy. We were able to quickly come up with the PoC, iterate on it, and then plan and write the whole thing in $LANGUAGE_OF_CHOICE.
I also prefer doing a POC, but it's not without risk, especially if your stakeholders are just a bit too eager. Another problem I've seen is that a POC can hide complexity, so a lot of weight is on you as the author to do the due diligence before and bring that along.
The last thing we wanted was for an "Isn't it neat?!" hacked-together demo to be mistaken for something shippable, if workable at all.
As long as someone doesn't go - "Why do we need requirements, you've built the system already!"....
One example: setting the agent ablaze on some task, keeping it going, and after a few days of working with the agent you have a feature. But it's not what you were supposed to make. The agent didn't have all the context and made something slightly off, and you never internalized the problem enough to even spot it. If you actually stopped to think a bit on how the feature would have to work to tie it in with everything else, like you would have done before, you would've spotted it.
Second example: something wasn't feasible to do before, due to not being worth the time investment. Like a feature that would need a bigger architectural change to implement. You and the agent take a crack at it, and rewrite huge parts of the code, and it seems to work. But now no one understands how, and it might have been the wrong way to solve it, you just went with it. Before, you would've sat down and discussed and thought about the architectural tradeoffs. Now one decision was just made with little thought.
Real life is full of unknown unknowns, AI risks putting you on the wrong path without you even realizing it.
It doesn't help a bit that (almost? I'd say all) AI products are very confident while they're guiding you on that unknown unknown path, so of course that you don't realize soon enough the epistemological situation said AI product has driven you into.
I used to do the same thing without AI, I'd spend a week working on a task and only realizing at the end it was wrong, but because I spend so much time on it, I was incentived more to keep going and ignoring sunk-cost.
Now I don't care, it only takes me a an hour and I have no problems throwing it away and trying something else.
I've seen the same behavior using AI. They just keep double it down without seeking human feedback nor asking themselves if there's prior art tackling the same problem. At the end, they don't only get into sunk cost fallacy but also go into a shadow IT journey achieving generational tech debt in a few weeks.
If you didn't allow yourself for a feedback loop venue and constructive feedback from peers, AI will not solve that issue.
If the situation that you have to convince a programmer to stop working on something is something that happens more often than very rarely is in my opinion a strong sign of bad leadership. These are people who are really in love with what they are doing and are thus so attached to it, and you want to cast out this love for working?
So, the moral that I can only get from your post is:
- AI can be used as a mitigation for bad leadership.
- Programmers should care much less about the work that they do.
I see people ship a half baked feature then spend the next weeks ripping and replacing huge pieces causing all sorts of issues
Much easier to engineers to move to product than product to move to engineers. Or at least the minimum amount needed to fill all product roles. I’m seeing we can do that now and it’s _much_ more efficient to not have to have back and forth communication as in the past with that communication being by far the slowest part of build processes.
One can have this stance. But in practice, programmers who have strong opinions on this topic that is not aligned to the management wishes will commonly become personae non gratae in the company, and are thus commonly on the brink of getting fired.
So, in the end, the incentives that exist in most companies are strongly biased towards the position that figuring out if you're building the right thing is the job of the managers and product owners. :-(
For the way orgs are currently set up, yes, conflict between engineers and management can cause issues. I'd put somewhat of a bet that those types of org setups won't be the way in the future.
If the engineer is told to build a bridge that is virtually guaranteed to collapse, then it a reasonable person ( ideally, same person as engineer ) would note that particular risk.
It may not be engineer's responsibility to build the exact right thing, but it sure is their responsibility to build it right without having the bridge to collapse the moment someone stands on it.
Otherwise, the person building the bridge is not an engineer.
One is likely not an engineer if one does not notice the risk. But in practice, managers commonly desire docile subordinates, so the only thing an engineer can do in such a situation is to ensure that a paper trail gets generated that will be capable of breaking the manager's neck once the disaster has occurred. :-(
If you don't understand what you are building, chances are you'll take suboptimal decisions or even come up with a solution that completely misses the point.
To properly understand what you are going to build, it's not enough to read specifications from some manager as gospel. You need to ask questions, and challenge the requirements sometimes, to make them your own.
Many managers don't like being challenged. :-(
I feel like going slower gives you time to let the details form the solution. You think “hm maybe that doesn’t make as much sense as I thought, maybe there’s a better way to frame the issue…”. If you don’t let a problem really soak in, you don’t get the “hammock driven development” that Rich Hickey talks about.
Of course some problems don’t need to soak in. A lot of problems just need code to be cranked out. I love slopping together a monster script that solves exactly one problem perfectly
Same with demo. Do a rough wireframe or something with default bootstrap style and it’s way easier to target the meat of the problem. Not so much on a full site
Always easier to discuss what the client actually wants if you've got a demo on the table.
I'm doing short feedback loops with product owners more and more - sometimes within the same sprint. I'm not even getting bikeshedding back, but that might be because we have some fairly solid design guidelines.
I guess that’s just the old “Build One To Throw Away” in a modern light, where prototyping more freely is now actually feasible. I think if you apply the good engineering ideas of the past decades to AI, the results can be really good!
Except I’d also add a lot of testing to the prototype, to bring up as many edge cases as possible.
If oftentimes happens that you don't know that that's the wrong answer, or you don't realize it right away, for that matter, and hence that's I think that AI is a new (and very big and important) source of information entropy.
Just a recent personal example, yesterday I was curious about the historical figure that was present in an online photo taken in 1930s Romania. Google's Gemini was very quick to point out that that was (military dictator) Ion Antonescu [1], which it was obvious that he wasn't. I wrote down that that wasn't in fact Ion Antonescu, at which point Gemini was very quickly and very surely providing me the info that that guy indeed wasn't Ion Antonescu, but (former Foreign Affairs) minister Manoilescu. At this point I wasn't so sure myself, I don't have a visual image of Manoilescu in my head, so (ironically) I had to AI-dumb google for Manoilescu's available online images and it seemed like Gemini had been wrong a second time. I didn't bother asking it for a third time.
Just to put things into perspective, here in Romania it is illegal to mention Ion Antonescu's name (and propaganda image) in a positive matter, as in one risks prison for doing that, now, just imagine that the political powers that be here decide to use an AI-tool like Gemini in order to identify potential law-breakers in that respect. People would risk going to jail just because Google's Gemini was completely wrong in identifying a WW2 military dictator. Absolutely atrocious product(s).
[1] https://en.wikipedia.org/wiki/Ion_Antonescu
Someone has to sign off on the requirements and also what is released. So, two approval steps by a person. The first approval is for a plan and the acceptance criteria. The second approval is a check against the plan. The agents can do all the work of taking the plan, breaking it down into tasks, building, and then verifying it. A good orchestrator will include people in the workflow at the points where their decisions matter and maintain a record of it.
The idea is that instead doing things correctly, you do "something", then, if it fails (it will), you change some random stuff until it passes. It typically results in code no one understands and that fails each time something unexpected happens.
AI makes the process much faster, but just as wrong.
Software engineering is almost always a process of iteration. The better you get at iterating, the better you are at engineering. This can take on a lot of forms (my old manager would constantly repeat the mantra "don't let perfect be the enemy of good," which is arguably a recognition of the same dynamic), but at the end of the day, if you expect to "one-shot" a complex implementation and you build a process around that assumption, then you will fail. Almost ironically, the best way to avoid that issue is to assume you will fail (potentially multiple times) and to build a process around that assumption.
Interestingly, it seems like a lot of experienced engineers I work with have just forgotten this concept in the world of AI. They expect AI to just get things perfect in one-shot and are dismayed when it fails. There's a lot of discussion around how we handle code reviews because some developers are just letting AI one-shot a solution then sending it to review. It boggles my mind that competent engineers aren't allowing their AI to fail, so to speak, and are instead wasting cycles trying to figure out how to get AI to produce the perfect solution the first time.
To me, it's obvious that there's just a fundamental gap in alignment that prevents a consistent "perfect one-shot" to probably ever be possible (at least, within the current paradigm of development). I can spend an hour writing a spec and try to include every little detail of context I can think of, but in what world could we expect anyone, let alone an AI, to be able to envision the solution the same way we can? We just lose way too much information through communication for that to ever be possible. Yet I see people very dismissive of the capabilities of AI because it's not literally magic.
Very weird way to say this. Like it holds true for biological beings because pregnancy by default has a fixed timeline. But how does this apply to AI? Also what even is an "agent"? Are they distinct worker units on a program or the same worker unit split into multiple instances?
Why are we assuming agent = man when its a computer program?
It would be something like "nine women cannot deliver a baby in one month", which can be more easily transposed to "adding resources to a SW project does not make it faster".
The agrument is that adding people increase coordination and communication overhead, which gets bigger as the team grows. Moreover, some tasks cannot be parallelized that easily and create dependencies.
I have only worked with agents for personal projects, but I cannot say that explicity dividing the work between multiple agents and asking them to coordinate is inherently faster than having a single agent work on it (of course the single agent will spawn subagents in rencent harnesses.)
Agents still have to communicate using tokens (for now). There are more advanced mechanisms being proposed, but for now, and until proven otherwise, the same scaling problems apply to agents communicating as humans, it just happens a bit faster, and with no HR issues because someone slept with the wrong person. Mesh networking, and thus agents too, are beholden to Gupta-Kumar scaling law.
Anything grindy. Reverse engineering. Performance optimizations.
That's where swarms shine I think. But that's a much much much smaller problem space than what these agents are being sold for.
"You're absolutely right, that drug was lethal and that's on me. I'll add a note to check human toxicity for all compounds in the future. To verify the safe dosage, I'll administer a high dose and then check smaller doses until the patient survives — not guesswork, grounded, load-bearing experiments."
I think its practical to solve cancer on a war footing where we would expect people to die.
And Farber's methods were pretty fast for his time - lol Farber would be a perfect name for this AI that wants to solve cancer knowing what's at risk.
And if I break up an application then 9 coders with Claude Code can build that application in an unprecedentedly short period.
Is asking an LLM to "make an open-source Photoshop clone" more like GIMP, or more like opening someone else's photo in Photoshop and clicking the menu option for the filter to make it look like a stained glass window and claiming the stained glass window version is your own IP that doesn't need permission from the original creator?
We may need new IP laws. Or, to the horror of many software developers 20 years ago, software patents.
And "new IP laws" doesn't mean "stronger": the justification for giving creators a monopoly on their works (the right to copy, or copyright) is to encourage more. If we've got a machine to automate this, there's suddenly no reason to encourage more.
If LLMs were performing according to hype then yes, virtually all paid software would be gone by now and there would be a high quality FOSS equivalent of all of it.
Maintaining vibe coded software is going to become hours spent with Claude not your users.
That's going to be the difference. It takes nothing to rebuild the software, but listening to users, iterating, handling issues. That's boring.
The ones that win will be the ones that stay the course, not the ones that were built the quickest.
But I guess you mean the discovery part? Yea, agents are not going to totally replace that anytime soon. Though, Claude voice mode is pretty good these days, so I’m sure it’s on their mind.
Not sure what you mean by “stay the course.” I think the winners will be those with the most effective marketing strategies. Surely that will require automation.
Get it out quickly, market it, iterate it. That hasn't changed. Just the speed of iteration before you go from product to product that sells.
Once you know what sells, then again, it takes far less time to rebuild it well if you need to.
Case in point: I am building a digital files archive organizer platform.
This is simply not the kind of product you do a quick prototype of, get it to market quickly, and iterate on based on any failures or issues.
There are an almost infinite number of ways to get the product wrong, in a technical, architectural, and business/market sense. It requires a lot of deep thinking and internal prototyping to even get at what would actually be useful and address the walled-content-silos problem tech vendors love to foist on us. it requires careful implementation to not mess up user data. It requires a ton of architectural and UX design to get a performant product that is easy to understand. I have mulled over architectural decisions for months and thrown them out totally after mounting evidence they were not right, without a single user yet (except myself).
Just quickly coding up the first ideas that come to mind in this space is almost guaranteed to be wasted effort, because I could try a 100 approaches in the market and all could be bad. Do not let the users do your work for you. Make sure you actually understand what you are building and why it is important. Then let the user's experiences tell you how to tweak it to be better.
Yes, with the caveat that the application doesn't actually work.
P.S. If you wrote non-working applications even before the age of AI, then this is an upgrade, I guess.
As soon as your spec has a clearly defined reachable goal and non-contradictory constraints, and doesn't require taste or judgement, current agents are pretty good at reaching it, because it's all they're optimized for. Writing that spec in a non-contradictory manner is not trivial, though.
I explored frameworks and engines, and landed on Bevy, I asked for a rudimentary arena, isometric perspective, 4 players, xinput support, portable desktop and wasm targets.
After that part done we've made the characters into chickens using no assets, only primitive mesh, having a trail of feathers, flapping wings on jump/double jump as well as gliding, picking animation, bite/grab, zenith shadows on characters (despite being unrealistic, in favor of platforming), physics objects, a few game modes like soccer, bowling, etc.
Each of these were iterative additions, so it's like previous development, only the coding/debugging time is largely removed. Is there bloat? Absolutely. But it still works, and while it's not a "real" game yet, I do believe it's original, it's certainly evolving exactly to our design, however confused it is.
It doesn't fulfill its primary purpose of being a (fun) game.
How do you do that? If I let just 2 agents work in parallel they keep stepping on each other, waiting for each other and the perf tests become super noisy (because they run them in parallel)
Turtles all the way down.
You’re not running tests in CI? The agent should only run the minimum tests necessary and then idle and wait for feedback from a CI run.
So nothing has changed fundamentally, only perhaps superficially.
And talking to AI agents is not the same as using your brain. It's frustrating, it seems to be intelligent, you think you're using reason with them, but it rapidly degrades your ability to reason. It encourages you to accept answers without checking them thoroughly. So much for the skills of accuracy and integrity you built up. It's a sugar rush.
OK, so I'm still very low on the spectrum of "I just command it and sit back", but I think the final toolbox will at least include adversarial questioning of the bot. For example, "Why does that code do A, wouldn't B be better?" or "Would this code break if a C event occurred?"
Sometimes it reveals a bug or a questionable implicit assumption, other times it leads me to see another part of the code, and sometimes the thing just lies at me... But it does help you keep some critical-thinking practice.
Another task might be to find and refactor/rename parts of the code that are just... not easy for humans to grasp. Some readers are thinking: "No, the next edit will be by LLM anyway, leave it so the bot understands", however I think that's short-sighted: Either these things are going to become good-enough that they should cater to human comprehension, or else they've reached a plateau and we'll want something that can resist the chaos-rot.
So then I spend all this time getting a mental map of the code it wrote, and making my own decisions about that code. Then I ask it to rearrange it in consistent ways. Then I find bugs or oversights. Etc.
What I'm trying to say is that while all of that process with the LLM is modestly intellectually stimulating, it's not as stimulating as just writing the code myself, and it's also incredibly frustrating to have to go through the agent. And yes, I could just rewrite the functions my own way, but once I'm in a project that's LLM-driven, the temptation is to make the LLM fix it instead of fixing it myself. Whereas in a project that I'm writing from scratch, I wouldn't make those mistakes or have to think about those stylistic things, I would have already seen the bugs that it missed before I wrote the code, and I would be using my mind to its fullest potential instead of delegating my thinking to a stupid robot.
Who got more time thanks to AI ? I think a lot of us are working more instead