The Performative Programmer in the AI Era and the Cost to Your Organization

When the appearance of productivity drifts away from the work needed to deliver a reliable solution

Picture the scene. Someone shares their screen, shows off a good-looking system and announces that they built the whole thing in a few hours. There is a dashboard, a chart, animation, AI integration and a presentation that looks like it came from a startup about to land an investment.

The meeting gets excited. Someone is already calculating how many people could be replaced by all that efficiency.

Then comes a question: who can access whose data?

Silence. The demo was ready to show what happens when everything goes right. That part had not made it into the script yet.

This imaginary scene helps bring a provocation from Mano Deyvin about the “performative programmer” into the workplace. His name is Deyvid Nascimento, a developer who identifies himself as the person behind the @manodeyvin alias and works with Rails. [1]

Mano Deyvin… or should that be Cousin Deyvin? My surname is Nascimento too, and my family is enormous. Who knows, this investigation might end at a family barbecue, hehe.

On social media, he poked fun at the signals people use to project a programmer identity, as well as the “performative vibe coder,” including displays of equipment, tools and AI consumption. The discussion became a topic on his Mano Rage Show. [2][3]

I want to build on that provocation to discuss what happens when an organization starts buying the appearance of competence as though it had already received a reliable deliverable.

My argument is that AI can reduce the effort required to produce visible signs of productivity. That makes it even more important to verify the work those signs represent.

When the work turns into a persona

I use “performative” here to mean putting on a professional performance: maintaining an image of expertise, speed or importance that the evidence of the work does not support.

It can show up in an exaggerated promise, a demo that leaves out limitations or a task marked as complete while other people still need to work out how to make it function.

A keyboard, a code editor and a LinkedIn photo cannot tell you whether someone does this. Creating content, explaining decisions and presenting a project well are legitimate activities. Someone can do all of them and deliver excellent work.

We should also protect the work that gets less attention. Investigating a defect, mentoring a colleague, simplifying a solution and preventing a dangerous change can take hours without producing a new screen to show at the next meeting.

The standard needs to be the correspondence between what was promised, what was demonstrated and what the organization actually received.

A beginner who explains their limits and asks for a review gives the team a chance to manage the risk. An experienced professional who hides their uncertainties can do the opposite. Years of experience and follower counts do not settle this question.

AI also helps produce the presentation

It is easy to see the appeal of AI for people who want to build things. You can explore an idea, ask for alternatives, generate an initial implementation and iterate on it. That creates room to learn and experiment.

But the same convenience can give a professional finish to something that has not yet been understood.

Imagine a project whose code, documentation, architectural explanation and tests were all produced through the same sequence of prompts. Each piece seems to confirm the one before it. The whole package looks convincing, even though it may still share a mistaken assumption about the problem.

If the person responsible understands the limits, checks the decisions and fixes the flaws, that material can be very useful. If they accept everything because “the AI explained it so well,” the organization gets a story about security before it has enough evidence to support it.

Things become especially delicate when a demo turns into a commercial commitment. The customer believes they have bought a finished system; the presenter was still testing a hypothesis.

A prototype can be an excellent deliverable, provided it is presented as a prototype. Confusion starts when that distinction disappears from the conversation, the deadline and the price.

The productivity we feel and the productivity we can measure

Research shows how our perceptions can fail us in this assessment.

In July 2025, METR published an experiment involving 16 experienced developers and 246 tasks in projects they knew. With the AI tools tested, the tasks took 19% longer. Even after the experiment, participants estimated that they had gained roughly 20% in speed. The study captures that particular setting and tools from early 2025. [4]

The February 2026 update brought indications of improvement, but METR itself explained that the selection of participants and tasks, among other measurement problems, prevented a confident estimate of the current effect. Treating the 19% figure as a verdict on all AI-assisted programming in 2026 would go beyond the findings. [5]

In May 2026, another METR survey gathered responses from 349 technical workers and found gains reported by the participants themselves. The researchers distinguished perceived speed from perceived value produced, while also identifying limitations in the sample and in personal estimates. This kind of research helps us understand people's experiences, but it does not establish the gain through direct measurement. [6]

There is important positive evidence too. Three workplace experiments, covering 4,867 developers, estimated an increase of approximately 26% in completed tasks as an effect of adopting GitHub Copilot. The measure relied mainly on completed requests for code changes, known as pull requests. The paper appeared in Management Science in February 2026; results varied across companies. That indicator does not automatically translate into profit or lasting quality. [7][8]

These studies examine different conditions. And none of them identifies a category of “performative programmers” or calculates how much it costs.

What they help support is a more reasonable requirement: we need to observe the outcome as well as the feeling of speed.

Someone may sincerely believe they are producing much more. They may even be right. Management's responsibility is to make it possible to verify that, without relying entirely on the presenter's enthusiasm or the audience's skepticism.

The cost that moves to someone else's desk

One way to look extremely productive is to finish your own part of a task before all the necessary work has been accounted for.

Imagine someone submitting a huge change, celebrating the deadline and moving on to the next task. Another professional has to understand what changed, check whether the behavior makes sense, request fixes and work out how the new feature fits into the rest of the system.

Review is part of development. The problem arises when the deliverable was announced as complete and the remaining effort was left out of the account of whoever received the credit.

The work can keep moving: from development to review, from review to support, and from support to whoever has to explain the problem to the customer.

Then comes maintenance. A decision nobody can justify, an unnecessary dependency or an integration without failure handling can make future changes more difficult. The bill follows the system for much longer than the excitement of its launch.

In the presentation, one person appears to have saved two days. In operation, several people may have spent three finishing what was missing. That possibility needs to be measured in the project, but it already shows why evaluating implementation speed alone is insufficient.

There is also the opportunity cost. While an experienced professional reconstructs decisions that should have been clear, another improvement waits. That delay should be measured carefully, so the same loss is not counted twice when adding up hours and postponed opportunities.

The useful question becomes: how much effort did the whole team need to invest before this deliverable could be used with confidence?

The pretty screen and the magic admin password

I once encountered a situation in which the condition for making someone an administrator came down to checking whether the password was admin123.

That was the logic used to determine administrative access. A rule like that may appear to work in a demo: someone enters the password and the dashboard opens. But a successful demonstration does not make the access control adequate.

The case alone does not establish that AI wrote the code or that its author tried to deceive anyone. It illustrates how a feature can be demonstrated without properly addressing the responsibility it carries.

OWASP's authorization guidance includes granting only necessary privileges, denying access by default and checking permissions on every request. Validation must happen in a trusted component of the system; hiding a button in the browser is not enough. [9]

For an organization, the possible consequences of inadequate controls go beyond “there's a bug.” They may include unauthorized access, changes to records, disruption of activities and the work of investigating and correcting the exposure. The extent depends on the data, the permissions and what actually happened.

In systems supporting public services, commerce or administrative routines, the failure can also reach people who never took part in that enthusiastic meeting.

That is why a seemingly dull question about permissions deserves time before the applause.

Even the test needs to show what it is testing

Another risk is treating a screen full of passing tests as sufficient proof that everything is correct.

A test can check exactly the behavior that was implemented while still failing to check the rule the user needed. If the system was supposed to prevent an operation, but the test was written to confirm that it happens, the green light is not much help.

OWASP warns about agents that weaken checks or remove failing tests. It also recommends human responsibility for AI-generated changes. A tool's output needs to be reviewed, including when the tool produces its own validation. [10]

That calls for specific questions. Which requirement does the test establish? What failure would it detect? Was an important scenario left out?

AI can help identify those scenarios. The key is to keep an independent reference for what “correct” means: the user's need, the business rules and the system's constraints.

The same applies to documentation. An elegant explanation of the architecture becomes valuable when it reflects the system another person will need to operate and modify.

A simulation that puts a price on the discussion

Let us use an entirely hypothetical example, with the same scope and the same acceptance standard. To keep things simple, each hour of work costs R$100 in Brazilian reais, regardless of the role.

Both deliveries may use AI. The comparison below represents a reference delivery and another that was declared complete too soon.

Work required	Reference delivery	Delivery declared complete too soon
Implementation	12 h	4 h
Review	3 h	6 h
Fixes	2 h	10 h
Initial support	1 h	4 h
Total work	18 h	24 h
Cost of the hours	R$1,800	R$2,400

If someone shows only the implementation, the second delivery appears to have saved R$800. Once the remaining work is included, it ends up costing R$600 more.

These figures are not a market estimate. They illustrate the calculation each organization should make using its own data. Competent use of AI can also reduce review, fixes and support, improving the overall result.

The actual cost may also include tools, infrastructure and the consequences of incidents. Each component needs to be assessed without mixing costs already incurred with risks that may never materialize.

The point is to follow the delivery through to the stage at which the advertised savings can be confirmed.

Management has a role in the spectacle

It would be convenient to place all the responsibility on the professional who oversells the presentation. But someone chose which signals would be rewarded.

If a company values the amount of code produced, people have an incentive to produce more code. If it rewards constant demos, what appears on the screen gains an advantage over the maintenance work that keeps it running.

AI adds other eye-catching indicators: the number of agents, the volume of tokens and the percentage of automatically generated code. That information can help manage tools. On its own, it says little about the benefit delivered to the user. A screenshot of the bill proves consumption. Progress still needs to be demonstrated.

The SPACE framework, published by researchers from Microsoft, GitHub and the University of Victoria, treats productivity as multidimensional. Its dimensions include satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. Reducing everything to one count loses an important part of the work. [11]

DORA 2025 offers another contribution: it presents AI as an amplifier of an organization's existing conditions. The official retrospective reports improved delivery throughput, accompanied by a risk to stability when the foundations are weak. This is organizational research, not a causal guarantee for every team. [12][13]

My reading of this is that speeding up the generation of changes without taking care of the capacity to assess them may simply move the bottleneck. The company needs to look at the entire flow.

Sometimes the programmer has simply learned to deliver exactly the show management decided to buy.

What to ask before approving a delivery

An organization does not need to turn every change into a doctoral defense. It needs to ask questions proportionate to the risk and accept answers that can be verified.

I would start with these:

1. What problem has been solved for the user? An available feature still needs to demonstrate its usefulness. Observe a real task: has it become faster, clearer or less prone to error?
2. What is ready, and what is still a hypothesis? A prototype, a pilot and operation with real users involve different commitments. That distinction should be clear to both the buyer and the people who will maintain the system.
3. How were access, data and significant failures checked? The depth depends on the system. An informational form and a workflow that changes payments call for different levels of care.
4. What work is still left for other people? Review, integration, documentation and support need to appear in planning and in the assessment of the result.
5. Can someone else take it from here? The person responsible needs to be able to show the decisions, dependencies and limitations. The explanation can be written or demonstrated; it does not need to become an eloquence contest in a meeting.
6. How will we notice and fix a problem after delivery? Depending on the risk, that involves logs, monitoring, reverting changes and restoring operation.

These questions also help with hiring. Rather than rewarding only the most impressive presentation, you can observe how a person handles a limitation, explains a choice and incorporates a review.

To track the work, I would combine the time it takes a change to reach the user with rework, significant failures, maintenance effort and the service outcome. I would compare similar periods and deliveries, taking the system's complexity and maturity into account.

Turning those data into an automatic employee ranking would recreate the problem. The more useful purpose is to discover where the process is working and where costs are being hidden.

The opportunity remains enormous

There is plenty of room to build better with AI. It can help beginners, extend the capabilities of experienced professionals and make experiments viable that would previously have consumed too many resources.

To benefit from that, an organization needs to allow learning and acknowledge uncertainty. If every doubt is treated as incompetence, the company encourages precisely the theatrical confidence it will later complain about receiving.

I want to work with people who can say, “this part has been validated; this other part needs a review.” That clarity makes it possible to decide on deadlines, risks and priorities more responsibly.

It is entirely possible to use several AI tools, present a project well and deliver value. It is also possible to do so with an understated setup and few tools. The evidence lies in the result the organization can use, maintain and understand.

Cousin Deyvin gets the credit for the provocation. We can investigate the family connection later.

For anyone buying technology, I would leave one question for the next presentation: how much work is still left after this demo, and who is going to pick up the bill?

Sources

[1] Deyvid Nascimento. Personal website. Identity and professional background.

[2] Mano Deyvin. Post about the performative vibe coder. Published on the author's profile.

[3] Mano Deyvin. Post announcing the topic for episode 262. Programadores Performáticos episode of the Mano Rage Show.

[4] METR. Measuring the Impact of Early 2025 AI on Experienced Open Source Developer Productivity. July 10, 2025.

[5] METR. We are Changing our Developer Productivity Experiment Design. February 24, 2026.

[6] METR. Measuring the Self Reported Impact of Early 2026 AI on Technical Worker Productivity. May 11, 2026.

[7] Cui, Demirer, Jaffe, Musolff, Peng and Salz. The Effects of Generative AI on High Skilled Work. Management Science. Published online February 27, 2026.

[8] Cui and colleagues. Full version made available by MIT. February 2025. Details of the productivity measures.

[9] OWASP. Authorization Cheat Sheet.

[10] OWASP. Secure Coding with AI Cheat Sheet.

[11] Forsgren and colleagues. The SPACE of Developer Productivity. ACM Queue, 2021.

[12] DORA. State of AI Assisted Software Development 2025.

[13] DORA. DORA 2025 Year in Review. January 7, 2026.