Vibe Coding Frameworks: Do You Still Need Them? CTO View

AI removes some typing, but ownership remains

The argument for dropping frameworks is simple: if an agent can generate the code, why accept someone else's rules? That argument focuses on the first version. Our concern is what happens when the software changes or breaks.

Frameworks save repetitive work, and AI reduces that benefit. But someone must still check the result and explain it to the next engineer. In our Web Development work, those handovers and later changes matter when choosing the foundation.

The word "framework" also groups together tools with different jobs:

• Server frameworks, such as Laravel, Spring Boot, and Django, organize application logic and data access.
• Interface tools, such as Vue.js and Next.js, help build the parts users interact with.
• Go Fx connects application components and manages their startup and shutdown.
• Libraries provide a narrower function that an application calls when needed.
• SDKs provide ready tools for an external API, the interface through which systems exchange requests and responses.
• Agent frameworks coordinate AI models, tools, and steps in a workflow.

A reason to avoid one small SDK is not a reason to abandon an entire application framework.

Mature frameworks give AI agents a known structure

Mature AI-assisted development frameworks give the team and the agent ready components, documentation, and diagnostic tools. That leaves more attention for business rules. In our experience, this structure becomes especially useful when the application needs years of support.

Ready components and shared rules

Server frameworks and their ecosystems cover common needs:

• Sending an incoming request to the right code.
• Reading and writing database records.
• Checking submitted data.
• Managing users and access rights.
• Running background jobs through queues.

A crm system manages customer relationships. Its customer assignment rules may be unique to the business. The basic machinery for receiving requests and checking input usually does not need a fresh design.

Shared conventions also show an agent where a change belongs. An engineer familiar with Django or Laravel starts with a useful map of the project. A homemade foundation requires that map to be learned first.

Documentation helps people and agents

Official documentation and worked examples give an agent useful references. Community discussions can also explain known failure cases. With a custom foundation, the team must create and maintain more of that knowledge itself.

Widely used frameworks receive public scrutiny and fixes. Popularity does not guarantee security, though. Correct configuration and timely updates remain the team's responsibility.

Using existing components might also reduce an agent's generated code and token use. I treat that as a possibility for individual tasks, not a measured cost saving.

Diagnostics matter when something breaks

A failed background job is easier to investigate when the tools already exist. Mature ecosystems offer practical ways to inspect application behavior:

• Laravel Horizon monitors Redis-backed job queues.
• Laravel Telescope helps inspect requests, errors, and database activity.
• Spring Boot Actuator provides application health checks and metrics.

Uber Fx serves a different purpose. It manages component dependencies and lifecycle in Go. It provides structure, rather than replacing those monitoring tools.

These tools matter most to us during production incidents. That is a poor time to start building a way to see what the application is doing.

Vibe coding without frameworks fits small, bounded tasks

Vibe coding without frameworks makes sense when the task needs little infrastructure. A one-off script or small utility may be easier to understand and maintain as a minimal program. A large framework can add more work than it removes.

For example, a script that converts a local CSV file into another format may need only a standard library. Adding an application framework introduces setup and updates without helping the task.

I would compare the work across the solution's whole life:

• Learning and integrating the chosen tools.
• Testing normal behavior and failures.
• Applying updates and security fixes.
• Handing the code to another engineer.

Anthropic's guidance on building effective agents also favors simple, composable solutions. It mainly concerns agent orchestration, not web frameworks such as Laravel or Django. The useful lesson is to avoid layers that add no value.

If a prototype becomes a permanent service, review its architecture again. A program used once has different support needs from a service customers rely on every day.

A small SDK needs its own maintenance check

An SDK can save integration work, but its value depends on its coverage and maintenance. A package maintained by one or two people may fall behind the external API. Your team can then inherit work it expected the package to handle.

Before choosing an SDK, I would look for these warning signs:

• Long gaps between updates while the API keeps changing.
• Missing methods that the product needs.
• Weak tests, especially for errors.
• Hidden request or response details needed for debugging.
• A design that forces awkward changes elsewhere in the application.

For SDK vs custom API integration, AI changes the initial effort of building a narrow client. A weak package no longer wins simply because it already exists. A well-maintained SDK can still be the better choice.

Binance and Bitget showed us two different ownership costs

We support a high-load platform for algorithmic trading and market analysis. A third-party Binance SDK helped us start, then became code we had to maintain ourselves. For Bitget, we used AI agents to build a narrow client of our own.

These are our team's experiences with specific integrations. They are not an external audit of either exchange or a verdict on their SDK ecosystems.

Binance: from ready package to our own fork

The Binance package already covered the functions we needed first. That saved initial implementation work.

Later, it lagged behind the API and lacked methods we needed. Its structure also limited how we wanted to organize the integration. We created a fork, our own copy of the package, so we could change it.

We then owned the work of extending and maintaining someone else's code. The original shortcut had become technical debt: a choice that made later changes more expensive. That lesson concerns this package in this project.

Bitget: a narrow client built with agents

For Bitget, we chose our own client. The agents worked from the API documentation and checked how the service behaved:

• They ran real requests and requests in the test environment.
• They checked test operations.
• They tested WebSocket connections, which keep a connection open for ongoing updates.
• They recorded differences between documented and observed behavior in a README and a report.

By my estimate, we had a working base in about one working day. The API had detailed documentation and a test environment. We also kept the required set of functions small.

That timing belongs to this project. The first day's result still needed further testing and work to handle failures reliably.

What remains our responsibility

Owning the client gives us control over its design. It also leaves us responsible for every failure path:

• Error handling: deciding what happens when a request fails or receives an unexpected response.
• Retries and idempotency: making sure a repeated request does not perform the same operation twice.
• Request limits: staying within the exchange's allowed request rate.
• Connection recovery: reconnecting after a dropped connection and checking for missed updates.
• Key protection: keeping credentials out of source code and logs.
• Testing and support: checking changes as the API and our application evolve.

AI coding research gives context, not a framework verdict

The studies below do not directly settle the framework question. They show that AI's effect depends on the task and tools, and that generated code needs checking. My architectural judgment is separate from those findings.

Speed depends on the setting

In METR's 2025 experiment, 16 experienced developers completed 246 tasks in mature open-source projects. With early-2025 AI tools, they took 19% longer. That result describes this setting, not all developers.

METR's 2026 update discusses selection bias: who joins an experiment and which tasks they bring can distort the result. The researchers say newer tools are probably more useful. They also explain why measuring the current effect reliably is difficult.

A Google experiment with 96 engineers estimated about a 21% reduction in task time in a particular company setting. That estimate had substantial uncertainty. There is no single AI productivity number that tells us which architecture to choose.

Trust and security require checks

In the Stack Overflow Developer Survey 2025, about 66% of respondents to the AI frustration question selected answers that were "almost right, but not quite." On accuracy, 46% distrusted AI output and 33% trusted it. These are responses to separate questions, not measurements of code quality.

Comparisons with the 2026 survey require matching question wording and respondent groups. Trust when an answer is easy to verify is different from general trust in accuracy.

Security vendor Veracode reported insecure results in about 45% of its selected generation tasks. The tasks tested security-sensitive coding scenarios. The figure does not describe 45% of all AI-generated software.

My practical inference is to limit unnecessary custom security-sensitive code. Reusing maintained components reduces the new implementation we must inspect. Application-level security testing remains necessary.

Keep structure and question extra layers

OpenAI's Harness engineering case describes agent-led development supported by architectural boundaries and documentation. It also emphasizes automated checks, metrics, and tools for observing system behavior. It is one company's experience, not a comparison of web frameworks.

I see a shared principle in that case and Anthropic's guidance: give agents clear rules and avoid needless layers. Mature frameworks can provide those rules. The team still has to decide which parts the project actually needs.

Framework vs custom code: weigh complexity and support

I start with two questions: how complex is the system, and how much must it fit special requirements? Then I assess the cost of supporting it. AI changes implementation effort, but it does not make that decision for us.

For complex B2B systems, the hybrid is often our preferred approach. We retain a mature application foundation and build selected integrations ourselves. A good library or SDK can fill those gaps when it fits.

This matrix is a guide, not a rule. Check the actual package and API. Use established implementations for cryptography and critical infrastructure rather than asking an agent to invent replacements.

In our web design & development services, this choice is part of planning long-term support. A useful final question is: who will understand and maintain this code in two years?

Choose the foundation you can keep supporting

For complex software, I still favor mature frameworks with small custom components where they earn their place. For a bounded script, I favor a minimal solution. The deciding factor is the work of owning the result after the first version runs.

Discuss the architecture and long-term support of your business-critical software with Webdelo.