{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihietemn4ie7tqxd4nd6qy4ys7f7bnw3ljn76tas33falohpudm5i",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mpmckh6ysqe2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreicvek2vksyrbjetihaiscv5hguafgrv75rvcklppjgcnclosf7zke"
    },
    "mimeType": "image/webp",
    "size": 573554
  },
  "path": "/ayush_dubey/stop-asking-ai-to-write-code-start-asking-it-to-design-applications-1m0g",
  "publishedAt": "2026-07-01T19:20:32.000Z",
  "site": "https://dev.to",
  "tags": [
    "ai",
    "architecture",
    "softwareengineering",
    "systemdesign",
    "https://trillo.ai/contact"
  ],
  "textContent": "_Disclosure: I work on Trillo AI. This post explains the problem we're trying to solve and how our approach differs from typical AI coding tools; take the framing with that in mind._\n\nAI coding assistants like Claude Code, GitHub Copilot, Cursor, and Gemini have gotten very good at one thing: turning a prompt into working code. Given a clear spec, they'll generate a function, fix a bug, or scaffold a small app in seconds.\n\nBut if you've built enterprise software, you know that writing code is the _easy_ part. The hard part happens before the first line is written:\n\n  * What are the business entities and how do they relate?\n  * What's the application architecture?\n  * What APIs does this need?\n  * What's the auth and authorization model?\n  * Where do AI agents run, and what do they need access to?\n  * How does this get deployed, monitored, and scaled?\n\n\n\nAnswering these questions is what actually eats weeks or months on enterprise projects — not typing out functions. And most AI coding tools don't touch this part at all. They wait for you to hand them a fully-formed spec, then generate code against it.\n\nWe think that's backwards. This post is about why, and about **Trillo AI** , which we built around the opposite order of operations: design first, code second.\n\n##  The bottleneck isn't code generation\n\nEvery enterprise has a backlog of ideas waiting to become software — a vendor portal, an internal workflow tool, a logistics dashboard, an AI assistant for support tickets. The path from idea to production usually looks like:\n\n\n\n    Discovery → Architecture review → Data modeling → API contracts\n    → Security review → Compliance check → (finally) development\n\n\nEven with a great coding assistant, someone still has to do all the steps before \"development\" — and that's usually where the calendar time actually goes. Speeding up the coding step doesn't move the bottleneck; it just makes you wait faster for the same planning phase.\n\n##  What \"blueprint-first\" means, concretely\n\nInstead of generating files, Trillo AI generates a structured application blueprint from a natural-language description — the same kind of intermediate artifact an architect would sketch on a whiteboard before anyone opens an IDE.\n\nFor example, given a prompt like:\n\n> \"Build a vendor management platform where suppliers register, upload compliance documents, get approved, and message procurement teams. Add an AI agent that validates uploaded documents and flags missing information.\"\n\nTrillo generates a blueprint that includes entities and relationships, business functions, API surface, and agent definitions — something along these lines (simplified):\n\n\n\n    entities:\n      Vendor:\n        fields: [name, taxId, status, contactEmail]\n        relations: { hasMany: ComplianceDocument }\n      ComplianceDocument:\n        fields: [fileUrl, docType, status, uploadedAt]\n        relations: { belongsTo: Vendor }\n\n    functions:\n      - submitVendorApplication(vendorInput) -> Vendor\n      - uploadComplianceDocument(vendorId, file) -> ComplianceDocument\n      - approveVendor(vendorId, reviewerId) -> Vendor\n\n    agents:\n      DocumentValidatorAgent:\n        trigger: on ComplianceDocument.created\n        action: validate document, extract required fields\n        on_missing_fields: notify(Vendor.contactEmail)\n\n    apis:\n      - POST /vendors\n      - POST /vendors/:id/documents\n      - GET /vendors/:id/status\n\n\nThat blueprint — not raw source code — becomes the shared source of truth for the team. It's editable and reviewable before anyone commits to an implementation, which is a much cheaper place to catch a wrong assumption than three sprints into development.\n\n##  Coding assistants still do the coding\n\nThe blueprint doesn't replace Claude Code, Copilot, or Cursor — it feeds them. Once entities, relationships, and business logic are defined, your coding assistant has a real spec to implement against instead of having to infer the data model from a vague prompt. In practice this means fewer mismatched assumptions between what you meant and what the assistant generated.\n\n##  Production is where most AI-generated apps stall\n\nA prototype that works on localhost and an application that's actually safe to run in production are very different things. The gap between them is usually:\n\nConcern | Typically requires\n---|---\nAuth & RBAC | Custom implementation or a third-party identity provider\nAudit logging | Bolted on after the fact, often inconsistently\nAPI hosting & scaling | Infra setup, load balancing, deployment pipeline\nAgent execution | Sandboxing, rate limits, monitoring\nCompliance | Manual review, usually late in the process\n\nThis is the part that quietly consumes more engineering time than the original feature ever did. Trillo pairs the blueprint engine with **Trillo AOS** (Application Operating System) — a runtime that every generated application deploys onto, so auth, RBAC, audit logging, email/SMS, webhooks, event processing, scheduling, serverless APIs, agent execution, and databases (relational, vector, graph) are already there rather than re-integrated per project. Each app runs in its own sandbox but shares the same underlying platform, security model, and observability — API performance, agent execution traces, event logs, and infra health in one place.\n\n##  How this differs from low-code platforms and BaaS tools\n\nIf you're thinking \"isn't this just Retool / Supabase / Amplify with extra steps\" — the honest answer is there's overlap, and it's worth being specific about where:\n\n  * **Low-code builders** (Retool, etc.) are mainly UI-first: you assemble screens against existing data sources. Trillo starts from a data/business model and agent definitions, not a screen builder.\n  * **BaaS platforms** (Supabase, Firebase) give you backend primitives (DB, auth, functions) that you wire together yourself. Trillo's blueprint layer generates the data model, business logic, and agent definitions from a natural-language spec, then deploys onto a platform with those primitives built in — closer to \"backend-as-a-service plus the design step\" than either alone.\n  * **AI coding assistants** generate code directly from a prompt with no intermediate architecture artifact. Trillo generates the architecture first and hands the coding assistant a spec to implement against.\n\n\n\nNone of these are strictly better or worse — they solve different parts of the stack. Trillo is aimed specifically at the planning-to-production gap for internal/enterprise tools, not at replacing a general-purpose coding assistant or a consumer app builder.\n\n##  Where this is going\n\nThe workflow we think wins over the next few years looks like:\n\n  1. Describe the business problem in plain language.\n  2. Generate an application blueprint (entities, logic, APIs, agents, architecture).\n  3. Use an AI coding assistant to implement against that blueprint.\n  4. Deploy to a platform that already has auth, compliance, and observability built in.\n  5. Monitor and evolve the app from real usage data.\n\n\n\nCode generation alone speeds up step 3. The bigger unlock is compressing steps 1, 2, 4, and 5 too — because in enterprise software, the blueprint is usually what determines whether the code becomes a working application or a demo that never ships.\n\nIf you want to try the blueprint step on a real prompt, or want to see the AOS deployment side, contact us at https://trillo.ai/contact. Happy to answer questions or dig into specifics in the comments.",
  "title": "Stop Asking AI to Write Code. Start Asking It to Design Applications."
}