Knowledge and learning with AI

2026-09-04

At work I am expected to use AI agents to augment the speed of my output, I am being careful of how I introduce these tools into my workflow since there appear to be inherent risks. The main issue I’ve experienced is that my role has shifted from including the whole development process to replacing parts of the code generation step with reviewing AI generated code. That is a surprisingly tedious task which takes an entirely different type of thinking and concentration, it feels like I have to pretend to be the compiler all day.

Threatened knowledge

A more insidious risk is that of slowly losing understanding of my own projects. Previously I had time to learn and understand the new code I was writing because I was there every step of the way. It wasn’t hard to wrap my head around some specific implementation detail that may seem odd from the outside because I got to it myself. Reviewing AI generated code puts you on the outside of the process that lead to the code in the first place. I find that it goes better when I follow along as the agent builds the code and actually read the reasoning behind decisions, but it’s often very alluring to just let the agent get on with it and focus on some other work that inevitably needs to be done.

Apart from missing out on learning about the project I am working on I am also missing out on learning how the tech and dependencies of the project work. Sure, I can see the final result and know something about how to use an API or a tool, but it just doesn’t stick as well as when I had to figure it out myself by reading docs and trying things out. What worries me is that if I am feeling this way after a few short months of working with coding agents then there is a big risk that the amount of missed knowledge will pile up quickly over time. Not to mention all the effects that I am not aware of.

Finally I see a risk of losing interest in a project as I get more detached from the actual creation. This is probably a personality issue that points to the fact that I enjoy the process of creating as much if not more than I enjoy having a final product. I don’t find this to be a problem in a professional setting since motivation isn’t solely based on how much I care about the project in that case. But on side projects it’s more of an issue.

I tried vibe coding earlier this year just to understand the state of the technology and was very impressed. But I quickly lost interest in the project, partly due to being detached from the process of creation and partly due to not enjoying the pacing. The agents where making such fast progress on the project that I wasn’t able to keep up, I felt like I needed more time to reflect on how things turned out to be able to know what should happen next, time that I usually get as I work on the implementation of my ideas. Ultimately I abandoned the project, it feels like a cool party trick, but it doesn’t work for me when it comes to serious work at this point.

Another way

During my summer vacation I experimented with a new approach to working with AI agents that I think can help alleviate the brain drain that I experience when using AI as a coding agent. Instead of asking the agent to generate code for me I asked it to teach me things. The idea being that if I am the one writing the code and figuring out the solutions then I will retain the knowledge about the project and the concepts that it is built on.

On a practical level I used an extension for Pi which didn’t allow the agent to make edits. The extension also outlined some rules about how to break concepts into a natural order for learning and to explain the reasoning for learning a particular thing at any given time. I paired this with OpenAIs latest Terra model simply because I happened to be trialing their service at the time. This setup worked surprisingly well despite its simplicity, which makes me think that with some more work and thought it could get even better.

A session would start with me stating the overarching goals of a new feature. The agent would then break it down into smaller tasks based on how the various concepts I needed to understand fit together and what was already in place. It would then start by introducing the first concept and either ask me to implement something based on it or to confirm that I had understood by answering a question. I also had the option to request a clarification if I felt like it had skipped something that I didn’t yet understand. Once I had written my implementation it would ask me to explain in my own words what I had done and then it would review my implementation. This would then repeat until I had a completely working implementation and hopefully an understanding of it.

Project origin

The project I chose came to me somewhat without my chosing. A combination of my interests happened to align perfectly and I felt drawn to pursue something that didn’t make much sense on paper and seemed way to hard to accomplish. I have always been interested in cars and other vehicles since I was a very young boy: my parents tell the story of how I used to sit on the back my mother’s bike at the age of 3 or 4 and name all the car makes that I saw as we traveled through streets of Rotterdam. Video games have also been with me since I was a kid, and making games was an early fascination although I didn’t get into actually making games until later in life.

For my summer project I wanted something that could help with moving Flint forward, but still allow me to take a break from working directly on that project. The idea of making a car game on the level of the early GTA games (GTA 3 to GTA San Andreas), has been rattling around my brain for a while. More recently, after watching a tutorial on Blockbench a few years ago I have fantasized about how cool it would be to be able model simple low polly cars with pixel art textures and then get to drive them. When Box3D was released to much hype, everything started to come together in my mind.

I set myself a few goals without knowing how realistic they were, after all this was for fun and learning:

Result

I reached all the goals I set for myself and got a bunch more done that I didn’t expect to get to. I only used the teaching agent for certain parts of the project: primarily the car physics calculations, some details of the 3D renderer architecture, and matrix math. I am blown away by what I achieved and now have the basis to build lots of more interesting things.

The renderer features a skybox with a simple day night cycle, lambertian lighting, shadows, textures, and it can draw cubes and arrays of triangles. Since it is built on SDL GPU it picks the relevant graphics backend based on the platform it is running on while I only had to write one implementation. For shaders I used HLSL as the source format and then used SDL_shadercross to convert to the shader formats needed for each platform. Once Zig’s support for shaders improves I hope to switch to using Zig as the source language.

Getting Box3D built using the Zig build system went very smoothly, I just followed the cmake files and it now builds on Linux, Mac, and Windows without issue. Working with Box3D has been a pleasure too, it’s well documented and once I got things setup the physics solving has been rock solid. I haven’t tried the built in vehicle physics primitives provided by Box3D though, I wanted to make my own implementation that I could understand. I’m impressed considering it is just an initial release, it feels like this is going to be a solid option for 3D physics.

The project is open source and available on GitHub as Wildcar, currently it relies on pre-release versions of Zig and Flint but I will update it once those releases have landed. If you give it a try you’ll see that I chose to make the suspension very “boaty”, partly as an homage to GTA IV. I wasn’t expecting to create vehicle physics that are in some ways similar to a game of that caliber!

Car gone wild An very early version of the suspension system that lacked damping.

First texture The first model and texture I managed to import from a .glb file.

First car model The first car model I imported from a .glb file.

Jump! Demonstration of driving, suspension, and steering.

Conclusion

It’s hard to come to any kind of long term conclusion on this since this is still recent in my memory, the real test is if I will still understand these concepts when I revisit the project in the future. From a day to day perspective I found it a lot more enjoyable than reviewing a giant lump of code, spat out by an agent. I was constantly excited to learn the next part and figure out an implementation, but that was partly a function of picking topics I cared about.

I enjoyed this enough to not dismiss it outright, it felt like I learned a lot faster than if I had studied the old fashioned way but i retained ownership of the code since I wrote it all. I’ve also taken notes about what I would want from a more thought out teaching agent, so I might try my hand at writing one of my own at some point.

I’m not sure this kind of workflow will be common in a professional setting any time soon, I think we would need to start seeing more problems due to loss of knowledge before this topic will become relevant there. But I hope that I can still apply this approach to a small extent, when building things that I don’t know much about, since it isn’t significantly slower than regular agentic workflows but it lets me gain more knowledge and expertise.

For my side projects I will continue to avoid both vibe coding and agentic coding, but I may introduce a small amount of the type of the workflow that I described here. I can also see it working for troubleshooting by asking the agent to indentify a problem and describe it to me rather asking than fixing it. In general I plan to continue exploring ways of using these tools to improve and augment me rather than to just replace me.