Coding is like taking a lump of clay and slowly working it into the thing you want it to become. It is this process, and your intimacy with the medium and the materials you’re shaping, that teaches you about what you’re making – its qualities, tolerances, and limits – even as you make it. You know the least about what you’re making the moment before you actually start making it. That’s when you think you know what you want to make. The process, which is an iterative one, is what leads you towards understanding what you actually want to make, whether you were aware of it or not at the beginning. Design is not merely about solving problems; it’s about discovering what the right problem to solve is and then solving it. Too often we fail not because we didn’t solve a problem well but because we solved the wrong problem.
When you skip the process of creation you trade the thing you could have learned to make for the simulacrum of the thing you thought you wanted to make. Being handed a baked and glazed artefact that approximates what you thought you wanted to make removes the very human element of discovery and learning that’s at the heart of any authentic practice of creation. Where you know everything about the thing you shaped into being from when it was just a lump of clay, you know nothing about the image of the thing you received for your penny from the vending machine.
Very well said.
@aral so true, and not only for code.
singed
i use AI mostly when i can't get my head around something (or there's something missing but i don't know what), which happens like every 2 months or so
several times when i used the AI for asisstance, it threw out some 50 lines of code but there was 1 line which helped me getting past my coding block
@aral Writing music feels much the same way. If I've ever thought I knew exactly what I wanted and stuck doggedly to the vision, the final product was always the worse for it. Follow the muse where it leads you!
@aral and following with your last metaphor, with the vending machine, at least, you know what you got is edible
@flooper Have you actually ever eaten vending machine food? I’d say “edible” is a stretch :) Perhaps “not immediately ruinous.”
@aral But so many times you just want a library to do some specific thing, you don’t care a lot about its implementation, so you add it to your project without looking at the code. Maybe you heard it’s good, you have a look at the download count or the commit history to see if it’s actively maintained, but in the end it’s not critical and it could be replaced without much consideration. In the same way AI-generated code is useful in similar cases.
@alfonsomunozpomer Any library worth adding to your project is written by people who have spent extensive time and effort in the problem domain. It has vigorous tests and is actively maintained. None of that is true for AI-generated code which is more akin to adding the first Node module that comes up in a npm search and hoping for the best. In fact, no, you’d likely still get higher quality code that way due to npm’s default algorithm surfacing higher quality libraries.
@aral I’ve had Copilot write tests for me; other times I wrote the tests myself and have had Copilot write the implementation. I always read and review what it writes. Just yesterday it saved me time by rewriting some documentation, and pasted some DDL and ask it to write a few SQL queries. Granted that none of that is “vibe coding”, but I think AI assistants can be used judiciously and they can be helpful.
@aral Programming is definitely a creative process.
When I do code reviews, I keep my eye out for bits that don't look aesthetically pleasing. This is usually where the bugs lurk.
@gunchleoc @aral Then you would love vibe coding as it just like doing code reviews.
@Kiteros @aral No thank you. I have to do too much of that in my translation job already and that type of correct-looking-but-not-quite-right text is very hard to correct. Machine Translation post-editing jobs are the worst.
Human mistakes have a completely different quality to AI mistakes and are a lot less stressful to deal with.
Also, code reviews are not just about code quality - they are also about mutual learning, thus improving *future* code quality too.
@gunchleoc @aral Yeah, they learn from corrections in coding.
@aral thanks for writing this.
@aral This is true no matter what you are working with, be it clay, wood, fiberglas or metal.
@aral Love it!
I've never had this more then with (indie) gamedev! Often start out with an idea but at the end there often not much left of the original idea and has improved so much
Besides, the process is the part where it all comes together but also where one learns the most I think, the part of discovering more or alternative options to one's design for example
If you skip right to the end you'll never walk that road and miss out on a lot, prob the most
@aral This is breaking down, though. The last decade I've noticed developers are less and less interested in understanding their code and working on it. They want to just get something that passes tests and move on to the next thing, and if it breaks in production they'll put that in the queue to fix.
@tknarr What a horrible existence.
@aral Exactly. Even if some hypothetical fancy computer program could generate actual good and working code - I'd still write code myself.
@aral I’ve been using claude.ai to do basic web development - a thing I’m not very good at. I do get a wall of code, but I know enough about how code generally works and where the the functionality I want is located that I can trim out the pieces I don’t want and modify the pieces I do want to get the final result.
I think a good art analogy is sculpting, where rather than mould the medium, you take away from the medium. Either way, you still need to understand and practice.
@nisha Not sure the sculpting analogy holds. Michelangelo didn’t start with Peter and remove the bits he didn’t like to arrive at David; he started with a block of marble.
(And his chisel didn’t require new fossil fuel power plants and data centres that contaminate fresh water at a time when humanity faces an existential threat of its own making to its own habitat.)
@aral spare a thought for where the clay and marble comes from and who’s mining it.
And I’m pretty sure neither of us are art experts to make an air tight analogy for art and coding.
Let’s instead argue about how much resources are spent making a “somewhat deterministic” code generator and whether all the other “features” are worth it.
One of the things you learn in many art classes as an adult is that the product is much less important than the process. Take pleasure in the process, and the outcome will take care of itself.
The artists I know draw and paint and sculpt (and since I know techie artists) “make” for the sheer pleasure of it.
Having said that, having programmed for fifty years, there’s a lot of boilerplate involved in programming. AI tools help one turn a human-language description of a problem and potential solutions into a partial solution in a matter of minutes.
One might ask: why is there so much boilerplate? Maybe our programming systems should seek to eliminate boilerplate by being more expressive?
To that, I agree. But one of the ways of being more expressive is using an expressive language to describe problems and possible solutions — and what is a coding-specific LLM if not that?
Of course, one can write buggy code in any language. The LLM does not free you from that, so walk through the output carefully, suggesting changes, asking for reasons of particular constructions. The LLM is also a pattern completer, so it will insert unnecessary, but frequently used things. The LLM has limited attention, so it may lose track of the project goal when down in the weeds.