init blog post

Author: davidabram

apps/website/astro.config.mjs

@@ -9,6 +9,8 @@ const classes = {
   summaryClass: "cursor-pointer font-bold text-[1.25rem]",
   detailsClass: "mt-[2.5rem]",
   iframeClass: "border-none w-full h-[360px] overflow-y-hidden",
+  ctaClass: "my-12 rounded-lg border-l-4 border-primary bg-primary/5 p-6",
+  ctaTitleClass: "text-xl font-semibold text-foreground mb-3",
 };
 
 const remarkPlugin = createRemarkPlugin(classes);

apps/website/src/content/posts/your-ai-prototype-is-not-a-product.md

@@ -0,0 +1,162 @@
+---
+title: "Your AI Prototype Is Not a Product"
+description: "AI prototypes help teams validate ideas quickly, but they are not production-ready software. Learn how CTOs and engineering teams can turn AI-generated prototypes into secure, maintainable products."
+createdAt: 1773156448016
+updatedAt: 1773156448016
+authors: ["david"]
+category: "AI"
+editors: ["velimir"]
+abstract: "AI prototypes are powerful discovery tools, but shipping them as products creates expensive problems later. The real job is to extract the intent, keep the useful signals, and rebuild with production standards in mind."
+image: "/images/you-should-not-measure-developer-productivity-response-to-mckinsey.png"
+draft: false
+---
+
+Your founder shows up with a working app built over a weekend.
+
+App works, even the UI looks decent. Everyone claps. 👏👏👏
+
+Then engineering opens the codebase; witness the fastest mood souring ever.
+
+AI has changed the front end of product development fast. Getting from idea to something clickable used to take weeks. Now it can take days, often just hours. That's genuinely useful. The problem starts when teams confuse **"we have a working prototype"** with **"we have a product we can ship."** Not the same thing!
+
+And if you are a CTO or engineering leader, managing that gap is becoming part of the job.
+
+## Contents
+
+## Prototypes got cheaper. Engineering did not.
+
+For a long time, the bottleneck was getting from idea to something visible. You had an idea, then wireframes, then designs, then handoff, then tickets, then implementation. That bottleneck is smaller now.
+
+Getting to a prototype is no longer in the hard part. The hard part is turning that prototype into software your team can actually own.
+
+That means software that is secure, maintainable, testable, observable, consistent with your stack, safe to deploy, and understandable by people other than the single person who prompted it into existence.
+
+## But... But it already works
+
+Yes. Kind of. It's s trap.
+
+A vibecoded prototype often works in the same way a movie set looks like a real building. From the right angle, everything is there. Open the wrong door and you are staring at plywood.
+
+You will often find things like:
+
+- duplicated business logic
+- inconsistent naming and data shapes
+- auth rules that only work in the happy path
+- placeholder persistence pretending to be a real data model
+- components that look reusable but aren’t
+- generated code that no one on the team would have written on purpose
+
+A prototype is supposed to prove movement. It is supposed to make the idea visible. It is supposed to help people react to something real instead of debating a vague concept for three weeks. That is incredibly valuable. But don't forget it is still a prototype, its sole job is to reveal intent.
+
+## Prototypes were never about the code
+
+When a founder or product person builds an app with AI, the most valuable thing they have produced is usually **not** the generated codebase. It's the intent hidden inside it.
+
+That includes:
+
+- what users are trying to do
+- which workflows matter
+- what language the business uses
+- which edge cases showed up early
+- which assumptions changed during the process
+- where the product got more complicated than expected
+
+That information is pur gold. And in a lot of cases, the prompt history is just as useful as the prototype itself. Because prompts contain the missing "why."
+
+Why was this step added?
+Why was that role introduced?
+Why does this page need that action?
+Why did this flow get split in two?
+
+That is useful product and domain knowledge. That is what engineering cares about. Keep the prototype, keep the prompt history too, but please don't confuse either of them for your production system.
+
+## Extract the Intent
+
+The right workflow is not:
+
+**prototype -> clean up a few things -> ship**
+
+It is much closer to:
+
+**prototype -> extract intent -> rebuild properly -> validate behavior**
+
+In the short term, this is slower than shipping the generated output directly, but in the medium term, it is usually much faster than inheriting a mess your team now has to maintain.
+
+Because once prototype shortcuts make it into production, they become expensive liabilities. They show up later as impossible migrations, brittle integrations, weird bugs, frontend complexity that keeps multiplying, and engineers quietly avoiding entire parts of the codebase.
+
+You can move quickly with AI, I mean you should move quickly with AI. But you still need to decide what counts as source material and what counts as source of truth. For any production systems, the source of truth still needs to be your architecture, your standards, your tests, your delivery pipeline, and your operational model.
+
+::cta Engineering leaders: want AI speed with predictability and team alignment?
+
+[Shared Context Engineering](https://sce.crocoder.dev/) is our approach for helping teams turn AI prototypes into real products by making AI agents reliably follow your team's domain knowledge, engineering decisions, and established way of building software.
+
+If you want AI-assisted delivery without drift, rework, or inconsistent output across engineers, [contact us](/contact).
+
+::endcta
+
+## What should Engineering take from the prototype
+
+The real value is in extracting what actually matters: the core ideas, the useful patterns, and the parts that proved the concept works. A prototype was always a discovery tool. The job of Engineering is to identify the signals hidden in the noise, then rebuild it properly with production standards in mind.
+
+So, what should engineering look out for?
+
+### Core user flows
+
+Forget whether the implementation is good. Look at the behavior.
+
+What is the happy path? What are the critical steps? Where are the handoffs? Which states matter?
+
+That gives engineering something much more useful than a pile of screens.
+
+### Domain concepts
+
+What entities actually exist in the system?
+
+Users? Teams? Projects? Bookings? Reports? Permissions? Statuses?
+
+AI tools often generate vague or inconsistent structures, but they still reveal what the system is trying to model.
+
+### Contracts and boundaries
+
+Where should the frontend stop and the backend begin?
+
+What API calls need to exist? What data shapes should be stable? What permissions must be enforced server-side?
+
+Engineering needs to redraw those boundaries.
+
+### Roles and permissions
+
+Who can do what?
+
+Prototypes often imply authorization rules without implementing them properly. That does not make the rules useless. It means they need to be made explicit.
+
+### Edge cases
+
+Where did the generator or prompter keep correcting behavior?
+
+Those corrections usually point to the parts where the original idea first met real-world constraints.
+
+Those are the signals engineering should catch early.
+
+## A good prototype should make engineering smarter
+
+A good prototype should not save engineering from thinking, it rather gives engineering better material to think with.
+
+It helps the team answer the important questions earlier:
+
+- Is this workflow worth building?
+- Are we solving the right problem?
+- Which states actually matter?
+- What is missing from the domain model?
+- Where will users get confused?
+- Which parts are easy to fake, but hard to operationalize?
+
+That is incredibly useful, but again only if the team treats the prototype as evidence, not as a finished product.
+
+## TL;DR
+
+AI has made product discovery much faster. What it has not done is remove the need for architecture, standards, testing, security, and ownership. If anything, those matter more now.
+
+Teams can generate "almost software" at a much higher speed, but still someone has still responsibility to decide what is actually ready to become a real product.
+
+An AI prototype can be useful, but it is still not a product.

packages/remark-plugin/index.ts

@@ -6,11 +6,15 @@ function remark({
   detailsClass,
   summaryClass,
   iframeClass,
+  ctaClass,
+  ctaTitleClass,
 }: {
   titleClass: string;
   detailsClass: string;
   summaryClass: string;
   iframeClass: string;
+  ctaClass: string;
+  ctaTitleClass: string;
 }) {
   return () => {
     return (tree: Node) => {
@@ -86,7 +90,25 @@ function remark({
         if (!node.children || node.children.length !== 1) return;
         const textNode = node.children[0];
 
-        // non h title rule
+
+        if (textNode.type === "text" && textNode.value.startsWith("::cta ")) {
+          console.log("Found CTA:", textNode.value);
+          const ctaTitle = textNode.value.substring("::cta ".length);
+          const node = {
+            type: "html",
+            value: `<aside class="${ctaClass}"><span class="${ctaTitleClass}">${ctaTitle}</span>`,
+          };
+          parent.children.splice(index, 1, node);
+        }
+
+        if (textNode.type === "text" && textNode.value.startsWith("::endcta")) {
+          const node = {
+            type: "html",
+            value: `</aside>`,
+          };
+          parent.children.splice(index, 1, node);
+        }
+
         if (textNode.type === "text" && textNode.value.startsWith("::title ")) {
           const titleText = textNode.value.substring("::title ".length);
           const titleNode = {