AI-Assisted Development Changes What Matters in Framework Selection
The two-minute deploy is killing my productivity.
That sounds wrong until you think about proportions. Two minutes is nothing. But when AI-assisted development shrinks the time spent writing code, those two-minute deploys start consuming a much larger percentage of your development cycle.
I discovered this while building with a managed backend framework that requires redeployment even during local sandbox development. The frontend rebuilds in seconds. The backend takes two minutes. Suddenly, that backend deploy time is where I spend most of my dev cycle waiting.
A caveat before going further: this observation comes from a greenfield project where I'm moving quickly and iterating frequently. AI-assisted development changes the structure of work in existing projects too, but this effect is most pronounced when building something new and small, where rapid iteration is the default.
The Cycle Time Shift
Before AI-assisted development, a typical development cycle broke down like this: writing code consumed the majority of time, with testing, building, and deploying as smaller slices. A two-minute deploy was noise in a four-hour feature implementation. According to IDC research, developers spend only 16% of their time on actual coding, with the rest consumed by operational tasks, testing, and deployment.
AI changes that math completely.
Research from GitHub found that developers using Copilot completed tasks 55% faster than those without it. With AI writing code (even accounting for review time), the code creation phase compresses significantly. But the build still takes the same time. The deploy still takes two minutes. The tests still run for however long they run.
When code writing shrinks, everything else becomes proportionally larger. Fixed-time operations that used to be rounding errors now dominate the cycle. Worth noting: not all research shows AI speeds up development. A 2025 study from METR found experienced developers were actually 19% slower when using AI tools on familiar open-source codebases. The productivity gains appear most pronounced in greenfield projects and for less experienced developers. This shift creates new quality and risk tradeoffs that didn't exist before, changing how you should approach both development practices and tool selection.
What This Means Practically
I'm spending more time watching terminals than iterating on code. The feedback loop that used to be think, write, run, debug has become prompt, review, tweak, wait, tweak, wait, debug. I use that time to revie tickets, think about what I expect the AI to return to me, and review other work plans. That's breaking flow, though.
The waiting parts didn't change. The active parts got faster.
So now I wait proportionally more. And those waiting periods have real costs. When builds or deploys force you off task multiple times a day, those interruptions compound.
This led me to optimize things I never would have bothered with before. My pre-commit hooks were running the full test suite for a monorepo (maybe 45 seconds). Totally fine when commits happened every few hours during deep coding sessions. But when AI-assisted development means I'm committing more frequently with smaller changes, that 45 seconds adds up.
I split the pre-commit checks to only run backend tests when backend code changes and frontend tests when frontend code changes. A small optimization, but it matters now that the percentage of time spent on these checks has increased.
Framework Selection Criteria Need to Change
This is the broader insight: the evaluation criteria for frameworks and languages should shift when AI is part of the workflow.
I used to care most about developer ergonomics, ecosystem maturity, and long-term maintainability. Those still matter. But now I'm also thinking about:
Rebuild speed. How fast can I see changes? Hot module replacement matters more than it used to. Frameworks with slow compilation or mandatory deployment steps for local changes become friction. A framework that rebuilds in 200ms versus one that takes 10 seconds is now a meaningful productivity difference.
Test execution time. Fast tests were always nice. Now they're critical. The difference between a 500ms test suite and a 30-second test suite compounds when you're running tests ten times more frequently. If AI-assisted development means I commit 20 times a day instead of 5, test speed becomes a first-class concern.
Deployment complexity. Serverless frameworks that require deployment to test anything are more painful than they used to be. Local-first development with fast iteration wins. Managed frameworks that abstract away infrastructure can be great for operations but terrible for development velocity when every change requires a full deploy cycle. This is why iteration speed has become such a critical evaluation criterion, especially when using AI to accelerate feature development.
Static analysis speed. Linting, type checking, and pre-commit hooks need to be fast. These used to be minor inconveniences. Now they're bottlenecks. I've started evaluating whether a language has fast incremental type checking, not just whether it has type checking at all.
Language Popularity Now Matters Differently
Here's something I didn't expect: the frontend framework I'm using is significantly more popular than the backend framework. And the AI is noticeably better at the frontend code.
This makes sense. AI models are trained on existing code. Popular languages and frameworks have more training data. The AI has seen more React components than it has seen code for my niche backend framework. It makes fewer mistakes, suggests better patterns, and requires less correction. Framework popularity directly impacts AI output quality because the model has learned from more examples of production code.
Before AI-assisted development, I chose frameworks based on what solved my technical problems best. Popularity was a factor for ecosystem reasons, but not a dominant one. Niche tools that fit the problem well were often the right choice.
Now popularity directly affects how much the AI can help. An obscure but perfect framework might mean I spend more time correcting AI mistakes, which slows down the cycle, which reduces the benefit of AI-assisted development in the first place.
This doesn't mean everyone should use React and Python for everything. But it does mean the calculation has changed. The productivity boost from AI assistance is larger for popular frameworks, and that needs to factor into decisions.
The Real Takeaway
AI-assisted development hasn't just made coding faster. It has changed which parts of the development cycle matter most.
I'm now evaluating frameworks on a different set of criteria:
- How fast is the local development loop?
- How quick is the test feedback?
- How much training data exists for AI to learn from?
- How much fixed-time overhead exists in the build and deploy process?
The frameworks that will win in an AI-assisted world aren't necessarily the ones with the best abstractions or the cleanest APIs. They're the ones that let you iterate fast when code writing is no longer the bottleneck.
Related Reading
The insights here connect to several other patterns in AI-assisted development:
- Risk Evaluation in the Age of AI-Aided Development explores how AI changes your quality assessment and code review strategy
- Quality In, Quality Out explains why framework popularity and training data directly impact AI output quality
Related Content
