DEV Community: Alexander Valenchits

Why I Use Two AI Assistants at Once: My Experience with Perplexity Pro and Kimi Allegretto

Alexander Valenchits — Sat, 02 May 2026 10:51:05 +0000

Over the past few months, I’ve been deliberately paying for two AI services: Perplexity Pro and Kimi Allegretto. On the surface, that probably looks strange—even to me—but in practice they fill different roles. In this article, I want to share my personal experience: where Perplexity is genuinely stronger than a classic “chat with a model,” where Kimi turns out to be more useful, and what I end up criticizing in each of them.

Why Pay for AI Assistants at All

I regularly do more than just coding—I also spend a lot of time on research and self-education: tracking who is launching what, which pricing plans are appearing, and how AI products and architectures are evolving. On top of that, I’m constantly reading articles, documentation, blogs, and technical deep dives. Standard assistants at the level of an “IDE helper” like Cursor and similar tools are not enough for this: they help write code, but they do not really handle deep research or help build a broad picture of the market.

At some point it became clear that I needed a separate layer in my stack for research and for working with large volumes of text and code. That’s how Perplexity Pro and Kimi Allegretto entered my workflow.

Perplexity Pro: an answer engine, research tool, and “browser with a brain”

Deep Research and skills

After a month of heavy use, Perplexity stopped feeling like “just another chatbot” and became a dedicated research tool for me. What I liked most was Deep Research: it can pull together insights from dozens of articles, attach source links, and re-check its own conclusions, turning large amounts of information into a coherent overview of a topic. If you give it meaningful context—not “find something somewhere on the internet,” but a clearly defined task with boundaries and nuances—it can produce a detailed and careful analysis.

A separate story is the skills system. Perplexity lets you connect custom skills, including ones found on GitHub, literally as a single file, and then simply tell the model to “use this skill.” I tested this for SEO optimization and various research workflows, and the combination of Deep Research plus skills gives a very noticeable boost in depth and analysis quality.

Computer and Personal Computer: an AI layer over the system

From a developer’s perspective, I was also impressed by Perplexity Computer with Anthropic’s latest model. It is a separate paid mode available on higher-tier plans, and it launches a full agent with access to the browser, files, and codebase. When I pointed it at a real Git repository and gave it the necessary skills, I got a refactoring result that genuinely felt like it had been done by a human developer: it reviewed the code, organized everything clearly, and ultimately proposed a pull request with understandable changes.

There is also the separate Personal Computer initiative. Perplexity recently announced the Personal Computer program and opened a waitlist: the idea is to build an “AI operating system” that lives on your Mac, continuously works with local files and apps, and orchestrates tasks in the background. Naturally, I joined the waitlist, but for now it is still a closed product, and the timeline and chances of getting access look rather vague.

Comet: a browser with an assistant built in

I also want to highlight Comet, Perplexity’s own browser. It is not just a Chromium fork, but a browser with a built-in assistant that understands page context and can work across multiple tabs like an agent. In practice, it feels like something between Yandex Browser with AI features and a standalone agentic environment.

As a translator, Comet behaves confidently: it understands context well and preserves both structure and meaning during translation, so reading articles and documentation in other languages feels comfortable. You can also use it as an agent—give it a task like “go through several pages, collect the facts, make a summary, and draft an article or a table,” and Comet will actually move across tabs, extract data, and return something already structured and meaningful. That saves time when you need to turn a set of links into text or organized data quickly.

That said, Comet has one important limitation: it cannot translate videos such as YouTube clips, while Yandex Browser can at least generate a rough Russian translation after a pause—often enough to understand the gist.

Multimodality as a nice bonus

In terms of multimodality, Perplexity looks quite decent: thanks to built-in Gemini and GPT models, it can produce reasonable images and basic videos, especially when you need complex prompts or text rendered inside images. But there are still some unclear generation limits tied to plan level and credits, so it does not really work as a primary “visual content factory.” My practical conclusion is that this is a useful layer on top of research, not a replacement for dedicated graphics or video tools.

The downsides of Perplexity: limits, plans, and no IDE integration

Despite all the strengths, Perplexity has several drawbacks that are critical for me.

First, there is the complete lack of transparency around limits. As a user, I do not fully understand how many Deep Research runs, Computer sessions, or tokens I still have left: the dashboard does not provide a clear enough usage overview. Sometimes the service suddenly refuses access to certain features in the middle of the week, even though the billing month is not over yet, and from the outside it looks like random disabling without a clear counter. If you care about planning workload and budget, this is much more irritating than it should be.

Second, there is the pricing structure. Right now, there is basically a reasonably priced Pro plan and then a jump straight to Max/Computer-level plans at around $200+ per month, where Computer access and much higher limits are included.

Third, there is the lack of native VS Code integration. Compared with Kimi, which has Kimi Code and an official IDE extension, Perplexity feels slightly disconnected from my day-to-day development environment. If they introduced a middle-tier plan with basic Computer access plus an official VS Code plugin, Perplexity could become not just an answer engine for me, but a real infrastructure layer around development.

Kimi Allegretto: agents, IDE integration, and long-running workflows

An ecosystem built around the developer: Kimi Code and Claw

I started using Kimi Allegretto only recently, but even after a couple of days it became clear that this is not just a chat app—it is more of an ecosystem built around the K2.6 model.

For a developer, the first thing that stands out is Kimi Code with its native VS Code extension: you can discuss code directly inside the editor, inspect diffs, and apply changes without switching back to the browser. That feels natural because the assistant lives in the same place as the main workflow.

Another important part of the ecosystem is Kimi Claw. In essence, it is a persistent agent that lives in its own workflow space, has its own folder, stores files, and accumulates experience and skills as work progresses. Unlike disposable chat sessions, Claw builds a knowledge base around your tasks, which makes it easier to return later and continue the flow instead of starting from scratch.

At the platform level, Kimi feels cohesive: there is a desktop client, mobile apps, and a web interface, so you can access the same agent from any device. The ecosystem also includes web tools for internet access and several agent modes—from document and slide processing to Sheets integrations and Agent Swarm scenarios. I have not had time to test everything yet, but the platform clearly aims to be broader than a simple chat app.

Website agent: UI generation out of the box

One specific feature that pleasantly surprised me was the agent mode for websites. In a simple “describe what you want” format, Kimi can produce a pretty decent UI: it can think through page structure, navigation, section copy, and generate interface code. This is not design-award material, of course, but for prototypes and first product versions the output is already usable and feels roughly on the level of modern AI tools in the Vercel/design-to-code ecosystem.

Pricing and transparency of limits

Compared with Perplexity, Kimi’s pricing feels especially pleasant. There are several tiers, and you can choose a comfortable “middle” package with higher limits instead of jumping straight into something that feels enterprise-grade.

That is the plan I chose, and so far the limits seem sufficient. The dashboard is also more transparent: it shows how many requests and tokens have already been used, so you can actually see where your quota is going and plan when to run heavy agent tasks or long sessions.

The downsides of Kimi: languages, speed, IDE constraints, and expensive multimodality

Kimi also has some serious limitations.

First, there is the language issue. The ecosystem is clearly optimized for English and Chinese first, and that is noticeable in practice. In my case, Kimi did not handle Russian dictation at all in the way I expected, so I either have to switch to English or type manually. If a large part of your workflow depends on Russian or other less-supported languages, Kimi currently feels much less convenient.

Second, there are the limitations of Kimi Code in VS Code. In the current implementation, you can only keep one active agent per window: when you launch a new task, the previous one effectively stops. Compared with tools like Codex or Cursor, where parallel development contexts are normal, this is a real step backward in convenience when juggling multiple tasks and repositories at once.

Third, there is speed. Compared with Codex and Cursor on some tasks, Kimi feels noticeably slower, sometimes by a large margin. The main reason seems to be the thinking mode: when it is enabled, the model produces long reasoning chains. If you turn thinking off, Kimi does become faster, but at the cost of quality: the answers become more superficial, so you constantly have to choose between depth and speed.

Finally, there is one very practical point: visual tasks burn through limits quickly. In my case, a test website design with 3–4 pages in agent mode consumed around 4–5% of the monthly Allegretto limit, which feels expensive for that scope. Video was even worse: two test runs produced very weak results but consumed roughly a third of the monthly limit. By contrast, normal code-related work seems much more economical. So my practical conclusion is simple: in Kimi, multimodality—especially video—does not currently justify the limit cost, and the tool makes the most sense primarily for text and code.

Comparison

Criterion	Perplexity Pro	Kimi Allegretto
Main focus	Answer engine and research: Deep Research, citations, verifiable answers	Long context, agents, and a working environment around code and documents
Web and sources	Strong live web search, neat citations, structured summaries	Web tools exist, but less emphasis on transparent source citation
Browser	Comet as a browser with an assistant and translator, but no video translation	More classic browser-style workflows through web tools
Code and refactoring	Skills plus higher-end agent workflows for repository analysis and PR-style refactoring	Kimi Code with VS Code integration, plus persistent agents such as Claw
Multimodality	Good images and basic video, but with plan and credit limits	Available, but in my experience expensive in terms of limits
Plans and limits	Pro around $20/month, Max around $200/month, and the jump between them is steep	Multiple tiers, with Allegretto as a workable middle option
IDE integration	No native VS Code plugin publicly highlighted in current plan materials	Kimi Code includes VS Code-oriented workflows
Languages and dictation	Better suited to multilingual reading and research in my workflow	Stronger for English/Chinese, weaker for Russian dictation in my use
Speed	Generally fast, with tolerable delay even in heavier modes	Slower in thinking mode, with more trade-off between speed and depth

My short conclusion

Perplexity Pro is excellent for research, gives detailed source-backed summaries, can support serious code analysis through its more advanced agent features, and Comet adds a useful browser layer.
Kimi Allegretto is more comfortable as an environment for working with code and documents, offers longer-lived agents, has a more explicit mid-tier pricing option, and feels closer to the developer workflow.

What will ultimately stay in my stack, I still have not fully decided. For now, I’m going to keep using both in parallel, compare how they handle the same tasks, and if anything particularly interesting comes out of that, I’ll return with another article.

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