Vibe Coding Format Strings 2

After Claude wrote the design goals and road map, I considered the initial changes carefully. Claude started with my existing repo and tests, and I told it it could nuke everything and start fresh. It did besides taking a bit of my terminology and core algorithmic techniques. For example, I referred to the curly-bracket placeholder syntax as "holes" and Claude mostly kept that naming convention.

Claude did more abstraction work than me because his plans were more ambitious. I asked Claude what it liked and didn't like about the original code. It liked my coding style and test coverage, but thought I should be supporting more features. For example, my original code didn't support width and alignment specifiers. Claude got to work.

I watched Claude closely at first. I made sure it followed a tight iteration loop. Every new feature needed to compile without warnings and introduce corresponding tests. One funny thing I noticed was how at first Claude attempted to overload the name Format through many instantiations of generic format functions, but the compiler can't handle that for some reason. But Claude was successful in undoing this design mistake without much help. At this point I felt comfortable to auto allow all edits and git commits.

Claude kept an appropriate iteration loop going. There was a bit of struggle with formatting. Claude had a tendency to leave trailing spaces in files and end files without newlines. I'm not sure why the former happens but I know the latter is probably due to some aggressive string trimming in the Claude package. Both of these things lead to many style errors on every compilation. Formatting was greatly improved when I pointed Claude to a gnat format binary to auto format the codebase. It took a few attempts to figure out the tool use, but it mostly got there.

After about 3 hours and $70 spent, I was closing in on more credits than I wanted to spend so I asked Claude to stop new development to polish and prepare for publishing. Claude was able to achieve most of its five phase development plan.

It is too early to make a definitive pronouncement on how I feel about the library yet, but my initial impression is positive. All the expected uses have good test coverage. I have done `alr publish` and am waiting for the review to go through at this point.

One thing I am disappointed about is Claude was not able to find a good solution to the fundamental constraints of Ada's type system making formatting hard. A truly general system has to support arbitrary types and arity and the only ways to do this in a type-safe manner is to provide a function for every combination of arity and types and give an extension mechanism for the user to define formatters for their own types.

Claude ended up settling for a Format_X, Format_XX, Format_XXX, … naming convention where Xs represent the combination of types. There should be a way to use the name Format for all combinations and let overloading handle the ambiguity, but I think this would require making a type declaration for every combination with a corresponding definition that does a private instantiation of the generic Format/N function and returns that.

I'm not too disappointed because I wasn't sure how to solve this problem either.

Another thing I noticed was how Claude began taking co-authorship credit in commit messages. I had no problem letting that stay, but it was annoying it also included a self-promotional link for others to download Claude Code.

Either way, I found the tool and basic experience of using it very promising and hopeful for the future.