Writing code by hand is now an advantage transcript

Writing code by hand is now considered a waste of time. Or at least that's increasingly become the narrative we're hearing online. One that's being driven by the fundamental change taking place in the world of software development, the rise of agentic engineering. Now, whilst it's fair to say that coding by hand does take time, I don't think it's fair to call that time a waste. And in fact, I think there's a different perspective to consider.

One that complements why many software developers are able to be effective at using agents in the first place. Therefore, I present the following claim. Coding by hand is not a waste of time and instead can actually be considered an advantage. Okay, so I realize that some of you watching might think this sounds a little like cope, especially given how much things have changed over the past 12 months. >> [snorts] >> Therefore, in order to explain why, I've come up with the following thought experiment.

One that's also shows how the rise of agentic engineering has in fact contributed to this being the case. To begin, let's imagine that you're looking to hire a software engineer. One to take over the development of a video editing application that you've built using Rust and FFmpeg. In front of you are the three final candidates. Each of whom was selected because they recently built their own video player using Rust.

The first is candidate A. An experienced software developer who has leaned fully into agentic engineering and has done so since it was first called vibe coding. Because of this, candidate A hasn't written a single line of code since the start of 2025. And in fact, they've never written any Rust code by hand nor any code that integrates with FFmpeg. Instead, when it came to implementing their own video player, they did so entirely using agentic engineering.

Making use of tools such as Claude Code and Codex and using techniques such as loops and adversarial review. Next, we have candidate B, who is also an experienced software developer who has picked up agentic engineering over the past few months. Unlike candidate A, however, they do have extensive experience of writing Rust code by hand, having used it daily for the 3 years before the advent of a genetic engineering. As for candidate B's video player implementation, whilst they built a lot of this by hand using Rust and the fantastic iced desktop framework, they didn't implement the actual video player themselves, instead making use of an existing crate which provided the functionality for them.

Lastly, we have candidate C, who, as you might be able to tell, is a slightly different candidate from the other two. Candidate C is also an experienced software developer who, just like the other two, makes use of a genetic engineering in their day-to-day. What sets them apart, however, is that they still like to find reasons to spend time writing code by hand, especially when it comes to their own personal learning and development.

This is a trait that's reflected in their own video player, as they decided to implement the majority of the media engine themselves by hand, and did so using the FFmpeg sys crate with Rust and only using AI to assist whenever they got stuck. So, with each of these three candidates in front of you, which one is going to be your first choice in order to make an offer to? Whilst I can't speak for everyone watching, for myself, there's a clear winner, candidate C.

And it's not just because of what they're wearing. Instead, it's because out of the three, they're the only candidate who has built a key component of their video player by hand, the media engine. In doing so, they've gained a hands-on experience, which implies they have an understanding of many of the key concepts that they'll encounter when developing a video editor, giving them an advantage over the other two. Now, to be fair, this is clearly a stacked deck.

I mean, candidate C is an actual wizard, for crying out loud. Despite this, however, given the trajectory of where software development is going, I don't think that this is an entirely implausible situation, especially considering the fact that more and more developers are now building full applications without ever writing a single line of code. Therefore, if this trend continues, then the experience of writing code by hand will become increasingly less common.

Meaning that the simple act of doing so can cause a developer to stand out from the crowd. However, in order for this to be a real advantage, we need to consider whether or not the experience of writing code by hand still provides any value. Again, whilst I can't speak for everyone, for myself, this question was recently answered by a problem I recently had. About a couple of months ago, in my own video editor project, I kept running into a knowledge gap when it came to the media engine, of which was built entirely using agentic engineering.

Whilst the agents had produced an implementation that worked, it wasn't what I would consider to be correct. And given the vast range of media files out there, it kept breaking for my users, because Murphy's law is still very much a thing. Now, I could have kept trying to improve upon this using agents, and eventually may have reached a correct solution. However, because I had a knowledge gap, I wasn't able to know whether or not that solution was in fact correct and would support the future goals I had in mind.

Therefore, rather than continuing to trust the agents who had already let me down, I decided to bridge this knowledge gap by learning FFmpeg. And to do so, I decided the best way would be to build a simple media engine pipeline by hand, whilst also making use of AI in order to do so more effectively. If all of this sounds somewhat familiar, then just hold onto that thought for a second. So, whilst this approach to learning did take quite a bit of time, it certainly wasn't time wasted, as it resulted in me having a deeper understanding of many of the concepts related to media playback.

Which meant I was not only better equipped for rebuilding my own media engine, but I was also able to be more effective at using agentic engineering in order to do so. Basically, if it's not yet clear, I myself had transformed from candidate A all the way into candidate C through the simple act of writing code by hand. Now, this isn't to argue that one can't learn through the act of agentic engineering. And in fact, I think there are many different ways to use these tools effectively for developing one's own technical understanding.

The problem, however, is that when using these tools, it's very easy to bypass the situation that causes one to learn in the first place, which is the struggle of encountering a problem and the discoveries made in pursuit of a solution. Therefore, because of this, I've been making a conscious effort to spend time writing code by hand, not necessarily for everything, but for reasons where I find it gives the best return on investment when it comes to my own personal development, as well as making use of AI in order to do so more effectively.

So, the first reason why I still like to code by hand is probably the most obvious reason on this list, which is when it comes to learning a new programming language. Now, there's some debate as to whether or not this is useful in 2026, especially as agents are now incredibly good at being able to generate code in various different languages. Whilst this is true, it doesn't change the fact that, for myself, I don't regret any of the time spent learning a programming language in the past.

And therefore, applying that same logic, I think it's still worthwhile to do so in 2026, even with the increase in AI-driven development. As for how I like to learn a new programming language in the modern era, well, I still do it the old-fashioned way, picking up a book on the language I want to learn and going through it and implementing the code by hand. Then, if I happen to get stuck or need a different explanation than what the reference material provides, I can just ask an LLM to help bridge that gap.

This is actually the approach I took recently in order to refamiliarize myself with Rust. And in doing so, it provided a few benefits when it came to working with agents. The biggest benefits is that it gave me a much better intuition for detecting common code smells when it comes to reviewing AI-generated codes. For example, one common code smell I often find in agent-generated code is what I like to refer to as Boolean creep, which is where an agent will often introduce new Boolean values rather than using a well-defined enum and adding another variant.

For example, in my own code, I found this wonderful struct to track the active tab of a sidebar on my main landing page. As you can see, it has multiple Boolean values, with each one used to represent a variant of the sidebar's active item states. >> [snorts] >> Anyone who's built software by hand in the past will recognize this as bad code, and a much better approach, especially in Rust, would be to make use of an enum in order to model each variant exclusively.

Whilst this is a rather simple, yet real-world example, when it comes to my own experience, there are many mistakes that an agent will make when using your language of choice that can easily be caught by just learning the language itself. Of course, we're in the year 2026, and there's a good chance that most developers will start building a project before deciding to learn the language. Therefore, how can one prevent these sorts of issues from accumulating in one's code base before knowing enough to catch them?

Well, that's where the sponsor of today's video comes in, Code Rabbit, who provide a couple of solutions to help improve the quality of one's code base. Now, I've been using Code Rabbit for the past couple of months during development of my own next-gen video editor project, Kiru, and it's helped me to prevent a number of potential bugs from making their way into my production code, both when it comes to writing code by hand, but also when it comes to using agents.

The way it works, in my case, is that I have Code Rabbit connected to my GitHub project, and any pull request that I make to my main branch will be automatically reviewed for me, with any potential errors, stylistic improvements, and even ready to apply fixes, all performed automatically. For example, here I have a simple PR that adds a new API endpoints, of which has a pretty bad bug when it comes to security. Code Rabbit has not only detected this and raised it through a comment, but it also provides a detailed summary and even a prompt I can send to an agent in order to get it resolved.

This not only helps with security issues, but also works for things like edge cases and other common problems encountered when working with agents. In addition to helping me improve the quality of my code base, Code Rabbit also helps me to improve my understanding, thanks to their new review UI, which aims to improve the experience of code review in the modern era. Unlike other code review tools, which tend to just show a flat diff of all of the changes, Code Rabbit review instead provides you the ability to see each of the changes as different layers, allowing you to review the code the same way it's actually called in your application, which personally, I find a lot easier to reason about.

In addition to this, the new review UI also provides some other useful features, such as a summary of what each layer is doing, the ability to leave review comments on specific changes, and for those who love UML, generated sequence diagrams of the code interaction. Whether it's a simple function with integrations or an API endpoint, providing details such as the actual path. This not only makes it much easier to review the code that an agent generates, but it also helps me to gain a better understanding of my code base, which I think is one of the biggest problems in 2026 and something I'll discuss more later on.

So, to try out Code Rabbit and their new review UI today, then make sure to use my link in the description down below in order to start your free trial. A big thank you to Code Rabbit for sponsoring this video. Okay, so in addition to programming languages, another area of learning that I found writing code by hand to be advantageous is when it comes to learning dependencies. Whilst the majority of dependencies are pretty self-explanatory.

There are some that come with some rather major quirks. One such example is Cpal, which is what I use for playing audio across Windows, macOS, and Linux. The way it works is that upon creating a context to a hardware device, you're then presented with a thread that allows you to write audio samples to, of which will be played out by the speakers on your device. This thread is called a real-time audio thread, which as the name implies, means it needs to run as fast as possible in order to prevent any issues with audio playback, such as pops, skips, and other unwanted artifacts, all of which the human ear is incredibly sensitive to.

Fortunately, when I tried to implement this using an agent, it decided to use a mutex in order to guarantee thread safety. This is a big no-no in the world of real-time audio, as it can cause the thread to block, which will result in the samples being dropped. Fortunately, because I had implemented this first by hand in a dummy project, I was able to understand this constraint in the review of my code, and therefore I knew what the correct approach was when it came to thread synchronization, which was to use a real-time ring buffer.

In addition to Cpal, other dependencies in my application that I decided to learn by hand include FFmpeg and GPU I, both of which have pretty terrible documentation. Fortunately, this is actually where using an agent came in handy, as it allowed me to make up for this documentation gap through asking questions, reducing the amount of time it took for me to understand how each dependency worked. This then meant that by learning these dependencies, especially FFmpeg, it had a positive feedback loop when it came to working with the agent in the future, especially when it comes to this next point.

One of the main properties I find when it comes to AI coding tools is that they often like to take the shortest path to producing working code. Whilst this can sometimes be useful, when left unchecked, it can easily turn your code base into a tangled mess, one that makes adding new features much harder than it would in a well-architected system. Now, that's not to say you can't create good architecture using agents. However, I find that doing the initial or high-level design by hand allows me to feel the air.

Uh that's a reference to the movie Interstellar, specifically when Coop is piloting the craft to land on Miller's planet, and in doing so, rejects the computer assistance saying that he wants to instead feel the physical feedback in order to better pilot the craft. >> I need to feel the air. >> By doing the high-level architecture by hand, it allows me to feel out any resistance of the overall design before letting the machine take over, where I will lose that direct feedback. >> [snorts] >> In fact, this is what I did recently when it came to rebuilding the media engine of my video editor application, starting with defining traits and high-level types before then moving on to method and function signatures.

Then, by using the unimplemented macro in Rust, it allowed me to compile the code without needing to implement it, which meant I could both feel the air and also use it as a marker for an agent to know what to implement. Overall, this resulted in me having a much more capable media engine than the one I had with my agent-driven design, and allowed me to have results consistent no matter which platform I was running on, and also made adding in future features such as images, effects, and transitions much, much easier.

It also provided me with another benefit, one that I still struggle to get when I only use an agent. Codebase comprehension. If someone asked me what I think is going to be the biggest problem that developers will face in the future, my answer would be codebase comprehension. In the past, this was something I always found to be rather valuable, as after spending enough time working in a codebase, I would end up with a pretty decent mental model.

So much so that it meant whenever a bug or issue was raised, I would intuitively know where in the codebase it most likely originated from. Now, however, for any projects that I build using agents, that understanding is nowhere near the same, even if I built the project entirely from scratch or have made a habit to review every change. Of course, I'm not the only one and in fact the software industry is in a rather precarious position where we have full projects being built where none of the code is fully understood by its own authors.

Whilst some people will argue that's fine, I personally find it to be rather uncomfortable, especially if I'm shipping that code to other users for them to run on their own devices. So, to rectify this, I've been making a habit of manually implementing any code that I want to better understand and then delegating out to an agent in order to improve on it or continue implementing the same pattern elsewhere. Whilst this approach is definitely slower than one shotting it, I find it allows me to build a mental model of the code first, which then enables me to have a greater understanding.

Now, to be fair, writing the code out by hand isn't the only way to improve one's own understanding and I have found that asking questions to the agent about an implementation to be also rather valuable, even if [snorts] it does hallucinate from time to time. Because of this risk of hallucinations, however, there are still a few areas of my code that I will only ever write by hand in order to fully understand and ensure correctness.

These include things such as handling payments, user authentication, and other areas of my code where introducing a bug could be potentially devastating. Ironically, however, this is one area that I really like to have adversarial review through the use of an agent or with tools such as Code Rabbit in order to prevent these kind of bugs from ever reaching production. Okay, so the last point on this list is certainly not the least.

And in fact, for myself, is actually probably the most important. Whilst I know not everyone in the industry feels this way, one of the things I personally really liked about developing software was the joy of writing the actual code itself. Now, that's not to say I don't enjoy the more product development side of building software. However, the thing is, I find that using agents to do so is nowhere near as mentally stimulating as when I used to build products through writing code by hand.

Therefore, rather than mourning the so-called death of writing code by hand, I've instead decided to just re-embrace it. And whilst there's many people who consider the act of writing code by hand to now be a waste of time, I don't think wasting time on something you enjoy isn't fact time wasted at all.