For about two years now, I’ve been continuously experimenting with so-called “Vibe Coding” development using tools like Cursor. Even at that point, the speed of creating mocks and simple applications was considerably faster than before.
However, in the past six months to a year, I feel there’s been another significant shift. Since being able to brainstorm system architecture with Claude or ChatGPT and delegate implementation and peripheral tasks through Claude Code, it’s moved beyond mere code generation to change the entire approach to system development.
Implementation Got Faster, but Getting Stuck at “Deploy and Show”
After creating a prototype, the next requirement is getting it into a state where you can show it to management or demonstrate it to clients in sales situations.
What was surprisingly challenging here was:
- What format is best for demonstration?
- How much should we consider production-ready architecture?
- How do we separate development and production environments?
- To what extent should we prepare with operations in mind?
These aspects of deployment, environment setup, and operational entry points became bottlenecks.
Real Example: New Video LMS System Reached Deployable State in About 2 Person-Days
For this system, we adopted Next.js 15 for frontend/BFF, Moodle for the LMS engine, Mux for video delivery, Zoom for live lectures, PostgreSQL for business DB, Redis for queue/cache, MariaDB for LMS-side DB, AWS ECS Fargate + Terraform for infrastructure, and Auth.js v5 for authentication.
In this development project, the speed felt like:
- Mock creation: About 3 hours
- Infrastructure design and setup: Additional 3 hours
- DB connection through E2E test completion: About 1.5 days
In other words, we reached a deployable and demonstrable state in about 2 person-days.
What This System Can Do
For learners, there are navigation paths for homepage, course catalog, course details, learning interface, my page, certificates, badges, profile settings, events, and community features. For administrators, it includes dashboard, course management, webinar management, learner management, reports, FAQ management, badge management, and other functions.
Overall, it encompasses 18 screens, 40+ APIs, 19 tables, and 28 E2E tests.
When You Let LLMs Handle Terraform and E2E, the Atmosphere Changes
Recently, I thought “Now that we’ve come this far, why not let it handle Terraform and operational scaffolding too?” When I tried this, the experience changed dramatically.
The biggest change was not having to start from a blank slate. Terraform scaffolding appears. Configuration templates can be created immediately. When you provide premises like “I want to separate dev environments at this granularity” or “Not as heavy as production, but extensible later,” it returns something sufficiently usable as an initial foundation.
The same applies to E2E testing—what was difficult just six months ago has now entered quite practical territory for quality assurance at the PoC stage.
As a Result, Bottlenecks Shifted from Implementation to “Deployment, Operations, and Decision-Making”
As AI-driven development advances and mock-ups or SaaS-like prototypes can be created in short time frames, “whether it can be implemented” is no longer the main issue.
Instead, what becomes critical are questions like:
- What do we want to validate?
- At what state can business decisions be made?
- Who are we showing this to?
- What quality level should we achieve?
- When should we start considering operations?
These are questions closer to business and management concerns.
Summary
In this new video LMS system example, we brought a system with 18 screens, 40+ APIs, 19 tables, external integrations, infrastructure, and E2E tests to a deployable state in about 2 person-days.
What AI is accelerating isn’t just code generation, but the speed to reach a state where it can be shown to management and sales, and consequently, the speed at which business quality becomes apparent.