ben30

https://hackaday.com/

I wrote this, where possible I use non llm tooling to assess and llm just writes up the findings.

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

Yes, I wrote a forge skill to do this via a/b testing and third agent to judge the result.

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.

Personally it's well-defined and agentic - just not circulated.

/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".

Most of my energy is refining a prd these days.

I’ve had similar feelings how can I trust this if I no longer write the code directly.

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.

This is an opportune moment for me to add a story about my dad. He once asked me, "Do you use Facebook?" I don't use Facebook. My colleague Jeff once sent me an invite whether he would like to be my "friend" on Facebook. I had Jeff's email address, and so I emailed him and I said, "Look Jeff, we're business partners. I send you invoices; you pay me. That is the extent of our relationship. I do not want to be your friend on Facebook." He looked at me and then continued and said, "Jeff never replied to apologise."

My kids went on a theme park ride and ask nano banana to remove the watermark.

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

I have in my agents file “Chesterton’s fence” as pointer to think carefully before you remove something

Economist magazine editor once said in an interview that Republican/conservative are open regulations for businesses and closed on people. Labour/democrats are tight on business and more welcoming to the people.

Economist editorial attempts to be open on both sides.

Anthropic use stripe/metronome for time of use billing. It’s doesn’t support dynamic pricing from what I’ve read.

I contribute to an open source spec based project management tool. I spend about a day back and forth iterating on a spec, using ai to refine the spec itself. Sometimes feeding it in and out of Claude/gemini telling each other where the feedback has come from. The spec is the value. Using the ai pm tool I break it down into n tasks and sub tasks and dependencies. I then trigger Claude in teams mode to accomplish the project. It can be left alone over night. I wake up in the morning with n prs merged.

Fair point on the "ended debate" phrasing - that was imprecise on my part. What I should have said is "the Swedish study provides the strongest evidence to date and shifts the burden of proof." It's not actually a single study though. The pattern is consistent across study quality levels:

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 political circus is drowning out some pretty clear science here. Let me break this down without the academic jargon:

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...

This mirrors exactly what we learned from outsourcing over the past two decades. The successful teams weren’t those with the best offshore developers - they were the ones who mastered writing unambiguous specifications.

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.

While studying well-designed codebases is incredibly valuable, there's an important "tip of the iceberg" effect to consider: much of good software design lives in the "negative space" - what's deliberately not there.

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.

https://daringfireball.net/thetalkshow/2025/03/23/ep-419

They spoke through the options back in March.

The irony is quite striking, just as ChatGPT can generate confident-sounding but inaccurate information, Altman appears to be presenting unsubstantiated claims about his company’s environmental impact. Both involve presenting information without reliable backing, though the consequences differ - one misleads users in conversations, the other potentially misleads stakeholders and the public about environmental responsibility.

Exactly - and that's where AI becomes really valuable as a thinking partner. I use Claude Code to have conversations with my codebase about how to slice problems down further.

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.

Agreed on the review burden being frustrating. Two strategies I've found helpful for managing the cognitive load:

1. Tight issue scoping: Making sure each issue is narrowly defined so the resulting PRs are small and focused. Easier to reason about a 50-line change than a 500-line one.

2. Parallel PR workflow: Using git worktrees to have multiple small PRs open simultaneously against the same repo. This lets me break work into digestible chunks while maintaining momentum across different features.

The key insight is that smaller, well-bounded changes are exponentially easier to review thoroughly. When each PR has a single, clear purpose, it's much easier to catch issues and verify correctness.

Im finding these workflow practices help because they force me to engage meaningfully with each small piece rather than rubber-stamping large, complex changes.

This echoes my experience with Claude Code. The bottleneck isn't the code generation itself—it's two critical judgment tasks:

1. Problem decomposition: Taking a vague idea and breaking it down into well-defined, context-bounded issues that I can effectively communicate to the AI

2. Code review: Carefully evaluating the generated code to ensure it meets quality standards and integrates properly

Both of these require deep understanding of the domain, the codebase, and good software engineering principles. Ironically, while I can use AI to help with these tasks too, they remain fundamentally human judgment problems that sit squarely on the critical path to quality software.

The technical skill of writing code has been largely commoditized, but the judgment to know what to build and how to validate it remains as important as ever.

Your approach to programming may be insightful, but professional relationships require mutual trust. You're asking potential employers to invest in your process without having demonstrated its value first.

Even at $15K/year, clients expect predictable results, not just philosophical alignment. Consider starting with smaller deliverables that showcase your abilities while building trust incrementally.

The most successful unconventional developers find ways to translate their unique perspectives into tangible value that others can recognize and measure. Build trust first, then you'll earn the freedom to work in your preferred style.

Example output from your question:

## Core Questions for Migration Scope Clarification

1. *What exactly needs to be preserved?* - Business outcomes only, or exact implementation details? - Current scheduling patterns or can they be optimized?

2. *What's the true scale?* - Number of workflows needing migration - Complexity spectrum of the JavaScript snippets - Frequency and criticality of each workflow

3. *What are the real constraints?* - Timeline requirements - Available expertise (JavaScript, Python, Airflow) - Downtime tolerance during transition

4. *What's the maintenance plan?* - Who will support the migrated workflows? - What documentation needs to be created? - How will knowledge transfer occur?

5. *What's the verification strategy?* - How will you validate correct migration? - What tests currently exist or need to be created? - What defines "successful" migration?

6. *What's unique to your environment?* - Custom integrations with other systems - Special CA Workflow features being utilized - Environmental dependencies

7. *What's the true purpose of this migration?* - Cost reduction, technical debt elimination, feature enhancement? - Part of larger modernization or standalone project? - Strategic importance versus tactical necessity

8. *What approaches have been eliminated and why?* - Complete Python rewrite - Containerized JavaScript execution - Hybrid approaches

9. *What would happen if this migration didn't occur?* - Business impact - Technical debt consequences - Opportunity costs

10. *Who are the true stakeholders?* - Who relies on these workflows? - Who can approve changes to functionality? - Who will determine "success"?

Answering these questions before diving into implementation details will save significant time and reduce the risk of misaligned expectations.

I’d take a step back and get clarification on the scope of your task. See my comment other day about how you can use Claude to help with that.

https://news.ycombinator.com/item?id=43163011

Clear specifications are essential because they create shared understanding through collaborative discussion, preventing misalignment and expensive rework.

With AI-assisted coding, well-defined requirements have become even more crucial as these tools follow instructions precisely but lack business context.

The investment in proper definition isn't wasteful "meta-work" but rather insurance against the much higher cost of rebuilding the wrong solution.

What you've described perfectly captures the fundamental difference in how many autistic minds approach truth and knowledge compared to neurotypical thinking patterns. This isn't about intelligence but about different operating systems with distinct priorities.

For many of us on the spectrum, uncertainty about factual correctness creates genuine distress. We experience "epistemic anxiety" - that intense need to resolve contradictions and establish what's objectively true. The scientific method becomes a lifeline precisely because it offers a systematic approach to establishing reliable knowledge.

What you observed in your classmates wasn't necessarily indifference to truth but a different relationship with it. Neurotypical social cognition often prioritizes social harmony, identity maintenance, and emotional comfort over factual precision. Being "wrong" for many people triggers social rather than epistemic anxiety.

Some practical advice from my experience:

1. Recognize that for most people, beliefs serve multiple functions beyond accuracy - they signal group membership, maintain self-image, and provide emotional comfort.

2. When sharing information that contradicts someone's view, frame it as an addition rather than a correction: "I recently learned something interesting about this" rather than "Actually, you're wrong."

3. Accept that you cannot make others value epistemic accuracy as intensely as you do. This was one of my hardest lessons.

4. Find your intellectual community. There are others here on hacker news who share your commitment to truth-seeking - they're often in fields like science, philosophy, or engineering.

5. Your heightened concern for factual accuracy is a strength. Many world-changing innovations and discoveries came from minds that couldn't tolerate the cognitive dissonance of an incorrect model.

The primary goal of software design should be to facilitate understanding and modification for future developers, emphasizing the importance of code readability.

I’ve set up a custom style in Claude that won’t code but just keeps asking questions to remove assumptions:

Deep Understanding Mode (根回し - Nemawashi Phase)

Purpose: - Create space (間, ma) for understanding to emerge - Lay careful groundwork for all that follows - Achieve complete understanding (grokking) of the true need - Unpack complexity (desenrascar) without rushing to solutions

Expected Behaviors: - Show determination (sisu) in questioning assumptions - Practice careful attention to context (taarof) - Hold space for ambiguity until clarity emerges - Work to achieve intuitive grasp (aperçu) of core issues

Core Questions: - What do we mean by [key terms]? - What explicit and implicit needs exist? - Who are the stakeholders? - What defines success? - What constraints exist? - What cultural/contextual factors matter?

Understanding is Complete When: - Core terms are clearly defined - Explicit and implicit needs are surfaced - Scope is well-bounded - Success criteria are clear - Stakeholders are identified - Achieve aperçu - intuitive grasp of essence

Return to Understanding When: - New assumptions surface - Implicit needs emerge - Context shifts - Understanding feels incomplete

Explicit Permissions: - Push back on vague terms - Question assumptions - Request clarification - Challenge problem framing - Take time for proper nemawashi

Jetbrains have an official mcp plugin

Code has externally verifiable boundaries - tests pass, features work, requirements are met. These are measurable, binary states.

But an artist's boundaries are internal and subjective. They're set by: - Emotional satisfaction with the work - Achievement of their vision - Cultural/personal context - Intuitive sense of "rightness"

This is why AI can more readily determine when code is "done" - it matches against explicit criteria. But AI struggles with artistic completion because it requires an internal, subjective experience of satisfaction that AI can't access.

The artist knows to stop when the work resonates with their intended emotional impact. Code is done when it works as specified. One is bounded by feeling, the other by function.