{"slug": "you-re-not-a-better-engineer-because-you-type-git-commands-by-hand", "title": "You're Not a Better Engineer Because You Type Git Commands by Hand", "summary": "After 27 years of coding, a senior engineer now delegates commit messages, PR descriptions, code comments, naming conventions, and other tedious tasks to AI agents, arguing that AI performs these with more consistency and frees developers to focus on application logic. The engineer notes that LLMs particularly benefit from well-structured code context, enabling more fluid collaboration.", "body_md": "July 10, 2026\n\n# You’re Not a Better Engineer Because You Type Git Commands by Hand\n\nAfter 27 years of writing code, I have stopped spending time on a long list of small but painful engineering tasks. AI agents now handle commit messages, pull request descriptions, code comments, naming conventions, Git hygiene, issue tracking, and release workflows with more consistency than most teams ever managed by hand.\n\nOne of the things I like most about AI is something I did not expect to appreciate this much: **it is remarkably good at the tasks developers rarely enjoy doing**, and when we do them properly, **they consume a ridiculous number of hours.**\n\nLet’s start with commit messages, everyone’s forgotten friend.\n\nI cannot remember how many hours I have spent writing good commit messages, useful PR descriptions, and all the surrounding context that makes a change understandable to somebody else. Most engineers I have worked with barely wrote meaningful commit messages. Then, when it was time to review or merge something, we spent even more time digging through the code just to understand what the commit or PR was supposed to do.\n\nNow I delegate that work to AI.\n\nIt writes commit messages and PR descriptions the way **I want them written**, with a level of precision that scared me a little at first and that I now absolutely love. I can focus on the application instead of writing a small book for developers who will probably scan it once while drinking coffee.\n\n## Comments are finally cheap\n\nThis is not only about commits and PRs. It also applies to comments in code. There is a clear polarization around this subject. Some engineers love good comments in code (me, for example), [while others would happily remove every comment from the repository](https://www.youtube.com/watch?v=Bf7vDBBOBUA). Honestly, I understand both positions. Over the years I found a balance. I do not want to rewrite the entire codebase in human-readable English just to repeat what the code already says. But I do have specific rules for comments: no emojis, no decorative nonsense, comments appropriate to the language I am working in, consistent formatting, proper file headers, full file paths when useful for LLM context, one-line factual descriptions, information about the architectural layer a file belongs to, and so on.\n\nI remember spending hundreds of hours maintaining these details by hand. And, oh boy, every time something changed, the headers and comments had to change too. Now most of that is automatic. The repository stays properly described, and I do not need to pour brain cells into maintaining details that are useful but painfully repetitive. And do not blame me. For years I thought that putting this amount of care into a codebase was part of doing professional work. Reality kept throwing cold water on that idea: almost nobody cared, except for the few people who also did this kind of work.\n\nIronically, **the audience that values all that structure the most is now LLMs.**\n\nThey love this context. They can use the rules, comments, paths, intent, and architectural descriptions that I wrote earlier. This makes working with agents much more pleasant. You get interactions like:\n\nYou wrote this rule, but now you are asking me to do the opposite. How should we reconcile that?\n\nThat kind of interaction makes the AI-assisted engineering process much more fluid. The repository stops being a pile of source files and starts carrying enough explicit intent for an agent to challenge inconsistencies.\n\n## Naming things is still hard, so I stopped doing all of it by hand\n\nAnother task I used to spend an absurd amount of time on was naming files, classes, functions, modules, and everything around them. I wrote dozens of developer guides for teams I worked with. Naming conventions, directory structures, suffixes, prefixes, abstractions, exceptions to the conventions, and eventually exceptions to the exceptions. **AI does this job better.** No more 30 or 40 different file-naming styles once a project is a year old. Fewer naming conflicts. No more spending ten minutes trying to remember what we called the file responsible for some urgent check six months ago. **Things get named consistently.**\n\nEven changing your mind becomes almost irrelevant. I can say:\n\nDo not use\n\n`class PostgreSQLClient {}`\n\n. Use a generic name such as`class DatabaseClient {}`\n\n.\n\nThen the agents can perform the refactor, update references, run the tests, fix the missing pieces, and mark the relevant checkboxes in the ticket. Changing your mind used to be expensive. Now, for many changes, it is mostly an instruction.\n\n## I also stopped babysitting Git\n\nGit is another area where I am happy to let agents do the boring work. I no longer make the same stupid mistake for the hundredth time: starting work on `dev`\n\n, `main`\n\n, or some unrelated feature branch. It happened constantly. I would merge a PR, come back to my local environment later, start changing code, and only then realize I was still sitting on the branch that had just been merged and deleted remotely.\n\nNow an agent checks this for me:\n\nYou are on\n\n`dev`\n\n. I will create the proper branch and continue the work there.\n\nGood. Please do.\n\nAnd it does not stop at creating a branch. In my workflow, agents can prepare PRs with `[WIP]`\n\n, apply the proper labels, assign the PR, write a meaningful description, add checkboxes, and keep those checkboxes updated as tasks are completed and changes are pushed. They can create GitHub Issues, move them to the proper project column, link an Issue to a PR, apply labels, and write descriptions. I do not need to think about most of that anymore. I can spend my attention on finding a good solution to the actual problem.\n\n## Delivery is becoming a sequence of checks, not a ritual\n\nThe same thing happens when it is time to *deliver*.\n\nFirst, I invoke my `/definition-of-done`\n\nskill. It checks whether the implementation covers what was stated in the PR and in the plan. It checks tests and the other validations I care about. It tells me when something looks unusual, broken, or missing. When everything looks good, I invoke another skill, `/pr-check-release`\n\n. That checks the remote PR, updates labels, removes `[WIP]`\n\n, adds `[RFC]`\n\n, updates the description, and prepares the change for review. If one day passes and nobody on the team reviews the PR, we merge it. The agent also tracks that condition for me, so I can run `/pr-merge-dev`\n\n, and it takes care of the process: merge the PR, delete the remote branch, delete the local branch, and pull `dev`\n\nback into a fresh state. None of these steps is particularly difficult. *That* is exactly the point.\n\n## Tiny tasks are expensive because there are thousands of them\n\nThe relief of not having to do this enormous collection of tiny, painful tasks is worth a lot of money. A lot. There are engineers who still believe that typing Git commands by hand, manually writing every PR description, or carefully hitting the keyboard with their own fingers to produce a commit message is some kind of craft that elevates them above everyone else. I think they have no idea how much money disappears into these rituals. Not minutes. Hours. Repeated across every engineer, every pull request, every release, every branch mistake, every forgotten checkbox, every stale description, every naming discussion, every issue that was not linked correctly, every comment that became outdated, every bit of repository housekeeping that somebody had to remember.\n\nI still care about all of those things. Probably more than most people. The difference is that I no longer believe I need to perform every mechanical step myself in order for the result to count as professional work.\n\nIn 2026, if you are not delegating this kind of engineering overhead to AI, **you are burning money.** And, more importantly, you are burning *your life*.", "url": "https://wpnews.pro/news/you-re-not-a-better-engineer-because-you-type-git-commands-by-hand", "canonical_source": "https://www.minid.net/2026/7/10/ai-works-for-me", "published_at": "2026-07-10 17:01:25+00:00", "updated_at": "2026-07-10 17:46:35.607119+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools", "ai-agents", "ai-tools"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/you-re-not-a-better-engineer-because-you-type-git-commands-by-hand", "markdown": "https://wpnews.pro/news/you-re-not-a-better-engineer-because-you-type-git-commands-by-hand.md", "text": "https://wpnews.pro/news/you-re-not-a-better-engineer-because-you-type-git-commands-by-hand.txt", "jsonld": "https://wpnews.pro/news/you-re-not-a-better-engineer-because-you-type-git-commands-by-hand.jsonld"}}