Jonathan Haaswritingnowusesabout
emailgithubx
Jonathan Haaswritingnowusesabout

Building a Developer Environment That Actually Works: My Dotfiles Journey

July 11, 2025·3 min read

Most developer environments are optimized for keystrokes. The actual bottleneck is context transfer between you and your AI tools.

#developer-experience#dotfiles#productivity#automation

Most developer environments are optimized for the wrong bottleneck. Developers spend years shaving keystrokes -- gs instead of git status, arcane aliases nobody else can read. The actual bottleneck in 2025 isn't typing speed. It's context transfer between you and your AI tools.

I deleted my dotfiles and rebuilt them around a different principle: every command, alias, and tool should be legible to both humans and AI models.

The Problem with Clever Shortcuts

A shell alias like gpsup='git push --set-upstream origin $(git_current_branch)' saves 4 seconds per use. It costs you every time you need to explain your workflow to an AI assistant, onboard a teammate, pair program, or work on a machine without your configs.

This is a bad trade. The 4-second savings is local optimization. The costs are systemic -- they compound across every collaboration surface in your workflow.

AI coding assistants read your shell history, parse your command output, and suggest next steps based on what they can understand. Opaque aliases are invisible to them. Structured, descriptive commands are actionable.

The Rebuild: Context Over Keystrokes

Three design constraints drove the new architecture:

Descriptive commands. list-files-detailed instead of ll. show-git-status instead of gs. Verbose, yes. But every command is self-documenting and parseable by any AI model reading your terminal session.

Structured output everywhere. Every custom tool emits JSON or structured text. A project-context script generates a full project overview -- directory structure, git status, dependencies, key files -- that pipes directly into an AI prompt. A diff-summary tool produces machine-readable changelogs for PR descriptions.

Workflow composition. Five custom tools (git-ai, project-context, error-parse, pre-commit-fix, diff-summary) chain together into complete workflows. Each tool does one thing. Each tool's output feeds the next. Each tool is legible to both humans and AI.

What Actually Changed

After six months, the measurable differences: 60% faster machine/teammate onboarding. 50% fewer back-and-forth clarifications with AI tools. 90% reduction in formatting-related PR comments.

The unmeasurable difference is bigger. AI suggestions became dramatically more relevant because the model could actually read my workflow context. The collaboration surface between human and AI went from narrow (copy-paste code snippets) to wide (full project context, structured history, semantic commit messages).

The Trade-off

You lose speed on individual commands. Typing show-git-status is slower than gs. That's the cost.

You gain legibility across every interaction that isn't you typing alone in your terminal -- which, in an AI-augmented workflow, is most of them.

The developers who will be most productive in the next few years aren't the ones with the cleverest shortcuts. They're the ones whose environments are designed for context transfer -- to teammates, to CI systems, and to the AI models that are becoming their primary collaborators.

share

Continue reading

The CLI Renaissance: How AI is Driving the Command Line Revolution

AI coding assistants output shell commands, not GUI instructions. That single fact is reversing a decade of developer tooling trends.

AI Code Review Is Reasoning, Not Pattern Matching

AI code reviewers moved from rules-based checking to reasoning-based analysis. The gap between what they catch and what humans catch is closing fast.

The Shift to Async Code Gen: What It Means for Developers

Async code generation turns development into specification and review. The coding happens in the background. This changes what it means to be a senior...

emailgithubx