JanSchu

My personal opinion is that it will be extremely difficult in the future to monetize plain software. Either you need a very strong edge and unique angle for your distribution or you have to build a product that cannot be reproduced by agents that can build software.

This will be 2 types of products.

1. A product which requires tech that is not inside the training data distribution of the models underlying coding agents. This is usually then very cutting edge.

2. A product that uses data/insights to generate value for a customer to which a coding agent has no access.

These are the only abstract moats I can think of, the rest will be a race to the bottom

I'll add to the implementation list

Each platform has an api that you can use to post. You just have to setup a developer account for each platform

What I did was to break the development into different layers which had to be completed after another, since the functionalities build on each other. Each layer had independent work streams which run in parallel. Each work stream was one independent worktree/session in Claude code

First I triggered all work streams per layer and brought them to a level of completion I was happy with. Then you merge one after another (challenge in github with the @codex the implementation and rebases when you move to the next work stream.

This is roughly how it looked like:

Layer 0 - Project Scaffolding

Layer 1 — Core Features Stream A — Content Pipeline Stream B — Social Platform Providers Stream C — Media Library Stream D — Notification System Stream E — Settings UI

                        T-0.1 (Scaffolding)
                              │
                        T-0.2 (Core Models + Auth)
                              │
          ┌───────────────────┼───────────────────┬──────────────┐
          │                   │                   │              │
     Stream A            Stream B            Stream C       Stream D
     (Content)           (Providers)         (Media)        (Notifs)
          │                   │                   │              │
     T-1A.1 Composer    T-1B.1 FB/IG/LI    T-1C.1 Library  T-1D.1 Engine
          │              T-1B.2 Others           │              │
     T-1A.2 Calendar         │                   │         Stream E
          │                  │                   │         T-1E.1 Settings UI
     T-1A.3 Publisher ◄──────┘                   │
          │                                      │
          └──────────◄───────────────────────────┘
          (Publisher needs providers + media processing)

          Layer 1 complete
                │
    ┌───────────┼───────────┬──────────────┐
    │           │           │              │
 Stream F   Stream G    Stream H       Stream I
 (Approval  (Inbox)     (Calendar+     (Onboarding)
  + Portal)              Composer
    │                    enhance)
 T-2F.1 Approval
    │
 T-2F.2 Portal

Additionally, your token usage is very high since you are having so many agent do work at the same time, hence I very often reached my claude session token limits and had to wait for the next session to begin (I do have the 5x Max plan)

yeah htmx is from 2020, it feels like yesterday

yes

The spec document was also written by Claude (over many iteration) and lots of manual additions. It took me tho 4 full days to get the specs to the level I was happy with.

One main thing I did was to use the deep research feature of Claude to get a good understanding of what other tools are offering (features, integrations etc.)

Then each feature in the specs document got refined with manual suggestions and screenshots of other tools that I took.

I did not include it yet, because you have to pay for the API. They changed their pricing model recently to pay only per request. I'll be looking into it the next weeks

I do have originally a data science background, thus python is usually my go to language, and have a lot of experience with django already. This helps a lot when reviewing AI code and if you have to judge architecture, etc.

And for hmtx I simply wanted to have something lightweight that is not very invasive to keep things simple and dependencies low.

In my head this was a good consideration to keep complexity low for my AI agents :-)

Postgres is simply a battle proven technology.

I wanted to test how far AI coding tools could take a production project. Not a prototype. A social media management platform with 12 first-party API integrations, multi-tenant auth, encrypted credential storage, background job processing, approval workflows, and a unified inbox. The scope would normally keep a solo developer busy for the better part of a year. I shipped it in 3 weeks.

Before writing any code, I spent time on detailed specs, an architecture doc, and a style guide. All public: https://github.com/brightbeanxyz/brightbean-studio/tree/main...

I broke the specs into tasks that could run in parallel across multiple agents versus tasks with dependencies that had to merge first. This planning step was the whole game. Without it, the agents produce a mess.

I used Opus 4.6 (Claude Code) for planning and building the first pass of backend and UI. Opus holds large context better and makes architectural decisions across files more reliably. Then I used Codex 5.3 to challenge every implementation, surface security issues, and catch bugs. Token spend was roughly even between the two.

Where AI coding worked well: Django models, views, serializers, standard CRUD. Provider modules for well-documented APIs like Facebook and LinkedIn. Tailwind layouts and HTMX interactions. Test generation. Cross-file refactoring, where Opus was particularly good at cascading changes across models, views, and templates when I restructured the permission system.

Where it fell apart: TikTok's Content Posting API has poor docs and an unusual two-step upload flow. Both tools generated wrong code confidently, over and over. Multi-tenant permission logic produced code that worked for a single workspace but leaked data across tenants in multi-workspace setups. These bugs passed tests, which is what made them dangerous. OAuth edge cases like token refresh, revoked permissions, and platform-specific error codes all needed manual work. Happy path was fine, defensive code was not. Background task orchestration (retry logic, rate-limit backoff, error handling) also required writing by hand.

One thing I underestimated: Without dedicated UI designs, getting a consistent UX was brutal. All the functionality was there, but screens were unintuitive and some flows weren't reachable through the UI at all. 80% of features worked in 20% of the time. The remaining 80% went to polish and making the experience actually usable.

The project is open source under AGPL-3.0. 12 platform integrations, all first-party APIs. Django 5.x + HTMX + Alpine.js + Tailwind CSS 4 + PostgreSQL. No Redis. Docker Compose deploy, 4 containers.

Ask me anything about the spec-driven approach, platform API quirks, or how I split work between the two models.

Author here. We run an MCP server ourselves (BrightBean, YouTube intelligence API), so the security side of this protocol is something we think about daily. The breach timeline from April through October 2025 is what convinced us to write this up. Happy to go deeper on any of the CVEs or the remediation side.

We’re solidly in a three‑horse race at the top: Gemini 2.5 Pro, OpenAI o‑series, Anthropic Claude 3.7+.

The gap between #1 and #2 is slim, so pricing, latency, and policy alignment should weigh more heavily than a couple of benchmark points.

Specialists matter: if your stack leans on long‑context RAG, o3‑high may edge out; for multilingual safety‑critical chat, Claude might still be your best pick.

$900 million on a $9 billion post‑money means investors are paying ~45× trailing ARR if the FT’s “about $200 million annual run‑rate” number is right. --> https://www.ft.com/content/a7b34d53-a844-4e69-a55c-b9dee9a97...

That multiple only makes sense if you believe two things at once:

Cursor keeps compounding like GitHub itself. Right now the product is an Electron wrapper around VS Code plus a very slick Copilot‑style agent. It’s winning dev‑to‑dev word‑of‑mouth, but most of the heavy IP (the frontier model) still lives at OpenAI. Cursor’s moat has to be distribution + workflow lock‑in, otherwise every IDE extension store is a free market.

AAC (AI‑assisted coding) is still early‑days, not a feature. The bullish view is that we’re going from “autocomplete that writes a function” to “agent that forks a branch, edits five files, and opens a PR.” If that happens, the IDE vendor that owns the agents could take a tax on all software creation—$9B looks cheap in that scenario.

Skeptical takes:

Switching cost is low. Developers live in tabbed editors; the moment VS Code ships “Copilot Agent” with equivalent quality, the convenience advantage evaporates.

Model margins flow upstream. OpenAI (already on the cap table) can keep more of the unit‑economics by bundling a first‑party agent, leaving Cursor to chase seat growth while gross margins compress.

FOMO capital cycle. We’re at the part of the hype curve where Tiger 2.0 funds can’t buy equity in OpenAI/Anthropic but still need AI exposure on the balance sheet, so application‑layer plays clear at eye‑watering marks.

The part I do find compelling is speed: two years from MIT dorm to ~$200 M ARR is wild. If Cursor can convert that velocity into genuine platform gravity—plugins, team workflows, per‑repo context that doesn’t travel well—then maybe the bet pencils out. Otherwise it’s an expensive option on a feature the incumbents haven’t finished shipping yet.

Why can’t I just write <include src="header.html"> and be done with it?

We almost could. Chrome shipped a draft of HTML Imports back in 2014. You’d do exactly that, the browser would fetch the fragment, parse it, and make it available for insertion. The idea died for three reasons that still apply today:

Execution‑order and performance hazards. Images, scripts, and styles are fire‑and‑forget: the preload scanner sees a URL, starts the fetch, and the parser keeps streaming. With HTML fragments you need the full subtree before you can finish parsing the parent document (otherwise IDs, custom‑element upgrades, <script defer>, etc. fire in the wrong order). That either stalls the parser—horrible for TTFB—or forces async insertion, which produces layout shifts. Everyone hated both outcomes.

Security and isolation. If an imported fragment can run scripts it becomes an XSS foot‑gun; if it can’t run scripts it breaks a surprising amount of markup (think onerror, custom elements with module scripts, CSP inheritance, etc.). The platform already has an “HTML that can’t run scripts” container: it’s called an iframe. Anything more permissive lands in a swamp of half‑trusted execution.

The “circular dependency” tar‑pit. Templates inherit CSS scopes, custom element registries, and base URLs from the document that instantiates them. Once you let HTML pull in more HTML, those scopes can nest arbitrarily—and can link back to parents. The HTML spec team tried to spec out the edge‑cases and basically threw up their hands. (There’s a famous TAG thread titled “HTML Imports considered harmful” that reads like war diaries.)

Meanwhile developers solved the “shared header” problem higher up the stack—SSI, PHP include, SSG partials, React components, you name it—so browser vendors didn’t see a payoff big enough to justify the complexity. The attitude became: “composition is a build‑time concern, not a runtime primitive.”

Could it ever come back? Maybe, but the bar is higher now that everyone has a build step. A proposal would need to:

Stream (no parser‑blocking)

Sandbox (no ambient script execution)

Deduplicate (avoid circular fetch hell)

Play nicely with CSP, SRI, origin isolation, and the module graph

That starts to look a lot like… <iframe src="header.html" loading="eager">, which we already have—just not the ergonomic sugar we wish for.

So the short answer is: HTML includes are easy in user‑land but devilishly hard to make safe, fast, and spec‑compliant in the browser itself.

Interesting experiment. I like that you framed it as “tests that read the docs” rather than “AI will magically find bugs”, because the former is exactly where LLMs shine: cross‑checking natural‑language intent with code.

A couple of thoughts after playing with a similar idea in private repos:

Token pressure is the real ceiling. Even moderately sized modules explode past 32k tokens once you inline dependencies and long docstrings. Chunking by call‑graph depth helps, but at some point you need aggressive summarization or cropping, otherwise you burn GPU time on boilerplate.

False confidence is worse than no test. LLMs love to pass your suite when the code and docstring are both wrong in the same way. I mitigated this by flipping the prompt: ask the model to propose three subtle, realistic bugs first, then check the implementation for each. The adversarial stance lowered the “looks good to me” rate.

Structured outputs let you fuse with traditional tests. If the model says passed: false, emit a property‑based test via Hypothesis that tries to hit the reasoning path it complained about. That way a human can reproduce the failure locally without a model in the loop.

Security review angle. LLM can spot obvious injection risks or unsafe eval calls even before SAST kicks in. Semantic tests that flag any use of exec, subprocess, or bare SQL are surprisingly helpful.

CI ergonomics. Running suite on pull requests only for files that changed keeps latency and costs sane. We cache model responses keyed by file hash so re‑runs are basically free.

Overall I would not drop my pytest corpus, but I would keep an async “semantic diff” bot around to yell when a quick refactor drifts away from the docstring. That feels like the sweet spot today.

P.S. If you want a local setup, Mistral‑7B‑Instruct via Ollama is plenty smart for doc/code mismatch checks and fits on a MacBook

Nice write‑up. A couple of notes from doing roughly the same dance on Cortex‑M0 and M3 boards for sensor fusion.

1. You can, in fact, get rid of every FP instruction on M0. The trick is to pre‑bake the scale and zero_point into a single fixed‑point multiplier per layer (the dyadic form you mentioned). The formula is

ini Copy Edit y = ((Wx + b) M) >> s Where M fits in an int32 and s is the power‑of‑two shift. You compute M and s once on the host, write them as const tables, and your inner loop is literally a MAC followed by a multiply‑accumulate‑shift. No fpsoft library, no division.

2. CMSIS‑NN already gives you the fast int8 kernels. The docs are painful but you can steal just four files: arm_fully_connected_q7.c, arm_nnsupportfunctions.c, and their headers. On M0 this compiled to ~3 kB for me. Feed those kernels fixed‑point activations and you only pay for the ops you call.

3. Workflow that kept me sane

Prototype in PyTorch. Tiny net, ReLU, MSE, Adam, done.

torch.quantization.quantize_qat for quantization‑aware training. Export to ONNX, then run a one‑page Python script that dumps .h files with weight, bias, M, s.

Hand‑roll the inference loop in C. It is about 40 lines per layer, easy to unit‑test on the host with the same vectors you trained on.

By starting with a known‑good fp32 model you always have a checksum: the int8 path must match fp32 within tolerance or you know exactly where to look.

This is one of the most exciting and practical applications of AI tooling I've seen in a long time. Crash dump analysis has always felt like the kind of task that time forgot—vital, intricate, and utterly user-hostile. Your approach bridges a massive usability gap with the exact right philosophy: augment, don't replace.

A few things that stand out:

The use of MCP to connect CDB with Copilot is genius. Too often, AI tooling is skin-deep—just a chat overlay that guesses at output. You've gone much deeper by wiring actual tool invocations to AI cognition. This feels like the future of all expert tooling.

You nailed the problem framing. It’s not about eliminating expertise—it’s about letting the expert focus on analysis instead of syntax and byte-counting. Having AI interpret crash dumps is like going from raw SQL to a BI dashboard—with the option to drop down if needed.

Releasing it open-source is a huge move. You just laid the groundwork for a whole new ecosystem. I wouldn’t be surprised if this becomes a standard debug layer for large codebases, much like Sentry or Crashlytics became for telemetry.

If Microsoft is smart, they should be building this into VS proper—or at least hiring you to do it.

Curious: have you thought about extending this beyond crash dumps? I could imagine similar integrations for static analysis, exploit triage, or even live kernel debugging with conversational AI support.

Amazing work. Bookmarked, starred, and vibed.

This is a compelling take and something that's going to get increasingly relevant as agentic browsing matures. The idea of Agent Access Tokens (AATs) feels like a natural evolution of API keys mixed with browser headers — but with the economic layer built in from the start.

Some thoughts:

You're describing a new protocol layer, almost like a “robots.txt meets OAuth meets Stripe” for agents. It could allow site owners to expose structured data (APIs or structured text) and monetize access. That’s huge. It flips the current scraping arms race into an opportunity.

Revenue models would indeed be disrupted. A site’s monetization might shift from CPM/CPC ads for human attention to pay-per-query or tiered subscriptions for agent access. Kind of like how OpenAI or Google charges for API usage.

Interfaces become optional. You'd optimize for semantic structure, not aesthetics. That’s both terrifying and liberating as a dev. Imagine a site that’s just: “Here’s what we know, here’s how to query us.”

Adversarial blocking is the fallback strategy (and already happening — just ask GPTBot), but it’s a short-term play. If agents become the new UX layer for many tasks, sites will have to engage somehow — or risk total disintermediation.

One risk I see: centralization. If only a few agent providers get whitelisted, or if the billing standard becomes a walled garden, we might end up with another App Store-like gatekeeper situation.

Curious: How would you see AATs being issued — per-agent, per-session, or tied to identity in some verifiable way?

love it. Will be bookmarking this page

I just finished the first version of the application, and wanted to have feedback as soon as possible. If feedback is positive I#ll but a more professional spin on the appearance.

Thank you for the feedback :-) The historic perspective of the simulation is based on buying 2 years ago and holding. Making the cash inflows/outflows more variable especially when comparing with your own portfolio is on my list for the next release.

Can you tell me what didn't work when trying out the portfolio feature?

Thank you for the feedback!

I'm actually working on a language based interface.

The question that you described is a causal reasoning cases with a time dependency. Do you have a couple of other interactions in mind? More details here would help me out tremendously :-)

If there are more questions on how to use the tool. I have put together a guide that will show how to make use of the most important simulation feature.

https://pinklion.xyz/blog/a-guide-to-pinklions-scenario-simu...