I Needed a Ditch. You Brought an Atomic Bomb.

The AI discussed intelligence. I pressed Ctrl+C.

Knowing many methods does not guarantee choosing a useful one.

I had been discussing democracy, assumptions and intelligence with an AI. The conversation was worth keeping, and I wanted the whole thing preserved so I could use it elsewhere.

The exchange wandered into documents, exports and workarounds. I did not want a summary. I wanted the conversation. Eventually I simply scrolled up, selected it with my mouse, pressed Ctrl+C, and pasted it into a document.

That worked for my situation. A simple human action had accomplished what an increasingly elaborate technical discussion had failed to make easy.

The irony was difficult to miss. We were talking about intelligence while I was explaining to the AI how to copy some text. My reaction was that this was another example of why GPT was not yet AGI.

That reaction captures my frustration; one incident does not settle every possible definition of artificial general intelligence. The narrower lesson is enough: the system had failed to exercise practical judgment about the task directly in front of it.

The knowledge was available. Recognizing which knowledge mattered was the missing step.

An atomic bomb is not a better shovel

Capability only becomes useful when it fits the job.

“It’s an atomic bomb when I just need a ditch” was how I described the mismatch. The joke works because the proposed power is so far out of proportion to the need.

A more elaborate method may require setup, extra accounts, file conversions, troubleshooting and instructions. Each step can make sense in isolation. Together they can turn a small job into a project.

That is why “technically possible” and “useful to this person now” are different judgments. The user pays for the complexity in attention, time, uncertainty and opportunities for error.

Sometimes a complex method is justified. Copying text might not preserve all images, formatting or hidden portions of a conversation. A structured export could be necessary for those requirements. In my case, selecting and pasting delivered what I needed. The proper first step was to understand that need and test the straightforward option.

The standard is the simplest reliable solution that meets the actual requirements—not the fewest steps regardless of what gets lost.

We called it “cube thinking”

The interesting engineering problem can displace the customer’s actual problem.

When I worked in sales at Landesk, I remember a company with roughly 150 software engineers and three or four product managers. They would develop ideas that were not always connected to what customers were asking us to solve.

When sales brought back a specific customer problem, it could receive little enthusiasm because it was not interesting to the people designing the product. We called this “cube thinking”: thinking from inside the cubicle rather than from inside the customer’s situation.

That is my recollection of a pattern I encountered, not a judgment on every engineer or every product decision. Customers do not always see the best underlying solution either. Their proposed feature may need rethinking. But the difficulty they are experiencing is evidence to investigate, not an inconvenience to dismiss.

The parallel with the AI was striking. In each case, the solution-maker could become more engaged by the technical possibilities than by the modest result that would make the user’s day easier.

An impressive answer can still be a poor answer

Judge the result from the person’s side of the desk.

An answer may be fluent, detailed and technically informed while leaving the user further from completion. A product can have an extraordinary feature list and still make an ordinary task unnecessarily difficult.

Ask what happened after the explanation. Did the person finish? Did they understand the next step? Did the suggested approach introduce more work than it removed? Did it solve the whole need or only the portion the expert found interesting?

This is a familiar concern in user-experience design. Don Norman and Jakob Nielsen place meeting the customer’s needs at the center of their definition of user experience, with simplicity and elegance serving that goal. My stories are applications of that established principle, not a claim to have invented it.

A polished demonstration shows what a system can do. Watching a real person try to finish a real task shows whether that capability is usable.

Ask what “done” looks like before choosing the machinery

A short outcome check can prevent a long, unnecessary project.

1. Describe the finished result. “I can read and reuse the complete conversation in this document” is more useful than “I need an export solution.”
2. Identify what must survive. Exact wording? Images? Formatting? Dates? Searchability? Do not quietly replace the user’s requirement with an easier one.
3. Try the smallest credible method. Test an ordinary copy, existing feature or simple manual action before designing a new workflow.
4. Check the result. Look at the beginning and end, confirm completeness, and verify that the material is usable where it needs to be.
5. Add complexity for an observed reason. If something important is missing, address that specific failure. If the job is done, stop.

The same method applies to a manager requesting a report, a consultant proposing a process, or a developer designing a feature. Before building anything, ask the person who will use it what would make their problem go away.

A shovel today. Machinery when the job earns it.

Simplicity is a fit decision, not a rule against automation.

Copying one conversation manually may be sensible. Preserving thousands on a schedule, with dependable completeness and structured metadata, may justify an automated system. A quick workaround that must be repeated all day can become the expensive option.

Consider the full cost over the relevant period: setup, use, maintenance, mistakes and recovery. The right solution can change as the volume, risk or requirements change.

This connects to handling big, hairy, complex projects: start with a useful step, learn what it reveals, and let evidence guide the next action. It also complements Execution turns an idea into value. Neither elaborate plans nor elegant explanations create value until they help something worthwhile happen.

What this has to do with choosing a judge

Both stories ask whether the mechanism serves its intended outcome.

The conversation I was trying to preserve led to What If Democracy Elected Outcomes Instead of Politicians? That article asks whether citizens should focus on choosing desired outcomes, with competent appointment and independent assessment handling delivery.

At the doorstep, a candidate’s presentation prompted a question about how we select people for serious work. At the computer, an elaborate response prompted a question about how we select methods for simple work. In both cases, an impressive performance could become detached from the result being sought.

The two problems are not equivalent. Government involves competing values, rights, power and accountability; copying text does not. The crossover is a discipline of thought: define the purpose before defending the familiar process.

Start with the outcome people need, then judge the process by how well it delivers.

The next improvement is better judgment

Knowing when to use a simple solution is part of being capable.

This experience does not erase what AI makes possible. In AI is like magic in a box, I explore how it can shorten the distance between an idea and something useful. That makes failures of practical judgment more revealing, not less.

The question for an assistant, human or artificial, is whether it notices that its approach is going wrong, returns to the actual objective and changes course. Acknowledging a mistake helps. Avoiding the same unnecessary detour matters more.

Before admiring the machinery, ask: did we get the ditch?

Sources and perspective

Two personal experiences illustrate a broader design principle.

The copy-and-paste episode and Landesk account are Tim Barrie’s recollections, including approximate staffing numbers. “Cube thinking” is the term he recalls using with colleagues; no claim is made about its original coinage. “It’s an atomic bomb when I just need a ditch” is his metaphor. The article title is an editorial adaptation of it.

Conceptual background: Don Norman and Jakob Nielsen, The Definition of User Experience, Nielsen Norman Group, 1998. The account supports a practical lesson, not a controlled comparison of AI and human intelligence or a definitive test of AGI.

Developed with AI assistance from Tim’s discussion. All cartoons are fictional conceptual illustrations. Their exaggerated machines and dialogue are humor, not a literal reconstruction of the software or workplace.