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.
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.
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.
[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!"
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.
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 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?