{"slug": "i-don-t-need-smart-ai-to-build-apps-here-s-why", "title": "I Don't Need Smart AI to Build Apps. Here's Why.", "summary": "A developer reports that using TDK CLI, a tool that generates typed infrastructure resources (frontend, backend, worker, agent, mcp) and locks runtime files under .autogenerated/ against snapshots, lets simpler and cheaper AI agents build apps reliably because infrastructure decisions are made by the tool rather than the model. The developer says the CLI exposes the stack to agents via tdk status --json, tdk up --json and an MCP server with six tools, and shares three prompts written for fast, low-cost models.", "body_md": "I stopped reaching for the most capable model for every app. With TDK CLI, the infrastructure is already decided, so a simpler agent only has to get the application logic right.\n\nFor a long time I assumed that building an app with AI needed the best model available. Every project got the most capable assistant, the longest prompts, and the most careful review. Most of the effort went into getting the infrastructure right, not the features.\n\nI stopped doing that. I now use simpler agents for most of my app work, and the results are good enough that I rarely go back. The reason is not that the simpler models got better. It is that [TDK CLI](https://github.com/tdk-landscape/tdk-cli-core) removed most of the decisions a model used to get wrong.\n\nThis article explains what that means, where the limits are, and three prompts I use with a less capable agent.\n\nAsk a model to build a small app and it can write a handler, a component, or a query well. The trouble starts around the code:\n\n`Dockerfile` that builds but runs the wrong command,`docker-compose.yml` whose ports disagree with the proxy config,\nEach of these costs a debugging round. A smarter model makes fewer of them, so people paid for smarter models. The cost of that is real: more tokens, more waiting, and more review of output that is only infrastructure.\n\nWhat I needed was not a smarter model. I needed the infrastructure to stop being a question.\n\nTDK CLI treats each service as a typed resource. You declare what kind of thing you are building, and the generator fills in the rest.\n\nThe resource types are listed by `tdk resource --help`:\n\n`frontend`` backend``worker`` agent``mcp`` bring-your-own``sdk`\nEach type comes with decisions already made. A frontend gets an API client and an environment config. A backend gets health routes, a port read from the environment, and a binding to every interface, so it runs inside a container without extra work. An MCP service gets a server that creates a fresh instance per request, so there is no session to lose on restart.\n\nThe generated runtime files are then fixed by the tool, not by the model. For a frontend, that is 18 files under `.autogenerated/`, each marked as generated, and each checked against a saved snapshot before the stack starts. I counted them in a scratch project. The agent does not have to write them, and it cannot quietly drift from them without `tdk up` blocking the change.\n\nOnce the infrastructure is decided, the agent's job narrows to three questions:\n\n`tdk up` starts it?\nA less capable model can answer those. It does not need to remember which port the proxy expects, or which Dockerfile layer caches the dependencies. The tool answers those questions the same way every time.\n\nThe repo also writes some rules down where an agent will read them. The contributor guidance says new examples run database migrations in a separate `migrator` resource, not in the API's startup, and that `tdk doctor` warns when a backend runs a migration from its start script. That is one of the mistakes a capable model makes often, and the rule is there whether or not the agent remembers it.\n\nTDK also exposes the stack to agents directly. `tdk status --json` reports readiness. `tdk up --json` reports `ok: false` with errors. `tdk mcp` gives an agent six tools (`doctor`, `up`, `down`, `status`, `logs`, `resource_list`), so it checks the result instead of trusting its own summary.\n\nThese are the prompts I use. They are written for a model that is fast and cheap, not one that reasons deeply about infrastructure. Each one assumes TDK CLI is installed and the project was created with `tdk project`.\n\n```\nCreate a frontend resource called \"shop-web\" with tdk, using React.\nRun: tdk resource shop-web --type frontend -y\n\nThen open services/main/shop-web/src/App.tsx and build one page:\na product list that fetches from the API client in .autogenerated/api-client.ts\n(do not write your own fetch URL). Show loading and error states.\nDo not edit anything in .autogenerated/. Do not change service.json.\nWhen done, run: tdk up main --dry-run and report what it says.\n```\n\nWhy it works: the agent has one file to change, one client to use, and a command to check the result. The rule against editing `.autogenerated/` matches what the tool enforces anyway.\n\n```\nCreate a backend resource called \"orders\" with tdk, using Hono.\nRun: tdk resource orders --type backend -y\n\nAdd a GET /orders route that returns a JSON array. Keep the data in memory for now.\nAdd a GET /health route if one is not already there.\nDo not change the port or the health path in service.json.\nThen run: tdk up main --dry-run, and tell me which services it would start and in what order.\n```\n\nWhy it works: the agent builds the route and leaves the infrastructure alone. The dry run is a check the agent can read back.\n\n```\nCreate a worker resource called \"order-emails\" with tdk.\nRun: tdk resource order-emails --type worker -y\n\nGive it a loop that logs \"processing\" every five seconds.\nMake it depend on the orders service by adding it to dependsOn in its service.json.\nThen run: tdk up main --dry-run and confirm that orders starts before order-emails.\nIf the dry run shows any error, stop and report it instead of changing other files.\n```\n\nWhy it works: the dependency is declared, not hoped for. The agent checks the start order against what the tool reports, and it has a clear stop condition if something fails.\n\nNote that the dry-run flag and the exact start-order output come from the CLI. Run the prompts once on your machine to confirm the output matches before you rely on them.\n\nThis approach is not magic. I want to be clear about the limits.\n\nMost of my time used to go into infrastructure review, not features. With TDK, that review mostly disappears, because the decisions are made by the generator and checked by `tdk up`. What is left is application code, and a simpler model does that well when the prompt is clear.\n\nThe savings are real. Smaller models cost less per token, respond faster, and make it easier to run several agents at once on different services. The tradeoff is that I review the application logic more closely, because I no longer assume the model got the hard parts right.\n\nThat is the whole argument. The tool carries the infrastructure, the prompt carries the feature, and I carry the judgment about the logic.\n\n```\nnpm install -g @tdk-landscape/tdk-cli-core\ntdk project --yes\ntdk resource shop-web --type frontend -y\ntdk up main --dry-run\n```\n\nThen give your agent the first prompt above, and check the result against the dry run. If it works, the next two prompts follow the same pattern.", "url": "https://wpnews.pro/news/i-don-t-need-smart-ai-to-build-apps-here-s-why", "canonical_source": "https://dev.to/mynameis0d3c53a3/i-dont-need-smart-ai-to-build-apps-heres-why-4249", "published_at": "2026-10-18 12:38:58+00:00", "updated_at": "2026-10-18 12:46:56.489921+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "agent-protocols", "ai-products"], "entities": ["TDK CLI", "tdk-cli-core", "GitHub", "React", "Docker"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/i-don-t-need-smart-ai-to-build-apps-here-s-why", "markdown": "https://wpnews.pro/news/i-don-t-need-smart-ai-to-build-apps-here-s-why.md", "text": "https://wpnews.pro/news/i-don-t-need-smart-ai-to-build-apps-here-s-why.txt", "jsonld": "https://wpnews.pro/news/i-don-t-need-smart-ai-to-build-apps-here-s-why.jsonld"}}