The architecture, trade-offs, and engineering decisions behind a solo-built AI feedback analysis system

By Abdu Alim Arlikhozhaev

Reading ten reviews is easy.

Reading ten thousand isn’t.

At small scale, customer feedback is something you read. At large scale, it becomes something you have to analyze.

That distinction is what led me to build ReviewLens.

The idea is simple: take a large collection of unstructured customer feedback and turn it into something a product team can actually act on — recurring themes, sentiment, frequency, and an executive-level summary.

But the interesting part wasn’t calling an LLM.

The interesting part was everything around it.

How do you process thousands of pieces of text without sending everything into one enormous prompt? How do you prevent the same analysis from running twice? How do you run a 90-second AI pipeline without blocking an HTTP request? How do you let someone share a report without forcing the recipient to create an account?

Those questions shaped the system far more than the choice of framework.

Live demo: ReviewLens
Source code: GitHub
Portfolio: arlikhozhaev.dev

The Problem Isn’t Reading Reviews. It’s Finding Patterns.

A normal app user might read two or three reviews before downloading something.

That’s not the problem ReviewLens is trying to solve.

The problem appears on the other side of the product.

A product team can accumulate thousands of reviews, support messages, survey responses, or other pieces of customer feedback. At that point, reading individual entries isn’t enough.

The questions become different:

• What problems are appearing repeatedly?
• Which complaints are most significant?
• Are customers talking about the same problem using completely different words?
• Which themes are growing?
• What should the team investigate first?

A keyword search might find:

“delivery was late”

but miss:

“shipping took forever.”

A basic sentiment score might tell you that 23% of reviews are negative without explaining why.

The useful information isn’t just in the words.

It’s in the relationships between them.

That became the design problem behind ReviewLens.

What ReviewLens Actually Does

ReviewLens takes customer feedback and transforms it through an analysis pipeline:

Ingest → Embed → Cluster → Interpret → Persist → Share

A user can upload a CSV or paste feedback. ReviewLens processes the entries, groups semantically similar feedback, asks an LLM to interpret those groups, and produces a dashboard containing:

• recurring themes
• theme frequency
• sentiment
• an executive summary
• the underlying analysis results
• shareable reports
• PDF and CSV exports

The important distinction is that the LLM isn’t asked to understand everything from scratch.

It sits inside a larger system.

That architectural decision is the foundation of the project.

I Started With Constraints, Not Technologies

ReviewLens was built solo in roughly four weeks.

That constraint mattered.

I wasn’t designing infrastructure for millions of users. I was trying to build a production-quality system quickly without creating a distributed system that would take longer to maintain than the product itself.

So I started with a few constraints:

• One developer, four weeks → minimize operational complexity
• 15–90 second analysis pipeline → don’t block HTTP requests
• Stakeholders need reports → owners and viewers need different access models
• AI costs increase with volume → batch work and cap expensive operations
• The product should work locally → don’t make development dependent on production infrastructure

Those constraints led to a relatively simple architecture:

Next.js + TypeScript for the application, PostgreSQL + Prisma for persistence, Inngest for production background execution, OpenAI embeddings + gpt-4o-mini for semantic analysis and interpretation, and Resend/Auth.js for passwordless authentication.

The architecture isn’t impressive because it has a lot of services.

It’s useful because each component has a specific job.

The AI Pipeline: Why Not Just Ask GPT?

This was one of the most important architectural decisions.

The obvious approach would be:

 500 reviews
     ↓
    GPT
     ↓
"Tell me what's going on"

It works.

But it isn’t particularly good engineering.

The prompt becomes large. Costs increase. Results become harder to audit. And it becomes difficult to answer a simple question:

How many reviews actually support this theme?

Instead, ReviewLens separates semantic discovery from language generation.

Customer feedback
       ↓
   Embeddings
       ↓
   Clustering
       ↓
   Theme groups
       ↓
   LLM analysis
       ↓
Decision-ready insights

Each review is converted into an embedding using text-embedding-3-small.

Reviews with similar meaning become closer together in semantic space.

I then use k-means++ to group them.

The LLM receives those groups rather than the entire dataset and generates structured interpretations such as a theme label, description, and sentiment.

That separation gives each component a clear responsibility:

Embeddings answer:
“Which feedback is semantically similar?”

Clustering answers:
“What groups naturally exist in this dataset?”

The LLM answers:
“How should a human understand and describe those groups?”

That is a much more controllable architecture than treating the LLM as a black box that does everything.

The Small Heuristic Behind the Clusters

Clustering introduces an awkward question:

How many clusters should there be?

For the current version, I use:

k = max(2, min(8, round(n / 15)))

The goal isn’t to claim that this is the universally correct clustering algorithm.

It isn’t.

The goal is to make the system predictable and understandable for the datasets ReviewLens currently targets.

Too few clusters and unrelated problems collapse together.

Too many and the dashboard becomes noise.

So I bounded the number of themes and roughly targeted 15 reviews per cluster.

The trade-off is intentional:

It’s explainable, testable, inexpensive, and good enough for the current product.

If the system grows, I’d replace the heuristic with a more sophisticated evaluation-driven approach rather than pretending the heuristic is perfect.

AI Jobs Don’t Belong Inside HTTP Requests

One of the first problems I encountered was architectural rather than AI-related.

An analysis can take 15–90 seconds.

A normal request-response cycle is not a good boundary for that.

Instead, ReviewLens separates starting the work from performing the work.

Upload
  ↓
Create analysis session
  ↓
Return response
  ↓
Background execution
  ↓
Embeddings
  ↓
Clustering
  ↓
LLM summaries
  ↓
Persist results
  ↓
UI polls for status

In production, the job is dispatched through Inngest.

For local development and fallback execution, the pipeline can run through waitUntil.

The UI polls the analysis status approximately every two seconds and exposes progress rather than leaving the user staring at a frozen button.

This taught me something important:

Async execution is a UX decision as much as an infrastructure decision.

Users don’t care whether Inngest exists.

They care that the application doesn’t freeze.

The Double-Click Problem

A user clicks Analyze.

The browser retries.

The network reconnects.

A worker receives the same job twice.

Now the system has two workers trying to process the same analysis — and potentially two OpenAI bills.

That’s why the job isn’t simply marked as “processing.”

It is atomically claimed.

const claimed = await prisma.analysisSession.updateMany({
  where: {
    id: sessionId,
    status: "PENDING",
  },
  data: {
    status: "PROCESSING",
  },
});

if (claimed.count === 0) {
  return { started: false };
}

The important part isn’t the syntax.

The database transition is conditional.

Only one caller can successfully change the session from PENDING to PROCESSING.

Everyone else loses the race safely.

This is a small piece of code, but it represents a bigger principle:

Expensive work should be designed around failure, retries, and duplication — not only the happy path.

Sharing a Report Without Creating Another SaaS

I considered building organizations, invitations, multiple seats, roles, and full workspace management.

I didn’t.

The actual use case was much simpler:

“I want to send this report to someone.”

So the first version uses password-protected share links with expiration.

Owners authenticate with magic links.

Viewers don’t need accounts.

Share access is protected through unguessable slugs, hashed passwords, and HMAC-signed httpOnly cookies.

Most importantly, the same authorization model applies across the dashboard, status endpoints, and exports.

That matters because security bugs often appear at the edges.

A protected dashboard is meaningless if /api/status or /api/export quietly exposes the same data.

Authorization belongs at the API boundary, not only in the UI.

The decision to not build full workspaces was also an engineering decision.

Every unfinished feature creates schema, authorization, testing, and maintenance costs.

Scope is architecture.

Where This Architecture Breaks

ReviewLens isn’t serving 100,000 users today.

Pretending otherwise would be dishonest.

But thinking about where today’s architecture breaks is useful engineering.

I’d also keep the monolith longer than the internet sometimes recommends.

Microservices aren’t a maturity badge.

I’d split a boundary when there is a reason: independent scaling, independent ownership, different reliability requirements, or meaningful operational separation.

Not because a diagram looks more impressive.

The Engineering Practices Behind the Product

The project is small, but I wanted the codebase to behave like something another engineer could inherit.

That meant:

• Strict TypeScript and Zod at boundaries
• Structured logging with request/session IDs and stage timing
• CI covering lint, types, tests, builds, and Playwright
• 93 unit tests across parsing, validation, cryptography, clustering, and API contracts
• ADRs documenting architectural decisions

The goal wasn’t to maximize the number of tools.

It was to make important assumptions visible and testable.

What Building ReviewLens Changed My Mind About

The biggest lessons weren’t about OpenAI.

AI is a component, not an architecture.

The model can produce an impressive answer and the product can still fail because of queues, authentication, cost, retries, or bad data handling.

Idempotency matters earlier than you think.

You don’t need millions of users to encounter duplicate requests.

One impatient click is enough.

Cutting features is engineering.

A half-built workspace system would have made ReviewLens look bigger while making the underlying product worse.

Async work is part of product design.

The user experience changes when a task takes 90 seconds.

The infrastructure has to acknowledge that.

The “why” is as important as the code.

The code tells another engineer what the system does.

An Architecture Decision Record tells them why it ended up that way.

That distinction becomes extremely valuable when requirements change.

What I’d Build Next

The next version of ReviewLens shouldn’t just produce prettier reports.

It should become better at answering:

“What changed, and what should we care about?”

That means:

Persistent embeddings — avoid paying to embed unchanged feedback repeatedly.

Evaluation datasets — measure theme quality against labeled examples instead of relying only on whether the output looks convincing.

Historical analysis — compare themes across time and releases.

Real connectors — ingest feedback directly from sources such as Shopify and app stores instead of relying primarily on CSV uploads.

Evidence-backed insights — every generated theme should trace back to the underlying feedback that supports it.

Team functionality — organizations and roles only when actual users need them.

The product vision stays deliberately narrow:

The fastest honest path from messy customer feedback to a decision.

The Part I Find Most Interesting

I started ReviewLens thinking primarily about reviews.

I ended up thinking much more about systems.

A handful of reviews can be read.

Thousands need structure.

And once the data becomes large enough, the hard questions stop being:

“Can an LLM summarize this?”

They become:

Can I process it reliably?

Can I control the cost?

Can I prevent duplicate work?

Can I explain where an insight came from?

Can I protect the underlying data?

Can I measure whether the output is actually useful?

Those are the questions that made ReviewLens worth building.

The LLM is only one part of the solution.

The real engineering challenge is building everything around it.

At small scale, customer feedback is text. At large scale, it becomes a systems problem.

ReviewLens is my attempt to solve that problem — one architectural decision at a time.

Try ReviewLens
Read the source code on GitHub
See more of my work

— Abdu Alim Arlikhozhaev

Introduction: Faster Code, Harder Questions

AI coding assistants are everywhere.

Students finish assignments faster.
Errors get resolved in seconds.
Productivity feels effortless.

But speed alone doesn’t define learning.

The real question isn’t whether AI helps students code faster — it clearly does. The real question is this:

Does AI improve code quality and understanding, or does it simply help us finish sooner?

To explore this, I surveyed 40 student developers who actively use AI coding assistants in real coursework and personal projects. The results confirm a familiar story about productivity, but they also reveal a quieter, more important shift in how developers learn, reason, and take ownership of code.

This article breaks down what actually changed, and what didn’t.

Who This Study Represents

This survey reflects real-world usage, not controlled experiments.

• 40 anonymous student developers
• Skill levels ranging from beginner to intermediate
• Regular use of tools like ChatGPT, GitHub Copilot, Claude, and similar assistants
• Applied to real assignments and projects, not hypothetical tasks

This isn’t about perfection.
It’s about habits, trade-offs, and lived experience.

AI’s Biggest Strength: Speed and Momentum

One signal in the data is impossible to miss.

Most respondents strongly agreed that AI coding assistants

• Help them complete programming tasks faster
• Reduce the time spent stuck on errors or syntax issues

In other words, AI’s primary strength today isn’t creativity or deep reasoning.

It’s friction removal.

By eliminating common blockers, AI keeps developers moving forward, which explains why adoption feels almost inevitable.

Survey Scale

All quantitative questions in this study use the same 5-point Likert scale:

• 1 — Strongly disagree
• 2 — Disagree
• 3 — Neutral
• 4 — Agree
• 5 — Strongly agree

Unless stated otherwise, this scale applies to every chart below.

📊 Chart 1 — “AI helps me complete programming tasks faster”

📊 Chart 2 — “AI reduces the time I spend stuck on errors”

The Core Insight: Productivity Is Outpacing Understanding

This is where the story changes.

When asked whether they fully understand the code they submit while using AI, responses shifted noticeably toward neutral rather than strong agreement.

Confidence dropped even further when students were asked whether they could explain AI-assisted code in an interview setting.

The pattern is clear:

AI accelerates output faster than it builds understanding.

That gap doesn’t show up in grades or completed assignments, but it becomes very visible during debugging, interviews, and long-term skill development.

📊 Chart 3 — “I fully understand the code I submit when using AI”

📊 Chart 4 — “I feel confident explaining AI-assisted code in an interview”

Debugging: A Subtle but Important Trade-Off

Another interesting pattern emerged around debugging.

While AI prevents many errors upfront, a meaningful portion of respondents reported that debugging AI-generated code feels harder.

Debugging requires mental ownership:

• Understanding intent
• Tracing logic
• Reasoning through failure

When code is generated rather than constructed step by step, that ownership can weaken.

This doesn’t mean AI makes developers worse at debugging — 
It means passive usage has a cost.

📊 Chart 5 — “Debugging AI-assisted code feels harder”

Dependency: Real, but Not Inevitable

Some respondents reported a growing sense of dependency on AI tools.

Not overwhelmingly — but enough to matter.

This suggests something important:

AI doesn’t automatically create dependent developers.
Dependency emerges when AI replaces thinking instead of supporting it.

AI doesn’t remove responsibility: it shifts it.

📊 Chart 6 — “I feel dependent on AI coding tools”

What Students Actually Use AI For

Open-ended responses reinforced the quantitative results.

This aligns perfectly with AI’s current strengths:
excellent at local, well-defined problems — weak at strategic reasoning.

What This Means for Student Developers

The takeaway isn’t to avoid AI.

It’s to use it deliberately.

Based on the patterns in this study, effective learning with AI requires

• Never submitting code you can’t explain line by line
• Rewriting AI-generated solutions in your own words
• Using AI as a debugging partner, not a reasoning replacement
• Practicing verbal explanations of AI-assisted code

AI can accelerate learning — but only if understanding remains the goal.

Limitations

This study has clear boundaries:

• A relatively small sample size (40 participants)
• Focused specifically on student developers
• Based on self-reported experiences

I’m grateful to the 40 student developers who took the time to share their experiences and perspectives for this study.

The goal isn’t universal claims, but to surface practical insights grounded in real-world usage.

Final Thoughts: The Tool Isn’t the Problem

AI is changing how quickly we write code.

The harder question is whether it’s changing how deeply we understand it.

Tools have always increased speed.
What separates strong developers from average ones isn’t how fast they produce code — it’s how well they understand the systems behind it.

Speed is seductive.
Understanding is earned.

AI isn’t the problem.
Unexamined reliance is.

If you’re a student developer using AI, the question isn’t whether you should use it — it’s whether you’re using it to sharpen your thinking or slowly replace it.

Written by Abdu Alim Arlikhozhaev, a computer science student focused on developer productivity, AI-assisted programming, and software engineering education.

AI Made Student Developers Faster — But Not Necessarily Better was originally published in Coffee☕ And Code💚 on Medium, where people are continuing the conversation by highlighting and responding to this story.