DEV Community: Alexander Valenchits

We Shipped an MVP With Vibe-Coding. Here's What Nobody Tells You About the Aftermath

Alexander Valenchits — Tue, 21 Apr 2026 14:25:30 +0000

This one's for mid-to-senior developers wondering where they stand in the age of AI.

There's an endless debate in the IT world: will AI replace developers? I'm a tech lead at AluSoftBel, and I want to share my perspective — both as a developer and as someone who works directly with business stakeholders. Spoiler: the answer might surprise you.

The Uncomfortable Truth About AI-Generated Code

Let me be straight: the quality of code AI models produce is poor. But here's the other side of the coin — since AI arrived, businesses have felt the speed of development increase, and now they want more features, faster.

This creates a classic conflict of interests. Business wants to earn more money. Developers want maintainable, quality code — so we don't shoot ourselves in the foot later. Both sides are right. The question is how to balance them.

How We Actually Use AI: A Real-World Workflow

Let me walk you through the approach we landed on at our company.

Phase 1: MVP First — Quality Later

Step one is always an MVP. Fast, hardcore, zero regard for quality. The only goal: ship a working product that can be sold.

Yes, you end up with technical debt. Yes, it's messy. But the product hits production quickly, it works — somehow — and that's enough to build on. You can show it at a presale, close a deal, get a budget approved.

The key insight: an MVP doesn't just give you a demo. It gives you a real working product where you can see what's strong, what's weak, and course-correct before serious money is invested.

Phase 2: Sell It, Then Plan For Real

Once the product is sold, the tech lead, business analyst, and PM sit down and build a real development plan. I look at technical implementation, the analyst looks at business requirements. We're not guessing anymore — we're working with concrete, real-world cases and filing down what already exists.

Simultaneously, the business side collects real user feedback: what works, what doesn't, what's frustrating. Not assumptions — live cases. From these, the PM and analyst build a proper spec with clear requirements and a real product vision. Only then does full-scale development begin.

Phase 3: Dealing With the Aftermath

Now comes the technical debt cleanup. In my case, the MVP was pure vibe-coding — a term for AI-assisted, low-oversight rapid prototyping. The code was rewritten 3–4 times, leaving behind dead models, orphaned database tables, unused libraries, and broken legacy code.

After the cleanup comes decomposition into a proper tech stack — moving everything into a structured architecture based on actual design patterns. From chaos to order. This is the work AI simply cannot do.

The Real Costs: Pros and Cons

❌ Cons

Overhead on one or two people. Someone has to carry a massive workload alone, fall out of their normal rhythm, work overtime. In my case — that was me.
Technology chosen on the fly. Libraries with a handful of GitHub stars, experiments run directly in production, no upfront research. Everything was battle-tested the hard way — and that costs time and sanity.
The team still pays the price. After the MVP, the whole team has to sit down, read through the messy code, and redo the decomposition. The "fast start" delays the pain — it doesn't eliminate it.

💬 Sound familiar? Drop a comment — I'm curious how your team handles the post-MVP cleanup.

✅ Pros

Business gets a proof of concept for relatively little money. If the idea works, they invest properly and build a real product. If it doesn't — losses are minimal. It's essentially the Lean Startup model in practice.
The team gets a project, investment, and — let's be honest — work. In today's climate of automation anxiety, that last point matters more than people admit.
We cleared almost all of our company's technical debt using this approach. AI accelerated the start, but the people cleaned up and built what lasts.

So, Will AI Replace Developers?

Based on my experience: no — and here's why.

The number of products being built is going to grow. Which means the amount of work is going to grow. The cycle looks like this: AI helps spin up an MVP quickly, it gets validated, it gets launched — and then someone still has to build something that actually works at scale.

Because AI is prone to mistakes when designing databases, choosing indexes, picking architectural patterns, and selecting the right tech stack. These aren't edge cases — they're the core of every serious product. In the end, developers — senior and junior alike — will come in and fix it, extend it, maintain it. AI creates work. It doesn't eliminate it.

Yes, there's a market dip right now, and it will probably continue for a while. But my bet is that the economy will recalibrate — and we're heading toward a genuine boom in software development and technology.

The developers who will thrive aren't the ones who refuse to use AI. They're the ones who know how to wield it — and how to clean up after it.

TL;DR

AI code quality is poor, but it's fast enough to validate ideas
Use vibe-coding for MVP → sell → then rebuild properly
The "fast start" creates real overhead for real developers
AI increases the number of products → increases demand for developers
Learn to use AI as a tool, not a replacement

Have you shipped a vibe-coded MVP? Did the cleanup take longer than the build? Drop a comment — let's compare war stories.

Stop Writing CRUD Boilerplate for FastAPI — Use ViewSets Instead

Alexander Valenchits — Tue, 21 Apr 2026 09:34:37 +0000

If you're building REST APIs with FastAPI, you've probably written this code dozens of times: a router, a list endpoint, a get-by-id endpoint, a create, an update, a delete… and then you do it all over again for the next resource. And the next. And the next.

There's a better way. Meet fastapi-viewsets — a library inspired by Django REST Framework's ViewSets that lets you generate all six standard CRUD endpoints from a single class with one method call.

The Problem: FastAPI CRUD Is Verbose by Design

FastAPI is fantastic for building APIs. It's fast, it's type-safe, it generates OpenAPI docs automatically. But it's deliberately low-level — it gives you routing primitives, not conventions. That means every resource you build looks roughly like this:

from fastapi import APIRouter, Depends, HTTPException
from sqlalchemy.orm import Session
from typing import List

router = APIRouter()

@router.get("/items", response_model=List[ItemSchema])
def list_items(limit: int = 10, offset: int = 0, db: Session = Depends(get_db)):
    return db.query(Item).offset(offset).limit(limit).all()

@router.get("/items/{id}", response_model=ItemSchema)
def get_item(id: int, db: Session = Depends(get_db)):
    obj = db.query(Item).filter(Item.id == id).first()
    if not obj:
        raise HTTPException(status_code=404, detail="Not found")
    return obj

@router.post("/items", response_model=ItemSchema)
def create_item(item: ItemSchema, db: Session = Depends(get_db)):
    obj = Item(**item.dict())
    db.add(obj)
    db.commit()
    db.refresh(obj)
    return obj

@router.patch("/items/{id}", response_model=ItemSchema)
def update_item(id: int, item: ItemSchema, db: Session = Depends(get_db)):
    obj = db.query(Item).filter(Item.id == id).first()
    if not obj:
        raise HTTPException(status_code=404, detail="Not found")
    for key, value in item.dict(exclude_unset=True).items():
        setattr(obj, key, value)
    db.commit()
    db.refresh(obj)
    return obj

@router.delete("/items/{id}")
def delete_item(id: int, db: Session = Depends(get_db)):
    obj = db.query(Item).filter(Item.id == id).first()
    if not obj:
        raise HTTPException(status_code=404, detail="Not found")
    db.delete(obj)
    db.commit()
    return {"status": "ok"}

That's ~50 lines of nearly identical logic. And you'll write it again for users, orders, products, categories... You get the idea.

The Solution: fastapi-viewsets

fastapi-viewsets brings DRF-style ergonomics to FastAPI. Instead of repeating yourself, you declare one class, call .register(), and all the endpoints are wired up automatically — complete with Pydantic validation, OpenAPI docs, and proper HTTP semantics.

Here's the same resource from above, rewritten with the library:

from fastapi import FastAPI
from pydantic import BaseModel, ConfigDict
from sqlalchemy import Column, Integer, String

from fastapi_viewsets import BaseViewset
from fastapi_viewsets.db_conf import Base, engine, get_session

app = FastAPI()

class Item(Base):
    __tablename__ = "items"
    id = Column(Integer, primary_key=True)
    name = Column(String(255), nullable=False)

class ItemSchema(BaseModel):
    model_config = ConfigDict(from_attributes=True)
    id: int | None = None
    name: str

Base.metadata.create_all(bind=engine)

items = BaseViewset(
    endpoint="/items",
    model=Item,
    response_model=ItemSchema,
    db_session=get_session,
    tags=["items"]
)
items.register(methods=["LIST", "GET", "POST", "PATCH", "DELETE"])
app.include_router(items)

That's it. ~20 lines instead of ~50, and you get the same 5 endpoints. The more resources you have, the more time you save.

What Gets Generated

A single .register() call produces these routes (using LIST, GET, POST, PATCH, DELETE):

Method	Path	Description
`GET`	`/items`	List all items (paginated)
`GET`	`/items/{id}`	Get single item by ID
`POST`	`/items`	Create a new item
`PATCH`	`/items/{id}`	Partial update (only provided fields)
`PUT`	`/items/{id}`	Full replacement
`DELETE`	`/items/{id}`	Delete by ID

Built-in pagination is included on the LIST endpoint via limit and offset query parameters — no extra code needed:

GET /items?limit=20&offset=40

Multi-ORM Support

fastapi-viewsets isn't locked to one ORM. As of v1.1.0, it ships with pluggable adapters for:

SQLAlchemy (sync and async)
Tortoise ORM
Peewee

You can select your ORM via the ORM_TYPE environment variable, or pass an adapter instance directly:

pip install "fastapi-viewsets[tortoise]"

The same BaseViewset / AsyncBaseViewset interface works regardless of which adapter you're using.

Async Support Out of the Box

If your FastAPI app uses async/await (and if you care about performance, it probably should), use AsyncBaseViewset — it has the exact same interface but all handlers are async:

from fastapi_viewsets import AsyncBaseViewset

items = AsyncBaseViewset(
    endpoint="/items",
    model=Item,
    response_model=ItemSchema,
    db_session=get_async_session,  # your async session factory
    tags=["items"]
)
items.register(methods=["LIST", "GET", "POST", "PATCH", "DELETE"])
app.include_router(items)

Swap BaseViewset → AsyncBaseViewset and get_session → get_async_session. Nothing else changes.

Authentication in One Line

Want to protect write operations behind OAuth2? Pass your OAuth2PasswordBearer and a list of methods that require a token:

from fastapi.security import OAuth2PasswordBearer

oauth2 = OAuth2PasswordBearer(tokenUrl="/token")

router = BaseViewset(
    endpoint="/items",
    model=Item,
    response_model=ItemSchema,
    db_session=get_session,
    tags=["items"]
)
router.register(
    methods=["LIST", "GET", "POST", "PATCH", "DELETE"],
    oauth_protect=oauth2,
    protected_methods=["POST", "PATCH", "DELETE"]  # read is public, writes require auth
)

GET and LIST remain open. POST, PATCH, and DELETE require a bearer token. The Swagger UI will automatically show the lock icon on protected routes.

Custom Logic: Just Subclass

BaseViewset is an APIRouter under the hood, so you can extend it just like any Python class. Override any handler method to add custom business logic:

class ItemsWithStats(BaseViewset):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        # Add custom routes BEFORE register() to avoid path conflicts
        self.add_api_route(
            f"{self.endpoint}/stats",
            self.collection_stats,
            methods=["GET"],
            tags=self.tags or [],
        )

    def collection_stats(self) -> dict:
        return {"resource": self.endpoint.strip("/")}

    def list(self, limit=10, offset=0, search=None, token=None):
        # Add custom filtering logic here
        return super().list(limit=limit, offset=offset)

You're not locked into the generated behavior — it's a starting point, not a cage.

How It Compares

	fastapi-viewsets	fastapi-crudrouter	Hand-rolled FastAPI
Pattern	DRF-style ViewSet class + .register()	CRUD generator, router per resource	Full manual control
Boilerplate	Minimal — one class + .register()	Low — one router call per resource	Maximum
ORM support	SQLAlchemy, Tortoise, Peewee via adapters	SQLAlchemy, Tortoise, Ormar, Databases, Gino, In-Memory	Any ORM you integrate
Async	AsyncBaseViewset	Supported	Fully custom
Auth	OAuth2 per-method via register()	Custom dependencies	Fully custom
Extensibility	Subclass + override any handler	Limited override options	Unlimited
Pagination	limit/offset built-in	Supported	Fully custom
Fits existing routers	Yes — BaseViewset is an APIRouter subclass	Partial — requires specific integration	Yes

The key difference from fastapi-crudrouter is the DRF-style ViewSet pattern — the BaseViewset is a full APIRouter subclass, so it fits naturally into any existing FastAPI app without any special integration.

Installation

pip install fastapi-viewsets

# Optional ORM extras
pip install "fastapi-viewsets[sqlalchemy]"
pip install "fastapi-viewsets[tortoise]"
pip install "fastapi-viewsets[peewee]"

What's Next

The roadmap includes:

Server-side search — wire the search query param to real database queries
Declarative ordering and advanced filters
Dedicated AsyncModelViewSet ergonomics on top of SQLAlchemy 2.x async sessions
Richer OpenAPI for nested Pydantic models

Try It

The library is open source under the MIT license. If it saves you time, a ⭐ on GitHub goes a long way!

📦 PyPI: https://pypi.org/project/fastapi-viewsets/
🐙 GitHub: https://github.com/svalench/fastapi_viewsets

Stop writing the same CRUD code over and over. Your future self will thank you.

Built by Alexander Valenchits — Tech Lead @ AluSoft, Minsk.

Tags: fastapi python webdev tutorial