Programming in Human | SkillCanvas

1959: COBOL. “English-like programming so managers can read it.”

1987: HyperTalk. “Authors, not programmers.”

1993: AppleScript. “Just write what you mean.”

All failures.

Not because the vision was wrong. Because the implementation was impossible. You can’t make a syntax parser understand intent.

Why Everything Before Failed

Every “natural language” programming attempt made the same mistake: they created English-looking syntax that still required exact phrasing.

AppleScript is the perfect cautionary tale. You could write tell application "Finder" to delete file "test.txt". Looks like English. Feels like English. But change one word — “remove” instead of “delete” — and it breaks.

“It gives one the sense that one just knows AppleScript because one knows English, but that is not so.”

The problem: these systems parsed your words. They matched patterns. One wrong word, one missing comma, one slightly-off phrasing — rejection.

SQL was supposed to let business users write queries. “Structured English Query Language.” In practice: “Most non-IT users can only write very simple queries.”

The true advantage of natural language is ambiguity. You can say things imprecisely and be understood. Traditional programming — even “English-like” programming — doesn’t support this. One error crashes everything.

Why Skills Are Different

Skills don’t parse syntax. Claude reads your instructions and understands what you mean.

Write this:

## Stage 1: Describe characters
First, create detailed descriptions of all characters...

Or this:

## paso uno - personajes
describe quiénes son, cómo se ven, su personalidad etc

Both work. Same result. Claude understands that these are the same instruction.

Typos work. Mixed languages work. Informal phrasing works. “Use that popular HTTP library” works even if you forgot the name.

This isn’t parsing. This is comprehension.

What This Actually Means

You write instructions like you’d brief a colleague. Not “execute function X with parameters Y and Z.” Just “analyze this code and find security issues.”

No need to handle edge cases in your instructions. Claude notices them. “I changed the header, but there was a typo — fixed that too. Should I have left it?”

No need to specify error handling. Something fails, Claude tries another approach.

No need to structure data between stages. Claude maintains context. What Stage 1 produces, Stage 2 can reference naturally.

The friction disappears. The gap between “I know what I want” and “I can make it happen” closes.

The Irony

Dijkstra argued against natural language programming in 1978. His point: formal notation exists for precision. English is ambiguous. Ambiguity is bad for programs.

He was right — for programs that execute literally.

He didn’t anticipate a system that interprets intent. Where ambiguity becomes a feature, not a bug. Where “figure it out” is a valid instruction.

Skills are not programs in the traditional sense. They’re briefs. You describe the outcome. Claude handles the implementation.

The Limit

This works until it doesn’t.

Small skills — 50 lines — are pure magic. You write, it works.

Large skills — 500 lines, multiple stages — become black boxes. The natural language that made creation easy makes debugging hard. You can’t grep for where “describe characters” connects to “generate images.” There’s no explicit data flow. It’s all in Claude’s interpretation.

The same flexibility that lets you write imprecisely makes it hard to trace why something broke.

Jake’s visual novels render with characters changing hairstyles. Which stage caused it? The instructions don’t say. Claude figured out the connections. Now Jake has to figure out Claude.

Programming in human finally works. But reading your own code back? That’s a different problem.