Developers Look for Something to Show When an Agent Writes the Code in 5 Minutes

Five minutes. That is how long, by the Habr columnist's estimate, a neighbor's agent needs to reproduce code you wrote with your own agent. From this the author concludes that the usual way of making yourself known in the profession, which is to publish your code, works less and less well. The piece opens with a question that the published introduction does not yet answer: what should a developer show in 2026?

Kleon's Idea and Three Pieces of Advice

The starting point is Austin Kleon's short book "Show Your Work!" Its main thesis: don't wait for a finished result, show the process. Show the small steps, what you are learning, what inspires you, how you are moving toward your goal. Share a little at a time and every day, teach what you know, and make sure it doesn't turn into spam. The logic is simple: people find you through what you share, and some of them start to help.

Developers usually apply this philosophy in three ways:

• publish code as open-source;
• keep a public log of what you did each day;
• describe how you thought through a problem.

The author notes that even advocates of the first option admit it looks boring.

Where Each Option Breaks Down

The main complaint is aimed at code, and it has two parts. The first is legal and practical: if your employer owns the code, you can't share it. For most employed developers, that is the bulk of their daily work. The second part is economic. If an agent generated the code anyway, it stops being unique evidence of skill. Anyone who gives a similar task to a similar tool will get the same result.

This shifts the very thing being demonstrated. A GitHub repository used to be indirect proof that a person could solve problems: commits, architecture, style. When an agent sits between the task statement and the working code, it is harder to tell from a repository where the human contribution ended. An employer or colleague sees the artifact but not the decisions that led to it.

A daily log and a description of your reasoning are closer to what Kleon proposes, but they don't solve the problem entirely either. Without a concrete result, such entries easily become self-description rather than a demonstration of value.

What This Means in Practice

In the part of the piece that is available, the author does not offer a ready-made answer. Beyond this point, we can only guess at a direction based on how the problem is framed. If value shifts from the text of the program to the decisions around it, it makes sense to show those decisions:

• which task you chose and which ones you turned down;
• how you framed the problem statement and verified the agent's output;
• which model errors you found and how you fixed them;
• what you learned about the process, in a form you can retell without revealing corporate code.

This set doesn't violate an NDA, because it doesn't require publishing source code. Your neighbor's agent can't reproduce it: these are records of judgment, not of syntax. And it fits Kleon's original advice to share the process, not just the outcome.

For those building a public presence now, the takeaway is practical. Don't wait for a perfect portfolio project. You can start with short notes on specific decisions, stripping out anything that belongs to the company. The author's full answer will be in the main Habr article, linked from the original publication. For now, the question itself is telling: the industry is starting to discuss seriously what proves professionalism when writing code is no longer something only a human can do.