User:Gavinandresen/Blog/2026-01-14 Claude Code

Claude Code

All the cool kids are using Claude Code these days, so I decided to jump in and try it.

It's very good, both for coding and creating new RiskiPedia pages!

Coding

It wrote all of the code for a new, RiskiPedia-specific <riskgraph> feature, using a test-driven-development approach. It didn't get everything right the first time, and I had to give it a lot of direction for how, exactly, riskgraph should work. But it saved me a lot of time-- I didn't have to spend hours figuring out how to make Chart.js (the javascript library that actually draws the graphs) do what I wanted it to do. The AI super-power is the extremely wide knowledge base in it's learning data set.

Creating RiskiPedia Pages

That super-power means it is pretty darn good at creating new RiskiPedia pages. I told it to fetch the Help:AIPrompt page for context-- I didn't spoon-feed it a piece at a time like I did for other AIs (Grok, Gemini, ChatGPT). It is much better at creating valid wikitext the first time, and much better at creating valid references to data or studies.

Still, creating the Concert Hearing Loss page took a few hours of my time. Much of that time was spent waiting for Claude. That will get better-- AI hardware and software will just get faster and faster over time.

I spent a lot of time interacting with the pages claude produced, and thinking about how to present the numbers it the most intuitive way possible. I didn't get it 100% right; there are certainly better ways to present the risks, maybe using a graph. Maybe my next session with claude I'll ask it to come up with a few different approaches I can try and see what feels right.

The pages could certainly look prettier; I'm terrible at graphic design, and I don't think claude would be much better. Or, at least, I don't think I know enough to to keep claude from creating a nightmarish 11-megabyte .css file to make the sliders a little prettier.

Gory details for geeks

I've got a development environment set up on my laptop, with a copy of the RiskiPedia database and and code so I can make changes to the code or pages before uploading them to the riski.wiki server.

I asked Claude for advice on using it for both coding and creating wiki pages, and it suggested separate CLAUDE.md files (the file that claude reads on startup to give it instructions it should remember between sessions) in separate directories for working on code versus working on content.

The content/CLAUDE.md file was created by feeding claude the documentation for all the RiskiPedia extensions and the Help:AIPrompt file, and asking it to create it.

Conversation

Once that prep work was done, here's how the conversation went:

Me: Let's talk about creating a riskipedia page on the risks of hearing loss from attending loud concerts. Is there good data available that will let us quantify the risks, given some input about user behavior (like what kind of music, how often concerts are attended over how many years, etc)

Claude: ... lots of web searching... and results, ending with: The biggest challenge is that the dose-response relationship for intermittent recreational exposure (like occasional concerts) isn't as well-characterized as occupational exposure. The NIOSH data is based on daily 8-hour workday exposure over 40 years. We'd need to make some assumptions about how intermittent high-intensity exposure translates to cumulative risk. Would you like me to proceed with creating a page? I'd recommend being transparent about the uncertainty and framing results as "your exposure exceeds safe limits by X%" rather than claiming precise probability of hearing loss.

Me: Let's handle the uncertainty a different way-- let's have the riskmodel calculate a range of reasonable estimates, and give the reader an absolute range, along with the baseline-- something like "about 1 in 10 people experience permanent hearing loss by the time they're 60 years old. If you attend 10 heavy-metal concerts per year for ten years without hearing protection, the risk for you goes up to somewhere between 1 in 2 and 1 in 5 chance of having permanent hearing loss."

Claude: That's a much better approach - honest about uncertainty while still being informative. Let me find baseline hearing loss prevalence data by age to anchor the comparisons. ... more searching and a proposal for what inputs to ask readers...

Me: I don't think asking current age is the right way to go. I think people will be interested in: 1) if they've been going to concerts for years with no ill-effects, are they at increased risk of hearing loss when they're older? 2) If they change their concert-going behaviour going forward, how much will they increase/decrease their risk of hearing loss?

Claude then created an initial version of the page and saved it to a file on my laptop. I asked it:

Me: Create the page using the mediawiki api or command-line maintenance.php

... and after trying and failing a couple of ways, eventually did get the page into my localhost:8080/ development wiki where I could try it out. Impressively, it worked the first time!

Me: It looks pretty good; let's sanity check. If I select 12 Pop/Hip-Hop concerts over 5 years in the past, No protection, and 20 more years of wearing musicians earplugs I see: ...

Then claude sanity-checked both the math and checked against the research data. At least, it claimed it checked against the research data...

Claude: Potential concern: The range "1 in 2 to 1 in 6" is quite wide. But given the uncertainty in: - Actual dB levels at concerts (varies by venue, position) - Individual susceptibility (10x variation) - Recovery between exposures ...the wide range seems appropriate. Do you want me to narrow it, or add text explaining why the range is wide?

Me: The wide ranges are fine as-is. But I see a UI issue: if I set How many more years to 0, the text is: If you continue for 0 more years: Your lifetime risk of noticeable hearing loss rises to between about 1 in 2 and about 1 in 6. ... which is not a rise at all. There should be some logic around that result

Claude: Good catch. Let me fix that with conditional logic.

Me: That's better, but I'm still seeing things like this: Your accumulated exposure so far: 10 years of attending ~5 Pop / Hip-hop concerts per year has likely increased your risk to somewhere between about 1 in 2 and about 1 in 6. If you continue for 2 more years: Your lifetime risk of noticeable hearing loss rises to between about 1 in 2 and about 1 in 6. ... which, again, is not a rise

Claude: You're right - the 5% threshold is too small because the One_In_X template rounds to nice numbers, hiding small differences. Let me increase the threshold so "rises to" only appears when there's a visible change.

Me: The page is empty now, try writing it again

Claude: Page is back (11,610 bytes). Let me verify the content is rendering.

I have no idea what caused the blank page, but claude did fix it. I did more testing, and then told it to use a more robust approach for the UI-- I could tell it was getting into an unproductive AI loop where it thinks it knows how to fix something ("if it's within 20%...") and then tries to fix the fix by adding more complication ("if it's less then eleven and within 20%... else ..."):

Me: Use better logic for the "remains about the same case" : Have the RiskModel use {{One_In_X}} to round the risk_low and risk_high variables, and use {{#if ({current_risk_low} = {projected_risk_low}) and ({current_risk_high} = {projected_risk_high}) ... }} instead of using a 20% threshold.

Claude: Good idea - comparing the actual displayed values is more reliable. Let me update the model to calculate the "1 in X" values and compare them directly.

Me: Why are you using round 0 instead of {{One_In_X}} for data-current_x_low ?

Claude: You're right - round 0 won't match the rounding logic in {{One_In_X}}. I should use {{One_In_X}} directly to get the display values, then compare those strings with #ifeq.

Maybe AI next year will be better at figuring stuff like this out on it's own?

Me: That works correctly now. A couple of minor edits: Remove Template:Short description from the top (there is no short description template). And add the no-table-of-contents wikitext thingie so there is no Contents [show] box.

Claude: Done. Removed the short description template and added to hide the table of contents.

Me: Let's create a template called RiskRange that makes the ranges given more intuitive. It is confusing to see risk estimates with different denonimators ("between 6 in 10 and 1 in 5"). To start, read the source for the One In X template: http://localhost:8080/index.php?title=Template:One_In_X&action=raw And the ProbabilityFormat module: http://localhost:8080/index.php?title=Module:ProbabilityFormat&action=raw and ask me if you have any questions

Claude came back with:

 Questions before I build RiskRange:
 1. What format do you prefer for ranges? Options:
   - Always use a common denominator: "between 6 in 10 and 2 in 10"
   - Always use percentages: "between 60% and 20%"
   - Use "1 in X" for both when possible: "between 1 in 2 and 1 in 5"
   - Something else?
 2. Should the template take two probabilities as input? Like {{RiskRange|0.6|0.2}} → "between 1 in 2 and 1 in 5"
 3. Should it always put the higher risk first? (Currently your display shows high estimate first, which seems intentional)

Me: Use a common denominator always-- e.g. if it is between 1 in 100 and 1 in 1,000 give the range as "between 1 to 10 in 1,000". Yes, take two probabilities as input. I think it makes sense to put the higher risk estimate second, and let's not repeat the denonimator. And let's handle special cases; create test cases like http://localhost:8080/index.php/Test/One_In_X?action=raw. It might be better to create a Lua Module in addition to a template, for efficiency and so complicated logic is easier to follow. If we do create a Lua Module, create test cases for it like exist for ProbabilityFormat: http://localhost:8080/index.php/Module:ProbabilityFormat/testcases?action=raw

This is where using claude code saves SO MUCH time! It "one-shotted" the RiskRange feature, writing the test cases, writing the code (Lua and Template), saving them to my development wiki, and running the test cases and revising the code until they passed (it self-corrected a mistake that had 26 of 30 tests passing the first time).

It even updated the Concert Hearing Loss page to use the new template without me having to prompt it. I did have to ask it to create documentation.

One everything looked good on my dev server:

Me: Looks great! Please create an xml file with all of the files we created for Concert Hearing Loss, so I can upload them to the production server. Double-check to make sure ONLY the new page, template, and module (and test/doc pages) are included in the export.

I uploaded the .xml file it produced to the server, tested there, and am pretty happy with the results. The page could be prettier, the wording could probably be improved, I could reach out to actual experts on hearing loss to do more fact-checking or suggest ways to improve it... but that's why this is a wiki. Anybody can make the page better.

Better/Faster/Stronger next time

I ended the conversation with this:

Me: I notice you keep trying to use your internal Fetch to get pages from localhost:. Can you look back over our conversation and see other actions that repeatedly failed, and update CLAUDE.md with instructions to yourself to save time in the future?

Claude: Good idea. Let me review the conversation for repeated failures and update CLAUDE.md.