I write code to solve a problem. Not code that looks like it solves the problem if a non-technical client squints at it.
And if you don't prove your code, do you not design at all then? Do you never draw state diagrams?
Every design is an informal proof of the solution. Rarely I write formal proofs. Most of the time I write down enough for myself to be convinced that the desing solves the problem.
You are correct. However, humans sometimes do write stuff that "looks like it solves the problem". A prime example of this is a student who doesn't know how to answer a question. So they make up a plausible sounding answer.
As a exam grader, you can easily tell when a student has the mindset of "solving a problem" but made a mistake, and when they had the mindset of "looks like it solves the problem" and just wrote some stuff.
Yes, you can dedicate extra tokens to draw state diagrams, the LLM can actually do that, if you don't have it generating one or more design documents before you are writing code you are doing that wrong. I still don't get how that is different from what humans are doing.
> Most of the time I write down enough for myself to be convinced that the desing solves the problem.
Again, why do you assume we aren't doing the same thing with LLMs?
1. Spec given
2. Ask LLM to write a bunch of design documents based off of spec
3. Ask LLM to identify edge cases
4. Ask LLM to device edge cases in to a test plan involving N tests
5. Ask LLM to write tests
6. Ask LLM to write commented code
7. Ask LLM to run tests on code, and determine on failing tests if test or code is wrong, go back to the appropriate step to fix test and/or code.
Whenever I hear someone here on HN imply that the only way to code with an AI is via vibe coding I just die a bit more inside.