Building a Portfolio When the Agent Wrote Half the Code

Your GitHub profile has twenty-three repositories on it and you have started to suspect this is working against you. Anyone with a subscription and a free afternoon can produce a repo that looks broadly like your best one, and the person reading your profile knows that at least as well as you do.

So the question is not how to make your projects look more impressive. It is what a portfolio is supposed to prove now that the thing it used to prove has become cheap.

The signal that stopped working

The old contract was simple. A working project proved you could take an idea, hold all of it in your head, and produce running code. Effort was a reliable proxy for skill.

That proxy has broken. A polished CRUD app with authentication, dark mode and a tidy commit history is now forty minutes of work for someone with no idea what any of it does. The reviewer cannot tell your project from that one by looking.

What has not become cheap is judgement. Deciding what not to build. Choosing the constraint that shapes the architecture. Recognising in month four that the design from week one was wrong. None of that shows up in a screenshot, which is exactly why it is now the thing worth showing.

Which is why a profile full of half-finished generated projects is now actively negative. It does not read as prolific; it reads as someone who produces starts and has never carried one past the interesting phase. Archive them. Not delete — there is no shame in old work, and what matters is what you pin — but stop presenting them as a body of work. What you want is two or three things that are real: deployed, used by somebody who is not you, and maintained over time.

"Still running nine months later" is the one claim that cannot be manufactured in an afternoon. Everything else can be generated. Duration cannot. Four users who complain when it goes down beat ten thousand hits from a launch post, because complaints mean somebody depends on you.

Write the page around decisions, not features

Most project descriptions are a feature list and a technology list. Both are worthless now: the features describe something an agent could build, and the technologies were probably defaults. Write about decisions instead, specifically three.

What you chose not to build. The reasoning behind a deliberate exclusion is the clearest evidence of judgement you can produce. Anyone can add. Declining to add, with a reason, is rarer.

The constraint that shaped the architecture. Real systems are bent by something awkward: a legacy database, users on terrible connections, a cost ceiling. Name it, and explain how the design bent around it.

The thing you got wrong and what it cost. Not a humble-brag, an actual mistake with a price in time or money. It is the most credible paragraph you will write, because nobody fabricates failures with costs attached.

Show the boring proof

Below the decisions, put evidence. The incident you handled and what you changed afterwards. The migration you ran without downtime. The test suite and what it covers. The load you genuinely serve.

Present it at whatever scale it really is. "Peaks at about 40 requests a second on one small instance" reads as honest. "Built for scale" reads as nothing. Inflated numbers are the one thing a technical reader will check, and being caught costs you the whole document.

Open-source your agent setup

Publish the repository holding your rules files, your custom commands, your hooks, and the harness you make the agent run before it declares anything finished. Write a short readme explaining why each rule exists, usually because something went wrong once.

That artefact shows how you work, which is the thing everyone is trying to assess and nobody can see. Few people have published a good one. It takes an hour and it is more distinctive than another side project.

Disclosure, handled honestly

Do not caveat every project with "AI-assisted". It reads as apologetic, it draws attention to the exact anxiety you are trying to move past, and it treats a normal tool as a confession. Nobody labelled their work IDE-assisted.

There is a hard line, though, and you should apply it ruthlessly. Never imply hand-authorship you cannot back up. The rule: you must be able to explain any line in your portfolio and defend the design. Any line. If someone opens a file and asks why the retry logic backs off the way it does, you need an answer about the problem, not about what the model suggested.

That rule caps how much you can show: anything you have not read and understood does not go in. It will shrink your portfolio, which is correct.

Practise coding without the agent

You will be asked, at some point, to write code in a shared editor with no agent and someone watching. That is not going away, because it is the cheapest way for an interviewer to check that the judgement you claim is yours.

If you have worked with an agent daily for a year, you have probably lost fluency in things you once did without thinking: method names, exact syntax, structuring a function while somebody watches. It comes back quickly, but not during the interview. So practise. An hour a week, agent off, something small end to end.

Contribute to something you did not start

A merged pull request into a project with real users is a stronger signal than another side project, by some distance. It proves what a solo repo cannot: you read someone else's codebase and understood it, you worked within conventions you did not choose, and a maintainer with no reason to be kind accepted your work. Start with a bug you hit in a tool you use.

Before and after

The project is invented; the structure is the point.

Before:

TaskFlow — A full-stack task management application built with Next.js, TypeScript, Tailwind, Prisma and PostgreSQL. Features real-time updates, drag-and-drop scheduling, dark mode, authentication and a fully responsive design.

After:

TaskFlow — Job scheduling for a two-van removals firm in Bristol. Live since March 2025, used daily by four dispatchers, holding around 40,000 jobs. The hard part was never the interface. It was that two dispatchers routinely edit the same day's schedule at once, one of them on a patchy connection in a yard. I built optimistic updates with a conflict-resolution layer first and abandoned it after two weeks, because the merge behaviour was impossible to explain to someone who had just watched their own edit move on screen. What shipped is duller: per-job row locking with a thirty-second lease and a visible "Dave is editing this" banner. The emails about lost edits stopped. What I did not build: no mobile app, because dispatchers work from a laptop and drivers only need a read-only day view, which is a URL. No multi-tenancy, because there is one tenant and generalising early would have cost me a month for nothing. What I got wrong: job history lived in the same table as active jobs, and by month six the dispatch query had crept past 900ms. Partitioning it took a weekend and a twenty-minute maintenance window I should not have needed. Notes in docs/adr/004-job-partitioning.md.

The second version is not longer for the sake of it. Every paragraph contains something the reader could not have guessed and an agent could not have invented, because it comes from having been there.

Be clear-eyed about the cost. This is harder than the old way and it takes considerably longer. You cannot assemble it in a weekend before applying for jobs; it requires that you ran something for a year and paid attention while you did. The old portfolio rewarded a burst of effort. This one rewards the thing that burst was always a proxy for, and now the proxy is worthless, the only route left is the one it was standing in for.