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 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 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.
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".
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
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?
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?
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.
But that's not programming because its a natural-language conversation?
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.
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.
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
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"....
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.
> 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.
Also, our profession is doomed if we won’t give less experienced colleagues a chance to shine.
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.
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?
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.
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...
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.
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.
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.
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.
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 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.
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.