惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Google DeepMind News
Google DeepMind News
C
Check Point Blog
J
Java Code Geeks
腾讯CDC
Martin Fowler
Martin Fowler
MongoDB | Blog
MongoDB | Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
博客园 - 三生石上(FineUI控件)
Apple Machine Learning Research
Apple Machine Learning Research
大猫的无限游戏
大猫的无限游戏
Engineering at Meta
Engineering at Meta
罗磊的独立博客
Last Week in AI
Last Week in AI
B
Blog
IT之家
IT之家
S
SegmentFault 最新的问题
D
DataBreaches.Net
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
GbyAI
GbyAI
博客园 - 聂微东
U
Unit 42
有赞技术团队
有赞技术团队
Y
Y Combinator Blog
MyScale Blog
MyScale Blog

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
Shipping full-stack apps from a prompt: what AI gets righ...
Ruslan Ianberdin · 2026-06-26 · via DEV Community

AI app builders crossed a line in the last year. They went from generating throwaway demos to scaffolding apps people actually deploy and charge money for. I've been shipping full-stack apps this way, and the honest engineering picture is more interesting than either the hype or the backlash. Here's the breakdown.

What the model reliably gets right

The boring 80% is genuinely solved:

  • Scaffolding and routing. A coherent project structure, sane file layout, a working router. No more staring at an empty directory.
  • CRUD and boilerplate. Endpoints, form handling, validation stubs, an auth flow that works on the first run.
  • Schema-to-UI. Give it a data shape and it wires up the list/detail/edit screens that would have eaten your afternoon.
  • Deploy config. Build scripts, env wiring, the stuff everyone copies from a previous project anyway.

If your reaction is "that's just the easy part" - that's exactly the point. The easy part is most of the typing.

Where you still have to think

The model produces a plausible answer, not the correct one for your domain. Four places it consistently needs a human:

  1. Data modeling. It will pick a reasonable-looking schema, but your invariants, relationships, and what-must-never-happen rules are domain knowledge it doesn't have. Review the data model before you look at a single screen.
  2. Edge cases and error states. The happy path is free. Empty states, partial failures, concurrent edits, the 3am "what if this is null" cases - those are still yours.
  3. Security boundaries. Authorization (not just authentication), input validation at trust boundaries, and "can user A read user B's row" are where generated code is most confidently wrong. Read every access check.
  4. Behavior under real load. The query that's fine with 10 rows and melts at 100k. Profiling is human work.

The part people underestimate: running it

A generated app isn't done when it renders locally. It's done when it has a real backend, a database, HTTPS, a custom domain, and a way to undo a bad deploy. That last one matters most: the first time an AI-assisted change breaks prod, one-click rollback is the difference between a shrug and an outage. This is the half of the problem the "watch it build a landing page in 30 seconds" demos skip - and it's the half that decides whether you can actually trust the output. A platform like Playcode Cloud runs the generated app with the database, hosting, previews, and snapshots already wired, so "ship it" and "roll it back" are buttons, not a weekend.

A workflow that holds up

What's worked for me:

  • Describe the outcome, not the stack. "An appointment booking app for a salon with SMS reminders," not "a Next.js app with a Postgres table."
  • Review the data model first, UI second. If the schema is wrong, every screen is wrong.
  • Deliberately test the error paths before the happy path. That's where generated code is thin.
  • Ship behind previews, keep snapshots, and treat rollback as a normal operation, not an emergency.

The takeaway

AI doesn't remove engineering judgment - it relocates it. You spend less time typing boilerplate and more time reviewing decisions: is this schema right, is this access check correct, what happens when this fails. That's a better use of the hours, but it's still engineering.

If you want to try the describe-it-and-it-builds-it loop on a real full-stack app, with the backend and hosting handled for you, that's what Playcode is built for. Either way: let the model write the boilerplate, and keep your judgment on the parts that decide whether the app actually works.