JanSchu

[flagged]

3개월 전discuss

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

JanSchu

3개월 전discuss

I'll add to the implementation list

JanSchu

3개월 전discuss

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

JanSchu

3개월 전discuss

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 2 — Collaboration & Engagement Stream F — Approval & Client Portal Stream G — Inbox Stream H — Calendar & Composer Enhancements Stream I — Client Onboarding

          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

Thus I did run up to 4 agents in parallel, but o be honest this is the max level of parallelism my brain was able to handle, I really felt like the bottleneck here.

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)

JanSchu

3개월 전discuss

yeah htmx is from 2020, it feels like yesterday

JanSchu

3개월 전discuss

yes

JanSchu

3개월 전discuss

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.

JanSchu

3개월 전discuss

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

JanSchu

3개월 전discuss

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

JanSchu

3개월 전discuss

Postgres is simply a battle proven technology.

JanSchu

3개월 전discuss

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.

JanSchu

4개월 전discuss

[dead]

JanSchu

4개월 전discuss

[dead]

JanSchu

4개월 전discuss

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.

JanSchu

4개월 전discuss

[dead]

JanSchu

4개월 전discuss

[dead]

JanSchu

작년discuss

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.

JanSchu

작년discuss

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

JanSchu

작년discuss

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.

Submissions

[untitled]

[untitled]

Show HN: I built a social media management tool in 3 weeks with Claude and Codex

[untitled]

[untitled]

[untitled]

YouTube's Reimagine Lets Anyone Turn a Short into an AI Video

Anthropic's code execution pattern for MCP cuts agent token usage from 150K – 2K

Ask HN: What is your CPM Target when working with Influencers?

[untitled]

[untitled]

[untitled]

[untitled]

Show HN: Developing an AI Image Editor: Challenges and Takeaways

[untitled]

[untitled]

AI's Battle in Marketing: Can We Innovate Without Losing Integrity?

LinkedIn Extends Its Ads Offering: A New Era for B2B Marketers

Ask HN: SaaS Subscription or Usage-Based Pricing?

comments