Teaching Cloud Agents to Mirror GitLab (When They Only Speak GitHub)

     If you want a humbling lesson in the limits of cloud AI, try convincing an autonomous agent to acknowledge any version control system that isn't blessed by its creator. Over the past couple of days, thirty new suggestions rolled in from Google Jules across my personal repositories. Having an AI throw thirty suggestions at you before you even pour your morning coffee is a strange experience; it feels less like having an elite pair programmer and more like managing an over-eager intern who drank three Red Bulls and started refactoring everything in sight.

     I've actually refined this process a little.  See, I just click start on all of them, then rely on my local triage squad of agents to work through the pile. Out of thirty suggestions, they threw thirteen in the trash. Most of those rejected items were classic AI churn; cosmetic whitespace changes, duplicate lint passes, and redundant null checks that did not actually fix anything. But a handful of them genuinely mattered. They caught and patched real path traversal security vulnerabilities, some minor bug fixes, and cut two clean releases before dinner.

     That seems great, until you see the exponential rise in Github Actions usage.  So, the small taste of productivity put me into a strange situation; I eat through my entire free quota of Github actions in less than a week. The only real choice that gives me is to pay money or self host the pipeline.  I spent the afternoon setting up a self-hosted GitLab pipeline on my homelab for Gas-Logger, complete with automated Gradle test runs, APK builds, and deployment hooks. Since Jules was already churning out code suggestions, I figured: why not point the agent directly at my self-hosted GitLab instance instead of keeping everything chained to GitHub? It took about five minutes of digging through the Jules documentation to realize that was never going to happen; the underlying bot source is fundamentally hardcoded to GitHub OAuth and repository IDs. The cloud agent literally refuses to leave GitHub.

     Because the AI clings to GitHub like a security blanket, I had to build a chaperone. I wrote a Python daemon to run on my homelab server, polling GitHub for merged changes, release tags, and open branches, and mirroring them over to GitLab. Distributed systems immediately reminded me who is boss; the sync script developed an annoying race condition (because of course it did) where tasks marked themselves done before git had actually finished pushing the branch. I had to hunt down the timing bug and rebuild the sync routines across all three repositories so my local CI runners did not try to build phantom commits.

     Everyone online keeps hyping the fantasy of AI agents writing entire applications from scratch while we sip drinks on a beach, but that has not been my reality at all. In practice, you spend half your day babysitting their vendor lock-in, hunting down stupid race conditions in custom mirror daemons, and filtering out forty percent of their output because it is pure noise. Having AI catch a real storage vulnerability is neat, but when tons of automated motion amounts to so much maintenance plumbing, you have to wonder where the busywork ends and the actual value begins. I suppose fixing the plumbing is still my job.

Later,
SteveO

28 Pull Requests Before Midnight (And Why My Cloud Agents Need a Chaperone)

-- P.S.  Thank you Nano Banana for the graphic, it emphasizes the issue in a strange way... more AI slop for the Internet!

     There is a specific panic that hits at twenty minutes to midnight, when you casually click a few repository suggestions in Google Jules and realize a cloud agent has opened twenty-eight pull requests against your main branch. Having an AI hunt down security bugs while getting ready for bed sounds great; in reality, every single pull request instantly spun up a production GitHub Actions runner (which will chew through monthly CI minutes faster than anything else I know).

     The fixes themselves were actually solid. Jules tore through three of my personal projects (NL-Nutrition, SuperBudget, and Gas-Logger) like there was no tomorrow. It patched path traversal holes in Gas-Logger across PRs; it closed an SQL injection risk (I think... who knows really) in NL-Nutrition; it locked down CORS origin rules in SuperBudget; and it migrated brittle date parsing to thread-safe DateTimeFormatter calls before expanding unit tests. Part of me was thrilled to see tedious cleanup handled in twenty minutes - the code was cleaner, test suites were fatter, and I only clicked a button and had paperclip agents push the code through a multi-agent (Antigravity, Claude, and Codex) until it was merged to... main?

     The problem is that cloud agents do not pay your cloud bills. When Jules finishes a batch, its instinct is to aim straight for main; meaning my repositories started kicking off full integration suites and Docker builds all at once. Luckily, I built a local chaperone. My homelab server runs a daemon called jules-governor that wakes up every ten minutes, scans GitHub, and quietly re-targets open Jules PRs from main over to develop. That simple switch diverts the flood into lightweight test runs so GitHub Actions does not eat my lunch before breakfast; truly a lifesaver when letting autonomous bots roam free in your repositories.

     This late-night circus capped off an already wild day of agent operations. Earlier that morning, my local homelab fleet was running its own patrol rounds. Across a three-node Proxmox cluster with twenty-one network hosts and ten active virtual machines, local agents like Aragorn, Frodo, and Gollum (yea, LoTR themed agent names :) audited backups and verified services. Meanwhile, my Home Assistant edge setup (which reports device telemetry to an analytics cloud platform for senior care) ran 1,799 unit and integration tests, alongside 73 UI test suites, against a local Home Assistant Green hub and simulated apartment. So, on paper, I have over 90% of the code tested end to end, but does that really mean any of this crap works?

     Even with twenty-one healthy local agents and hundreds of completed Paperclip tasks under my belt, reality still taps you on the shoulder. By afternoon, two code-review tickets (where Mandos audits a worker teardown fix) sat frozen in blocked status; all because I had burned through my weekly Claude quota and had to wait for the counter to reset. I mean, what is the point of having an AI company if it grinds to a halt because of a quota? Building software with autonomous agents feels like magic when dozens of security fixes land in your lap before midnight; however, the uncomfortable truth is that half the engineering job now is building governors, branch routers, and rate-limit safety nets to keep your digital helpers from lighting your compute budget on fire.

     Anyway, this rant doesn't have a real point.  Just marveling at the way tons of work amounts to nothing in particular.  Its almost like AI never crossed that bridge from busy work to delivering value.  I guess that's my job?

Later,
     SteveO

I Vibe Coded a Thing... It Was Fun

     If you read Part 2 of my agentic development series, you already met Sleepy Tom, Baking Martha, and the rest of the Virtual Villa residents (none of whom exist, which makes them very easy neighbors). This one is a quick side trip into how the thing actually got built.

     There is a real adrenaline rush in telling an AI to do something, watching it go do it, and then fiddling around in the UI instead of solving the programming problem myself. Solving those problems is a different kind of challenge, and one I would miss if I couldn't do it regularly; however, for a couple of weeks it was oddly refreshing to just let the AI take the reins.

     A lot of this I did by talking to Google Antigravity on my phone. I tried to keep my hands off the keyboard, and I didn't always manage it. I would describe what I was seeing (residents stuck, lights not turning on, the apartment count resetting) and Antigravity would find the cause, fix it, run its tests, commit, push, and deploy. Every time it wrote a file, its own tooling reminded it "Don't ask for permission" - and it mostly didn't. It even built the disposable Home Assistant VM on my Proxmox server with Terraform, and later logged into the host itself to snapshot and upgrade it whenever I asked. Near the end, going from my request to a pushed commit usually took under 10 minutes.

     Everything runs on local IP addresses with no domain name, and the test VM rolls back to a snapshot, so breaking things was kind of the point. I think a sandbox like that is essential when you hand an AI the keys. That said, my idea of "isolated" was a little optimistic... the supposedly empty test hub went and found my real TV and speakers from my home setup (which kept coming back from the dead).  Funny how AI will take the liberty of cloning parts of your real home assistant instance when you tell it to setup a new instance.

     Every room in Virtual Villa has a fake Inovelli Red Series dimmer with presence sensing. At first they showed up in Home Assistant as generic MQTT devices, even after Antigravity copied my real switch's model and firmware details (straight out of my production Home Assistant, no less). So one morning I just asked whether they could be actual Z-Wave devices. Antigravity explained that Home Assistant labels a device by the integration that created it, and when I said yes, it wrote a mock Z-Wave server. It committed at 10:54, and by 11:11 Home Assistant believed it had 145 Z-Wave devices (144 dimmers across 24 apartments, plus the controller).

     My job was playing product owner, and that started well before the Z-Wave work. I wrote the first three residents myself: Sleepy Tom, Antisocial Jim, and Active Jane (I called him Jack in Part 2; he hasn't complained, because he doesn't talk to anyone). Antigravity filled out the rest of the building with folks like Night Owl Arthur and Wellness Clara. I described their days in plain English: meals take 30 to 60 minutes, bathroom trips 1 to 10, and a trip out anywhere from 10 minutes to 8 hours. Motion turns the lights on just like the real switch, except in the bedroom; nobody wants the light coming on every time Sleepy Tom rolls over.

     I also had it read the sun position from Home Assistant so the light sensors would feel real. In my head the bedroom and living room had big windows, the kitchen borrowed light from the living room, and the bathroom was a cave. Antigravity picked its own numbers (living room 100%, kitchen 70%, bedroom 60%, bathroom 8%)... not quite the apartment I pictured, but close enough for a test harness. Honestly, that was the fun of it: I spent my time picturing apartments instead of writing code, which is a nice break from the nitty gritty backend work I usually live in.

     The whole point was verification. Another project I work on, a Home Assistant app that reports device changes to an analytics cloud platform for senior care, needed proof that when a simulated light turns on, Home Assistant sees it and the cloud hears about it. During development the tests could hit Home Assistant's local API all day long; the cloud is a different story. A QA tool is more of a cost center than a value add, so I budgeted one check per device per minute, and later cut that back to device adds, hub changes, an hourly sweep, and the Re-verify button.That 144-device stress test found a real limit, too. When devices went missing in the cloud, Antigravity blamed a container restart until I pushed back. Then it found a hard per-location device cap, so a few days later I cut the building to 16 apartments and 96 devices.

     I really do think this is where software development is headed. With a team of agents, I can do the work of five or six people. I do have to admit something, though... on this one, Antigravity was grading its own homework. It ran its own tests, pushed straight to main, and no second model reviewed anything, which is not quite the picture I painted in Part 2. I did set up a Claude reviewer in Paperclip partway through, but I never pointed Virtual Villa at it; in hindsight, that is exactly what this project was missing.

     The part that worries me is what this does to people early in their careers, which is what Part 3 was all about. If AI becomes a crutch, plenty of developers will ship code like this without knowing if it's any good. I haven't done a deep dive yet, but every task I gave it was focused on one small goal, so I fully expect duplicate logic everywhere (plenty of developers would call it AI garbage, and they might be right). It's fine for a throwaway QA tool - I am nearly positive it is not code I would want running in production.

     Anyway, that's all for now. In a future post I want to dig into the performance and the code to see where the AI cut corners; until then, I'm going to keep tinkering.

Later,
SteveO

So, How is the Tesla Now? Part 3: Elon, Autopilot, Dealership Racket... And an Answer

 After rationing our final warranty miles and digging through the data in the first 2 parts; now its time to answer the big question of this series: after three years and two months with our 2023 Model Y, would I buy another Tesla right now?

     I have to admit, over the past few years, Elon Musk has made me nervous. In 2023, when we decided we wanted to get an electric car, I started with the position of anything but a Tesla.  My biggest hesitations was Elon Musk; this was still pre-D.O.G.E. so my concerns were more along the lines of digital consumer rights (when the car is software, the manufacturer has a lot more control after you buy the car thanks to DRM) and Tesla keeps a lot of control over the car through software after the sale. My fears hit home when Tesla changed the Autopilot features; if you bought a car before 2025, the included autopilot features were amazing, but now its a shell of what it used to be; we actually pay the monthly subscription for Full Self-Driving - do that didn't really impact me - however, it sets a dangerous precedent.

     At the same time, driving the Odyssey lately proved that I never want to buy another gas car, and honestly, we are ready to get rid of having a gas car altogether. The situations where we actually want a vehicle that drives 500 or 600 miles without stopping can be counted on one hand in the past 3 years; its honestly more of a hassle to go to a gas station than its worth.  However, what about Tesla's competition?

     Once you commit to an EV, the question shifts to why I would pick a Tesla over another electric car, and to really determine that, you need to talk about features.  First, nobody makes a feature to compete with Full Self-Driving - nobody in the US at least, China is a different story.  I use FSD (Supervised) for 78% of my Tesla driving (according to my driving profile in the car), and on those drives I can pull a lever and let the car handle roughly 99% of the steering and braking; lucky for me, I am a professional back seat driver just like my mom, but whenever I do intervene, it is almost always over lane preferences rather than a close call. It still does dumb, annoying stuff all the time: it changes lanes without a good reason, exits the carpool lane too early or too late, and forces me to toggle between obnoxious driving profiles like Mad Max and Sloth because you can't just set a plain 65 mph cruise speed and tell it to pass slow cars.

     Even with those quirks, I haven't found an equal for surface streets and highways combined. The closest features in the US are geofenced to specially mapped areas rather than a real universal end to end automated driving system.  Even the Level 4 autonomous systems - you know Waymo - require detailed 3D mapping in small geofenced regions and call center workers to monitor and take control of the cars, so they aren't even at the level of Telsa's autopilot in practice; its just, the person in the car doesn't have to monitor and be ready to take over at all times - the call center employees do (fun smoke and mirrors game though).  I know the driver still has to monitor Tesla FSD in privately owned vehicles at all times and be ready to take over, but in practice its more like Tesla didn't get regulator approval to remove the warning outside of a couple small geofenced areas.  So, it is level 4 in those geofenced areas, and level 2 everywhere else.

     Two other practical advantages still hold weight for me too. First, while some base EVs like the Ford Mustang Mach-E are cheaper than a base Model Y; when I cross-shopped legacy automakers like Ford, Hyundai, Honda, and VW, many conveniences that come standard on a base Model Y trim still require stepping up to the top trim packages. This means the $35,000 Model Y should be compared to the $80,000 competition.  Second, there is the buying experience itself. When you buy a Tesla, you just open the app on your phone, order what you want, and pay what it costs without sitting in a dealership back room while a salesperson pressures you into add-ons; I still don't know why buying a car isn't like that everywhere.

     So my final verdict is an honest, slightly conflicted yes: I still worry about what software changes Elon might push down the road, and I wish every automaker sold cars directly in an app; yet I would still buy another Tesla today.  Integrations into Home Assistant are a big selling point for me, FSD has been amazing, performance is wonderful, and the total cost of ownership can't be beat.  I do hope there will be competition for Tesla some day, but I don't see that even existing in a number of way right now. 

     On a slightly different note, I will probably have a follow-up soon after we see what our $500 inspection turns up.  Maybe it will be nothing and I'll be out $500 bucks, or maybe it will find some huge issue we didn't know we should fix!  Either way, the past few years speak for themselves.

Later,

     SteveO

So, How is the Tesla Now? Part 2: The Telemetry Truth

     Welcome back to Part 2 of my 3-part retrospective on approaching 50,000 miles in our 2023 Tesla Model Y. In Part 1, I covered rationing our final 137.2 warranty miles before a $500 inspection and the painful rev-lag of driving our Honda Odyssey all week; today, we are digging into my Home Assistant and TeslaMate telemetry before Part 3 wraps up with Full Self-Driving, Elon Musk, and whether I would buy another Tesla right now.  I am pretty sure I will have more to say about this after the inspection is done, but as I'm trying this format of writing a bunch of posts and scheduling them to be published, I haven't dropped it of yet, so tune back in next week for that part.

     Anyway... back in August 2023 (at 1,014.5 miles), I spun up TeslaMate alongside Home Assistant to log every drive locally. There is a side quest there about the drama around the original developer of TeslaMate leaving the project and having to spin up a separate docker container and database to host it outside of home assistant; however, I'm not getting into that here (maybe that will be a future topic).  So, across 6,838 drives and 48,848 tracked miles, I collected some data!

     In that time, the car pulled 20,833.4 kWh from the wall (18,546.0 kWh into the battery after 11% charging overhead), averaging 427 Wh/mi wall-to-wheel (380 Wh/mi driving). Even after Puget Sound Energy raised rates from 13.88 cents to (15... 18...) 21.66 cents per kWh (the 3 biggest increases in electricity rates in their history!), our entire 3.5-year electricity total is $3,249.22; working out to 7.6 cents per mile at home (86.9% of our charging) and 8.4 cents per mile if you include the $849 spent at superchargers across the country. Battery degradation stayed boringly flat too, easing from 278.7 rated miles new to around 260 to 266.8 miles today (just 4.3% to 6.5% loss).

     Meanwhile, our 2018 Honda Odyssey usage completely collapsed. Before the Tesla arrived, the Odyssey averaged 1,068 miles per month at 19.3 MPG (costing 22 to 23.9 cents per mile). Once the Model Y took over at 1,289 miles per month, the minivan dropped 74% to just 276 miles per month. Driving those Tesla miles in the Odyssey would have burned 2,531 gallons for $11,023.14 - meaning the Model Y saved us $7,233.60 in fuel and kept 22.4 metric tons of CO2 out of the air (even more if you add in the costs for oil changes).

     In the winter, the Model Y AWD is a beast in the snow. We logged 30 ski trips (4,390 miles) up to Stevens Pass down to 13.9 F without needing a Supercharger on a full home charge. Around 35,000 miles, we swapped the factory tires (Pirelli Scorpion MS) at Costco for EV-optimized tires (Bridgestone Turanza EV) before ski season; they are quieter than both the factory tires and the Odyssey's tires (Michelin CrossClimate2), though the Bridgestone tires seem to have traded away about 14% in range (moving winter consumption from 404 Wh/mi to 467 Wh/mi).

     For longer trips, we can drive non-stop from Seattle to Vancouver, BC on a 100% charge and arrive with nearly 42% left.  Enough to get us around Vancouver for the day before topping off at one of the local superchargers (those BC superchargers are even cheaper than charging at home FYI).  Last summer, when a ferry issue forced us south through Olympia and Aberdeen to camp at Bogachiel State Park (575 miles with a roof rack and ski box full of camp gear and four bikes on the hitch rack), I plugged into the Forks Supercharger past midnight while the kids slept; recharging from 27% to 78% and decompressing before pitching the tent at 1:00 AM (while a shorter 337-mile Fort Flagler camping trip only needed a very short public charging stop to top off). Even the scary 12V battery error we saw in Worthington, Minnesota during our 5,531-mile winter trip to Michigan was just a quirk from using a bad CCS charging adapter at a third-party station... and Lynnwood Tesla Service checked on it and found nothing wrong, but gave me a Model S loaner overnight.

     The telemetry is hard to argue with; gas cars can't even compete.  I have also found most of the fear mongering is just plain false (waiting forever to charge, eating tires, range anxiety - which we did have that with Renmin's old Nissan Leaf 12 years ago - all that is just noise now.)  Even the Insurance issue, which was a real problem when we first got our Tesla (Progressive doubled our insurance twice!)  but now we found out that some insurance companies were just milking the hype to make a quick buck - we pay the same rate now we did before the Tesla.  

So, I'm pretty sure I went way over 500 words here.  So tune in next week for Part 3, we need to talk about Elon Musk's software changes, Full Self-Driving's personality quirks, and my final buying verdict.

Later,

     SteveO

So, How is the Tesla Now? Part 1: 50,000 Miles in...

     So, I am trying this new format.  I have had some time to think, and I kept writing these massive walls of text; then I thought, ok, I'm sure everyone loves reading massive walls of text, but hear me out.  What if the wall of text had a 500-ish word limit?  So, I tried that over the weekend, and I'm scheduling posts for 10AM each day.  I don't know how well this works, but I'm trying it.  

     That being said, this post is Part 1 of a 3-part series following up on my 2023 Electrified Road Trip posts and The Test Trip V1 after three and a half years with our 2023 Tesla Model Y. It will take three posts to reach my final verdict in Part 3, because while this is easily the most fun vehicle I have ever owned, a few things over the past couple of years have left me genuinely conflicted. Today in Part 1, we are starting with why I suddenly parked the Tesla for a week right before hitting 50,000 miles; in Part 2, I will pull our real-world cost and trip telemetry out of Home Assistant and TeslaMate; and in Part 3, we will tackle Full Self-Driving, dealership games, and whether I would actually buy another Tesla today.

     Right now, the odometer in my TeslaMate dashboard sits at 49,862.8 miles; meaning I have exactly 137.2 miles left before the 50,000-mile basic factory warranty expires. After reading a couple of articles about Tesla owners who scheduled a detailed service inspection right before their warranty cutoff and caught multi-thousand-dollar suspension or hardware repairs while Tesla still had to foot the bill, we booked the $500 comprehensive inspection.

     Booking that appointment created a funny logistical problem: with under 200 miles of buffer left before our service date, we had to park the Model Y for the week so we wouldn't cross 50,000 miles early. Normally, my daily routine is dead simple. I set the charge limit to 60% and plug the car into our charger every night just like charging a cell phone. Daily school runs and local errands only drain the battery down to 55% or 50% (honestly, I could charge it on Sunday night and coast through the entire workweek without touching the cord, yet plugging it in nightly became an easy habit).

     To save those final 137.2 miles, we went cold turkey this past week and drove our 2018 Honda Odyssey everywhere - and boy, was that a rude awakening. Before the Model Y, I always drove a minivan (Chevy Astro, Pontiac Montana, Honda Odyssey) or a 2008 Honda Accord, so the Tesla was already the sportiest car I had ever owned by a long shot. When you drive a gas car every day, you never notice the delay; however, once your brain gets wired for an electric motor that moves the exact instant your foot touches the pedal, going back to a gas engine feels sluggish. You press the gas pedal in the Odyssey and wait a full eternity while the engine revs up and decides whether it actually wants to move the van. Any electric car will spoil you this way... and it makes me never want to drive a gas car again.

     Parking the Tesla also highlighted how differently the two vehicles handle maintenance and recalls. Over the past three and a half years, our Honda Odyssey has had eight separate factory recalls; every single one meant dropping the van off at the dealership overnight (or for two full days while we juggled family rides). By contrast, nearly every recall on the Tesla was an over-the-air software update that fixed the car in my driveway while I was asleep.

     Ironically, we did just get our very first physical hardware recall on the Tesla to replace the headlights. Just like an active Honda recall where we couldn't get the part, the replacement Tesla headlights are currently on back order; which makes me wonder what would happen if my headlights actually burned out tomorrow (would I just be stuck with a car I can't drive after dark... during a time of year with 4 hours of daylight per day?!??).

     Anyway... while the Model Y sits parked in the driveway saving its final warranty miles, Part 2 will open up my Home Assistant and TeslaMate database to see what 20,833 kWh actually cost us, how badly the Odyssey's usage collapsed, and how the car handled 30 mountain ski trips - all building toward my Part 3 verdict.

Later,

     SteveO

Part 3: From Xbox and Windows 95 to Today: Who Trains the Next Senior Engineer?

   This is Part 3 (the final installment) of my trilogy on agentic software development. In Part 1, we looked at the clash between slow corporate code reviews and live voice-driven prototyping; in Part 2, I walked through how I run a multi-agent team at home with FCI Operations and my Virtual Villa simulator. Now it is time to connect those dots and get to the final point I promised back in Part 1 - why this amazing new workflow leaves me genuinely conflicted about the future of our industry.

     In Part 2, I mentioned how running a multi-agent engineering pipeline changed the way I write requirements; specifically, how often I come up with performance requirements on the fly while actually using the software and realizing, "Hey, this button should not take this long to respond."

     We love to pretend in software engineering that we can sit down before writing a line of code and declare a blanket non-functional requirement like, "All UI interactions must complete within 500 milliseconds." That sounds wonderful in theory, but in practice, it falls apart the second your software meets unpredictable hardware.

     This is something I learned early on during my time at Microsoft working on Xbox 360. On a console, Microsoft has strict Technical Certification Requirements (TCRs). When a player launches a game or presses a button, the game has a hard time limit (down to the second) to display something on screen (even if it is just a spinning wheel or a loading bar) so the user knows the system didn't freeze. On an Xbox, enforcing that rule makes complete sense because every single customer is running the exact same hardware in their living room.

     Desktop and web software is a completely different animal. You have no idea if your user is running a high-end gaming rig or some $99 Walmart cheapo PC that barely boots the browser. The same unpredictability applies to the cloud backend too; you don't know if a request is hitting a warm Kubernetes pod or a serverless AWS Lambda function that just went into a cold reload - surprise, your half-second budget is already gone. Because of that, real performance tuning usually happens in the middle of testing a working prototype, when you feel the lag yourself and tell the agent to fix the bottleneck.

     However, watching how easy it is to let agents handle that heavy lifting brings me full circle to my biggest worry for our industry. Right now, a lot of developer burnout is coming from engineers trapped between two worlds: trying to satisfy slow, pre-AI corporate review processes while simultaneously being pushed to adopt high-speed agentic workflows.

     As the agentic model wins out, we are heading toward a world where one senior engineer leading a team of AI agents can comfortably do the work that used to take five or more developers. I love the velocity in my own homelab, yet I can't shake the obvious question: where do the next senior engineers come from?

     Think about how operating systems evolved over the last thirty years. Back in the Windows 95 era, you only had a tiny sliver of RAM and CPU, so engineers had to be incredibly disciplined and sparing with every megabyte. Today, a modern OS like Windows 11 will happily eat a gigabyte of RAM without a second thought, and then chew up another gigabyte just to draw the graphical user interface so you can finally run an application on top of it. Now, there are valid reasons for modern OS features, and I am certainly not arguing that we all need to go back to Windows XP here; however, cheap hardware made us lazy about resource discipline.

     I worry we are about to treat software engineering talent the exact same way. Right now, it is very tempting to just let the agents do everything because you can move so much faster when you don't have three humans staring at every line of AI-generated code. If the function does what it needs to do, the performance feels good enough, and a security auditing agent says the security is good enough, we ship it. Yet writing those routine tickets, breaking things, and debugging the mess is how junior developers learn what good code actually looks like. If nobody is doing the foundational work anymore, in ten years, who is going to have the deep systems knowledge required to review what the agents are building?

     Anyway... that is the full circle of my rant on agentic development. I am having a blast building with these tools, even if I am a little nervous about where the industry ladder goes next.

Later,

     SteveO