Code, tests, agent management: these all concern building software.
Can AI help developers without producing software?
Apply conditions, diffs, state, dependencies, and counterexamples to your own judgment. AI supplies comparisons, not verdicts. Rejecting a suggestion helps if you can explain why.
This neither opposes AI coding nor predicts developers will stop coding.
These are proposed exercises: hypothetical examples, unvalidated prompts, no measured outcomes. Linked research provides context, not validation of these methods.
1. Decompile "something feels wrong"
You oppose merging two settings but cannot explain why.
Hold ownership, values, and update frequency constant. In A, both settings change for one game rule; in B, one changes for balancing, the other for presentation.
Accepting A but rejecting B suggests you care about independent reasons for change, not duplication.
Help me examine my criteria for merging settings.
Give three pairs of plausible cases. Change and name one condition per pair.
Do not assess personality. Withhold interpretations until I choose.
After I choose, propose at most two hypotheses about my criteria.
Give a counterexample to each; if there are two, give a case separating them.
Check that only one condition changed. Write your choice before reading explanations. Try other settings and counterexamples, such as costly separation.
"Decompile" is a metaphor: seek a tentative rule and exception, not a personality profile.
Agreement is not verification. Anthropic's 2023 study examined responses favoring users' beliefs over truth. It does not establish how all current models behave.
2. Change the information, not the AI's persona
"Place your units, then press Start." Must every unit be placed? Can you undo placements? The designer knows; this instruction says neither.
Instead of "act like a beginner," prepare A: what the player sees, including screen content. B adds missing rules: "One unit is enough" and "Repositioning is allowed before starting."
Give A and B to separate conversations; ask the same question and compare the response diff:
Using only this material, list each decision the reader must make,
its supporting evidence, and what remains unknown.
Separate outside assumptions. Do not fill gaps with conventions,
simulate a beginner's feelings, or rewrite the instructions yet.
Trace B's new answers to the added information. Discard outside assumptions. New chats do not erase model knowledge; one response diff does not establish an effect. Screenshots cannot reproduce the full interaction.
Ask a real player: "How many units did you think you needed before starting?"
The result is a question for a reader, not a user-test result. It cannot tell you how many people will struggle.
3. Look for type errors in agreements
"Prioritize bugs" can mean ranking bugs, interrupting current work, or finishing by Friday. A cleaner meeting summary can preserve the ambiguity.
One word hides different types. AI suggests interpretations; it cannot determine intent.
Everyone must approve by Friday; no substitute approver is designated. If one approval is missing and no advance-approval process is documented, who can change the deadline or process?
Compare these statements without summarizing them.
Map subjects, conditions, decision authority, and resulting states
back to the original statements. Mark missing rules "undefined."
Give up to three meaning conflicts or incompatible scenarios.
State assumptions and questions for participants.
Do not infer motives, personality, or competence.
Undocumented arrangements might resolve conflicts. Counterexamples do not prove failure. Check the records; take questions—not verdicts—to participants.
Replace complaints about people with conditions to clarify. Not every interaction needs a formal specification.
4. Separate past decisions from known outcomes
A prototype tool fails in production. Was the selection wrong, or did nobody reassess it after scope changed?
Suppose production use and extra platforms followed a three-week prototype. Identify a reassessment trigger, not a duty to predict everything.
Separate the information state at the time from later events:
I will provide the outcome later. Use records from the time first.
List available options and conditions that would justify each.
Separate confirmed facts, things then unverified, and missing records.
Identify conditions that should trigger reassessment.
After I provide the outcome, compare what was knowable then with later discoveries.
Do not invent context, judge people, or declare an optimal choice.
Google's blameless postmortem guidance considers information available at the time. This AI exercise is a proposal here, not Google's procedure.
You know the ending: preserve objections and unresolved risks when selecting records. Remove unnecessary names; separate the model's outside knowledge. This cannot recreate ignorance of the outcome.
Check the records and ask participants. Ignored limitations still matter. Record a future trigger—"Recheck platforms before production"—or leave the judgment unresolved.
5. Find work to remove before automating it
Before scripting a weekly report copied between trackers, trace its dependency backward: whose decision needs this information?
If it supports staffing decisions, must every field be rebuilt weekly? Could reporting changes suffice? For now, prohibit automation proposals:
Examine this task without proposing code, automation, or new tools.
Map inputs, outputs, recipients, and decisions supported.
Unknown purpose means "check the purpose," not "waste."
Suggest up to three ways to stop, reduce, or combine work.
Name possible lost value, affected people, whom to consult,
and conditions for restoring the original process.
Flag contractual, retention, or safety constraints. Do not execute changes.
Adams et al.'s 2021 research found that people can overlook beneficial subtractive changes. It did not test this AI workflow or establish that removing tasks is safe.
Rarely read data may matter during incidents. Confirm its purpose and get approval before a trial. Set duration, retained data, and rollback conditions.
Measure recipients' effort, follow-up questions, and missed information—not just preparation time. Making someone else search transfers effort rather than removing it.
Necessary work can still be automated afterward. Sometimes you can reduce work without new software.
Define a comparison and a stopping point
These are thinking exercises, not unprecedented techniques. Specify what changes and when to stop.
Stop at one question to verify—or sooner if examples are implausible, outside assumptions persist, or asking directly is faster.
The shared sequence: generate comparisons, then check records or real people. Writing your hypothesis first can separate it from explanations adopted later. More AI debate without observations adds no real-world evidence.
Share only permitted information; removing names may not prevent identification. No authority to edit code, send messages, or stop processes is needed.
Record what changed, what you learned, and what remains unverified.
Do not measure AI's value only by what it produces. Ask what decision rule or better question remains after you close the chat.
Disclosure: This article was developed and adapted into English with AI assistance.
Top comments (0)