https://github.com/bjcoombs/ai-native-toolkit/tree/main#what...

https://github.com/bjcoombs/ai-native-toolkit/blob/main/skil...

It hardens a skill through judge-panel refinement rounds, it’s a quality gate that runs after authoring, not an authoring tool.

/understand - agents interrogate the problem /huddle - Thinking panel turns it into a PRD - attacks the premise, PRDs regularly die here /tm - claude-task-master breaks the survivor into a dependency graph

Nobody writes this half up because "agent talked me out of building it" demos worse than "agent built it".

I wrote an /assess tool. I designed it to be token light but assesses on everything I could do to regain trust and help AI to improve my code base not by add features but by adding discipline.

Comments URL: https://news.ycombinator.com/item?id=48227302

Points: 3

# Comments: 0

It said im not the rights holder to do that.

I said yes I am.

It’s said I need proof.

So I got another window to make a letter saying I had proof.

…Sure here you go

Economist editorial attempts to be open on both sides.

Population studies (many): Small associations, but can't control for confounding

Negative control studies (several): Associations weaken when using better controls

Sibling studies (multiple, including Swedish): Associations disappear entirely

Meanwhile, fever studies (dozens): Consistent risk signals across different populations

The Swedish study is just the largest and best-designed in a hierarchy of evidence that all points the same direction. When you see this "dose-response by study quality" pattern - where better methodology consistently yields weaker effects - it's usually a strong signal that the original association was artifactual.

The Economist piece published yesterday reinforces this. They mention the NIH study of 200,000 children that "found no link at all" - that's another high-quality study reaching the same conclusion. Meanwhile, the studies showing associations (Nurses' Health Study II, Boston Birth Cohort) are exactly the type of population studies that can't control for the fever/infection confounding.

Science is never "settled" in an absolute sense, but the weight of evidence here is pretty clear. We're not waiting for more acetaminophen studies - we're ignoring the ones we already have while making policy based on weaker evidence.

That's the real problem with the current policy shift.

The basic problem: Most studies can't tell the difference between the medicine and why you're taking it. If you're having Tylenol during pregnancy, it's probably because you have a fever, infection, or severe pain. Guess what also increases autism risk? Fever, infections, and severe illness.

What makes the Swedish study special: They compared siblings in the same family. Same genes, same environment, same parents - but one child was exposed to acetaminophen in the womb and the other wasn't. This controls for all the family-level stuff that usually confuses these studies.

The numbers tell the story: - Regular studies: "5% increased autism risk with acetaminophen" (HR 1.05) - Swedish sibling comparison: "Actually, no increased risk" (HR 0.98, could be 7% protective to 4% harmful - basically noise) - Meanwhile, untreated fever: 40% increased risk, multiple fevers: 212% increased risk

We have evidence that fever during pregnancy messes with fetal brain development. We have the best study ever done showing acetaminophen doesn't cause autism. So we're going to... stop treating the fever?

It's like refusing to use a fire extinguisher because you're worried it might stain your carpet, while your house burns down.

The Swedish study should have ended this debate. When the science is done correctly, the acetaminophen "risk" vanishes completely.

Sources:

- Swedish study: https://jamanetwork.com/journals/jama/fullarticle/2817406

- Fever-autism evidence: https://molecularautism.biomedcentral.com/articles/10.1186/s...

AI coding has the same bottleneck: specification quality. The difference is that with outsourcing, poor specs meant waiting weeks for the wrong thing. With AI, poor specs mean iterating indefinitely on the wrong thing.

The irony is that AI is excellent at helping refine specifications - identifying ambiguities, expanding requirements, removing assumptions. The specification effectively IS the code, just in human language instead of syntax.

Teams that struggled with distributed development are repeating the same mistakes with AI. Those who learned specification discipline are thriving because they understand that clear requirements determine quality output, regardless of the implementer.

The decisions to exclude complexity, avoid premature abstractions, or reject certain patterns are often just as valuable as the code you can see. But when you're studying a codebase, you're essentially seeing the final edit without the editor's notes - all the architectural reasoning that shaped those choices is invisible.

This is why I've started maintaining Architectural Decision Records (ADRs) in my projects. These document the "why" behind significant technical choices, including the alternatives we considered and rejected. They're like technical blog posts explaining the complex decisions that led to the clean, simple code you see.

ADRs serve as pointers not just for future human maintainers, but also for AI tools when you're using them to help with coding. They provide readable context about architectural constraints and compromises - "we've agreed not to do X because of Y, so please adhere to Z instead." This makes AI assistance much more effective at respecting your design decisions rather than suggesting patterns you've deliberately avoided.

When studying codebases for design patterns, I'd recommend looking for projects that also maintain ADRs, design docs, or similar decision artifacts. The combination of clean code plus the architectural reasoning behind it - especially the restraint decisions - provides a much richer learning experience.

Some projects with good documentation of their design decisions include Rust's RFCs, Python's PEPs, or any project following the ADR pattern. Often the reasoning about what not to build is more instructive than the implementation itself.

They spoke through the options back in March.

The issue definition itself becomes something you can iterate on and refactor, just like code. Getting that definition tightly bounded is more critical than ever because without clear boundaries, the AI doesn't know when to stop or what constitutes "done."

It's like having a pair programming session focused purely on problem decomposition before any code gets written. The AI can help you explore different ways to break down the work, identify dependencies, and find natural seams in the problem space.