Test suites don't verify correctness. They just ensure that you haven't broke something so bad the specific instances that the tests assert have turned into a failure. You can have a factorial function and more likely the test cases will only be a few numbers. Which does not guarantee correctness as someone who know about the test cases can just put a switch and return the correct response for those specific cases.
The compromise is worth it in traditional coding, because someone will care about the implementation. The test cases are more like the canary in the coal mine. A failure warrants investigations but an all green is not a guarantee of success.
Deciding between 1000 different versions is a lot of effort IMO. With manual coding, you’re mostly deciding one decision point at a time, which is easier when you think about it. It just require foresight which comes from experience
IMO, plan mode is pretty useless. For bug fixes and small improvements, I already know where to edit (and can do it quickly with vim-fu).
For new features, I spend a bit of time thinking, and I can usually break it down in smaller tasks that are easy to code and verify. No need to wrangle with Plan mode and a big markdown file.
I can usually get things one-shotted by that point if I bother with the agent.
That’s like saying enjoying composing music, but not enjoying playing music. Or creating stories, but don’t like writing. Yes they’re different activities, but linked together. The former is creativity, the latter is a medium of transmission.
Code is notation, just like music sheets, or food recipes. If your interaction with anyone else is with the end result only (the software), the. The code does not matter. But for collaboration, it does. When it’s badly written, that just increase everyone burden.
It’s like forcing everyone to learn a symphony with the record instead of the sheets. And often a badly recorded version.
> That’s like saying enjoying composing music, but not enjoying playing music
Do you think that is impossible? There are plenty of people who enjoy composing music on things like trackers, with no intent of ever playing said music on an instrument.
I love coding, but I also like making things, and the two are in conflict: When I write code for the sake of writing code, I am meticulous and look for perfection. When I make things, I want to move as fast as possible, because it is the end-product that matters.
There is also a hidden presumption in what you've written that 1) the code will be badly written. Sometimes it is, but that is the case for people to, but often it is better than what I would produce (say, when needing to produce something in a language I'm not familiar enough with), 2) and that the collaboration will be with people manually working on the code. That is increasingly often not true.
I struggle to understand that comparison. Code is notation, you can’t write code for the sake of writing code. You have a problem and you instruct the computer how to do it. And for the sake of your collaborator and your futher self, you take care of how you write that. There’s no real distinction IMO.
> There is also a hidden presumption in what you've written that 1) the code will be badly written
The computers does not really care about what programming language you’re using and the name of your variables and other indentifiers. People do. You can have correct code (decompiled assembly or minified JavaScript) and no one will wants to collaborate on that.
Code is often the most precise explanation of some process. By being formal, it’s a truthful representation of the process. Specs and documentations can describe truth, but they do not embody it.
You can always collaborate with markdown files. But eventually someone will have to look at the code and understand what it does, because that’s the truth that matters. Anything else is prayers and hope. And if you’ve never cared about maintainability and quality of the code, it will probably be an arduous process.
> Code is notation, you can’t write code for the sake of writing code.
Of course you can.
> You have a problem and you instruct the computer how to do it.
And sometimes that problem is not the point. Just like sometimes I write for the joy of writing, not because I particularly care about a reader or the meaning of the output.
> The computers does not really care about what programming language you’re using and the name of your variables and other indentifiers. People do. You can have correct code (decompiled assembly or minified JavaScript) and no one will wants to collaborate on that.
This has no relation whatsoever to the sentence you quoted.
Using your analogy, I enjoy composing music and enjoy playing music. I don't enjoy going through the notion of writing the notes on a piece of paper with the pen. I have to do it because people can't read my mind, but if they could I would avoid it. Claude code is like that. The code that gets written, feels like the code that I would have written
Cool. And GNU "info" is a hyperlinked doc viewer system. Some GNU and other projects promote info doc as more authoritative than man pages. Man pages are expanded cheat sheets.
For in-depth doc, I do appreciate docset-based indexed search apps like Dash that can download and update comprehensive doc locally with greater performance and less internet dependency than internet only. There's even vim and nvim plugins to bring that to them too without leaving the terminal.
Unless it’s required (Starlink) or something I check often (not much this day), I don’t use the app version. I prefer grabbing my laptop and use the web version. But best is when there’s an API available so I can write my own tools.
Most people that don't know how to program have no real desire in coding with AI (unless to pose as a SWE and get that sweet money). Most of them don't even like computers. Yes they do some tasks on it, but they're not that attached to the tool and its capabilities.
- A lot of research. Libraries documentation, best practice, sample solutions, code history,... That could be easily 60% of the time. Even when you're familiar with the project, you're always checking other parts of the codebase and your notes.
- Communication. Most projects involve a team and there's a dependency graph between your work. There may be also a project manager dictating things and support that wants your input on some cases.
- Thinking. Code is just the written version of a solution. The latter needs to exists first. So you spend a lot of time wrangling with the problem and trying to balance tradeoffs. It also involves a lot of the other points.
Coding is a breeze compared to the others. And if you have setup a good environment, it's even enjoyable.
That's very much an echo chamber you find yourself in. I'm far away from any technological center and the main use of LLM for people is the web search widget, spell checking and generating letters. Also kids cheating on their homework.
The compromise is worth it in traditional coding, because someone will care about the implementation. The test cases are more like the canary in the coal mine. A failure warrants investigations but an all green is not a guarantee of success.
reply