At previous jobs I was building iOS apps with an embedded code editor. The only solution at the time was Highlightr, a Swift wrapper around highlight.js. It worked, but you paid for a JS bridge.

Over winter break I had time to revisit the problem. On iOS that gap is now closed. There are working tree-sitter Swift bindings, dedicated syntax-highlighting libraries, and full code-editor components. I assumed Android was the same, but it wasn't. The Kotlin tree-sitter bindings weren't usable at the time (may have changed since), and there were no real grammar engines. What I saw was ad-hoc regex per language or a few natively-supported languages.

So I wrote one, a pure-Kotlin port of Microsoft's vscode-textmate. Real .tmLanguage grammar support (600+ grammars the VS Code ecosystem already maintains) and Compose AnnotatedString renderer for Android.

Repo, architecture notes, and benchmarks all in the link.

We built Diffmode for bootstrapped founders who are tired of hearing the same growth advice: write content, run paid ads, build a community, post on LinkedIn.

That advice is not wrong. It is just crowded. If every competitor is running the same playbook, a smaller team usually loses.

Anton, our founder, was previously growth lead at JetBrains Academy. He kept seeing the same pattern: useful products would get early traction, then stall. Not because the product was bad. Because the next growth channel was not obvious.

So he started collecting mechanisms behind growth wins from real companies. Not "use TikTok" or "launch on Product Hunt." More like: counter-cyclical timing, pre-validation economics, audience borrowing, trust through curation.

That database is now 576 documented mechanisms: 347 demand-gen vectors and 229 CRO vectors.

Diffmode cross-references those mechanisms against your constraints: budget, team size, stage, skills, customer type, and channel saturation. Then it combines 2–3 mechanisms into tactics for your specific situation.

The important part: the output is not a list of ideas. It is a plan.

You get competitor landscape, buyer JTBD, channel gaps, prioritized tactics, day-by-day execution, templates, tools, and kill criteria. The goal is to tell a solo founder what to do Monday morning, and when to stop if the signal is not there.

There is a public sample report here: https://diffmode.app/reports/sample

Two things I would love feedback on:

1. Run the free Audit on your own product and tell me where it gets things wrong, generic, or overconfident.

2. Is the day-by-day format useful for a bootstrapped operator, or would you rather get something shorter and more strategic?

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

Points: 2

# Comments: 2

- Instruction files: Anthropic recommends <200 lines for CLAUDE.md. The "lost in the middle" problem shows 30%+ accuracy drop for information in the middle of the context window.

- Project structure: Independent benchmarks consistently show that 60–80% of tokens go toward figuring out where things are.

- Session length: There’s a strong intuition that longer sessions are better — the agent “already knows” our codebase, we don’t need to re-explain anything. In practice, the opposite is true.

- Self-verification: Anthropic calls giving the agent runnable tests "the single highest-leverage thing" for agent performance.

- Scaffolding: When an agent produces bad output, our first instinct is usually “the model is dumb.” But almost every time, the problem is in the scaffolding.

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

Points: 3

# Comments: 1

On the naming fair point, already renamed the CLI binary after an earlier comment here. The repo name is more about discoverability.

The hard part was picking when to trigger it. Too early and you're throwing away useful context. Too late and the model's already struggling. I ended up just using a simple token count — nothing clever, but it works.

And yeah, the Swift angle was genuinely fun. Defining tool schemas as Codable structs that auto-generate JSON schemas at compile time, getting compiler errors instead of runtime API failures is a huge win.

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

Points: 98

# Comments: 21

A lot of the real value shows up as workflow compression instead. Internal tools, one-off automations, bespoke research flows, coding helpers, things that would never have justified becoming a product in the first place.