A brief prompt:
In authheader.go write a function to parse a SIP WWW-Authenticate header for Digest authentication. It should return a map[string]string of key:value pairs which are present. It should handle the case of valueless parameter with no "=" by populating an empty string in the map. Write unit tests, including these WWW-Authenticate headers: 1. WWW-Authenticate: Digest algorithm=MD5,realm="example.com",nonce="abcd=" 2. WWW-Authenticate: Digest realm="example.com", nonce="efgh=", opaque="1234__", algorithm=MD5, qop="auth"

From this, Claude Code generated quite reasonable parsing code for a SIP WWW-Authenticate header. It did this in approximately one minute of wall-clock time at a cost of 19 cents. This is considerably more quickly and cheaply than I could have produced a similar function.
I made one manual fix: the string comparison for "Digest" and for parameter field names are supposed to be be case-insensitive, and I added unit tests for it. I hadn't specified this in the prompt, and Claude Code didn't figure that out from the mention of SIP.
I remain of the opinion that vibe coding can be a force multiplier for expertise, not a complete replacement for expertise.
Wisdom
Returning to an earlier topic: does the code which Claude Code generated exhibit wisdom? Did it have shortcomings which would be harmful? Claude Code came up with the following test cases, and wrote a Go table-driven test case for them.
- The two I explicitly gave it.
- Header with valueless parameter
- Header with unquoted values
- Empty header
- Header with comma in quoted value
- Header with extra spaces
I looked into the handling of unquoted values. The SIP standard says that fields like algorithm or qop which are enumerated in specifications can be left unquoted. What Claude Code generated would allow any field to be unquoted, including arbitrary text strings like realm.
The spec says these values must be quoted. Yet there is also the Robustness Principle, to be liberal in what you accept and strict in what you send.
Postel's Law Considered Harmful
Nowadays I think this principle has ultimately been more harmful than good. Over time we end up with a protocol which is only partially specified, where real implementations require a neverending series of quirks handling to work around the behaviors of widely deployed yet incorrect implementations which other implementations have liberally accepted. For new protocols I'm a fan of be strict in what you send and strict in what you accept, to not allow quirks to accumulate. Like barnacles, quirks slow the forward progress over time and tend to cause standrds to bog down and eventually stop even trying to evolve.
But SIP is ancient. In Internet Years it is a centennarian. What should one do about SIP? Being strict in what one accepts would lead to a series of relaxations being added during deployment when engineering philosophy meets harsh reality that there are a lot of barely-compliant production services run by vendors far too large to care what some Internet Rando thinks of their implementation.
I left the test cases and the handling of unquoted strings, for all fields. Life is too short to fight the weight of Internet Protocol Inertia.