What to show off when an agent writes your code in five minutes

When an agent writes the architecture, the framework, the baseline functionality, and half the working code in five minutes, what does a developer put in their portfolio? A codebase is no longer a signal of skill — anyone with access to the same agent can produce one.

This question picks up a principle from Austin Kleon's book "Show Your Work!": don't wait for a project to finish, show the process in small steps, teaching others what you know along the way. But in 2026, that idea needs rethinking: you need to show judgment, not artifacts.

Six things to show instead of code

What reveals your work when the code itself was written by an agent:

• Decisions and rejected options. These show judgment that the agent doesn't have about your project. When a directory of MCP servers docked two points because function names lacked dots (like `stories.search`), that was a deliberate decision: major model providers don't let dots through in names, and names matching the directory's convention would have broken the clients the server exists to serve.

• Failures and how you diagnosed them. Google started labeling pages as "soft 404" even though they loaded fine in a browser. The cause: a single line in robots.txt was blocking the API used to fetch content. Google renders like a browser, couldn't get the data, and saw an error screen instead.

• How you verified the agent's work. The most important skill right now, and invisible in the code. Three examples from one week: a server test checked the wrong error code and passed for days, until a real client using a third-party tool crashed with an exception; a stats block was empty in production because of a CDN security policy that the test browser didn't enforce; Google found nonexistent pages ending in `.mdread-only` — a link to the source text sat right next to a label, the browser rendered a space that wasn't in the source code, and Google glued them into one address.

• Instructions you gave the agent after a bug. Rules in configuration, reusable skills. After the security-policy bug, deployment now refuses to roll out pages with inline scripts. After a mismatch between the server's registry and its actual behavior, deployment now fails if the public surface changed without a version bump.

• Before-and-after numbers. A result is easy to show even when the system itself can't be shown. "Two days after the fix, Google stopped flagging the pages as soft 404" or "the check now catches this before release" says more than a diff would.

• What you'd do differently. An honest postmortem builds more trust than a success story, and it's more useful to anyone doing similar work.

How this plays out: a scenius, not a lone genius

When you show decisions and mistakes instead of code, people with different experience respond. Two comment threads on dev.to about an MCP server turned into actual product features: a version check and a test suite using a real client. One of those threads reached Sidney Bissoli, the author of seven MCP servers for Brazilian open data. He turned the idea into a standalone tool, ran it against all 142 versions of his servers, found two that didn't even start, and wrote a post with the takeaway: "one comment thread changed how eight servers get released." Austin Kleon calls this "scenius" — good work emerges from a group that shows each other what they're doing, not from a lone genius.

Inside a company: the mechanism without the names

worklore.dev publishes short stories: what was tried, what broke, what worked. When someone's agent reproduces a story, that gets tracked on the page. Content that can't be generalized for the public is still worth writing down for yourself — your own agent will repeat the mistake in a couple of months, once the details are forgotten.

Even on closed projects, most of this can be shown if you keep the mechanism and strip the names. "Internal service," "checkout step," "our CDN" — the lesson almost never depends on the brand. Show the reasoning, not the artifact: why you chose this approach, how you verified it, what you'd change. Ask for permission once — most managers don't mind an anonymized lesson. Small is fine: one problem, one fix, 300 words. A handy template: context → where the agent was confident and wrong → diagnosis → what you changed so it doesn't happen again.