Walk N' Squawk

AI, LLMs and a step change in SW engineering

2026-04-06T00:00:00+00:00

A lot has been written about AI and LLMs for the last year and a half (probably much longer). I mostly ignored AI and LLMs outside of chat clients on the web and found even with something like Cursor, that it wasn't quite up to what I needed to be that much more productive. Around the beginning of 2026, I ended up trying Claude Code at work and was sort of blown away. It has led to me using Claude on a lot of my own projects and getting through a huge backlog of annoying bugs or tasks that I had put off for a long time.

How Agent Coding has Changed my Dev Process</h2>
The velocity change in my hobby development has been crazy. I typically have 30 minutes to an hour a night to play around due to other responsibilities like parenting two amazing young boys, so I can kick off a task and come back and review and tweak things while making dinner - it's basically unlocked a bunch of time that I couldn't use before.
At the same time, a lot of bugs or tasks that I previously just wouldn't bother looking at, e.g. fixing stack trace printing on Windows for testz</a>, I was able to get done. Now, is the code perfect and how I would have written it? No. I wouldn't have written the code at all because I would always have had a lower hanging fruit to work on.
Is AI perfect? Absolutely not. It still can get into weird loops where it's not considering edge cases the way any human would. It's not great with software architecture choices all the time. But for tools, examples, handling boring boiler plate type work - it is really a game changer.

Implications to the Wider Industry</h2>
I've been a professional software engineer for over twenty years at this point and AI coding agents, like Claude Code, are the single most dramatic step change I've witnessed. I've seen many hype cycles over my career: virtualization, the cloud, containers, mobile development, front end java frameworks like React, etc.
You'd see r/programming</a> and Hacker News</a> filled with stories about the hype for some time, usually about a year and a half, and then it would start to die down. The difference there was each of those applied to specific groups of developers: backend web, frontend web, mobile apps. This change is more like going from assembly to having compilers and is affecting a much broader set of developers.
A big differences with that comparison though: going from everything in assembler to compilers ruling took years. The massive use of coding agents has been over the last few months, from what I've seen.
Many folks are worried that now real software engineering will get lost to agent coding slop and that there will be huge loss of software jobs as individuals can be more productive.
It's hard to say with any certainty, but I think like with moving from assemblers to compilers, we'll see the amount of software created massively expand.
The number of smaller companies that simply did without various automation tools is huge - they can now work to improve their business in a way that was not economically feasible before. The engineering job of translating rough ideas into requirements that can actually be created will exist in any case.
There will be much more sloppily written code, but as I've heard other people mention - many problems that we solve with software don't need super elegant code and other areas definitely need human review.
For example, a tool for generating a documentation site for a zig project</a> - the software architecture is not so important, just that the output is what I want. On the other hand, handling concurrency in an OS kernel - probably want a human to have verified all of the logic thoroughly.
I do believe in the short term we will see a massive downward pressure on software engineering salaries as companies see improved productivity. I also think we will see a huge number of 10-20 person companies that will have the same output as older 100-200 person companies. The lower communication overhead of a smaller team will allow product-first engineers to make progress far faster than larger organizations are able to.

Conclusion</h2>
At the end of the day, it doesn't really matter what software engineers want our job to look like. As I've said for a long time, in a professional context, our job is to provide business value and software is our tool. If it is possible to create that value more quickly, that is going to become the way it is done - with all the warts and problems that brings with it.
I'm excited about this change, mostly. It's sad to see a skill I've spent thirty years working on become far more commoditized over the course of a few short months - but this industry has always been one for people who can embrace change and learn new things.

Asking for engineering help

2025-11-26T00:00:00+00:00

As I've advanced in my career, I spend more and more time helping my team and others in adjacent teams with issues they're hitting. I realized that many engineers don't know how to properly ask for help from other engineers, leading to frustration and wasting time.

My Development System and Other Blog Updates

2024-11-25T00:00:00+00:00

Moving to Manjaro</h2>
It's been a while since I mentioned changes I've made to my development setup, the last being related to moving to Kubuntu from Windows 10</a>, as well as moving to using NeoVim as my editor with AstroNVim as the base configuration</a>. I'm still going strong with NeoVim and loving it as my main editor (including on my phone and tablet via Termux</a>!). For the last few years though, I've actually been using Manjaro Linux</a>, based on Arch Linux, as my OS and have been very happy with that setup.
I use KDE as my desktop environmet, so apart from using pamac</code> instead of apt</code> to install packages from the command line, it's relatively transparent that I'm not using an Ubuntu falvor of an OS.
The issue I ran into was that at one point I was using an x.10 release of Ubuntu and held off on updating for a while. As I've gotten older, I don't want to update a working setup unless I need to. There's almost never anything in it for me to do a larger update.
Since I had waited too long, the ability to upbdate Kubuntu through the normal dist-upgrade</code> channel was turned off, so I was stuck and was going to have to reinstall the OS from scratch. At that point, my brother mentioned to me that he had been trying various Arch distributions and liked Manjaro. He's since moved on to EndeavorOS, which I may try sometime. I gave Manjaro a shot and have had no problems with its rolling updates for over two years.
In the meantime, Steam on Linux has gotten to a point, where almost every title I want to play works on Linux without issues for me. The one area that's still not perfect is with multiplayer games that use anti-cheat software like Battle Eye (Rainbox Six Siege, I'm looking at you</a>).
Blog Changes</h2> I recently swapped from using Hugo as my static site generator for the blog to using Zola</a>. My main gripe with Hugo was that I kept getting warnings about themes getting out of date as I would deploy and Hugo on Gitlab would build with a newer version. I didn't really like how the themes in Hugo were setup, and this would have been the third time I went and hunted down a new theme to use that would be warning free. Instead, I had heard about Zola and thought I'd give it a try. The theme engine, shortcode setup and content layout feel far cleaner to me. That said, I setup my Hugo blog years ago, so maybe things had improved, but since this is just a place for me to publish ideas and articles I don't want to spend much if any time on maintaining my configuration - that takes away from the little time I spend blogging, adding another hurdle. One big difference in Zola is being able to put my images in the same place as the post. In Hugo I always had the images under the static</code> folder, which kept them far from the posts where they're used. Just like in code, this ends up being a bad idea. Again, maybe this was user error, but Zola was setup perfectly right out of the box with good docs. While working to convert things over, I stumbled on this article: Why I chose Zola to build this site</a>, where the author had a lot of the same issues with Hugo that I had. Converting my blog over to Zola from Hugo and changing over to hosting it on GitHub took about a day and was actually pretty fun. I also have a feeling this will be a more stable setup, which may actually encourage me to write more.
Rust vs. Zig and testz 2024-01-07T00:00:00+00:00 Earlier this year I made the switch from using C++ on my hobby projects to trying out Rust</a>. I spent about 6 months of hobby night-time programming time porting over my 2D game engine and the bulk of my 6502 CPU emulator project. There are a lot of aspects of Rust that are great, but I got tired of fighting the borrow checker left and right. I still feel like I have a hard time expressing myself in Rust. I had heard about and looked at the Zig programming language</a> before and really liked some of its core concepts such as comptime</code></a> for doing meta-programming in a much cleaner way than I've seen before. This was back when it was around 0.7 and it was pretty rough around the edges in many other areas though. I had another look towards the end of summer and found with version 0.11 it struck a chord with me and I've been using it ever since, getting further into a new porting exercise for my 2D game engine and 6502 CPU emulator in less than half the time it took me in Rust. I also wrote a small unit testing library for Zig called testz</code> to improve my testing development flow. FPGA design for Software Engineers, part 4 - Multiplexed Seven Segment Displays 2023-04-23T00:00:00+00:00 This time we'll continue from the last design article</a> and add in the ability to drive multiple seven segment displays. Neovim with a Little Bit of Config is Amazing 2023-04-18T00:00:00+00:00 I've recently switched from using Visual Studio Code as my main editor of choice to using Neovim with the awesome Astronvim</a> configuration and some of my own tweaks on top. It ends up functioning as a great development environment with code hints, debugging, file finder and at the same time uses much less memory. It even has one killer feature over VS Code. Rust unit test layout 2023-02-18T00:00:00+00:00 I've been succeeding in my fourth attempt at learning to use Rust. I come from mostly a C++ background, and I've struggled the first couple of times I've tried to pick up Rust, ultimately stopping the effort to work on the next shiny quarter. I started porting over my Nintendo 6502 processor emulator from C++ as a larger project to play around with. One thing I had done in the C++ one is have tons of tests for the different instructions - checking clock cycles and internal register states for the emulated CPU. Most of these tests ended up split up across different files to keep the codebase manageable. Unit Testing in Rust</h2> In Rust, the guides all mention keeping your unit tests in the same file in a sub module declared in the file and marked as a test module with #[cfg(test)]</code>. You can also have an integration tests folder that lives as a sibling folder to the src</code> folder, but there the idea is to handle the modules as black boxes without the ability to peek into the internals - which in some cases can be useful in unit tests. Splitting your Rust Unit Tests into Multiple Files</h2> It turns out to not be very difficult to split up your unit tests into separate files, but it took me a bit to figure out and thought it might useful to others. Here is what the layout of my dummy project looks like now: . ├── Cargo.lock ├── Cargo.toml ├── src │ ├── cpu.rs │ ├── lib.rs │ └── tests │ ├── cpu_tests.rs │ └── mod.rs</code></pre> All I've done is move the tests module's code into the cpu_tests.rs</code> file in the subfolder tests</code>. cpu_tests.rs</code></h4> use crate::*; #[test] fn it_works() { let result = add(2, 2); assert_eq!(result, 4); }</code></pre> I then have a tests/mod.rs</code> that includes all of the test files, tests/cpu_tests.rs</code> only in this case. mod.rs</code></h4> pub mod cpu_tests;</code></pre> Then by including that module in the top-level lib.rs</code> and marking it as a test module, it will still get run as a unit test without cluttering up lib.rs itself. lib.rs</code></h4> pub fn add(left: usize, right: usize) -> usize { left + right } #[cfg(test)] mod tests;</code></pre> And the results of running the unit tests when I do a cargo test</code>: ❯ cargo test Finished test [unoptimized + debuginfo] target(s) in 0.01s Running unittests src/lib.rs (target/debug/deps/nesters-0b3b29c8edf564ce) running 1 test test tests::cpu_tests::it_works ... ok test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s</code></pre>Conclusion</h2> Rust has been a great language to dig into a bit deeper, since it has some nice defaults, built in unit testing and the package and project management through cargo gets rid of a lot of boiler plate that I've constantly needed to duplicate across project for C++. There are still some areas where I'm learning how to structure my code in a way that feels the most manageable and comfortable to me. Given that the searches I did didn't show this solution published elsewhere, I hope others also find this useful. </div>