Why I Still Write Code By Hand And How AI Is Helping Me | Sem SinchenkoTLDR;<br>This post is about a harness' skill (SKILL.md) I made for myself. I named the skill guideme and it works similarly to Claude's "Learning Mode" or existing study skills, except it is focused on guiding a senior engineer, not teaching a junior engineer. I designed it to work as if I, a senior engineer on a project, were creating an onboarding ticket to help a new senior engineer dive into the codebase. Instead of generating code or giving long, newbie-level lectures with explanations of concepts, my skill tries to provide a focused guide on what, where, and how to change, assuming the person working on implementation knows how to code. Additionally, my onboarding ticket generator provides a high-level overview of the architecture of the part of the codebase where changes should be made, along with an explanation.

Introduction<br>Architectural misalignment and shortest-path bias of AI<br>From my experience working with AI and vibecoding projects, I've learned one important thing. AI almost always prefers to add new code rather than refactor existing code. This approach may be correct and prevent issues like "AI just purged my codebase." However, this approach introduces a new set of problems. For example, if an engineer asks AI to implement something new and misses a small detail, AI will just do it. It could add a copy part or a lot of if-else statements. But it will almost never say: this cannot be done cleanly without changing the interface.<br>An experienced engineer would almost always realize the problem after starting to work on the implementation. They would realize that the task is not solvable well or that a small refactoring could achieve the goal almost for free. AI tends to prefer the short path but often misses the "big picture."<br>At the same time, AI-generated code passes all the tests and looks correct, well-formatted, and well-documented, so catching such a thing in a review may be a non-trivial task.<br>AI-generated code is typically well-formatted, syntactically clean, and properly commented – qualities that make it appear higher quality during review. However, the issues that drive churn and turnover – architectural misalignment, unnecessary duplication, missing edge case handling – are precisely the issues that are hardest to catch during review and easiest to overlook when the code looks polished on the surface.

Source

Code ownership<br>You might call me a Luddite, but I still believe that code ownership matters. It looks like I'm not the only one who thinks so. I think senior engineers are paid not for the code they can write, but for owning the code. This means understanding how it works, the trade-offs, and the weak places. They are paid to understand the assumptions that were made. They are paid to understand top-level interfaces and contracts.<br>I agreed with an assumption:<br>The cost of producing plausible code has collapsed and it is not going back. Almost every claim beyond that is either unproven or wrong.<br>That AI tooling has made engineering orgs dramatically faster: unproven.<br>That code review, documentation, and onboarding are obsolete: wrong.<br>That you can run the same roadmap with half the people: a bet, not a fact.

As a code owner, if you do not understand the code, its contracts, interfaces, organization, etc., then I cannot imagine how you can properly review, explain, document, or onboard anyone to the code.<br>While it is possible to fully own a vibecoded codebase in this sense, I still think that writing the code by hand, or at least doing so occasionally, is the most straightforward way to maintain ownership.

Emotional connecting with the code<br>In the end I still love writing code. I work as an engineer, but my job is focused on productivity and achieving goals rather than code. So, I write a lot of code on my own time. I'm also trying to contribute to some open-source projects, and I have my own open-source projects. I wrote some of them line by line. Others I vibecoded for 100%. Some are a mix. I've found that if a project is fully vibecoded, I have almost no emotional connection to it. It works, or at least it looks like it works. In theory, I could improve it. But I don't want to do it. My vibecoded projects quickly enter "maintenance mode." At the same time, I want to go back to projects that I made by hand, line by line. I know the entire codebase, and I like reading some parts again from time to time because it reminds me of when I was sitting up at 4 a.m. trying to debug a line of code, even knowing that I had a daily Zoom meeting at 9:30 the next morning. I love my code. I'm proud of it. I want to go back to it. AI-generated code does not work the same way for me.<br>I'm not sure if my behavior is normal. However, I have some biased observations. First, most of the engineers I asked expressed the same opinion or something very similar. Second, I see a lot of abandoned projects on GitHub that are 100%...