2
8 Comments

Why "just use AI to buildit" usually isn't enough

A client came to me two months ago with an idea and no product. Today it brings in sales daily, on autopilot. Around $20k in two months.

The build wasn't the hard part. What actually made the difference:
We validated the idea before building, not after. Shipped a lean version fast instead of chasing perfect. Automated the flow so revenue comes in without manual work.

Here's the thing I keep seeing: founders assume the bottleneck is writing the code, so "AI can build it now" feels like the whole problem is solved. But the code was never the hard part. The hard part is deciding what to build, what to cut, what order to ship in, and where the thing breaks at scale. That's architecture and judgment, not typing.

An AI-generated product with no one thinking through those decisions rarely survives contact with real users. Someone has to own it end to end, less a coder, more a solution architect.

Curious if others have seen this: where does an AI-built or hastily-shipped product usually fall apart first for you?

on July 15, 2026
  1. 1

    The part people skip is that AI can generate code fast, but it has zero memory of why your team rejected an approach six weeks ago. So you end up re-explaining context every single session, which eats most of the time savings.

    I've seen this hit teams harder than solo builders honestly. One person can hold context in their head.

    A team of four with an AI in the loop needs that context written down somewhere the AI and the humans can both pull from, or you're just generating plausible code that ignores decisions you already made.

    Full disclosure, this is basically why I'm building what I'm building.

    Speed of generation was never the bottleneck, memory was.

    1. 1

      "Speed of generation was never the bottleneck, memory was" is a sharp reframe. And you're right it hits teams harder, solo you hold the why in your head, but four people plus an AI with no shared memory of past decisions means everyone's re-litigating settled calls. The AI confidently regenerates the approach you already rejected because nothing told it you did. That's a real gap. What's the product?

  2. 1

    Usually the moment it hits an edge case the prompt never covered and nobody understands the code well enough to fix it.
    What was the product though? $20k in two months on autopilot is doing a lot of lifting in that first line.

    1. 1

      Fair to press on it. It's an electronic filing system for a specific compliance niche, "autopilot" just means the filing and quote flow runs without manual work, not passive magic. The $20k is the client's revenue over the period. And your edge-case point is spot on: the prompt covers the demo path, then a real user hits something unplanned and nobody understands the code well enough to fix it. That's exactly where it breaks.

  3. 1

    On the big picture, I agree, but I'd push back on the "breaks at scale" part. In my experience, it breaks way before scale. The first real user is usually enough. The model optimizes for "works in the demo," so access control, auth edge cases, and exposed keys get skipped, and those blow up the moment someone who isn't you touches it. Feels less like a scale problem and more like nobody checked the boring stuff before shipping.

    1. 1

      Fair correction, "at scale" was lazy on my part. You're right it breaks at user one. The model optimizes for "works in the demo," so auth edge cases, access control and exposed keys never get considered because the demo never had a second user. Nobody checked the boring stuff is more accurate than any scale argument.

  4. 1

    Not at scale, in my experience. Much earlier, and much more boring than that.

    Recently I built a scanner that checks live sites from the outside, so I see a lot of shipped products. The first issues are always the same: dependencies frozen at whatever version they were generated with, each with publicly known CVEs (Common Vulnerabilities and Exposures). Security headers are often not set. SSL certificates expiring quietly.

    Worst one I've found live is a WordPress core version old enough to carry 158 known issues.

    None of that is an architecture problem. On day one it all works, and it keeps working until it quietly becomes exploitable while everyone assumes it's fine.

    So maybe it's less "less a coder, more a solution architect" and more "someone has to still care even after half a year".

    AI made software development shorter, but it didn't make the decay slower.

    1. 1

      This is the sharper version and I'll take it. "AI made development shorter, it didn't make the decay slower" is the whole thing in one line. Frozen dependencies with known CVEs, expired certs, missing headers, none of that is architecture, it's just nobody owning it past launch. Day one it works, month six it's exploitable, and the gap is that shipping felt like finishing. A WordPress core with 158 known issues is a grim proof point.