I Rebuilt My Portfolio with an AI Coding Agent: What Worked and What Didn’t
An honest case study of handing my portfolio to an AI coding agent: the audit that found hidden bugs, measurable performance wins, the mistakes, and what still needed a human.

Mohit Malaya Nandy
Software Engineer & Product Builder

On this page
This week I handed my portfolio, the site you are reading now, to an AI coding agent. Not for one small fix, but for a full clean-up: performance, security, SEO, a blog rework and a pile of new features. I stayed in the loop, made the decisions and reviewed the results.
Here is an honest account of what it did well, where it went wrong, and what I would do differently. No hype, no "10x developer" claims, just what actually happened.
The setup#
- The site: Next.js 16 with React 19 and Tailwind v4, a 3D lanyard card built with three.js, framer-motion everywhere, a blog and an AI chatbot.
- The agent: Claude Code running in VS Code, with access to my terminal and files.
- My role: give direction in plain English, answer questions, approve risky steps, and check the result.
My first prompt was two words: "analyze this". That turned out to be a surprisingly good start.
Step 1: The audit was the best part#
Before changing anything, the agent read the codebase and produced a prioritised list of problems. Some I knew about. Several I did not:
- The contact API route logged messages to the console and told users "thanks, we got it". Nothing was ever delivered.
- The AI chat endpoint had no rate limiting, so anyone could drain my API quota.
- Four installed packages were never imported anywhere.
- Several images were far larger than they needed to be, including a 2.9 MB PNG nothing used.
The most valuable find came later, during a deeper "analyze the complete project" pass. My theme provider returned null until the page loaded in the browser:
Every page on my site was being sent to Google as an empty shell.
All my SEO work, metadata, JSON-LD and the sitemap, was sitting on top of pages with no content in their server HTML. I had no idea. The fix was to render the full page on the server and set the saved theme with a tiny inline script before the first paint.
What worked well#
Measurable performance wins
| Change | Before | After |
|---|---|---|
| 3D lanyard libraries (three.js + physics) | ~3 MB loaded on every page | Loaded only when the lanyard opens |
| Preloader | 3 seconds, every visit | 1.5 seconds, once per session |
| 3D card model (card.glb) | 2.46 MB | 393 KB (textures converted to WebP) |
| About page background | 1.6 MB PNG | 106 KB WebP |
| Unused hero image | 2.9 MB | Deleted |
I wrote up the full performance story separately in Core Web Vitals in Practice.
It checked its own work
This surprised me most. After almost every change, the agent ran the production build and the linter. When it rewrote my MERN authentication tutorial, it pulled the code out of the article, installed the packages in a scratch folder, started an in-memory MongoDB and ran fourteen requests against it: wrong passwords, token rotation, rate limiting and more. All passed. When it built social share banners, it rendered them as images and looked at them, and caught that the cover art was being cropped mid-word.
It used current documentation
My Flask tutorial said to install Python with the classic .exe installer. The agent checked the official Python docs and found that installer is deprecated since Python 3.14, replaced by the Python Install Manager. Same for Express 5 and Mongoose 9: it caught breaking changes that most tutorials online still get wrong.
It found real security bugs in my own tutorial
My "production-ready" MERN auth article had an open admin registration route, error messages that revealed which emails had accounts, and refresh tokens that never expired. Embarrassing, but much better found now than by a reader's attacker. That review became its own post: Reviewing AI-Generated Code.
What didn't work so well#
Fast shell edits caused small messes
The agent often used quick shell commands for bulk edits. Twice they misfired. A rename script for 42 files produced names like pagex instead of page.jsx, and a sed edit left my Next.js config with a broken bracket. Both were caught and fixed within a minute, because the agent looked at the output, but they were reminders that speed and precision trade off.
It cannot see the site
The agent verified builds, HTML output and rendered images, but it never looked at the site in a browser. It said so clearly every time: "I haven't viewed this in a browser". Animations, layout on real phones and how the 3D card feels were still my job to check.
My vague prompts were the weak link
When I typed "remove all 6", it asked me what I meant instead of guessing, which was right. But some of my prompts were short to the point of being unclear, and each one cost a round trip. Clear requests got better results faster.
Some things needed credentials or a human decision
- It could not test code that calls paid APIs without a key, and said so rather than pretending it had.
- When X showed "Article Not Found" for my shared link, it worked out that the fixes had never been deployed, and that my domain redirected the wrong way. Deploying and changing Vercel settings were my calls, and it asked instead of acting.
Editing files at the same time causes conflicts
A few times I edited files in my editor while the agent was working. It noticed the files had changed, kept my version and worked around it, but it is still smoother to let one of us finish before the other starts.
What I learned#
- Start with an audit, not a feature. The most valuable output of the whole week was a list of problems I did not know I had.
- Ask for verification, and expect it. Builds, lint, tests and rendered output turned "looks right" into "is right".
- Commit checkpoints. Small commits made every change easy to review and undo.
- Keep the decisions yours. Deploys, domains, deleting things and anything public: the agent asked, and it should.
- Review the content, not just the code. It rewrote articles under my name. I read every one before publishing.
- Write clear prompts. The agent is only as good as the context it gets. I now keep an instruction file in the repo (more in Context Engineering).
Would I do it again?#
Yes, without hesitation. Not because it wrote code faster than me (it did), but because it found and verified things I would not have found myself, and it was honest about what it had and had not checked.
Found this useful? You can support my writing on GitHub Sponsors or with a coffee.


