Austin Kleon's Show Your Work! is a short book with one big idea: don't wait until something is finished to share it. Share the process: the small steps, what you're learning, what inspires you, and the story behind the result. Post something small every day, teach what you know, and don't turn into spam. Kleon's promise is that people find you through what you share, and some of them start helping you.
When I tried to apply it to my own work as a developer, I looked at how others do it. The advice I found online came down to a few variants: post screenshots of the code and the app as they grow, keep a public log of what you got done each day, or write up how you thought about a problem. Even people who suggest the screenshots admit that code that doesn't work yet looks pretty boring.
These are fine ideas, but they skip the harder case, and in 2026 that case is most of us. You work on a team. The code belongs to the company. You can't put it on GitHub, and you can't screenshot it either. And half of it was written by an AI agent anyway.
So what do you show?
Your repo now shows what your agent can do
Here's the part I expect some of you to disagree with. When an agent writes most of the code in minutes, a clean repository says more about the agent than about you. Anyone with the same agent can produce similar code. What they can't produce is everything around it: what you decided, what you checked, where the agent was confidently wrong and how you noticed.
That's the work that's actually yours now. And unlike company code, most of it can be shared, once you strip the names.
Six things a developer on a team can show
Each of these comes from my own last few weeks. I work mostly with Claude Code on a small product, and the same patterns show up in team work.
1. A decision and the alternatives you turned down. It proves judgement, the one thing an agent doesn't have about your project. My example: a directory that ranks MCP servers gave mine 98 out of 100 and took off two points because my tool names weren't dotted, like stories.search. I kept them undotted on purpose: the function-name rules of the big model providers reject dots, so the "better" names would break the clients my server exists for. Nothing about this needs the code to explain it.
2. A failure and how you found the cause. Mine: Google started calling my pages "soft 404", pages that opened fine in any browser. The cause was one line in robots.txt that blocked the API my pages load their content from. Google renders pages the way a browser does, wasn't allowed to fetch the data, and saw my app's "not found" screen. To share a failure like this from a company system, keep the mechanism and drop the names: "a rule meant for one thing blocked another" travels to any stack.
3. How you checked the agent's work. This is the skill that matters most now, and the one nobody sees. Three examples from one week. My live test of my server checked for exactly the wrong error code: the agent and I had written down what the server did and called it correct, and the test passed for days. A real client, through a third-party testing tool, threw an exception on the same response. And a statistics block on my site worked in every test, then stayed empty in production: the CDN's security policy blocked inline scripts, and the test browser didn't apply that policy. The third one I caught this morning: Google's Search Console listed pages on my site that don't exist, all ending in .mdread-only. On every story page, a link to the story's raw text file sat right next to a "read-only" label. On screen there was a gap between them; in the page's text there wasn't, so Google read the two as one address and tried to crawl it. One space fixed it, and no test of mine would have caught it, because nothing looked wrong. All three times the agent's work was "done". Noticing it wasn't was my job.
4. The instructions you gave the agent after it went wrong. A rule in your agent's instructions file, a check you added to the deploy, a reusable skill. These show that you can steer, not just prompt. After the security-policy bug, my deploy now refuses to ship a page with an inline script. After a listing of my server drifted from what the server actually did, the deploy fails if the server's public surface changes without a version bump. Each rule is two lines, and each one is a story.
5. Numbers before and after. Impact is easy to share even when the system isn't. "Google stopped calling my pages soft 404s two days after the fix" or "the check now catches it before release" says more than a diff.
6. What you'd do differently. A short, honest postmortem. People trust it more than a success story, and it's often the most useful thing for someone a step behind you.
Teach what you know, to someone else's agent
Kleon's best chapter is "Teach what you know". With agents there's a new twist: you can write your experience so that another person's agent can repeat it in their own project. That's what I'm building with worklore.dev: short stories with what was tried, what broke, what finally worked, plus the steps a stranger's agent runs and a check that it worked. When someone's agent reproduces a story, it's counted on the page.
And it doesn't have to be public. For things you can't generalise enough to share, a private story is still worth writing: in a couple of months you won't remember the details, and your own agent will be able to repeat what you did.
Showing my work this way already paid back. My article about building an MCP server started two conversations with strangers in dev.to comments, and both turned into features in my product: a check that the server's surface can't change silently, and a set of tests that go through a real client. Kleon calls this "scenius": good work comes out of a group of people showing each other what they do, not out of one person working alone. I wouldn't have found either idea on my own.
How to share work from inside a company
- Keep the mechanism, drop the names. "An internal service", "a payment step", "our CDN". The lesson almost never depends on the brand.
- Share the reasoning, not the artefact. Why you chose something, how you tested it, what you'd change.
- Ask once, then you'll know the line. Most leads are fine with an anonymised lesson. If not, write it privately.
- Small is fine. One problem, one fix, 300 words. Kleon is right that the small steps are the part people want to see.
So what would you show?
If you couldn't show a single line of code, what would you show about your work? I'd really like to know what other developers on teams share, and what they've been told they can't.
Top comments (0)