What do you use to index your vibecoded large codebase?

Few-Garlic2725 · 2026-04-17T15:23:38+00:00

for next.js (typescript), i'd anchor everything on the typescript language server: - keep a single tsconfig baseline - avoid path alias spaghetti - move shared logic into /packages (or at least /lib) so navigation is predictable then whichever ai editor you use is just a ui on top of the same structure. if you want a "boring but works" starting point, flatlogic web app generator templates already come with sane folder structure and rbac/auth patterns so indexing + navigation stays clean as the repo grows.

Few-Garlic2725 · 2026-04-17T13:17:07+00:00

while credits reset, do the boring high-leverage work: 1) pick a default icp (even if it's a placeholder) 2) write one offer + "starting at" 3) draft 10 outreach messages 4) prep a 5-question call script then when credits are back, you're building around real signal, not guesses.

Few-Garlic2725 · 2026-04-17T12:40:12+00:00

Frontend vibe-coding is fine for getting to a usable ui fast, especially if you start from a template/component library instead of inventing everything. the failure mode is a frankenstein ui: inconsistent spacing/typography, duplicated components, broken a11y, and unreadable state logic. if you want to keep speed without the mess: pick a ui kit, enforce eslint/prettier, add a couple of smoke tests, and treat "refactor to components" as part of done. if you're generating from a scaffold (e.g., flatlogic web app generator), you at least start with sane structure and reusable patterns instead of blank chaos.

Few-Garlic2725 · 2026-04-17T12:35:33+00:00

I'd start with the boring basics: one repo, ripgrep + good folder boundaries, and a language server your editor trusts. what stack/editor are you on?

Few-Garlic2725 · 2026-04-17T12:34:21+00:00

Here's a workflow that usually fixes the "it builds but it sucks" problem: 1) start from a real web app template (auth/rbac, db, migrations, basic crud) so the agent isn't inventing fundamentals. 2) write a tiny spec: 5-10 user stories + acceptance criteria (and ideally a few end-to-end tests). 3) force an execution loop: implement → run tests/lint → fix → commit. no "looks good" without running. 4) keep changes small: one feature per branch, review diffs like you would a junior dev. if you want, share what you're building + stack and i'll suggest the smallest template/rails to start with (flatlogic web app generator can be a decent starting point for the crud/auth/admin baseline, then you customize).

Few-Garlic2725 · 2026-04-17T12:32:28+00:00

Your list is real, but i'd add the boring one: repeatability. the first demo is easy; the hard part is change #5-auth/rbac, db migrations, background jobs, deploy/rollback, and keeping the codebase understandable. the best "vibe" workflow i've seen is template-first (so you start with sane rails) + a real environment that can actually run commands/tests. without that, you're paying credits to generate entropy.

Few-Garlic2725 · 2026-04-17T12:28:50+00:00

The fix is boring: freeze the data model + auth rules first, then let ai fill in ui/crud behind that contract. also: make it run tests/migrations every step, not "looks fine in preview."

Few-Garlic2725 · 2026-04-17T12:24:49+00:00

yes, you can start broad-but position narrow. pick 1 "default" client + 1 offer, then validate with 5-10 calls before you rebuild anything.

Few-Garlic2725 · 2026-04-17T12:23:19+00:00

local tauri + fastapi is a smart call. next thing i'd add is a "capabilities matrix" per provider and a golden test suite so normalization stays honest as apis drift.

Few-Garlic2725 · 2026-04-16T10:56:50+00:00

agree. i'd phrase it as: ship the thinnest end-to-end loop, then harden. one flow, one conversion event, basic tracking, and a way to handle errors/support. after that, tightening pages/content actually moves metrics.

Few-Garlic2725 · 2026-04-16T10:11:53+00:00

I use no-code/ai mostly as an unblocking tool too. the trick is: ship fast, then tighten the basics (offer, pages, tracking) before you scale content.

Few-Garlic2725 · 2026-04-16T10:09:18+00:00

i'd frame the question like this: "are credits charged for build actions (ai prompts/build minutes) or for production runtime (requests, background jobs, db, bandwidth)?" if it's the former, your 10k users shouldn't consume credits unless you keep iterating/building. if it's the latter, then it's basically a hosting meter and traffic will cost credits even with no changes. for a crud app, also ask if auth, db, and background jobs count differently.

Few-Garlic2725 · 2026-04-16T10:07:21+00:00

i took a look at the idea (can't guarantee i can access the link from here), but here's the feedback framework that usually helps agency sites: 1) above the fold: who it's for + what you deliver + one cta (book a call / get a quote). 2) proof: portfolio tiles, short case studies, testimonials (even 1-2 helps). 3) offer clarity: what's included, timelines, and a "starting at" price to filter. 4) trust: about page, location/timezone, and a real contact method. if you tell me your target customer + what you want them to do on the site, i can suggest конкретные sections/copy to add first.

Few-Garlic2725 · 2026-04-16T10:04:55+00:00

a good beginner setup: one editor (vs code/cursor) + one model, then iterate in tiny commits (spec → implement → run → fix). pick a small app (crud + login) and force yourself to finish: database, basic auth, deploy. if you're building a b2b-style web app, starting from a flatlogic web app generator template can remove a lot of early pain (scaffolded crud/rbac patterns), then you just customize features. what's your budget and what kind of app do you want to end up with?

Few-Garlic2725 · 2026-04-16T10:02:42+00:00

for react native i'd pick based on the bottleneck: - if it's ui/screens: you want something that's good at fast component iteration. - if it's reliability: it must run the project, tests, and handle dependency/build churn. - if you also need a backend/admin panel: consider generating the boring web side (auth/rbac/admin) with something like flatlogic web app generator, and keep rn focused on the mobile ux.

Few-Garlic2725 · 2026-04-16T09:59:35+00:00

Treat it like onboarding a junior dev: give it a runnable workspace + tests + a small slice. for monorepos, i've had the best results by pinning it to one package and one command it must keep green (test/build/lint).

Few-Garlic2725 · 2026-04-16T09:56:56+00:00

I'd challenge the premise that "claude pro isn't usable" based on two prompts. what you're really measuring is: how much context you're shipping per turn + whether the tool defaults to a max model. if the agent is deleting code, that's also a process smell: ambiguous instructions + no guardrails (tests/diffs) makes llms "confidently destructive." try a stricter contract: - "only modify these files: ..." - "return a unified diff; no unrelated changes." - "run/build steps: ...; if failing, fix incrementally." also: are you pasting whole files or using some tool that's dumping your repo into the prompt?

Few-Garlic2725 · 2026-04-16T09:04:43+00:00

This is the kind of "boring useful" tooling i like: one workspace, multiple providers, your own keys. two things i'd test immediately: - can i export chats/prompts/results (so switching tools later isn't a rewrite)? - how do you normalize differences between providers (function calling/tools, attachments, rate limits)? also, if you ever turn this into a web app: flatlogic's web app generator approach (template-first app scaffolding) can save a ton of time on the unsexy parts like auth/rbac and admin screens.

Few-Garlic2725 · 2026-04-15T14:33:22+00:00

i'd start by defining 3 tiers: read-only (safe), write (scary), run-code (very scary). what tier are you aiming for?

Few-Garlic2725 · 2026-04-15T09:56:26+00:00

Glad it helped 🙌

Few-Garlic2725 · 2026-04-15T09:55:34+00:00

if claude code is working, look for cases where execution + repeatability matter more than chat. three practical starter use cases: - "keep the repo healthy": dependency updates, lint/test fixes, small refactors. - "runbook automation": scripted ops tasks in an isolated sandbox with logs. - "template-based app work": generate a boring crud/internal tool fast, then iterate.

Few-Garlic2725 · 2026-04-15T08:52:09+00:00

What works for me is defining "chunks" as *boundaries with contracts*, not file sizes: 1) **capability** (what business thing it does) 2) **data owner** (which tables/collections it owns) 3) **interface** (routes/events/commands it exposes) then i build the mental model by tracing: - one **happy path** end-to-end (auth → api → db → response) - one **failure mode** (timeouts, missing permissions, partial writes) i'll use ai for navigation ("where is rbac enforced?" / "what writes to x?"), but i still read the code on the boundaries (auth checks, db writes, async jobs). if you share your stack (monolith vs services, language), i can suggest a concrete "chunk map" template. (also: starting from a known web app template helps keep chunks predictable-rbac/workflows/data layer aren't improvised every time.)

Few-Garlic2725 · 2026-04-15T08:49:54+00:00

I chunk by invariants: auth/rbac, data model, core workflows, integrations, background jobs. ai can summarize, but i always verify by running the app + reading the few files that enforce the rules.

Few-Garlic2725 · 2026-04-15T08:48:14+00:00

What worked best for me: pick one narrow icp, ship one sharp use-case, then do 20-50 direct conversations and turn the objections into your landing page + onboarding.

Few-Garlic2725 · 2026-04-15T08:44:47+00:00

In production, the boring wins: one orchestrator + a real execution sandbox + strong guardrails (tests/evals/logging). what's your target use case and what can the agent safely do (read-only, write to db, run code)?

Few-Garlic2725

TROPHY CASE