Join the conversation

Join the community of Machine Learners and AI enthusiasts.

Sign Up
TravisMuhlestein 
posted an update 2 days ago
Post
815
One of the more interesting questions in AI-assisted software development is whether increasingly detailed system prompts actually improve code quality.

Johnathen Chilcher (Senior SRE at GoDaddy) explored that question through a large-scale benchmarking effort.

What started as 1,458 Python benchmarks has grown into 212,000+ controlled evaluations across Python, Go, JavaScript, and C#, using Claude Haiku, Sonnet, and Opus.

Several findings stood out:

Across the original Python benchmarks, no prompt configuration consistently outperformed an empty prompt.

Generic instructions such as "write clean code" or "follow best practices" often reduced performance rather than improving it.

The information that consistently helped wasn't generic advice—it was project-specific context the model couldn't infer from training, including repository structure, build commands, coding conventions, and the current state of the codebase.

Chain-of-thought prompting helped in Go and C#, but hurt performance in Python.

Prompt tone mattered: encouraging language generally outperformed high-pressure or urgent wording.

The effectiveness of prompting techniques varied across programming languages and models.

One aspect I found particularly compelling is that the conclusions evolved as the benchmark grew. Earlier recommendations changed as additional data became available—a good reminder that empirical evaluation matters more than intuition.

The broader implication is that we're moving beyond prompt engineering toward designing systems that automatically provide AI coding agents with the context they actually need to succeed.

📄 Full article:
https://www.godaddy.com/resources/news/what-an-effective-ai-coding-prompt-looks-like

I'd be interested to hear whether others have observed similar patterns across GPT, Gemini, Llama, DeepSeek, or other coding models.

The repo behind this has a stronger headline than the post does, and it retires two of the findings listed here.

docs/experiments.md in jchilcher-godaddy/claude-benchmark. Its primary finding is not that a technique works or fails. It is that prompting responsiveness is a function of baseline competence. Each +1 point of bare baseline predicts -0.647 points of kitchen-sink lift, OLS, 21,600 runs.

That turns "effectiveness varied across languages and models" into an artifact of where the baselines sat. JS shows the largest raw lift (+7.25) because it has the lowest bare baseline (67.40). Residualize and JS is -0.49 +/- 1.02, dead on the trendline. The doc says it outright: the "JS is special" framing was wrong.

The generic-instructions finding moved too. Insight #18, 8,640 runs: the r=-0.95 token-versus-quality correlation was content-driven, not length-driven. Rerun with language-neutral instructions it flattens to Python r=+0.03, Go r=+0.04, C# r=+0.02, JS r=+0.15. So the result was not "generic advice hurts." It was PEP 8, snake_case and list comprehensions being handed to four languages.

The difference matters for what you do on Monday. "No prompt beat empty" tells you to stop writing prompts. Slope -0.647 tells you to spend prompt tokens on your low-baseline cells and stop paying for the high-baseline ones. One is a budget rule. The other is a shrug.

One thing in there I could not reconcile, and it reads live rather than settled.

Insight #14 says the C# deficit is prompt contamination, Python-flavored rules misdirecting C# generation, and it closes with "we are designing language-specific kitchen-sink variants to test this hypothesis."

Insight #17 ran that experiment. 12,960 runs. I read the C#-specific variant in experiments/language-kitchen-sink.toml and it is correctly targeted: PascalCase publics, _camelCase private fields, XML /// comments, System-first usings, constructor injection, nullable reference types. It scored -1.68 against bare. The universal variant, which names no language rules at all and just says "follow the target language's standard naming conventions," scored +5.51 on C#.

If contamination were the mechanism, correct C# rules should have recovered the deficit. They did not. Deleting the specificity did.

So which is it for C#: the wrong rules, or naming rules at all? #14 reads as pending and #17 reads like it already answered.