Cognitive Shortcuts

The cognitive budget paradox

Every decision an engineer makes (which test to run first, which flag to pass to a CLI tool, how to structure a commit message, which branch naming convention to use) consumes a fraction of their daily cognitive budget. These micro-decisions are not free.

Decision science research shows that decision fatigue is real and measurable.¹ After making dozens of small choices, engineers' decision-making quality degrades. They become more risk-averse, more conservative, less creative. Over a sprint, accumulated decision fatigue manifests as slower code reviews, more defensive refactoring, and architectural decisions driven by exhaustion rather than principle.

The paradox: adding AI to development can increase cognitive burden if we force engineers to make more decisions about how to use it. "Should I use Copilot or Claude Code? Should I ask for a plan or go straight to implementation? Should I use a slash command or type the full prompt?" More choices = more fatigue.

"The goal of cognitive engineering is not to make engineers think harder; it's to make the right decisions obvious, so they never have to think about them at all."

Slash commands as cognitive shortcuts

A slash command like /fix-issue isn't just a macro. It's a rigorously defined pipeline encoded into a single keystroke:

Read the issue description from the tracker
Analyze failing tests to understand scope
Research related code patterns in the codebase
Plan the solution as markdown
Implement with full test verification
Commit with a well-formed message

The engineer doesn't decide which of these steps to take; they're all implicit in the command. The engineer doesn't decide whether to run tests first or read the code first; that's baked into the command definition. The command encodes domain expertise.

This moves the team from imperative instructions ("do this, then that") to declarative outcomes ("resolve this state"). The cognitive shift is fundamental: instead of directing every step, the engineer describes the desired end state and lets the system determine the steps.

Designing slash commands for your workflow

Effective slash commands follow a pattern: they are specific, repeatable, and domain-aligned.

Specificity

A generic /help command is not useful because it doesn't reduce decisions; it still leaves the engineer asking "what should I ask for?" A specific /test-coverage-report command is powerful because it closes the loop: run all tests, generate coverage data, create a PR comment with the report.

Repeatability

Commands should be worth running dozens of times. /review-pr (which reads the PR, checks the diff, runs linting/type checks, and reports issues) saves 15 minutes of manual work per code review. Over a quarter, that's hours of cognitive budget recovered.

Domain alignment

Your command set should mirror your team's actual workflows. If your team spends 40% of time reviewing code, 30% debugging, 20% writing new features, and 10% maintaining infrastructure, your command set should reflect that distribution. Don't create a command for something you do once a quarter.

The Nielsen heuristics connection

UI design legend Jakob Nielsen's ten usability heuristics are directly applicable to CLI design.^2,3 The most relevant:

Visibility of system status: When /sync-db runs, show progress. Don't leave the engineer wondering if it's hanging.
User control and freedom: Never auto-commit. Always show a --dry-run option. Let the engineer review before the command executes destructive operations.
Error prevention: Make it hard to run destructive commands accidentally. Require confirmation for /delete-branch or /force-push.
Help and documentation: Every command should have a --help flag that explains what it does in plain language.

Cognitive load theory in practice

Cognitive Load Theory, from educational psychology, distinguishes between three types of load:^4,5

Intrinsic load: The inherent difficulty of the task. You can't reduce this; debugging a race condition is hard.
Extraneous load: The overhead of the tools and process. Slash commands directly reduce this. Instead of remembering a 10-step manual process, you type one command.
Germane load: The cognitive work applied to understanding and learning. Well-designed commands increase this, because the engineer freed from extraneous cognitive work can focus on deeper understanding.

The formula is simple: reduce extraneous load so engineers have mental capacity for germane load. Well-designed slash commands are a direct implementation of this principle.

Commands encode team expertise

The most effective teams don't optimize for developer velocity; they optimize for developer clarity. They encode their best practices and repeated workflows into commands so that every team member, regardless of experience level, can execute high-quality processes.

A new junior engineer running /review-pr performs the same multi-step review that a senior engineer would do manually. The command levels the playing field. It's not faster typing; it's smarter engineering.

What leaders should do

Audit the micro-decisions your engineers repeat every sprint, such as test order, CLI flags and commit message format, and encode the most frequent into slash commands.
Shape the command set to mirror where team time goes, for example 40% reviewing code and 30% debugging, and skip commands for tasks done once a quarter.
Give every command visible progress, a dry-run option, a help flag and a confirmation step before destructive operations, and never let one auto-commit.
Hand new junior engineers the same commands, such as a review command, so they run the multi-step review a senior engineer would do manually.