Please don't forget how to code (yet)

Ajouté : 2026-06-05

[00:00:00]So it was around this time last year uh when a friend of mine called me and he asked me to help him uh with uh some interviews. He was building a new team at the company he was working for and in this department they had no other engineers besides him. So he needed an extra pair of hands. Uh so we did that.

[00:00:16]We interviewed a bunch of people and I noticed that uh many of them had trouble writing very simple syntax. Uh we did a very simple coding exercise together.

[00:00:26]not like um um not like algorithms or having to write something complex at the spot, more like a pair programming exercise where both of us, you know, work through a through a problem together. And we just wanted people not to use AI. Uh not as a test for whether they remember the markup by heart or something. I've I've never been a fan of questions about APIs or uh or markup, but just to see how the person's mind flows and how how they think logically.

[00:00:57]When I have to do live coding, I usually stutter at first. I can't remember some keywords. I can't remember some basic syntax. Um but people had to look up like very very basic things like how do you define a class for example. Uh and it it wasn't just one person. And I we I just quickly realized that this is probably a result of the uh cursor phenomenon at the time where people were not writing that much code by hand if if any anymore. Uh and they were relying on the agents to do that work for them. And naturally as 2025 progressed and then through the winter and this year uh many people were jumping the jumping on the boat that you shouldn't be reading the code you write anymore. You should write some tests. You should write some guardrails but you should be you know looking to use agents and looking to uh like optimize your uh optimize your workflow and just take the code as an abstraction. Uh there were even people who compared uh AI generated code to um compilers that we don't verify compiler output. So why do we why do we bother uh verifying or reading through what the AI agent is uh is outputting? Um, now, um, at some point I was leaning more towards that mindset and I was thinking how, okay, maybe we don't need to to read everything. But I've got a whole other video about that. I'm not going to go on that tangent right now. But lately, I've been um, circling back to the initial idea that you need to own your ideas and you you need to own uh, your creativity and have a mental model of what you're building in in your head. And you should only use the agent to be more more productive in implementing what you what you already uh want to do. Uh because not understanding the code in in inside of your inside of your codebase is a recipe for disaster. I've seen how quickly a code base can become unmaintainable under the disguise of well-written abstractions and well-n named functions. And it turns out that it's an it's a illogical mess. and you cannot really make any uh any meaningful changes to this in the future without rooting everything out. Um and you can see that the industry is starting to push back on this. I was watching this video uh the other day um an interview with the creator of Zigg and he basically said that they have forbidden um LM LMS and AI assisted coding for their contributors. So if you want to contribute to Zigg or work on some of the issues that they have, you basically need to do this uh on your on your own.

[00:03:38]And he said that they're just getting showered with uh with issues and pull requests by people who basically act as intermediaries between the between the LM and them. Uh and he said that when they give people feedback and they react in a way that no person would usually work on on a on a problem. uh and much of the code that people want to push they just do not really understand and this has implications beyond you know just the momentary uh lack of understanding of that code base. There was um an an issue with one of the latest versions of R sync. RSync is a package that is basically used for for backups and it's probably used in most of the infra you run nowadays. uh and there was a correlation between uh when the maintainer uh of that package started uh utilizing vibe coding and they started pushing out more code than usual and the first actual issue that came up with this package. Scale and speed have um a correlation with reduced quality. Uh and you have probably experienced this uh firsthand. So, while I was looking for um a workflow or a way that I myself could adapt to agents, I'm now thinking more in terms of how I can adapt the agents to the way that I used to work before that. I don't think we go full full circle and we stop using them because they're just so valuable in some in some situations. They they can save a lot of work when when when used properly. But there are just so overwhelmingly many stories about people who are starting to step on guarding equipment when they try to produce software at scale. You know, there are some engineers who are trying to turn them into non-stop workers who can uh work on tickets while they sleep and they have like an army of agents pushing code for them. But but I am becoming more and more pessimistic and while earlier this year I was you know thinking how I need to become uh like an architect and a designer and step away from the details of the code and look at it more in terms of just taste you know whatever that means I'm going back on this idea I do not think that this works if you want to produce uh products of high quality we should not forget uh how to code while uh there are engineers who think that the inability to have an agent write all of your code is a lack of better tooling or a lack of context.

[00:06:08]I do think that it's a limitation of the underlying uh technology models are getting better uh with every release but you are seeing the effects on the industry like you're starting to see the effects on the industry uh when people try to produce software at scale that they do not understand you see what's happening with uh uh with GitHub's availability there were incidents related to AI and uh and Amazon the issue with the tooling that I mentioned earlier uh I've seen a bunch of issues firsthand in my work while I'm saying this there probably at least a couple of incidents that come to mind in in your in your line of work and this just proves that going you know hands off letting AI take the wheel and letting it drive you wherever it wants to it just doesn't work you know code code review is not just uh verifying whether the code works correctly you're not just looking for correctness or to follow you know you're not just looking to verify whether specific rules and standards have been followed these these checks can be automated Yes, but code review is a mentorship exercise. Code review is uh like a context sharing exercise. It's a way for me to tell the engineer who is reviewing my code here, this is what I'm working on. This is how I build it. If in the future you need to work on it, then you you you know where to look for that. The same way we have, you know, llinters and formatting tools and standard checkers, you can use uh the AI to do some rudimentary code review, but you need to have the person in the loop.

[00:07:35]You need to have that shared context.

[00:07:36]You need to have, you know, people who understand what is uh what is going on inside of this codebase. I think the industry is realizing this and there are already places who are stepping back their their AI adoption and this, you know, is leaving me with mixed feelings because I think that this is an incredible technology that we just took too far too quickly. As an industry, we're constantly trying to solve human problems with technology. uh and there are just some things that we cannot really automate and I think bu building quality software is one of them at least for now.