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

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)

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.

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 :-)

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.

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

Points: 188

# Comments: 131

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

Points: 1

# Comments: 0

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

Points: 2

# Comments: 0

I have to admit that we do not know yet the sales results, but such high CPMs make my head spin from a performance marketing perspective.

Do you have similar experiences? Since for such high CPMs, the conversion rates have to be extremely good to justify the spend.

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

Points: 1

# Comments: 0

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.

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.