I shipped the public resume builder at sabooralikhan.com by vibe-coding — two AI coding agents, OpenAI Codex and Anthropic Claude Code, running in parallel, passing intermediate work back and forth. This is the honest version of what that setup actually looks like, why it works, and how you can run it yourself.
I wanted the tools section of sabooralikhan.com to hold things I actually use. The resume builder solves a problem I had twice a month — adjusting a resume for a specific job posting without rewriting the same three sections by hand.
Putting it on the portfolio, rather than as a separate product, also makes the portfolio denser. Tools are a category of work. A site that only has case studies and an about page feels static.
Vibe-coding is a specific style: you drive the product direction, the agent holds the code. You describe outcomes, read diffs, redirect when the agent wanders, and never type a semicolon yourself. It is closer to being a tech lead than being a developer.
On this project I ran two agents instead of one. OpenAI Codex handled long-running, high-context tasks (refactors across many files, migration scripts, test scaffolding). Anthropic Claude Code handled the fast, surgical work (single-file edits, rapid UI iteration, debugging). They talked to each other through the filesystem — which is the only handoff protocol you actually need.
Setup is less complicated than it sounds. Both agents read and write the same repository on disk, so the "communication" is just the working tree. Here is the concrete setup I use.
Codex won on scale. When I needed to move the resume data model from a single object to an append-only block model, Codex rewrote 14 files in one pass, updated tests, and flagged three edge cases I had not considered. That was a three-hour manual refactor compressed into fifteen minutes.
Claude Code won on feel. The UI iteration loop — tweak padding, adjust typography, reshape a component — was noticeably faster with Claude because its diffs land cleaner for small changes and it asks fewer clarifying questions when the task is visual.
Put differently: Codex thinks, Claude moves. Using both in parallel gives you a tech-lead posture over the whole codebase.
Next.js app router, Supabase for auth and persistence, Tailwind for the UI, and a React-PDF renderer for the export. The only unusual choice is putting the authenticated app behind /tools/resume-builder/app while keeping a public /tools/resume-builder landing page for SEO.
The split matters because the landing page needs to be indexed, while the app behind auth should be kept out of Google. The robots.ts disallow rules and a per-page noindex take care of that. Codex wrote the robots config, Claude wrote the landing page copy — exactly the division of labor their strengths suggest.
Every resume builder eventually dies on PDF. The renderer choice sets a ceiling on what the product can do. I started with html-to-pdf wrappers, hit layout drift within a day, and had Codex migrate the pipeline to true React-PDF. The learning curve is worth it.
The trickiest constraint is that most ATS systems parse PDFs as if they were created in Word. The resume has to layout correctly and parse as plain-text correctly. Those two goals fight each other on almost every design decision — this is also exactly the kind of thing where having a second agent (Claude) checking the first agent’s (Codex) output catches the subtle bugs.
Supabase auth is the right pick for a portfolio-scale product. Row-level security means users only see their own drafts without any API layer of my own. The migrations stay in the repo, which matches how the rest of the site is versioned.
What Supabase does not solve: transactional email at scale, PDF rendering, or anything that needs background jobs beyond a simple cron. If the product grew, I would reach for a dedicated worker and keep Supabase in the auth + data role it is good at.
Start with the two-agent setup from day one. I used a single-agent flow for the first week and the productivity delta was obvious once I added the second pane.
Design the data model around exportable blocks from day one. I started with a "resume" object and fought that shape for two iterations before switching to an append-only block model (each section is a typed block with an order field).
Build the public landing page first and the app second. I did it in the other order and the landing page ended up under-built. For SEO purposes, the landing page is the thing that compounds.
The tool lives at sabooralikhan.com/tools/resume-builder. The case-study style write-up is at /projects/my-portfolio-2026. The full tools surface is at /tools.
If you are starting your own vibe-coding setup: two panes, two agents, git as the safety net, markdown files as the handoff. That is the whole thing. The tooling is not the hard part. The hard part is learning to stop typing and start directing.