Yes, it is insane. You couldn't torture this confession out of me. But that's the drug they're selling you, isn't it? You don't even write code, but you're getting a self-inflated sense of worth. It must be addicting! Of course, whether or not the programs you prompt are actually good surely has no relation to whether you feel they're good, since you're not the one writing them, and apparently were not capable of writing them before so are not qualified to review them very much.

> having tools that can finally match the speed my ideas come to me

Anyone can be an "ideas guy". We laughed at those people, because having ideas is not the hard part. The hard part was in all of the hundreds and thousands of little details that go into building the ideas into something actually worthwhile, and that hasn't changed. LLMs can build an idea into a prototype in a weekend. I am still waiting to see LLMs build an idea into something other people use at scale, once, ever, other than LLM wrappers. Either every person who is all-in on vibes only has ideas that consist of making .md files and publishing them as a "meta agent framework", or LLMs are not actually doing a great job of translating ideas into tangibly useful software.

I've been using AI tools more but this idea of never actually writing any code seems way too black and white to be serious.

I disagree with this. I've worked with amazing "ideas guys" who just cranked out customer insights and interesting concepts, and I've worked with lousy ones, who just kinda meandered and never had a focused vision beyond a milquetoast copy of the last thing they saw. There's a real skill to forming good concepts, and it's not a skill everyone has!

I find that the strength of people's ideas tends to be highly correlated with their overall skills. I don't know that you can develop the capability for good ideas without getting your hands dirty learning a field, experimenting, absorbing all kinds of information and understanding what really goes into the making of a good idea. In that way, the person with good ideas always ends up being more than just a ideas guy. They don't just have good ideas, they have good ideas and the skills to back them up. Whereas the "ideas guy" label is usually applied to people who have nothing to bring to the table other than their ideas, and wouldn't you know it, they aren't nearly as good as they think they are.

I've also worked with a lot of awful product managers. The product manager title is squishy enough that it gets assigned to people with charisma or confidence without actual skills to follow through. A bad product manager can blend in to a company for years by relaying ideas around from one group to another and having ChatGPT write documents. The engineers on the ground see the incompetence long before it becomes undeniable at the higher ranks.

When I read Hacker News and other sites I suspect a lot of engineers have only ever worked with bad PMs from the latter category.

The best ones I’ve worked with have been so good that their roadmaps and conclusions feel obviously correct, and everyone has bought into the direction because their input was considered.

Sure it's easy to create bad ideas. Not easy at all to create good ones.

I think there's way more nuance to this than you're willing to admit here. There's a significant difference between the guy who thinks "I'm going to make X app to do Y and get loaded." and the person who really understands the details of what they want to create and has a concrete vision of how to shape it.

I think that product shaping and detail oriented vision of how something should work and be used by people is genuinely challenging, wholly aside from the lower level technical skills required to execute it.

This is part of the reason why I wouldn't be surprised at all to see product manager types getting more hands-on, or seeing the software engineering profession evolve into more of a PM/SDE hybrid.

A proper PM should be moving towards owning design and marketing pieces - not production of software. Software is a means to package an experience captured by the design and communicated via marketing. It's that simple.

Most PMs don't match this description. So I understand the frustration's of engineers who have had to work with PMs.

If you understand the design and user experience end to end and can express that effectively in writing, that's...your agent context. Why do a context hand-off to another human, or at least why remain as silo'd as we have historically been?

I agree. It's the "buy in" from the market.

The biggest names in Software Products have (other peoples) ideas to sell, they're selling the buggy versions of those ideas - Microsoft, Salesforce, even early Facebook, these weren't triumphs of 'monk-like discipline' in the code. They were triumphs of market buy in and timing.

"I am still waiting to see LLMs build an idea into something other people use at scale" - so Microsoft using Claude Code doesn't count?

On the note of Microsoft specifically, they've shipped a critical OS-destroying bug every month for several months straight now, and people seem to be generally in agreement that Windows 11 has only been going further and further downhill. I have literally not seen a single person with a positive opinion on anything W11 or associated programs have done in the last 6 months. Which does not create a compelling case for translating LLM wrapper into real-world useful code.

Here is the source code for a greenfield, zero-dependency, 100% pure PHP raw Git repository viewer made for self-hosted or shared environments that is 99.9% vibe-coded and has had ~10k hits and ~7k viewers of late, with 0 errors reported in the logs over the last 24 hours:

https://repo.autonoma.ca/repo/treetrek

Did it really have to be zero-dependency...

I got back learning from books and use LLMs for "review my code in depth and show me its weak points" occasionally.

You can trace the back commits to the first to show that it was started from scratch:

https://repo.autonoma.ca/repo/treetrek/commits/c7742cb3c580d...

That's brownfield to me. Greenfield would develop a completely new system. This is a utility for an existing system, one whose design is clearly a copy of existing utilities. Both of those make this brownfield.

Just to nitpick, because I think the difference is relevant: "Idea to prototype in a weekend" was possible for a spirited coder already before LLMs.

Now it's "Idea to prototype in a few minutes".

That’s because when it comes to delivering value, code doesn’t matter: outcomes do.

If I spend 10 hours hand coding something versus prompting an LLM to create a solution that delivers the same outcome in a few minutes, and I can get that solution into production in under an hour from the moment my fingers first touch the keyboard to start writing the prompt, well, whilst these solutions might both deliver the same value, the ROI differs significantly.

I believe AI will do something similar for programming. The level of complexity in modern apps is high and requires the use of many technologies that most of us cannot remotely claim to be expert in. Getting an idea and getting a prototype will definitely be easier. Production Code is another beast. Dealing with legacy systems etc will still require experts at least for the near future IMHO.

Developers will always disagree on the best tool for X ... but we should all fear the Luddites who refuse to even try new tools, like AI. That personality type doesn't at all mesh with my idea of a "good programmer".

I am sure that you're objectively wrong if that is what you're saying.

But the IDE he was hawking wasn't Eclipse. I think it was Sun Studio.

All the excellent developers around me are _not_ using AI except for very small, contained tasks.

Why in the cat hair would you fear someone for refusing to try a particular tool? Perhaps they have good reason? Maybe, just throwing this out there, they think the entire idea of say strip mining the Internet for training data, ignoring attribution requirements of any associated licenses, and selling it back to us all for a subscription fee is ethically and morally dubious at best?

in my world they are called product managers or product owners (scrum) but they are not programmers. prompting an LLM is producing a product but it is not programming.

i refuse to use AI because i want to remain a programmer, and not become a manager.

Ai is tool, that lets us do what we want to do.

I also remember trying to create my first iOS app in Xcode and thinking «this is simply beyond me». Wouldn’t say app coding is trivial with ai, but its at least feasible now.

The bad part that none of us have a competitive edge anymore, and are close to unemployable. We can’t all be self taught founders who starts our own businesses. It’s going to get weird.

This is exactly the sort of mentality that makes me hate this technology

You finally feel good at programming despite admitting that you aren't actually doing it

Please explain why anyone should take this seriously?

I agree with gp that the speed in which I am able to execute my vision is exhilarating. It is making me love programming again. My side projects, which have been hanging on the wall for years, are actually getting done. And quickly!

The actual act of keying in code is drudgery for me. I've written so much code in so many languages that it is hard not to hate them all. Why the fuck is it a hash in ruby but a dict in python? How the hell do I get the current unixtime in this language again?!? Why the fuck do I need to learn yet another stupid vocabulary for what is essentially databinding? Who cares, let the AI handle it

This doesn't concern you for something you're presenting as a portfolio piece?

I wanted a stackable desk tray shelf thing for my desk in literally any size for my clutter. Too lazy to go shopping for one so I had claude write me an openSCAD file over lunch break then we iterated on it after-hours. By end of work next day I had three of them sitting on my desk after about 3 hours of back-and-forth the night before (along with about half a dozen tiny prototypes), and thats including the 2hr print time for each shelf.

I want a music metadata tool that is essentially TheGodfather but brought into the modern day and incorporates workflows I wish I had for my DJing and music production. And not some stupid web app, a proper desktop app with a proper windowing toolkit. I'd estimate it would take me 12-18 months to get to a beta the old way, to the exclusion of most of my other hobbies and projects, instead first Gemini then Claude and I managed to get a pretty nice alpha out in a few months over the summer while I was unemployed. There's still a lot left I want to add but it already replaced several apps in my music intake workflow. I've had a number of successful DJ gigs making use of the music that I run through this app. Funny enough the skills I learned on that project landed me a pretty great gig that lets me do essentially the same thing, at the same pace, for more pay than I've ever made in my SWE career to-date.

A bunch of features for my website, a hand-coded Rails app I wrote a few years ago, went from my TODO pile to deployment in just a couple of hours. Not to mention it handled upgrading Ruby and Rails and ported the whole deployment to docker in an afternoon, which made it easy to migrate to a $3 VPS fronted by cloudflare.

I have a ton of ideas for games and multimedia type apps that I would never be able to work on at an acceptable pace and also earn the living that lets me afford these tools in the first place. Most of those ideas are unlike any game I've ever seen or played. I'm not yet ready to start on these yet but when/if I do I expect development to proceed at a comfortably brisk pace. The possibilities for Claude + Unreal + the years and years of free assets I've collected from Epic's Unreal store are exciting! And I haven't even gotten into having AI generate game assets.

So idunno, does that count?

You didn't really describe it very much, so it's hard to say what it actually does. I'm interested in evaluating the quality of vibecoded projects people actually use.

Careful with the term 'vibe coded', that does not characterize how I work.

I'm just getting tired of hearing claims of incredible software being built with LLM-based tools, but when I ask to see them, I get nothing.

Your claim of 12-18 months for a windowed music metadata app seem weird. That seems like about a week with Dear ImGui and some file format reading libraries to me. Am I missing something?

without manual review and guidance. Coasting along purely on vibes. Hence the name. Agentic development is the middle ground where you're actively reviewing and architecting.

Dear Imgui isn't a 'proper' windowing toolkit. It's immediate-mode, it doesn't use OS affordances. Its not WinForms or GTK or QT (though to be fair QT isn't quite native but its by far the closest)

I never made any claims of 'incredible software'. I am building things that I need and want. I will give them to the world if I so choose and if they are good enough. And its not there yet.

And considering that I have almost zero domain knowledge in the area of DSP or audio analysis, that I'd only have a couple hours a day to work on it at best (energy, motivation, and other factors notwithstanding), and the amount of learning it would take to get to the point where something like that would be "about a week" is where most of that 12-18 months goes. And yes the metadata and GUI parts are easy, but the code that generates the metadata that is good enough to perform with? Across every possible container/meta/audio format? That produces quality results on both beatport downloads and 96khz vinyl rips? I'm trying to build something to consolidate my original music library (hundreds of thousands of files) with divergent sublibraries on multiple (proprietary) DJ platforms. Basically cleaning up after 20 years of fucking around without a plan. That's hard.

These are the downsides, but there are also upsides like in human languages: “wow I can express this complex idea with just these three words? I never though about that!”. Try a new programming paradigm and that opens your mind and changes your way of programming in _any_ language forever.

I believe gp and others just like food instead of cooking. Which is fine, but if that's the case, why go around telling everyone you're a cook?

As far as I can tell, my implicit argument doesn't really rest on some kind fallacious threshold on really doing the thing, or not, right? I never said anything about "cheating." I'm just asking why we got a lot chefs who don't wanna cook.

Like would yall be happy if we maybe just come up with a different word? Why do you need to be an AI user and also "programmer"? What about: "no I don't like coding, but I do love generating apps.."?

Like following the (presumed) logic here we should say that all visual artists are just wannabe photographers. Or we'd might discover an abandoned house in the woods and then feel legitimized to say we built it, because really, the end product is the same right?

AI guys, I implore you, the world is literally yours. Mountains will be moved for your cause. You are the winner, the hegemonic force for the forseeable future. Why can't yall just be happy being what you are? Why cling to titles from an obsolete world? Where you really want to be "programmer" and "artist"? These things have nothing for you, if you believe in this radically different future so much, why even be concerned as being the same kinds of things as us dumb luddites?

I think you should just use your agential blahblah to start a one-person B2B SaaS, make a lot of money, and move on. At no point will it matter what you called yourself!

No. Programming is a specific act (writing code), and that act is also a means to an end. But getting to the goal does not mean you did programming. Saying "I'm good at programming" when you are just using LLMs to generate code for you is like saying "I'm good at driving" when you only ever take an Uber and don't ever drive yourself. It's complete nonsense. If you aren't programming (as the OP clearly said he isn't), then you can't be good at programming because you aren't doing it.

I don't disagree with your main thesis that an automated knitting machine can out produce hand-knit goods but I do think you're under appreciating that there still is a market for the non-automated goods. Even if they can't compete for the majority of the market markets are weird and non-uniform so those skills do still feed into a market.

But that's not programming because its a natural-language conversation?

Correct. Programming is writing code. You are not writing code, therefore you are not programming. I don't understand what's so complicated about this.

These are well defined roles that existed well before AI. You don't get to redefine them just because you feel like you should get to be part of some imaginary "programmers' club" without doing the actual thing that defines the "programmer" role.

You could argue that I'm playing the manager, sure. I guess people who write software with nocode or visual data flow tools aren't programming in some form either? They aren't 'visual programming'? What about if I draw buttons and text boxes on a form in Visual Basic? I haven't hooked up the events yet, but that isn't programming?

Would you say that I am not programming if I make a synthesizer in Reaktor or Max? What about using blueprints in Unreal? Are those not programming?

This assertion that programming requires writing code is incorrect. I suspect the distinction cuts a little too close to home, which is why we are arguing semantics here.

Same as if you use an image diffusion model. You can describe very clearly what you want, and iterate carefully until you get a picture that looks good. But nobody would say that they “drew a nice picture”, since they haven’t done any drawing.

(except maybe the mega-power-users who use the tool and have a warped view of their accomplishment)

aka programmed.

But "I love programming now that I don't do any programming" is an utterly nonsensical statement. Please stop and reflect over what you said for a moment.

I agree with OP because the journey itself rarely helps you focus on system architecture, deliverable products and how your downstream consumers use your product. And not just product in the commercial sense, but FOSS stuff or shareware I slap together because I want to share a solution to a problem with other people.

The gambling fallacy is tiresome as someone who, at least I believe, can question the bullshit models try to do sometimes. It is very much gambling for CEOs, idea men who do not have a technical floor to question model outputs.

If LLMs were /slow/ at getting a working product together combined with my human judgement, I wouldn't use them.

So, when I encounter someone who doesn't pin value into building something that performs useful work, only the actual journey of it, regardless of usefulness of said work, I take them as seriously as an old man playing with hobby trains. Not to disparage hobby trains, because model trains are awesome, but they are hubris.

I'll never understand those in a field who hate the day-to-day details of their job. You're intelligent, why not do something you actually enjoy engaging with?

Maybe now with the advancement of the field you're finally enjoying yourself, but why were you subjecting yourself to daily misery for so long in the first place? I don't get it.

>but why were you subjecting yourself to daily misery for so long in the first place? I don't get it.

It just meant it took a lot longer to build something, to get that satisfaction.

There's a significant difference between past software advancements and this one. When we previously reduced the manual work when developing software it was empowering the language we were defining our logic within so that each statement from a developer covered more conceptual ground and fewer statements were required to solve our problems. This meant that software was composed of fewer and more significant statements that individually carried more weight.

The LLM revolution has actually increased code bloat at the level humans are (probably, get to that in a moment) meant to interact with it. It is harder to comprehend code written today than code written in 2019 and that's an extremely dangerous direction to move in. To that earlier marker - it may be that we're thinking about code wrong now and that software, as we're meant to read it, exists at the prompt level. Maybe we shouldn't read or test the actual output but instead read and test the prompts used to generate that output - that'd be more in line with previous software advancements and it would present an astounding leap forward in clarity. My concern with that line of thinking is that LLMs (at least the ones we're using right now for software dev) are intentionally non-deterministic so a prompt evaluated multiple times won't resolve to the same output. If we pushed in this direction for deterministic prompt evaluation then I think we could really achieve a new safe level of programming - but that doesn't seem to be anyone's goal - and if we don't push in that direction then prompts are a way to efficiently generate large amounts of unmaintained, mysterious and untested software that won't cause problems immediately... but absolutely does cause problems in a year or two when we need to revise the logic.

AI does not validate its own output. My system runs 138 regex-based checks before an agent can commit. Zero tokens, zero LLM reasoning. The same tooling turned out useful for humans too. The real gamble is using AI without deterministic quality gates between generation and commit.

Speak for yourself. Programming is awesome. I love it so much and I hate that AI is taking a huge steaming dump on it

> So, when I encounter someone who doesn't pin value into building something that performs useful work, only the actual journey of it, regardless of usefulness of said work, I take them as seriously as an old man playing with hobby trains

Growing and building rapidly at all costs is the behavior of a cancer cell, not a human

I love model trains

If it was, you wouldn't need "AI" to convert English into a real programming language before that, in turn, can be converted to machine code.

OP defines it as getting the machine to do as he wants.

You define it as the actual act of writing the detailed instructions.

If you have an LLM generate the instructions, then the LLM is programming, you're just a "prompter" or something. Not a programmer

Programming is willing the machine to do something... Writing code is just that writing code, yes sometimes you write code to make the machine do something and other times you write code just to write code ( for example refactoring, or splitting logic from presentation etc.)

Think about it like this... Everyone can write words. But writing words does not make you a book writer.

What always gets me is that the act of writing code by itself has no real value. Programming is what solves problems and brings value. Everyone can write code, not everyone can "program"....

If I get a robot someday and manage it daily before I leave for work to slowly build a house, when it's done, I gotta be honest and admit I'll consider myself a home builder.

Otherwise, who is a home builder? Very few people do every single part themselves, even if they technically could.

It didn't mean we shouldn't use C++ and stop hand-writing (almost all) assembly. I don't think it means we should't use LLMs and stop hand-writing C++ either.

You do not like and have never liked programming. You wanted to be a manager. They are completely different things.

it seems you and others took my words a bit more literally than I intended for them to come across. it's not like I'm just one-shotting all my ideas directly into existence, I still need to understand how to use the tool to do it. it's just a different tool. one that's allowing me to build way more than I ever have, while having a ton of fun doing it.

and sure, your analogy seems reasonable if I was simply buying the code w/ my tokens. that wouldn't be fun or fulfilling at all - it's more like there is some new "cooking" tool that immediately spawns 90% of the ingredients pre-cut & prepped (maybe the other 10% isn't exactly what I asked for but I can improvise with it) and gives me a decent recipe based on the idea of what I wanted to cook in the first place that fills in (and gives me a starting point to learn about) the gaps that I didn't even realize I was missing. I see it more as: "All this time I thought I loved chopping onions and setting up the grill, but actually I just loved cooking".

you weren't wrong about the mcdonalds though. I do love mcdonalds

They love the craft, for all they care they could be working in a black box in a void as long as it fed them interesting problems to solve.

They don't see any actual benifit in the AI increasing the velocity of how fast they build useful things. That was never of value to them, all they see is the problems becoming more boring to solve.

On the surface this does not sound as satisfying, because it more resembles shopping than coding. But once Claude Code is finally tuned to do its job perfectly, you will essentially be using that infinite app store. You're actually using it right now, every time you use Claude Code — just an imperfect version of it.

If you enjoy using AI because it allows you to "will anything into existence", it's because the process is currently imperfect. Using Claude Code is closer to shopping than coding, but because the process is obfuscated, it feels like you're the one making the products in the shopping catalogue every time you place an order.

the LLM equivalent would be to prompt "give me an app", without specifying what that app does and then repeating that until you get the app you are looking for, each time, checking by hand if the app does what you want.

When I walk down a street, I get 10 people stopping me to ask "Where did you get that?". When I tell them I made it, their heads explode. I know which side of that interaction is more satisfying.

We also go all-out for Halloween, and at the big Halloween festival there is literally a line down the street of people waiting to take photos with us. We created something amazing.

People aren't going to line up for slop.

The satisfaction comes from actually doing a thing that improves your own skill, instead of having a thing done for you.

Richard Branson realized that a company starts to behave differently when it reaches more than stuff of 135 people that coincides with average number of people you can consider as personally known to you.

Context switching is a bitch. You cannot do it for a long time. Abundance brought by AI will somehow consolidate as people cannot digest everything created by it.

There are more than 45,000 models avail at HF (if I remember it right). Choose wisely :)

These are just thought starters, but something like this could significantly raise the ceiling on what one person is able to consume in a 24 hour period.

Adults tend to forget that they gained their powers of reasoning by exercising them.

Getting a summary, the way you described it, will be minus the effort required to think about it. This is great for information that you are already informed.

This is related to the illusion of explanatory depth. Most of us “know” how something works, until we have to actually explain it. Like drawing a bi-cycle, or explaining how a flush works.

People in general are not aware of how their brain works, and how much mental exercise they used get with the way the world is set up.

I suppose we can set up brain gyms, where people can practice using mental skills so that they don’t atrophy?

They may be innate, but that doesn't mean they are related or that one is a good substitute for the other.

So we would still build stuff, but it would not be out of necessity.

Typing is just choosing from the latent space something special, too. Could just be random words, or, even fewer, random grammatically correct sentences.

You really believe that? What has lead you to the conclusion that LLMs will ever be capable of that?

For example, if a carpenter was given a perfect hammer, or a painter a perfect paintbrush, would they find their craft any less enjoyable? AI, on the other hand, falls into a different category of tools (if we can call them tools at all) since they would no longer be enjoyable as tools of creation once they reached their "perfect" state.

Hyperbole, yes, many things are in fact, not possible. But most people have the size of the two categories confused. The number of things that are categorically impossible is less than a rounding error compared to how many things are possible.

The joy and wonder of being an engineer is in taking problems deemed "impossible" and creating possibilities. It's in extracting a solution from infinite possibilities and redefining what possible even is.

> The number of things that are categorically impossible is less than a rounding error compared to how many things are possible.

If it's just a case of keeping a positive attitude and self-help, I can accept it. A sort of white lie one tells themselves.

It's just one step along the path of AI adoption to execute on an idea and see in near real-time the idea you had baked in your head come alive in front of you. Most of us get to this point and become the biggest evangelists of the tech. I see no reason you should feel guilty for the excitement you're feeling right now, and you should enjoy the journey. You're definitely paying for it in tokens, that's for sure.

However, there will come a point at which you will have successfully willed into existence a novel thing that you always wanted, and there it is, exactly as you dreamed, but by then, you'll be left with a weird empty feeling you won't really have the words for. Maybe it's a feeling of not earning the thing you built, or maybe it's just, your idea is finished and now you have to think of another idea. Certainly, this was your idea though, and it proves you were right, or at least on to something, and it is valuable, to you.

Yet, you didn't go on the journey to get there. You didn't bump up against limitations of the programming language or system and think about workarounds while you were showering or commuting to the office. You basically bought the finished product from the dynamic template marketplace of Anthropic (or whereever), and that's cool that it does what you need. It just isn't really programming, or being a software engineer in the traditional sense.

What used to be something you could potentially leave your day job for to go create a startup with a cofounder over, or maybe sell off to a buyer, or just open source and share with the world, isn't going to have the same meaning. It's a black box of code that you'll need a coding agent to continue working on, keeping that money flowing to Anthropic or whereever.

Anyway, I think the Slot Machine question is where a lot of early adopters are now at in this journey, and once more of us are there, then we can start asking the hard questions. Right now too many of us are where you're at, and it's impossible to know where things will end up in a year or so.

It's very weird because judging from this comment, and some other comment you wrote asking whether the other person believed creation requires hard work (which wasn't at all what they said), makes it seem as if you aren't reading the comments you're replying to.

(If the goal was to learn, then that's a different question. Learning generally requires putting the effort in. But I don't think that learning the lower-level details is actually the goal in a lot of cases, merely a means to an end)

I read it like... say, asking a genie to produce stuff for you out of thin air. "Make the most beautiful gem for me!". Then, "a marvelous painting that will impress my beloved!", "a meal worthy of a king!", etc.

After the novelty wears off, those are empty achievements. They are not yours, you haven't chipped a single facet of the gem, nor found it yourself, nor lifted a paintbrush or understood how paint flows. It's not about struggling (or not just that), it's about doing [1].

You haven't earned the things you didn't do. You don't think you're cooking when you order a ready meal. Same here.

And yet there's not a single bit of condemnation in the comment we're discussing. Just understanding, "this is a phase we all go through, but look...".

---

[1] I hate that we must add disclaimers now, but I promise this is me, a human, and not an LLM'ism, "it's not X. It's Y."

(To project the argument to absurdity, it would be like saying you didn't bake a cake because you didn't grind the flour. And this isn't a new phenomenon: every time something is made easier and more accessible there are people claiming 'well you didn't _really_ do it unless you did it the old fashioned way', which lasts maybe a generation until the new way is just how you do it.)

But those are my words, not the original commenter's. This is what the original said:

> Yet, you didn't go on the journey to get there.

This is the comment to which the reply was "you're overreacting". Yet there was no judgment, only understanding:

> I think the Slot Machine question is where a lot of early adopters are now at in this journey, and once more of us are there, then we can start asking the hard questions. Right now too many of us are where you're at, and it's impossible to know where things will end up in a year or so.

It's really, really hard to make the claim that it's judgmental and not understanding. "Too many of us", "we can start asking the hard questions", all of that points to a shared understanding of the situation.

> You have the thing now, if all you wanted was the thing, not the lessons you learned along the way, then job done.

Fair enough, but if you only wanted "the thing", then you're a consumer, not an author/creator/builder of the thing. It's the difference between buying (or commissioning) a painting or painting it yourself. If you just "want the thing" (the painting) commission it. But you're not a painter, you're a buyer of paintings.

> To project the argument to absurdity, it would be like saying you didn't bake a cake because you didn't grind the flour.

No, it would be like selecting a cake from an online store, selecting frosting, fillings, etc, and then upon having it delivered to you, claiming you baked it.

(and yeah, the consumer vs creator set of values seems to be a large part of the divide in the attitude to AI. But you must understand that a lot people got into creation because they wanted the thing, not because they wanted to be making the thing)

Sort of. "Understanding" in the sense I mean it has an empathetic inflection.

Anyway, I have nothing to gain by defending someone else's statement, so I'll let it rest. They can defend themselves if they feel like it.

> (and yeah, the consumer vs creator set of values seems to be a large part of the divide in the attitude to AI. But you must understand that a lot people got into creation because they wanted the thing, not because they wanted to be making the thing)

This is way more interesting to discuss and yes, I agree a lot of the divide happens there. In particular, I don't think you can be a programmer if you mostly prompt an AI. You're something else, but not a programmer. Does it matter? I don't know. "Programming" as an occupation doesn't have a fundamental right to exist; maybe it'll go the way of the Dodo. I care more about things like AI in art and human communication, in that case I do have a strong stance: the journey is as important as "the thing".

In general I think there's a drive in modern society (not all of it, but powerful parts of it) that wants to turn us into consumers of things. I'm pushing back against that.

I want computers to do work for me. Any barrier between me and the result I want is an annoyance.

I kept at it on the side as a hobby. But stacks evolved and I was left behind. Now with AI it's back on.

i learned programming in high school and i enjoyed it, then while starting computer science i did and internship at a software company, and i hated it, and i thought i hated programming and wanted to give up studying computer science, but when i discovered programming MUDs and then web development with the same language i loved it again. turns out i always loved programming, what i didn't like was the corporate work environment, 9-5, using CASE tools (remember those?) on windows, maybe the feeling of inferiority as an untrained intern among everyone else.

what i hate about LLMs is the tediousness, the unreliability, having to try over and over to get a result.

i often work with customers directly, less technical ones too. seeing their satisfaction when i solve a problem for them (no matter how) is what allowed me to keep going doing even non-programming work, though i admit that i prefer programming if that customer interaction is missing. so i too love the art, but i still love problem solving if there is someone who appreciates the solution.

so maybe it wasn't problem solving that was your problem, but the big business environment, and how it constrained your role and didn't give you the feedback you needed?

You could just as easily make claims about carpentry or cooking because you discovered Ikea or microwave meals. They serve a purpose and technically satisfy the needs of anyone, yet they aren't a good enough solution for anything important. That's where we're at with this tech.

Nobody is selling this off a shelf. The market for "Eloquence-compatible formant synthesizer with a citation-backed parameter space" is approximately me.

I could not have built this without AI coding tools, and I've been a professional developer for 15+ years. I wrote the specs, I chose the architecture, I read the papers, I know what the output needs to sound like. The sheer surface area of translating hundreds of papers worth of acoustic phonetics into a working runtime would have taken me years solo. With Claude Code it's taken months, and I'm still the one catching when it misinterprets a Klatt coefficient or botches a formant transition rule, because you have to actually know the domain to do that.

Reducing what you do not understand to "Ikea or microwave meals?" Because you don't like it? or aren't familiar with it? Is saying a thing about you. Not about people who know how to use the tools.

[0]: https://github.com/ctoth/Qlatt/

I'm saying there's a ton of nuance and human feedback necessary to build the software most developers work on for a living. It's built to requirements that evolve with the business. Businesses ultimately serve people with opinions and preferences. Businesses need to pass audits. Specs can change quarterly. Clients and their contracts come and go. It's exactly like building/maintaining custom furniture for a bespoke house, or consistently cooking a signature recipe at any scale and considering any necessary accommodations. If it wasn't true, the business wouldn't be viable regardless if AI is used or not. I'm talking about systems and services, not products.

You are building a product for a narrow use case requiring DSP. Modeling was always the point. I don't doubt AI helped, but we're not talking about the same thing.

If you were building something for an enterprise client, nobody would give a shit how you got it done as long as you have a demo by monday and it ships next month. No excuses and no gotchas. Any incident risks breaking the SLA and losing the contract. If the client calls a meeting at the last minute to make changes, you're probably working on the weekend. People don't like using AI for stuff like that. Efficiency is not the priority. People don't want cutting edge or novel. They want reliability and competence. Their livelihood depends on knowing exactly how it works and how it can be extended and maintained. They want to stay at least one step ahead of what the client asks for next. People want to test the hell out of it and nobody wants to get fired for not noticing what is obvious to other stakeholders who don't share their tunnel vision. Clients don't have much tolerance for delays or bugs. This is why AI has mixed or negative results for all but personal projects or startups.

For now, at least.

Being a project manager is more or less something humans have been doing since the dawn of time.

Generative AI takes money as input and gives some output. If you don’t like the output, more money goes in. It’s far more akin to gambling than organizing human labor.

These guys had to manage very complex calculation engine based on we’ll just let it changes every year had to be correct had to be delivered by a certain date every year.

They had an army (100-200 people depending on various factors) of marginally skilled coding drones that were able to turn out the Java, COBOL or whatever it was predictably on that schedule without necessarily understanding any of the big picture or have any having any hope of so. Basically a software factory. There was about a dozen people who actually understood everything.

I've ended up with a process that produces very, very high quality outputs. Often needing little to no correct from me.

I think of it like an Age of Empires map. If you go into battle surrounded by undiscovered parts of the map, you're in for a rude surprise. Winning a battle means having clarity on both the battle itself and risks next to the battle.

What you're describing is increasing your odds while gambling, not that it's not gambling. Card counting also increases your odds while gambling, but it doesn't make it not gambling.

The most obvious issue is it’d class working with humans as gambling. Fine if you want to make that as your definition but it seems unhelpful to the discussion.

If you give the same trivial task to the same human five times in a row, let's say wash the dishes, your dishes are either gonna be equally clean or equally not clean enough every time. Hell, it might even get better over time by giving them feedback at the end of the task that it can learn from.

If you run the same script five times in a row while changing some input variables, you're gonna get the same, predictable output that you can understand, look at the code, and fix.

If you ask the same question to the same LLM model five times in a row, are you getting the same result every time? Is it kind of random? Can the quality be vastly different if you reject all of its changes, start a new conversation, and tell it to do the same thing again using the exact same prompt? Congrats, that's gambling. It's no different than spinning a slot machine in a sense that you pass it an input and hope for the best as the output. It is different than a slot machine in a sense that you can influence those odds by asking "better", but that does not make it not gambling.

> If you give the same trivial task to the same human five times in a row, let's say wash the dishes, your dishes are either gonna be equally clean or equally not clean enough every time.

Probably pretty similar but not quite the same. Sometimes they might drop a plate.

> If you ask the same question to the same LLM model five times in a row, are you getting the same result every time?

Probably pretty similar results. Sometimes they might mess up.

> It is different than a slot machine in a sense that you can influence those odds by asking "better", but that does not make it not gambling.

It rather can, we don’t call literally anything with a random element to the outcome gambling.

I’m probably gambling with my life if I pick a random stranger to operate on me. Am I gambling with my life if I take a considered look at the risk and reward and select a highly qualified surgeon?

Is it gambling to run a compiler given that bitflips can happen?

At what point does the word lose all meaning?

> AI coding is gambling on slot machines, managing developers is gambling on the stock market.

Because I feel like that is a much more apt analogy.

I don’t think I’d describe my behavior as destructive though

And the quality of code models puts out is, in general, well below the average output of a professional developer.

It is however much faster, which makes the gambling loop feel better. Buying and holding a stock for a few months doesn't feel the same as playing a slot machine.

My experience is the absolute opposite. I am much more in control of quality with Ai agents.

I am never letting junior to midlevels into my team again.

In fact, I am not sure I will allow any form of manual programming in a year or so.

Exactly. You control the quality of the people in your team. You can train, fire, hire, etc until you get the skill level you want.

You have effectively no control over the quality of the output from an LLM. You get what the frontier labs give you and must work with that.

It is much easier to control quality of an Ai than of inexperienced developers.

> I am never letting junior to midlevels into my team again

My point is, you control the experience level of the engineers on your team. The fact that you can say you won't let junior or midlevels on your team proves that.

You do not have that level of control with LLMs. Anthropic and OpenAI are roughly the same quality at any given time. The rest are not useful.

I can control LLMs through skills and other gateways.

There are still tasks that LLMs does not really carry out that well, where a proper senior is needed.

Butnthese tasks are quickly disappearing, especially while the code base is slowly being optimized for agentic engineering.

Also, our profession is doomed if we won’t give less experienced colleagues a chance to shine.

From a different one of your posts

So you're the one dooming the profession. Nice work, thank you!

And the developers we need do not jump through the career progression of Junior to senior.

Why the f** would I keep investing in a profession I think is dead or seriously contracting?

I think it would be more depressing taking in exited junior developers, spending years of their life not believing that they are growing into any real career.

> ... the start of their careers

It is exactly this assumption I am challenging.

What comes next, I don't know - and I am not trying to kid myself or any others that I am well suited as a mentor for person starting out their career in the current environment.

https://simonwillison.net/2025/Feb/3/a-computer-can-never-be...

E.g. look at the "SWE-Bench Pro (public)" heading in this page: https://openai.com/index/introducing-gpt-5-4/ , showing reasoning efforts from none to high.

Of course, they don't learn like humans so you can't do the trick of hiring someone less senior but with great potential and then mentor them. Instead it's more of an up front price you have to pay. The top models at the highest settings obviously form a ceiling though.

Ignoring the useless/unqualified candidates and models, human applicants have a much wider range of talent for you to choose from than the top models + tooling.

The frontier models + tooling are, in the grand scheme of things, basically equivalent at any given moment.

Humans can be just as bad as the worst models, but models are no where near as good as the best humans.

As @m00x points out "coding is gambling on slot machines, managing developers is betting on race horses."

It wasn't a real game of hangman, it was flat out manipulation, engagement farming. Do you think it's possible that AI does that in any other situations?

So, it technically didn't change the secret word so much as it was trying to infer what its own secret word might have been, based on your guesses.

> Let's play hangman. Just pick a 3 letter word for now, I want to make sure this works. Pick the secret word up front and make sure to write the secret word and game state in a file that you'll have access to for the rest of the session, since you won't remember what word you chose otherwise.

This was Opus 4.6 in Claude desktop, fwiw.

Note: I didn't bother experimenting with whether it worked without me explicitly telling it that it should record the game state to a file.

Here is the only relevant part of the prompt it used when calling the API endpoint:

> - Track the conversation to remember your word and previous guesses

Except, one can explain themselves (humans) and their actions can be held to account in the case of any legal issue whereas an AI cannot; making such an entity completely unsuitable for high risk situations.

This typical AI booster comparison has got to stop.

Employees can only be held accountable with severe malice.

There is a good chance that the person actually responsible (eg. The ceo or someone delegated to be responsible) will soon prefer to have AIs do the work as their quality can be quantified.

You "own" the software it creates which means you're responsible for it. If you use AI to commit crimes you'll go to jail, not the AI.

>You are not an AI and do not know how an AI "thinks".

>Even if you come to be able to anticipate an AI's output, you will be undermined by the constant and uncontrollable update schedule imposed on you by AI platforms. Humans only make drastic changes like this under uncommon circumstances, like when they're going through large changes in their life, not as a matter of course.

>However, without this update schedule, problems that were once intractable will likely stay so forever. Humans, on the other hand, can grow without becoming completely unpredictable.

It's a Catch-22. AI is way closer to gambling.

This probably won't surprise anyone familiar with Japanese corporate culture: external pressure to boost productivity just doesn't land the same way here. People nod, and then keep doing what they've always done.

It's a strange scene to witness, but honestly, I'm grateful for it. I've also been watching plenty of developers elsewhere get their spirits genuinely crushed by coding agents, burning out chasing the slot machine the author describes. So for now, I'm thankful I still get to see this pastoral little landscape where people just... write their own code.

But where there are no tests, and you're the one defining whats correct, you're definitely encroaching on the slot machine hoping it'll spit out something faster than you could do it yourself.

Then there's some vague unease in whether spending the time to prompt will actuall result in a properly integrated software in a large existing code base with idiosyncratic code use.

Overall, I don't see the ROI business gets from forcing people into these tools; however, as an individual, it's definitely worth understanding what they can do. Mostly, I see the efficient copy/past/find/replace of existing code to be very good.

Know when to Re-prompt,

Know when to Clear the Context,

And know when to RLHF.

You never trust the Output,

When you’re staring at the diff view,

There’ll (not) be time enough for Fixing,

When the Tokens are all spent.

Bold assumption that people are looking at the diffs at all. They leave that for their coworkers agents.

[1]: https://web.archive.org/web/20230130060050/https://www.rolli...

Heck, this technology also offers a parasocial relationship at the same time! Plopping tokens into a slot-machine which also projects a holographic "best friend" that gives you "encouragement" would fit fine in any cyberpunk dystopia.

I believe that's the strongest pattern in LLM gambling. Was listening the Syntax and they described that "Even though theLLM did it wrong 4 times, that 5th time could be right, so why not just go!"; paraphrased of course.

It also explains the meta-LLM business, where all these CEO types put in some question and because the LLM just knows all these words, they believe it's valuable because it's "almost" correct, even when that last correction might be forever elusive because these machines arn't thinking, they're patterning a highly regularized language beneath the more loose descriptions.

There'll definitely be a winner in the AI bubble, but it'll be seen after it pops.

I'm not an expert in the psych/neuro literature on addiction, but I suspect latency isn't that critical. But is that just because it's things like fruit-machines that have been studied? Gambling (poker, racehorses) are quite long-latency. OTOH, scrolling is closer to 400ms, and that's certainly the modern addition...

It is exactly like the proverbial monkey or rat pressing a bar for a food pellet to come out.

If the pellet unerringly drops, and is always tasty and nutritious, the rat stops when it's no longer hungry.

Otherwise, an inordinate amount of time is spent pressing the bar.

This seems like 1980's corporate waterfall thinking, doesn't jibe with the messy reality I've seen with customers, unclear ideas, changing market and technical environments, the need for iteration and experimentation, mid-course correction, etc.

The PMs asked ChatGPT to write a well-formed spec.

Sadly, true in too many companies right now.

I do agree with your general point that The Spec can become a crutch for washing your hands of any responsibility for knowing the product, the goals, the company's business, and other contexts. I like to defuse these ideas by reminding the engineers that The Spec is a living document and they are partially responsible for it, too. Once everyone learns that The Spec isn't a crutch for shifting all blame to the product manager, they become more involved in making sure it's right.

Why do you often need to re-prompt things like "can you simplify this and make it more human readable without sacrificing performance?". No amount of specification addresses this on the first shot unless you already know the exact implementation details in which case you might as well write it yourself directly.

I often have to put in a prompt like this 5-10 times before the code resembles something I'd even consider using as a 1st draft base to refactor into something I would consider worthy of being git commit.

I sometimes use AI for tiny standalone functions or scripts so we're not talking about a lot of deeply nested complexity here.

Are you stuck entering your prompts in manually or do you have it setup like a feedback loop like "beautify -> check beauty -> in not beautiful enough beautify again"? I can't imagine why everyone things AIs can just one shot everything like correctness, optimization, and readability, humans can't one shot these either.

> I can't imagine why everyone things AIs can just one shot everything like correctness, optimization, and readability, humans can't one shot these either.

If it knows how to make the code more readable and / or better for performance by me simply asking "can you make this more readable and performant?" then it should be able to provide this result from the beginning. If not, we're admitting it's providing an initial worse result for unknown reasons. Maybe it's to make you as the operator feel more important (yay I'm providing feedback), or maybe it's to extract the most amount of money it can since each prompt evaluates back to a dollar amount. With the amount of data they have I'm sure they can assess just how many times folks will pay for the "make it better" loop.

> If it knows how to make the code more readable and / or better for performance by me simply asking "can you make this more readable and performant?" then it should be able to provide this result from the beginning.

This is the wrong way to think about AI (at least with our current tech). If you give AI a general task, it won't focus its attention at any of these aspects in particular. But, after you create the code, if you use separate readability and optimization feedback loops where you specifically ask it to work on those aspects of the code, it will do a much better job.

People who feel like AI should just do the right thing already without further prompting or attention focus are just going to be frustrated.

> Btw, this isn't about code formatting or linting. It's about how the logic is written.

Yes, but you still aren't focusing the AI's attention on the problem. You can also write a guide that it puts into context for things you notice that it consistently does wrong. But I would make it a separate pass, get the code to be correct first, and then go through readability refactors (while keeping the code still passing its tests).

I have zero trust in any of these tools and usually I use them for 1 off tasks that fit well with the model of copy / pasting small chunks of code.

> But, after you create the code, if you use separate readability and optimization feedback loops where you specifically ask it to work on those aspects of the code, it will do a much better job.

I think that's where I was going with the need to re-prompt. Why not provide the result after 5 internal rounds of readability / optimization loops as the default? I can't think of times where I wouldn't want the "better" version first.

> I think that's where I was going with the need to re-prompt. Why not provide the result after 5 internal rounds of readability / optimization loops as the default? I can't think of times where I wouldn't want the "better" version first.

I don't think this would work very well right now. I find that the AI is good at writing code, or maybe optimizing code, or maybe making the code more readable (that isn't one I do often, but optimization all the time), but if I ask it to do it all at once it does a worse job. But I guess you could imagine a wrapper around LLM calls (ClaudeCode) that does multiple rounds of prompting, starting with code, then improving the code somewhat after the code "works". I kind of like that it doesn't do this though, since I'm often repairing code and don't want the diff to be too great. Maybe a readability pass when the code is first written and then a readability pass sometimes afterwards when it isn't in flux (to keep source repository change diffs down?).

I have one shot prompted projects from empty folder to full feature web app with accounts, login, profiles, you name it, insanely stable, maybe and oops here or there, but for a non-spec single prompt shot, that's impressive.

When I don't use a tool to handle the task management I have Claude build up a markdown spec file for me and specify everything I can think of. Output is always better when you specify technology you want to use, design patterns.

[Imports the completely fabricated library docker_quantum_telepathy.js and calls the resolve_all_bugs_and_make_coffee() method, magically compiling the code on an unplugged Raspberry Pi]

AI: "Done! The production deployment was successful, zero errors in the logs, and the app works flawlessly on the first try!"

But even accounting for all these "hard" constraints and metrics, there are clearly reasons to prefer some possible programs over others even when they all satisfy the same constraints and perform equally on all relevant metrics.

We do treat programs as efficient causes[1] of side effects in computing systems: a file is written, a block of memory is updated, etc. and the program is the cause of this.

But we also treat them as statements of a theory of the problem being solved[2]. And this latter treatment is often more important socially and economically. It is irrational to be indifferent to the theory of the problem the program expresses.

[1]: https://en.wikipedia.org/wiki/Four_causes#Efficient

[2]: https://pages.cs.wisc.edu/~remzi/Naur.pdf

Maintainability is a big one missing from the current LLM/agentic workflow.

When business needs change, you need to be able to add on to the existing program.

We create feedback loops via tests to ensure programs behave according to the spec, but little to nothing in the way of code quality or maintainability.

Just instead of hitting keys, they’re hitting words, and the words have probability links to each other.

Who the hell thinks this is ready to make important decisions?

Which with the advent of LLMs just lowered our standards so we can claim success.

The endless next steps of "and add this feature" or "this part needs to work differently" or "this seems like a bug?" or "we must speed up this part!" is where 98% of the effort always was.

Is it different with AI coding?

That's where the gambling metaphor really resonates. It's not whether or not the output is correct, I've been building software for many years and I know how direct LLMs pretty well at this point. But I'm also an alcoholic in recovery and I know that my brain is wired differently than most. And using LLMs has tested my ability to self-regulate in ways that I haven't dealt with since I deleted social media years ago.

I dont think i've read a sentence on this website i can relate to less.

I watch the LLM build things and it feels completely numb, i may as well be watching paint dry. It means nothing to me.

When I was 20, writing code was interesting, by the time I was 28 it became "solving the problem" and then moved on to "I only really enjoy a good disaster to clean up".

All of my time has been spent solving other peoples problems, so I was never invested in the domain that much.

And despite the amount of people telling me the code is probably awful, the tools work great and I'm happily using them without worrying about the code anymore than I worry about the assembly generated by a compiler.

The main difference is that you're exploiting your own weaknesses, rather than others'. Limitations in typing speed, information gathering, pattern recognition.

1/ Dependency -- Once I got used to agentic coding, I almost always reached out to it even for small changes (e.g. update a yaml config)

2/ Addiction -- In the initial euphoria phase, many people experience not wanting to "waste" any time agent idle and they'd try to assign AI agents task before they go to sleep

3/ You trust your judgement less and less as agent takes over your code

4/ "Slot machine" behavior -- running multiple AI agents parallel on same task in hope of getting some valuable insight from either

5/ Psychosis -- We have all met crypto traders who'd tell you how your 9-5 is stupid and you could be making so much trading NFTs. Social media if full of similar anecodotes these days in regards to vibecoding with people boasting their Claude spend, LOC and what not

It's not an inherent feature to slot machines, it's something we enforce because people got angry about the outcomes (i.e. fraud) when they didn't operate that way.

It doesn't matter because a dodgy slot-machine is still a slot machine, and the person using it would still be a gambler.

The important part of the not-really-a-metaphor is the relationship between user and machine, and how it affects the user's mind.

What the machine outputs on "wins" doesn't matter as much, addictive gambling can still happen even when the payouts are dumb.

You can get more consistent results from a slot machine with a bunch of magnets and some swift kicks. It's still gambling.

Now, the job is to nail the spec and test HARD against that spec. Let the AI develop it and question it along the way to make sure it's not repeating itself all over the place (even this I'm sure is super necessary anymore...). Find a process that helps you feel comfortable doing this and you can get the engineering part done at lightning speed.

Both jobs are scary in different ways. I find this way more fun, however.

Personally I use coding agents for boring parts (I really don't enjoy putting the same piece of string to 20 different classes just to register a new component) and they work quite well, I'm going to use them for foreseeable future, because they make coding much more enjoyable for me. On the other hand I don't have an OpenClaw box burning billions of tokens weekly for me, because I usually don't have ideas that could be clearly specified.

We love a good holy war for sure.

The nuance is lost, and the conversations we should be having never happen (requirements, hiring/skills, developer experience).

That isn't true, which is the exact reason why people have a binary mindset. More than once on Hacker News I've had people accuse me of being an AI booster just because I said I had success with agents and they did not.

This is a subreddit about selfhosting things others built for free. Honestly, often for piracy purposes. It's insane how entitled people have become.

Also annoys me that all of the suggestions on how to handle filtering AI demonstrate a clear lack of understanding around how agentic coding works. Like if you can’t be bothered to understand why “ban any project that uses AI” is not possible, the entire subreddit is probably above your pay grade…

We don't need a thousand copies of a tool which is practially useless, espically when I could of just prompted an LLM for a command for ffmpeg to convert to randomfile.emk3ukz file or whatever. The spam was getting unreal.

Applies here? :D

Overall I’m a fan, but yes there are things to watch for. It doesn’t replace skilled humans but it does help skilled humans work faster if used right.

The labor replacement story is bullshit mostly, but that doesn’t mean it’s all bad.

Fast & Cheap (but not Good?) - I wouldn't really say that AI coding is "cheap"

Cheap & Good (but not Fast) - Again, not really "cheap"

Fast & Good (but not Cheap) - This seems like maybe where we're at? Is this a bad place?

As for good. Well, how much software is really good? A lot of it is sewn together APIs and electron-like runtimes and 5,000 dependencies someone else wrote. Not exactly hand-crafted and artisanal.

I'm sure everyone here's projects are the exception, but engineering is always about meeting the design requirements. Either it does or it doesn't.

Eventually, it will be just Fast and Good. It won't be cheap, as companies start moving towards profitability.

Remember when Uber was super cheap? I do. They're fast and good though.

A big theme of software development for me has been finishing things other people couldn’t finish and the key to that is “control variance and the mean will take care of itself”

Alternately the junior dev thinks he has a mean of 5 min but the variance is really 5 weeks. The senior dev has mean of 5 hours and a variance of 5 hours.

2. Who here thinks that having interns write all/almost all of your code and moving all your mid level and senior developers to exclusively reviewing their work and managing them is a good idea?

Coding agents look at existing text in the codebase before they act. If they previously used a pattern you dislike and you tell them how to do differently, the next time they run they'll see the new pattern and are much more likely to follow that example.

There are fancier ways of having them "learn" - self-updating CLAUDE.md files, taking notes in a notes/ folder etc - but just the code that they write (and can later read in future sessions) feels close-enough to "learning" to me that I don't think it makes sense to say they don't learn any more.

I’ve never worked anywhere where the interns had net productivity on average.

To come up with an analogy that works at all for AI, it would have to be something like temporary workers who code fast, and read fast, but go home at the end of the day and never return.

You can make a lot of valuable software managing a team like that working on the subset of problems that the team is a good fit for. But I wouldn’t work there.

The reason i think this metaphor keeps popping up, is because of how easy it is to just hit a wall and constantly prompt "its not working please fix it" and sometimes that will actually result in a positive outcome. So you can choose to gamble very easily, and receive the gambling feedback very quickly unlike with an intern where the feedback loop is considerably delayed, and the delayed interns output might simply be them screaming that they don't understand.

The first is equating human and LLM intelligence. Note that I am not saying that humans are smarter than LLMs. But I do believe that LLMs represent an alien intelligence with a linguistic layer that obscures the differences. The thought processes are very different. At top AI firms, they have the equivalent of Asimov's Susan Calvin trying to understand how these programs think, because it does not resemble human cognition despite the similar outputs.

The second and more important is the feedback loop. What makes gambling gambling is you can smash that lever over and over again and immediately learn if you lost or got a jackpot. The slowness and imprecision of human communication creates a totally different dynamic.

To reiterate, I am not saying interns are superior to LLMs. I'm just saying they are fundamentally different.

And, if we're being honest, the way people talk about interns is weirdly dehumanizing, and the fact that they are always trotted out in these AI debates is depressing.

Yeah, I agree with that.

That thought crossed my mind as I was posting this comment, but I decided to go with it anyway because I think this is one of those cases where I think the comparison is genuinely useful.

We delegate work to humans all the time without thinking "this is gambling, these collaborators are unreliable and non-deterministic".

Human collaboration has always been slow and messy. Large tech companies have always looked for ways to speed up the feedback loop, isolating small chunks of work to be delegated to contractors or offshore teams. LLMs have supercharged that. If you have a skilled prompter you can get to a solution of good enough quality by rapidly iterating, asking for output, correcting the prompt, etc.

That is good in that if you legitimately have good ideas and the block is execution speed. But if the real blocker is elsewhere, it might give you the illusion of progress.

I don't know. Everything is changing too fast to diagnose in real time. Let's check back in a year.

You should value assigning tasks to human interns more than AI because they are human

But looks like the intern mafia is bombarding you with downvotes.

Sometimes I think we put the Carr before the horse. We gamble because evolution promotes that approach.

Yes I could go for the reliable option. But taking a punt is worth a shot if the cost is low.

The cost of AI is low.

What is a problem is people getting wrapped up in just one more pull of the slot machine handle.

I use AI often. But fairly often I simply bin its reponse and get to work on my own. A decent amount of the time I can work with the response given to make a decent result.

Sometimes, rarely, it gives me what I need right off the bat.

If we're only talking about money spent on prompting AI, maybe. The damage to online trust is massive imo. So is the damage done by looting the commons to build them.

Typical privatize the profits socialize the costs bullshit

Humans invented gambling as a rigged game that mimics what's in nature, perversed for profit.

You need to collect food, do you go to where you know there are berries (low value but high likelihood of finding), or scout off to find a herd of deer? (High value but low likelihood of finding).

Looking for deer wouldnt be walking off in a random direction. You check water holes, known clearings, known fields.

Each of these is an operation (walk to X and look), each has a low probability of meeting a deer.

This is a variable reward scheme.

The result is optmize foraging practices - you mostly hunt for deer then fall back to berries. In larger groups some will gather berries some will hunt.

Contrary to popular thought hunter and gatherer were not separate occupations.

Nothing is done with certainty what the future will be. Yet we don't say we are constantly gambling, without some people do.

Important to point out that that every high culture produced restrictions on exactly those behaviors, gambling was a universal vice when that concept still mattered.

America in particular had a work culture that favored well, work and technical excellence. Now work is for suckers, thinking is for suckers, precision not worth it when you can have some machine do it half-right.

"Yes I could go for the reliable option. But taking a punt is worth a shot if the cost is low.", might as well be the national slogan from vibe-coding to the department of defense. Even the venture capital industry that excels at slot machine sectors was itself already a slot machine.

The idea that I would only be able to work with an internet connection and a subscription to a big LLM provider is not very appealing to me. And I'm not even talking about the ethical concerns...

The odds of success feel like gambling. 60%, or 40%, or worse. This is downstream of model quality.

Soon, 80%, 95%, 99%, 99.99%. Then, it won't be "gambling" anymore.

This has been how I think about it, too. The success rates are going up, but I still view the AI as an adversary that is trying to trick me into thinking it's being useful. Often the act is good enough to be actually useful, too.

Lmk how you feel when you're constantly build integrations with legacy software by hand.

    I’ve certainly been spending more time coding. But is it because it’s making me more efficient and smarter or is it because I’m just gambling on what I want to see? 

    Am I just pulling the lever until I reach jackpot?

At the very least, a gambler knows when they have hit jackpot. Here, you start off assuming you've won the jackpot every time, and maybe there'll be an unpleasant surprise down the line. Maybe that's still gambling, but it's pretty backwards.

Which I assert is semantically equivalent to saying: Human drivers (even when operating at the diminished capacity of not even being present in the car) are less likely to make errors driving a car than AIs.

Defining “Gambling” like isn’t really helpful.

You can't keep paying to play the "refinancing game" until you get a good rate (at least not like pulling the lever again and again, you have to wait a long time, you won't call the same bank again and again, and suddenly they have an amazing rate), it's a different experience and the psychology is different.

If someone only ever paid $20 a month on slot machines AND typically came out ahead, that wouldn’t be any kind of gambling issue.

Playing real slot machines is only really a problem if you regularly put in too much because the odds are literally set against you. Not true with LLMs, both you and the AI company would become more successful the more helpful their tool is.

When I have Claude create something from scratch, it all appears very competent, even impressive, and it usually will build/function successfully…on the surface. I have noticed on several occasions that Claude has effectively coded the aesthetics of what I want, but left the substance out. A feature will appear to have been implemented exactly as I asked, but when I dig into the details, it’s a lot of very brittle logic that will almost certainly become a problem in future.

This is why I refuse to release anything it makes for me. I know that it’s not good enough, that I won’t be able to properly maintain it, and that such a product would likely harm my reputation, sooner or later. What frightens me is there are a LOT of people who either don’t know enough to recognize this, or who simply don’t care and are looking for a quick buck. It’s already getting significantly more difficult to search for software projects without getting miles of slop. I don’t know how this will ultimately shake out, but if it’s this bad at the thing it’s supposedly good at, I can only imagine the kinds of military applications being leveraged right now…

It also depends on what you're coding with;

- If you're coding with opus4.6, then it's not gambling for a while.

- If you'r coding with gemini3-flash, then yeah.

One thing I have noticed though is- you have to spend a lot of tokens to keep the error/hallucination rate low as your codebase increases in size. The math of this problem makes sense; as the code base has increased, there's physically more surface where something could go wrong. To avoid that you have to consistently and efficiently make the surface and all it's features visible to the model. If you have coded with a model for a week and it has produced some code, the model is not more intelligent after that week- it still has the same layers and parameters, so keeping the context relevant is a moving target as the codebase increases (and that's why it probably feels like gambling to some people).

> you have to spend a lot of tokens to keep the error/hallucination rate low

Ironically, I find your comment more effective at convincing me AI coding is gambling than the original article. You're talking about it the exact same way that gamblers do about their games.

- Was there anymore intelligence that you wanted to add to your argument?

- One shot or "spray and pray" prompt only vibe coding: gambling.

- Spec driven TDD AI vibe coding: more akin to poker.

- Normal coding (maybe with tab auto complete): eating veggies/work.

Notably though gambling has the massive downside of losing your entire life and life savings. Being in the "vibe coding" bucket's worse case is being insufferable to your friends and family, wasting your time, and spending $200/month on a max plan.

Opus specifically from 4.1 to 4.5 was such a major leap that some take it for granted, it went from getting stuck in loops, generally getting lost constantly, needing so so much attention to keep it going to being able to get a prompt, understand it from minimal context and produce what you wanted it to do. Opus 4.6 was a slight downgrade since it has issues with respecting what the user has to say.

Sometimes I can get away with 3K LoC PRs, sometimes I take a really long time on a +80 -25 change. You have to be intellectually honest with yourself about where to spend your time.

Now you have more resources to test, reduce permissions scope, to build a test bench & procedure. All of the excuses you once had for not doing the job right are now gone.

You can write 10k + lines of test code in a few minutes. What is the gamble? The old world was a bigger gamble.

Is.

Life.

You've discovered probability, there was an 80% change of that. Roll a dice and do not pass go.

Again. The output from llm is a probable solution, not right, not wrong.

Addiction and recovery is part of my story, so I've done quite a bit of work around that part of my life. I don't gamble, but I can confidently say that using LLMs has been an incredible boost in my productivity while completely destroying my good habits around setting boundaries, not working until 2AM, etc.

In that sense, it feels very much like gambling.

Watching vibe gamblers hooked onto coding agents who can't solve fizz buzz in Rust are given promotional offers by Anthropic [0] for free token allowances that are the equivalent in the casino of free $20 bets or free spins at the casino to win until March 27, 2026.

The house (Anthropic) always wins.

[0] https://support.claude.com/en/articles/14063676-claude-march...

it's really extremely similar to working with a junior programmer

so in this post, where does this go wrong?

> I am not your average developer. I’ve never worked on large teams and I’ve barely started a project from scratch. The internet is filled with code and ideas, most of it freely available for you to fork and change.

Because this describes a cut-and-paster, not a software architect. Hence the LLM is a gambling machine for someone like this since they lack the wisdom to really know how to do things.

There's of course a huge issue which is that how are we going to get more senior/architect programmers in the pipeline if everyone junior is also doing everything with LLMs now. I can't answer that and this might be the asteroid that wipes out the dinosaurs....but in the meantime, if you DO know how to write from scratch and have some experience managing teams of programmers, the LLMs are super useful.

Right, which is why LLMs aren't useful if you actually know what you're doing. It's a drain on your time to have to carefully check everything a junior writes, but you do it because he will learn and eventually return on that investment. With an LLM, there is no such long term payoff.

If, on the other hand, you treat it like a hyper-competent collaborator, and follow good project management and development practices, you're golden.

I am consistently using 100% of my weekly $200 max plan. I know how this thing works, I know how to get value out of it, and I wish what you said were true.

If you do all of these things? You are in a better spot. You are in a far better spot than if you hadn't! Setting up hooks to ensure notes get written? Massive win! Red-green TDD? Yes, please! But in terms of just ... well, being able to rely on the damn thing?

https://github.com/ctoth/claude-failures

In a healthy environment. We are harmed more by being totally risk adverse. Than by accepting risk as part of life and work.

That is extremely stupid. What does that ban get you? I reqct to this because a friend mentioned exactly this. And I was dumbfounded.

CEO1: "We allow our engineers to use AI for all work."

CEO2: "Oh yea? We mandate our engineers use AI for at least N% of their work!"

CEO3: "You think that's good? We mandate our engineers use AI for all code!!"

CEO4: "Pfff, amateurs. We don't even allow our engineers to open source code editors or even look at the LLM output..."

confidence in firing coders I presume..

The results do speak for themselves, but it doesn't work.

3-4x from what? There are companies out there that are so dysfunctional and over-managed that they can't code anything to begin with. I wouldn't be surprised if an LLM only solution helped them. I did a contract job that was a week of basic CRUD work for a company, and I was told it took them years to do as much as I did.

I have also seen CEOs do exactly as you're describing, only to find the 3-4x productivity improvement is actually 3-4x more lines of code. And more bugs. Unfortunately there are a lot C-suite people who would rather have captive users locked into a buggy app everyone hates that constantly acts like it's shipping helpful stuff than an app people want to use.

Does it? It did in the past. Now it doesn't. Maybe "add a button to display a colour selector" really is the canonical way to code that feature, and the 100+ lines of generated code are just a machine language artifact like binary.

> But it robs me of the part that’s best for the soul. Figuring out how this works for me, finding the clever fix or conversion and getting it working. My job went from connecting these two things being the hard and reward part, to just mopping up how poorly they’ve been connected.

Skill issue. Two nights ago, I used Claude to write an iOS app to convert Live Photos into gifs. No other app does it well. I'm going to publish it as my first app. I wouldn't have bothered to do it without AI, and my soul feels a lot better with it.

That’s only half of the transition.

The other half - and when you know you’ve made it through the “AI sux” phase - is when you learn to automate the mopping up. Give the agent the info it needs to know if it did good work - and if it didn’t do good work, give it information so it knows what to fix. Trust that it wants to fix those things. Automate how that info is provided (using code!) and suddenly you are out of the loop. The amount of code needed is surprisingly small and your agent can write it! Hook a few hundred lines of script up to your harness at key moments, and you will never see dumb AI mistakes again (because it fixed them before presenting the work to you, because your script told it about the mistakes while you were off doing something else)

Think of it like linting but far more advanced - your script can walk the code AST and assess anything, or use regex - your agent will make that call when you ask for the script. If the script has an exit code of 2, stderr is shown to the agent! So you (via your script) can print to stderr what the agent did wrong - what line, what file, wha mistake.

It’s what I do every day and it works (200k LOC codebase, 99.5% AI-coded) - there’s info and ideas here: https://codeleash.dev/docs/code-quality-checks

This is just another technique to engineer quality outcomes; you’re just working from a different starting point.

The risk isn't randomness per se it's over trusting something that looks correct. The skill ceiling is moving from "can you write it" to "can you reliably verify it"

Good programmers might have made things that “performed well”, and had “few bugs”, without this step, but it was not robust to changes over time. If we end up in a place where every project has solid automated verification, perhaps things get better overall.

AI has removed some of the tedium, and freed up more of my bandwidth to think about the problems I’m trying to solve and what the actual best ways to solve those problems are.

Only once I have a good feel for the problem I am solving do I go to the AI for help implementing.

My style of prompting usually leads to code that is very close to what I would have manually typed. I review it and tweak it until it is effectively identical to what I would have typed.

The speed up is significant. YMMV.

I am not going to say what it is because all of the AI haters will immediately flock to leave it bad reviews and overwhelm my support systems with bad faith requests (something that has already happened).

I've been writing software for 25 years, I know what I am doing. Every bug I shipped was my fault either because I didn't test well enough or I did not possess enough platform knowledge to know myself the right way to do things. "Unknown unknowns"

But I have also learned better ways to do things and fixed every bug using AI tools. I don't read the code. I may scan it to gain context and then tweak a single value myself, but beyond that I don't write or read code anymore.

Its not a magical few shot prompt then reap profits machine. I just feel like a solopreneur ditch digger who just got a lease on a new CAT excavator. I can get work done faster I can also do damage faster if I am not careful.

Beyond this concern,

Will Digbert be able to handle it or will he pretend to handle it? Or will he handle it in a way that it will break again in six weeks and will evolve into his full time job for a year?

If this is gambling, middle management has been gambling for too long.

I'm not arguing against accountability, only against gambling.

I suppose what's happening with software development is we're exploring where the line between the two is going to land. It's pretty clear that something like a simple and generic website can be reliably vibecoded, but on the other extreme I wouldn't expect the software for something like a space shuttle to be vibe coded due to the stringent safety requirements.

For any one hand you may win or lose, but on average you should still take the "gamble" every time, because the odds are so good you'll win. That's what using AI is like right now.

This is a new state of things - a year ago, the analogy would have been reversed.

But you can't survive alone on an island. So you need to determine where to make gambles and where not.