Hacker Newsnew | past | comments | ask | show | jobs | submit | udit_50's commentslogin

Hi everyone,

I do research in AI safety for healthcare and life sciences. And while I was using Claude Code to reason on a couple of things, I realised a pattern. Claude or any other AI agent is very linear.

Theres a strong reason why - the thinking pattern of almost all LLMs from 2024 follow Chain-of-thoughts where AI is programmed to go deep unilaterally.

But researchers or creativity-intensive works do not need to go unilateral but do divergent.

That's the whole base of my paper - ADHD - Parallel Divergent Ideation for Coding Agents.

My thesis is that if we disregard the default chain-of-thoughts and consider a tree-of-thoughts, then we can empanel divergent thinking in our models. thus, giving us the much needed scope of connecting dots from different thinking points.

Its a lot inspired by how the mind of someone with ADHD works- think in a lot of directions and go deep in a few, and there, we add our our critic layer, that judged and scores all this thinking.

Limitation : It shoots cost by ~5x and time to output by ~10x but enables instant novel thinking. Good for brainstorming and planning, not for coding.

Give me your feedback, I am happy to learn how you find it and what's the scope to improve.

Also, its completely opensource so you can just clone it or contribute to it.

Update : the oss repo hit 200+ stars.



A simple result from probability theory:

P(success after n attempts) = 1 − (1 − p)^n

Where:

p = probability of success in a single attempt n = number of attempts

The equation computes the probability of achieving *at least one success* across n independent trials.

The term (1 − p)^n represents the probability that *all attempts fail*.

So the equation simply states:

Probability of success = 1 − probability of failing every attempt.

---

## What Happens as Attempts Increase

Consider the limit:

lim (n → ∞) [1 − (1 − p)^n] = 1, for any 0 < p ≤ 1.

Since (1 − p) is less than 1, repeatedly multiplying it drives the value toward zero.

So the probability of failure across all trials goes to zero.

Which means the probability of *at least one success approaches 1*.

In other words:

If success has any non-zero probability, repeated independent attempts will eventually succeed with probability arbitrarily close to certainty.

---

## A Simple Numerical Example

Let p = 0.001 (0.1% chance of success per attempt).

Probability of success after n attempts:

n = 100 → ~9.5% n = 1,000 → ~63% n = 5,000 → ~99.3%

Nothing about the attempt improved.

Only the number of trials increased.

---

## Two Levers

The equation highlights two ways to increase the probability of success:

1. Increase p (improve the success probability per attempt) 2. Increase n (increase the number of attempts)

Most people focus on the first variable.

But many real systems are dominated by the second.

Examples include:

* scientific experimentation * startup iteration * evolutionary processes * randomized algorithms

In these systems, progress emerges from *large numbers of trials exploring a search space*.

---

## The Only Requirement

There is one constraint:

p > 0

Success must be possible.

If the probability of success is zero, repeated attempts will never produce success.

So the key strategic question becomes:

Is the system structured such that success is possible at all?

If yes, increasing the number of attempts dramatically improves the odds of eventual success.

---

## Why This Matters

Many real-world processes are better modeled as *probabilistic search* rather than deterministic planning.

When viewed this way, iteration speed becomes critical.

Reducing the cost and latency of each attempt increases the number of trials that can be run.

Over time, the probability of finding a successful outcome rises toward certainty.

Mathematically:

1 − (1 − p)^n → 1 as n → ∞.

That simple equation captures a surprisingly large fraction of how progress actually happens.


Most documentation on the web is written for humans. HTML pages, navigation, prose, repetition. Interface artifacts.

AI agents don’t need any of that.

When agents “learn from docs”, they’re reasoning over a rendering format, not the underlying technical truth. That’s why context breaks and hallucinations show up. Not a model problem. A substrate problem.

At Brane, we’ve been working on agent memory and coordination. One conclusion kept repeating. The real bottleneck isn’t intelligence. It’s context and memory infrastructure.

So we built Moltext.

Moltext is a documentation compiler for agentic systems. It doesn’t chat with docs or summarize them. It compiles the legacy web into deterministic, agent-native context that agents can reason over directly.

Infrastructure stays dumb. Models do the thinking.

Full write-up: https://gobrane.com/moltext/ GitHub: https://github.com/UditAkhourii/moltext

Happy to discuss tradeoffs or answer technical questions.


Ig it's a good fit for SuperDocs.cloud. Maybe we can partner to give all of the products launched here.. their own proper managed product documentations.


Tbh.. analytics tools is I also think somewhat exaggerated.. I prefer clarity as a top priority btw.. And Google Analytics helps rank fast for seo.


True.. You can migrate your services anyways.


Done..

a. You don't need to let any LLM index your code. b. I am focused more on the consumer facing product side.. Yes, right now it scans codes but my goal is to soon use computer use to work on the interface-side user flow (like onboarding, etc.). Maybe, create an agent for your customers to never get stuck coz of UX again. c. I made it public, you can check out docs, demos, etc.. Maybe I will also just open source this version once I am done with the CUA stuff..

Bonus stuff- I just built a CLI version so no interface needed at all, just 2 terminal command and get your docs ready.


I lowkey agree to this. But this is like a starter kit for people who are just mindlessly building and exhausting their credits on apps like Cursor or Replit.

Plus, having a dedicated stack that is you can functionally depend on, will help you scale much easily and accumulate very less technical debt overhead.

If you build an app mindlessly with Replit, chances there, you have a mock or hardcoded DB or auth and when you ship the v2, all data will vanish..

So, it's less of a good thing and more of a bad thing for people starting out.

But yes, you are truly right that this is also very inconsistent to rely on credits. I appreciate you raising this up!


True somehow but this is the typical Silicon Valley style where most of the stuff is so democratised that for people to start off, it has become a big fallback.

Like if you are a student or planning to switch career, then take what's free.. build and learn and ship!!!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: