Writing Is Closer to Thought Than Code

I'd rather have a car built by people who made sure the code was highest priority and the code driving the assembly line robots was up to spec, versus having a car built by people who made sure the spec was highest priority, and the code driving the assembly line was not.

That's what code does.

I think he really wants to be having a debate about whether we ought to be using different coding languages, more based on natural languages, more declarative.

I think the law provides an interesting perspective. It has a technical, formalized language, built out of a natural language. Since laws and contracts can be very high-stakes, the technical/formalized aspects arose out of a need to express hard constraints using a language whose complexities seem to be built more for story-telling.

Nobody gets paid for "intent". You get paid for the result. I do not buy a video game that "intended to be good" and "had a great specification". It feels so weird that I tough that it was parody.

Next ... the bridge collapsed but that is beyond the point. Look at the specifications!

That's the bottom of the problem. You can think all you want in your spec doc, you won't fully solve all the problems that you will face during implementation.

That's why ports are easy with LLMs, cause the code implicitly carries all the spec.

Sure, there may be a gap between the code and the idea behind the spec, but it can be argued that the gap between the spec as a document and the idea behind the spec is just as wide, and in fact doesn't take into account the constraint of reality.

LLMs generally suck at taking the initiative. Tell it to build a report, it's going to do it, but then you'll have to iterate a lot to make sure it's producing it the exact way you want it.

>Say you want to draw a perfect picture of an owl. You have this beautiful image of it in your mind. But you can’t draw very well, and in this analogy the drawing is the code. So what comes out is a stick-figure owl that’s barely recognizable as an owl.

>In the code-is-the-source-of-truth version, that stick figure is now the authoritative artifact. We analyze it, document it, take notes on its proportions, and spend a whole bunch of time iterating on it. We’re running in circles around a bad drawing.

My only disagreement with the post is over whether articulating is is the main bottleneck. Right now, there are still issues and oversights humans would tend not to make even if you have model context and documentation accurately and clearly capturing your full intent.

Each year will decrease the rate of this, but software engineering will probably need until maybe 2030 until we've crossed a threshold towards solely being product managers/designers. This advice still applies today, but you do need more wrangling on top.

I have found that databases are the exception where documentation is critical, in that knowledge of what we do to the data (described in program logic) is completely different from knowledge of what the data means. Reverse-engineering that meaning often takes me longer than anything else.

Beyond that, however, English is a horribly ambiguous, contradictory and complicated programming language. It's a literal anarchy. Had it not been for primitive 1950's hardware, I suspect people would have refused to invent programming languages and insisted on AI-processed English anyhow. For now I guess we'll work as computational attorneys...

[1] - https://users.cs.utah.edu/~elb/folklore/mel.html

The brain being full of thoughts, will, sensors, and tension of conflicting values must translate from gray space to meat space to someone else's gray space.

Of course what is articulation but expression of the above into a medium that results in the reality being made manifest.

It was at the Tower of Babel where intent was disrupted by requiring chained levels of translation. From Brain to Speech or Writing to another's language through the filters of culture and nations, the ability to communicate was disrupted.

Code just happens to be one additional layer of translation.

Now, the bottleneck is no longer the code. We spend that time thinking about the solution, how to deliver value, and how to plan for it.

I notice this most during team working sessions. Previously, there was always a moment when someone would say, "Hold on, let me note this down" and either the conversation went on without them and they lost the thread, or everyone else had to wait. Now, those sessions are just about discussion and exploration: the AI takes the notes, better than any of us. You can focus on thinking.

The only way you are getting close to expressing firstness is through high speed, unedited word association poetry.

Humans don't really have introspection, we don't have access to what's going on in every subsystem, we don't even have control, otherwise we could think ourselves to death ala breaking emacs with the right line of lisp.

The idea that the thought or intent in your brain survives semantic translation is... well, it can only kinda happen. It can be a target but thinking it's possible in an absolute sense is the old map/terrain mistake.

I think fast iteration with image mocks and wire frame mocks is sufficient, understanding the process of rapid testing with isolated toys before locking in design is the best we can get.

Used in casual rebuttal when anyone in the group declares they want to write or become a writer, whether it be prose, music, code or even extrapolated to art.

I don't think any one form is close to my thought and I can definitely say diagrams and code often sit closer to how I think about systems than language.

I also think articulation is also a separate skill. I've met brilliant people that weren't great writers but that doesn't stop them from designing and understanding or building complex things with great accuracy

Certainly natural language prose can articulate human-level concepts and priorities that code cannot. The fact that LLMs can interpret and apply these things is novel and useful. I agree with the author there is a lot of juice that can be squeezed out of this.

But on the other hand, whenever I start writing code (with or without LLM assistance), there is always a huge amount of learning and iteration that happens. No matter how thoroughly I thought through everything, or how perfect the idea seemed in my head, it always evolved once the implementation was concrete. And furthermore, once you have code running and people depend on it, the code is the reality, and any other documentation or vision statements have a tendency to go stale. Obviously AI makes it easier to keep documentation up-to-date, but the disconnect between the idea of the system and what the system actually does remains.

For this reason I don't see any huge value in deliberately moving to a higher layer. All the same modalities can still be applied with AI: comments, commit messages, PR messages, literate programming, READMEs, AGENT.mds, tech specs, tech 1-pagers, vision statements, etc. I write a doc when it's useful to communicate to one or more parties, otherwise I try to keep everything as minimal and possible, often that means just live in the code.

War is peace, freedom is slavery, I know better than Djikstra.

Here is another take: Speaking is closer to thought that writing! Can I write a blog post now?