Additive vs. Mutative vs. Destructive Code Changes (and Why AI Agents Love the Wrong One at 2:13AM)

There’s a particular kind of pain that only software developers know.

Not the “production is down” kind of pain.

Not the “we deployed on Friday” kind of pain.

No, I mean the slow creeping dread of pulling the latest changes, running the tests, and realizing the codebase has been “improved” in a way that feels like someone rearranged your entire kitchen… but left all the knives on the floor.

And lately, this pain has been supercharged by AI tooling. Cursor, Claude, Copilot, Gemini, ChatGPT-driven agents, whatever your poison is this week, all share a similar behavioral pattern:

They can produce a stunning amount of output at an impressive speed… while quietly reshaping your system into something that looks correct but behaves like an alien artifact from a parallel universe.

The reason is simple: AI agents don’t “change code” the way humans do. They don’t naturally respect boundaries unless you explicitly enforce them. They operate like an overly enthusiastic intern with root access and no fear of consequences. To understand why this happens, we need to talk about the different types of code changes, and how AI tooling tends to drift toward the most dangerous ones.

So let’s name the beasts.

The Four (Actually Six) Types of Code Changes

Continue reading “Additive vs. Mutative vs. Destructive Code Changes (and Why AI Agents Love the Wrong One at 2:13AM)” →

12 Days into 2026 – Status & update of my projects.

As mentioned in my end of 2025 post, there were several projects I intended to start, continue, or finish up in 2026. This is a quick status and an additional few things I’ve started working on.

https://interlinedlist.com – This is live. Albeit not very built out, but the start is live. You can even sign up for an account and play around with it. A caveat though, this is pre-alpha, and not very feature rich at all and I don’t have the programmer oriented tasks integrated in yet. It’s just the micro-blogging. But hey, some progress is better than no progress!

https://www.datadiluvium.com – This is still live and I’ve got some changes to push, but they’re breaking, so as soon as I dig up a bit of free coder time those will get resolved and I’ll get the latest tweaks pushed. I also need to get some basic documentation and also something posted here on the blog about what you can do, or would want to do with it.

dashingarrivals – First commit isn’t done. Working on it, it’ll be coming soon per the pervious post.

collectorstunetracker – No current update. Albeit I need to do something about my collection, cuz it has only grown and not shrunk! 🤘🏻

Writing – This is one of many posts. I wrote this one too, not some AI nonsense.

New News About New Projects

I discussed it a while back on one of the social medias (I’m on Threads, Mastadon, and Blue Sky – join me there) the idea of doing some videos on algorithms and data structures. The intent is to put together some videos similar to these “Coding with AI: A Comparative Analysis“. It could be good, and I’d tack onto the algorithms, data structures some additional lagniappe via concurrency patterns I previously wrote about. If interested, subscript to the blog here or subscribe to my YouTube at https://www.youtube.com/adronhall.

Until then, keep thrashing the code! 🤘🏻

The End

Today is, for the most part, the end of my professional year of 2025. What have I done, what am I looking forward to in 2026?

2025 Year in Review

This year I’ve had the chance to work on some really cool tech. You can read more about it here, where I put together a quick QR code prototype. I also did a ton of documentation writing, but also shipping it as a product, and making sure it was updated and kept up with the products and services it was being shipped with; How Principal Engineers Shape Documentation as a Product + Punch List Lagniappe. Beyond that I’ve shipped tons of AI processing pipeline code that changed about 4,923,123** times because the tools provided weren’t up to snuff, so reinvention and filling the gap in the tools it was. Lots of fun challenges, great tech shipped, and users of said software up and running.

On a personal front I got a reasonable amount of my expectations met for 2025, which mind you, wasn’t a lot considering the changing of the guard and the current state of the tech industry. To which, let’s talk brass talks, not beat around the bush, dispense with formalities, and get to the pending chaos of 2026.

Let’s Talk, No Filter

Continue reading “The End” →

Setting Up TimescaleDB for Time Series Data with Postgres.app for all your “Time Scales”!

I used an image from The Geological Society of America‘s “Time Scale” but this isn’t about that, but it kind of is and I’ll have a future post about using TimescaleDB to organize “Time Scale” like this, but that’ll be a little bit in the future. For now, I posted that Time Scale for the LOLz. 🤙🏻

I’ve been using TimescaleDB for time-series data on and off for a while now. I recently fired up Postgres.app for local development. It’s one of the cleanest ways to get PostgreSQL running on macOS, and adding TimescaleDB is surprisingly straightforward once you know where to look.

Time-series data is everywhere—sensor readings, application metrics, user events, IoT data. Regular PostgreSQL can handle it, but once you’re dealing with millions of rows, you’ll notice queries slowing down. TimescaleDB solves this by turning your time-series tables into hypertables that automatically partition by time, compress old data, and optimize queries. The best part? It’s still PostgreSQL, so all your existing tools and SQL knowledge work exactly the same.

I’ve built enough dashboards and monitoring systems to know when you need proper time-series handling versus when you can get away with a regular table and a good index. Once you’re dealing with millions of rows and need to query across time ranges efficiently, TimescaleDB is worth the setup.

Continue reading “Setting Up TimescaleDB for Time Series Data with Postgres.app for all your “Time Scales”!” →

A Complete Native PostgreSQL Setup on macOS: Homebrew and Launchd

Advantages

Native PostgreSQL installation gives you the best performance and the closest thing to a production Linux environment on macOS. You get full control over configuration, service management, and when PostgreSQL starts. Homebrew makes installation clean, and launchd handles service management reliably. You can run multiple PostgreSQL versions simultaneously on different ports, and you have direct access to all PostgreSQL files and configuration. This is the most flexible option for serious local development.

Disadvantages

Native installation requires more setup and management than Postgres.app or Docker. You’re responsible for starting and stopping the service, configuring auto-start, and managing system-level settings. Updates require manual intervention, and you need to understand launchd and Homebrew service management. It’s easier to accidentally break things or create conflicts with other PostgreSQL installations. For developers who want simplicity, Postgres.app is easier. For those who want isolation and reproducibility, Docker might be better.

Sometimes you want PostgreSQL installed directly on your Mac. No containers, no apps. Just PostgreSQL running as a system service. This gives you the most control, the best performance, and the closest thing to a production Linux environment you’ll get on macOS.

The trade-off is you’re managing a system service. But if you know what you’re doing, it’s straightforward. Homebrew makes the installation painless, and macOS’s launchd handles the service management. You get full control over when it starts, how it’s configured, and what versions you’re running.

This is the complete guide to installing PostgreSQL natively on macOS, configuring it properly, managing the service, and setting up an initial development database named interlinedlist.

Continue reading “A Complete Native PostgreSQL Setup on macOS: Homebrew and Launchd” →