Hacker News new | ask | show | jobs
by supermdguy 20 days ago
“Do you know what the industry term for a project specification that is comprehensive and precise enough to generate a program?

Code. It’s called code.”

- CommitStrip (https://www.reddit.com/r/ProgrammerHumor/comments/1p70bk8/sp...)

I think if you’re doing it right, the core of your code should be the simplest expression of the underlying business logic. Of course there’s always going to be supporting layers, and maybe those don’t need to be reviewed. But if you haven’t read the code, there’s an extent to which you don’t know the business logic.

3 comments

My other article on this topic advocates for using code over specs :)

It’s ok to talk to the agent in code. Or create examples for it to follow.

https://softwaredoug.com/blog/2026/07/04/write-code-not-spec...

> It’s ok to talk to the agent in code. Or create examples for it to follow

If you're doing this, then why not just write the effing code?

"Hey Claude, can you please make a full matrix of tests according to the following pattern and parameters? Thanks." That's 15-20 minutes of work that can run in the background while I do something else.
Exactly this. Spending a few hours crafting and debugging a test you trust save hours of pointless agent time.
What I mean by "talk to the agent in code" really is to code. Establish patterns. Then have the agent use those patterns as reference for other areas of the project.
What I miss in Claude Code is code completion at prompt line.. ah wait it gets back to IDE and Copilot.
> My other article on this topic advocates for using code over specs :)

Code is executable. Specs are not.

Prompt is executable (interpreted) code with LLM agent harnes now, just the syntax is fuzzy.

"Please print 'hello world'"

This is why you need lisp.

First you write a programming language in which the language primatives are the business logic primatives, then you write a trivial program that describes what the business does in the new language.