Appearing Productive: How LLMs Fuel Workplace Theater in Software

Appearing productive through workplace theater is a growing problem in software engineering. The teammate who fills every Jira ticket with a novella, the manager who generates slide decks nobody reads, the architect who produces sprawling diagrams—they're all symptoms of a culture that prizes busywork over progress. A recent post on Hacker News titled "Appearing productive in the workplace" struck a nerve, gathering over 600 points and 200+ comments. The article argues that many knowledge workers—especially in software—have become virtuosos of what the author calls "the elongation of workplace artifacts." And with LLMs in the mix, the problem is scaling faster than ever.

The Rise of Workplace Theater

The piece, published on nooneshappy.com, dissects the gap between real productivity and the performance of productivity. Requirements documents have swollen from one page to twelve. Status updates now come as bullet-pointed pyramids. Every retrospective spawns a mountain of templates. The goal isn't to communicate, but to signal effort.

The article ties this to what I'd call Cargo Cult productivity: mimicking the outputs of effective work without replicating the underlying thinking. LLMs supercharge this dynamic. AI tools can churn out documentation, design proposals, and code at a pace that looks impressive to managers who don't read closely. One commenter on HN summarized the problem: "LLMs have automated sucking up to management." The result is a workplace where busywork replaces value, and the people who actually ship get buried in noise.

Why HN Can't Stop Talking About Fake Productivity

The HN thread is filled with people who recognize this phenomenon firsthand. A top comment captured the mood:

"Requirements documents that were once a page are now twelve. Status updates that were once three sentences are now bulleted summaries of bulleted summaries. Retrospective notes, post-incident reports, design memos, kickoff decks: every artifact that can be elongated is, by people who do not read what they produce, for readers who do not read what they receive."

Another commenter described a common scenario: "They hired an architect 18 months ago who used AI to architect everything. To the senior devs it was obvious—everything was massively over engineered, yet because he used all the proper terminology he sounded more competent to upper management." The community seems to agree that software engineering is particularly prone to this because of its invisible nature—you can't glance at a codebase and immediately judge its quality. As one person noted, "Many software engineers didn't do real engineering work during their entire careers. In large companies it's even harder—you arrive as a small gear and are inserted into a large mechanism."

Activity vs. Progress: My Take

The article hits on something I've seen across many organizations: the conflation of activity with progress. In a field where output is hard to measure, we fall back on proxies—lines of code, number of meetings, length of documents. LLMs exploit this beautifully. They produce tone-perfect prose, plausible code, and diagrams that look professional even when they're wrong. This doesn't just waste time; it actively degrades trust. When a manager can't tell the difference between a real design and an AI-generated one, the team loses the ability to make sound decisions.

The core issue is that our tools for evaluating work are stuck in an industrial era. We count artifacts because artifacts are countable. But software is a craft of judgment, not volume. LLMs aren't the cause of workplace theater—they're an accelerant. The same incentive structures that rewarded verbose reports before now reward AI-generated reports. The solution isn't to ban AI; it's to change what we measure. As The Mythical Man-Month taught us, adding more people to a late project makes it later. Similarly, adding more artifacts to a confused team makes it more confused.

What Builders Can Do About It

If you're a developer or a tech lead, here's what I suggest:

1. Shorten the feedback loop. The more removed you are from the actual impact of your work, the easier it is to fake. Push to ship small, measurable improvements. When you ship a feature, track its usage, not its documentation length.

2. Read more, write less. The best engineers I know read more code than they write. They spend time understanding the system before changing it. In contrast, the productivity-theater types write endless proposals and then discover the foundational assumption was wrong.

3. Demand clarity over volume. When reviewing a design doc, ask: "What is the key decision here? What have you ruled out?" If the document is long but answers none of those, flag it. One commenter on HN suggested LLMs are good for "intelligent autocomplete" and "brainstorming," not for producing final artifacts. I agree.

4. Be wary of the AI-generated portfolio. A candidate or colleague who produces a flood of polished diagrams and specs but struggles to explain tradeoffs is a red flag. Interview for understanding, not documentation output.

To illustrate, consider a typical bloated status update:

# Weekly Progress Report

## Overview

This week focused on integrating the notification system with the existing user preferences module. Several challenges were encountered, including race conditions in the database layer. After extensive debugging, a solution was implemented using optimistic locking.

## Accomplishments

- Researched three approaches for notification queuing
- Prototyped the Kafka-based approach
- Presented findings to the architecture review board
- Submitted pull request for user preferences refactor

## Next Steps

- Complete code review for PR #234
- Start implementing the chosen queuing strategy

Versus a concise update that actually informs:

### Notification system integration

- **Progress:** Done. PR #234 merges the feature into main.
- **Blockers:** None. Database race condition was fixed with optimistic locking.
- **Next:** Queuing strategy decision expected by Friday.

The second one takes 30 seconds to write and 10 seconds to digest. The first looks busy but adds no signal.

The Verdict

If you work in a knowledge-intensive environment—especially software development—you should care. The gap between looking productive and being productive is widening, and LLMs are the new shovel. If you're an individual contributor, guard your time against artifact inflation. If you're a manager, learn to judge outcomes, not outputs. If you're a founder, build a culture where clarity and impact are prized over verbosity.

The rest of the world can safely ignore this debate—until their next performance review.

---

Read the original article here and the HN discussion here.