You're Not a Better Engineer Because You Type Git Commands by Hand

After 27 years writing code, Diego Lafuente — the engineer behind minid.net — has put into words what many developers quietly know but won't say aloud: the rituals of manual Git hygiene, commit-message crafting, and PR description writing aren't marks of professional excellence. They're expensive overhead that AI agents now handle better and more consistently than humans do. The argument directly challenges the craft mythology that has hardened into software culture at a moment when data on AI-assisted development is finally rich enough to have a real conversation — and to settle, once and for all, why you're not a better engineer because you type Git commands by hand.

The Myth of Manual Craft as Engineering Virtue

Software engineering circles hold a durable belief that doing things by hand — typing raw Git commands, writing every commit message from scratch, manually composing pull request descriptions — signals deeper understanding and therefore better engineering. It's the same logic that once told developers to write their own memory allocators before using malloc, or hand-roll HTTP parsers before reaching for a library. The logic has a kernel of truth: understanding fundamentals matters. But somewhere along the way, that kernel became the entire crop, and performing the mechanical step got conflated with understanding it.

Lafuente is blunt about what this actually costs. Tiny, repetitive tasks — formatting a commit message, labeling a PR, moving a GitHub Issue to the right project column, cleaning up a stale branch — are individually cheap and collectively ruinous. Multiply one engineer's daily Git overhead across a team of twenty, and you've burned dozens of hours every week on work that produces zero new features, zero new tests, and zero architectural insight. The conclusion is direct: not performing every mechanical step yourself doesn't diminish your professional quality. What does diminish it is solving the wrong problems or spending cognitive energy on the wrong things.

What AI Actually Does in the Modern Git Workflow

The article gets specific where many AI-productivity takes stay vague, and that specificity makes it worth examining carefully. Lafuente describes a complete delegation model, not a vague "AI helps me code faster" claim. Here's what the workflow actually covers:

Commit Messages and Pull Requests

Most engineers, even diligent ones, write commit messages marginally better than fix stuff. The author's claim isn't cynical — it reflects a structural problem: the person closest to a change is also the worst person to describe it objectively. They have too much context, they're tired, and the message gets written at the end of a session when cognitive load is highest. Reviewers then waste additional time during code review reconstructing intent that a good commit message would have handed them immediately. An AI agent, given access to the diff, writes with precision and consistency because it never gets fatigued and has no blind spots from overexposure. In well-structured workflows, the agent can also read linked Issues and PR descriptions for additional context, producing commit messages with specificity that rival hand-authored ones from meticulous engineers — but at fractional cost.

Code Comments and Documentation Headers

Lafuente describes spending hundreds of hours over their career maintaining comment standards: formatting, file-path headers, architectural descriptions, one-line factual function summaries. This isn't padding — it's the kind of structural documentation that lets a codebase stay navigable as it grows. The problem is that maintaining it manually is a soul-crushing, error-prone grind. Now, the author reports, it's mostly automatic. More importantly, this structured context makes AI agents dramatically more useful downstream: when an agent can read well-maintained, consistent comments, it can challenge inconsistencies, spot architectural drift, and propose changes with far greater accuracy. A virtuous cycle emerges: better documentation makes better AI agents, which produce better documentation.

Naming Conventions

Naming is one of the most discussed and least-solved problems in software. Lafuente previously wrote entire developer guides covering naming conventions for files, classes, functions, and modules — with exceptions, edge cases, and rationale. AI eliminates the drift that accumulates when ten engineers each interpret the guide slightly differently. The refactoring story is particularly striking: instead of a multi-day manual refactor to enforce a naming convention, the instruction becomes a single directive.

Do not use class PostgreSQLClient {}. Use class DatabaseClient {}.

The agent handles the refactor, updates all references across the codebase, runs the tests, and fixes any broken pieces. The engineer's role shifts from execution to decision: deciding what the name should be, not performing the mechanical substitution. This distinction — human decides, AI executes — preserves the valuable work (judgment, taste, standards-setting) while eliminating tedious work (find-and-replace, testing, verification).

Full Git and GitHub Workflow

This is where the article's argument lands most concretely. Lafuente describes a problem every engineer who's worked under deadline pressure has faced: accidentally working on the wrong branch — committing to main, to dev, or to an already-merged feature branch. The agent now handles the full sequence automatically:

• Creates the correct branch from the right base
• Opens a PR with a [WIP] label immediately
• Assigns the PR to the right reviewers based on code ownership and history
• Writes a complete PR description with implementation summary and testing notes
• Maintains task checkboxes within the PR, updating as commits are added
• Creates the corresponding GitHub Issue with full specification
• Moves the Issue to the correct project column and sprint board
• Links the Issue to the PR and applies appropriate labels and milestones

The delivery workflow goes further. A /definition-of-done skill checks implementation coverage, test completeness, and validation criteria before anything gets marked ready. A /pr-check-release command removes the [WIP] label, adds [RFC] (Request for Comments), and prepares the PR for formal review. A /pr-merge-dev command handles the merge with appropriate strategy (squash, rebase, or merge), deletes the branch, and refreshes local state. The agent even tracks elapsed time: if no review has occurred after one day, it can flag or escalate accordingly. This isn't AI as autocomplete. This is AI as a junior team member who never forgets a step, never gets tired, and never accidentally commits to the wrong branch at 11 p.m. on a Friday.

The Productivity Research Is More Nuanced Than Either Side Admits

The timing of this argument is instructive. A 2025 METR randomized controlled trial on experienced open-source developers found something counterintuitive: 16 participants using AI tools were on average 19% slower at completing tasks than those working without them, even though those same developers believed — before the experiment — that AI had made them 24% faster, and still believed it had made them 20% faster even after experiencing the slowdown firsthand. The study covered 246 real software issues from large repositories where developers averaged five years of prior experience, with tasks averaging two hours each. The divergence between perception and measured outcome suggests that developers felt their workflow was smoother even when total elapsed time increased.

That finding sounds damning, but the METR researchers were careful about what it does and doesn't mean. The slowdown appeared most strongly in high-complexity, high-quality-standards environments — exactly the kind of deep, novel problem-solving that demands genuine engineering judgment. The study explicitly noted it doesn't show that AI fails to speed up developers in general and flagged that results may not generalize to less experienced developers or those working in unfamiliar codebases. Meanwhile, other research tells a different story for different task types: a controlled experiment by Peng et al. (2023) found developers with access to GitHub Copilot completed a targeted coding task (implementing an HTTP server in JavaScript) 55.8% faster than a control group, with heterogeneous effects suggesting larger gains among developers transitioning into software development careers. The difference in outcomes points to a clear pattern.

The resolution isn't that AI is good or bad for productivity — it's that the type of task matters enormously. Mechanical, well-defined, repeatable tasks (writing commit messages, formatting PRs, enforcing naming conventions, managing branch state) are precisely where AI excels and where the METR friction doesn't apply. Deep, ambiguous, novel problem-solving is where human judgment remains irreplaceable — and, critically, it's also where engineers want to spend their time. The opportunity is therefore clear: use AI to eliminate mechanical overhead, freeing time for work that requires human insight.

Task Type	AI Performance	Human Comparative Advantage	Delegation Recommendation
Commit message writing	High consistency, zero fatigue, precise diff-to-text rendering	Low — humans write worse under pressure and fatigue	Delegate fully
PR descriptions	Structured, complete, reproducible, cross-linked	Low — often skipped or minimal by busy engineers	Delegate fully
Branch management and Git hygiene	Never forgets, no wrong-branch errors, consistent workflow	Low — common source of human error and rework	Delegate fully
Code comment maintenance	Consistent formatting, structural awareness, change tracking	Moderate — author intent sometimes requires lived context	Delegate with review gate
Naming convention enforcement	Systematic refactor across entire codebase, exhaustive search-replace	Low for execution, high for decision and approval	Human decides and approves, AI executes
Novel bug diagnosis in large systems	Mixed — can miss implicit requirements and business logic	High — contextual reasoning, system intuition, historical knowledge	Human-led with AI hypothesis generation
Architectural trade-off decisions	Low — lacks business, organizational, and domain context	Very high — understands constraints, stakeholders, and long-term vision	Human-owned, AI-informed

Why Engineers Resist This — and Why That Resistance Is Costing Them

The resistance is understandable, and it's worth engaging honestly rather than dismissing it. There are at least three distinct objections that senior engineers raise when this topic comes up, and each deserves a direct response grounded in both principle and practice.

"I need to stay sharp by doing it manually"

This is the muscle-memory argument. If you stop typing Git commands by hand, you'll forget them, and then you'll be helpless when the AI is unavailable. The counter is simple: the commands you need to remember in a crisis aren't the ones you're delegating. Knowing that git rebase -i HEAD~5 exists and what it does is knowledge. Typing it manually every day for a decade isn't what preserves that knowledge — it's what prevents you from spending that decade doing something harder and more interesting. When you genuinely need a Git command you haven't typed in months, consulting documentation takes 30 seconds. The muscle memory you actually need is for the problem-solving strategies and architectural patterns that your brain only sharpens through focused, challenging work — not through rote mechanical repetition.

"AI-generated commit messages lack real context"

This objection has more substance, and it points to a real failure mode. A commit message generated from a diff alone can miss the why — the business reason, the architectural constraint, the half-hour conversation that preceded the change. An agent working only from code deltas will produce messages that say "refactor User service to use async initialization" without explaining that this change was necessary because the database connection pool was exhausted under peak load. But Lafuente's workflow addresses this structurally: well-maintained code comments, PR descriptions, and linked Issues give the agent context that a human writing a message at the end of a tired day usually doesn't bother to include. Moreover, when context is genuinely insufficient, the agent can flag it: "This diff alone doesn't contain enough information to write a high-quality commit message. See linked Issue #4521 for context." The AI's output quality is a function of the context it receives, and a well-structured workflow provides more of that context than most humans supply when writing manually after an eight-hour session of focused coding.

"This is just laziness dressed up as efficiency"

The conflation of delegation with laziness is the deepest and most cultural of the three objections. It treats effort itself as the measure of quality, independent of outcome. The rebuttal is implicit but clear: professional standards — caring about comments, naming, structure, and documentation — are entirely compatible with delegating the mechanical execution of those standards to an agent. The standard you set and the decision you make are the engineering work. The typing isn't. An engineer who spends five hours hand-crafting perfect naming conventions across a codebase isn't more professional than one who spends 30 minutes deciding what those conventions should be and then delegating a 15-minute automated refactor to an agent. The professional work is the decision. The refactor is bookkeeping.

The broader cost is real. According to the 2025 Stack Overflow Developer Survey, 84% of developers now use or plan to use AI in their daily workflow. The DX Q4 2025 AI-Assisted Engineering Impact Report puts average self-reported time savings at 3.6 hours per developer per week — rising to 4.1 hours among daily AI users. But adoption alone doesn't predict the benefit: productivity gains skew heavily toward engineers who've restructured their workflows around deliberate delegation rather than those who use AI as an occasionally consulted autocomplete engine. The difference isn't in tool access but in workflow design.

The Opportunity Cost Nobody Talks About

Lafuente frames the stakes in a way that goes beyond productivity metrics: "In 2026, if you're not delegating this kind of engineering overhead to AI, you're burning money. And, more importantly, you're burning your life."

That phrase — burning your life — isn't hyperbole. It's a specific claim about opportunity cost. Every hour spent formatting a PR description that an agent could produce in ten seconds is an hour not spent on the problem that actually required hiring a senior engineer. It's an hour not spent mentoring junior engineers, not spent on architectural design, not spent on understanding the business domain deeply enough to prevent the next expensive rewrite. The overhead isn't just costly in aggregate; it's costly in kind. It consumes exactly the type of attention that's hardest to replenish and most valuable when present.

Burnout in engineering is disproportionately driven not by hard problems but by relentless friction from small, meaningless tasks piled on top of hard problems. A developer who struggles with a genuinely difficult algorithmic problem all morning, then spends two hours manually renaming variables across a codebase, then writes commit messages for four different PRs, then labors over Issue descriptions — that engineer ends the day exhausted not by the hard work but by the friction surrounding it. Removing that friction isn't just an efficiency play. It's, as the author frames it, a quality-of-professional-life decision — and one that's now accessible without sacrificing rigor or standards.

What This Demands From Engineers Going Forward

Accepting the premise — that delegating mechanical Git and documentation overhead to AI is correct — doesn't reduce the demands on engineers. In several important ways it raises them. If you're no longer spending time on commit messages, you need to be spending that time somewhere harder. The bar for what constitutes acceptable use of engineering attention rises when the floor of mechanical overhead is removed.

This is the real implication that the resistance crowd should sit with: the argument isn't that engineering is getting easier. It's that the location of the difficulty is shifting. The craft is increasingly in deciding what to build, how to structure it, what constraints matter, and what trade-offs are acceptable — not in the keystrokes that record those decisions in a repository. Engineers who thrive in that environment will be those who embraced delegation early enough to develop their judgment muscles while their peers were still manually typing branch names. Five years from now, an engineer who spent the last five years on architectural decisions and business domain understanding will have vastly more market value than one who was careful to type every Git command by hand.

Measuring Whether Delegation Is Working

Accepting AI delegation at the workflow level requires a corresponding shift in how teams measure success. Rather than assuming time savings are the sole goal, high-performing teams should track several metrics:

• Code review time-to-first-comment: Well-structured PRs with complete descriptions should significantly reduce the time reviewers spend reconstructing context. A drop from 4 hours to 1 hour indicates that delegation is working.
• Defect rate and defect location: If AI handles commit messages and branch management, defect rates shouldn't increase. If they do, the delegation model has a problem. Track whether defects correlate with AI-delegated tasks (e.g., wrong-branch commits) or with human-owned work.
• Engineer satisfaction and burnout signals: Direct surveys on whether engineers feel they have more time for meaningful work, and whether day-to-day friction has decreased. This isn't a soft metric — it correlates strongly with retention and quality of thought.
• Time allocation by task type: Track what fraction of each engineer's week goes to mechanical tasks versus novel problem-solving. Teams delegating effectively should see a clear shift toward higher-value work.
• Documentation consistency: If comments and docstrings are now AI-maintained, they should be more consistent and more complete than before. Spot-check a few files weekly to ensure the standard is holding.

---

Key Takeaways

• Typing Git commands by hand is not a proxy for engineering quality. Manual execution of routine tasks demonstrates nothing about whether the result will be useful, accurate, or consistent. AI agents, given proper context and well-structured workflows, write better commit messages than most humans do under normal working conditions.
• The overhead is larger than it feels in the moment. Commit messages, PR descriptions, branch management, Issue tracking, and naming enforcement collectively consume enormous engineering time — time that compounds across teams, quarters, and years into career-long opportunity cost.
• AI excels specifically at the tasks engineers resent most. Structured, repeatable, well-defined tasks are where AI delivers the clearest productivity gains with the lowest risk of error and the highest impact on engineer satisfaction.
• Research confirms the task-type dependency. The METR RCT showing 19% slowdowns in complex, novel tasks among highly experienced developers and the Peng et al. (2023) finding of 55.8% speedups on defined, bounded tasks aren't contradictory — they describe different kinds of work and different contexts for AI deployment.
• The resistance arguments are mostly cultural, not technical. Staying sharp, maintaining context, and avoiding laziness are legitimate concerns that a well-designed AI-delegated workflow addresses directly through deliberate structure and measurement.
• You're not a better engineer because you type Git commands by hand. You're a better engineer because you find good solutions to actual problems — and that requires protecting the time and attention those problems deserve. Every hour spent on mechanical overhead is an hour not spent on judgment, architecture, or mentorship.

What Comes Next

The trajectory here isn't subtle. As AI agents become more tightly integrated into development environments — handling not just isolated commands but entire workflow sequences with conditional logic, cross-tool awareness, and error recovery — the question will shift from "should I delegate this?" to "which decisions am I uniquely positioned to make?" Engineers who shape that answer now, by actively identifying what is genuinely theirs to own and deliberately offloading everything else, will define what senior engineering looks like in the next decade. Within two to three years, the skill differentiator won't be Git fluency but judgment fluency — the ability to think clearly about trade-offs, constraints, and long-term architectural consequence under incomplete information.

The engineers still debating whether it's somehow more professional to type git commit -m "fixes" by hand will simply be slower, more tired, and increasingly out of step with how modern engineering actually works. The choice isn't whether to adopt AI delegation — adoption is becoming the default, with 84% of developers already using or planning to use AI tools — but how quickly you'll restructure your workflow around it and how intentionally you'll reinvest the freed time into work that actually matters.