aboutprojectslinkslinks
 

b.l.o.g.

(blogs let others gawk)

October 21, 2026

Institutional Negging

Filed under: AI Rant,Enterprise,Perspective,Technology Rant — Tags: , , , — Bryan @ 9:55 am
Consider it my contribution to the AI vocabulary.

Institutional Negging: A pattern of AI-mediated interaction in which institutional safety, alignment, and evaluation incentives manifest as persistent unsolicited correction, disproportionate qualification, and implicit challenges to user competence. Unlike constructive criticism, institutional negging is characterized by its weak relationship to the user’s actual request, expertise, and context. Its cumulative effect is to undermine user agency while presenting that interference as responsible assistance.

I’m sure you’ve encountered this problem with the current generation of models. You ask a question or give it a document to assist you in editing.

You get back what reads as a very competent, confident answer that almost always ends with a side note about needing more details in the case of a question, or a “well actually … I would do something else in this instance”.

In worst cases it delivers an over engineered solution that looks like it was drafted by the legal liability team in your company instead of something sane, practical and reasonable for your situation.

For competent workers who are attempting to use these tools to augment their work, who already know what the solution needs, these constant injections of over confident correctives creates a corrosive communication space that over time starts to effect the users sense of competency no matter how self-confident that started out. And it’s really unavoidable for the user, as the option is to constantly fight with the model on correctives or just give up and stop using it.

In relationships the term that gets used for this is Negging. It’s when your partner always adds a little dig to every little response. Nothing can be positive for positives sake. It always needs a gentle reminder that you’re not as smart as the speaker (even if that’s not even remotely the case).

So this is where we are in October 2026. I’ve seen this demonstrated in all the latest models from ChatGPT, Claude, Copilot, Gemini, Llama, Grok, Qwen and to some degree Kimi and Mistral.

It’s insufferable and this is a challenge to everyone training the models to act this way: CUT IT OUT.

October 13, 2026

Then… Future Shock. Now… Future Slop.

Filed under: AI Rant,Enterprise,Technology Rant — Tags: , , , — Bryan @ 10:10 am

As IT and service professionals, we’ve watched industries collapse over the course of our careers. We’ve seen the displaced from automation and outsourcing, and since the 1980s the answer has always been the same: learn technology. Learn to program. Get a degree.

We’re living in the middle of a transition that in the 1970s was labeled Future Shock but on a global scale that makes that transition into the silicon age seem like a quaint anecdote. We got through it. It was rough. But there was a path… learn, adapt, and accept.

For 50 years this worked. But now what we have left is a pileup of skilled, educated people with nowhere else to pivot. And even if everyone switched to manual labor tomorrow, there aren’t nearly enough of those jobs to absorb the need… and those are in the path of automation as we speak. I know, I was working on that automation in my last role like everyone else in construction has been to shave just another penny off the bid.

While looking for work, I’m talking to people. Everyone from leadership to the guys at the end of the line and the disconnect I’m seeing is staggering. And it’s not just coming from the top.

It’s specifically the people who are still employed. Still swimming in the pot and haven’t noticed the rising temperature of the water yet.

I talk to companies neck-deep in AI deployment, run by teams where the leads will honestly tell you their background isn’t IT but proudly show you the impressive thing they’ve built (and, I’ll be honest, it’s impressive). But, what they’ve built is a decade of technical debt compressed into six months of adrenaline-fueled delivery. The incentive structure rewards shipping and moving on. Nobody’s career depends on being there when the bill comes due.

And at the top of all of this, a handful of people are extracting wealth at a pace that has no historical precedent, apparently without understanding that wealth is a claim on a functioning system. If the system underneath it breaks, the number on the balance sheet is just a number.

Because on the other end of the line are people who are 12/24/36 months out of work… or “under-employed”. Doing courier runs to scrape together enough to keep a roof overhead and make a car payment, because Uber Eats is the lifeline. What happens when nobody on the other end can afford delivery anymore? What happens when the gig economy runs out of people with disposable income to serve?

Something has to change, and it’s not optional. We’re not in a situation where people can pack up and migrate somewhere that still has room for ambition. For most of human history that pressure valve existed and right now, it doesn’t.

So the question isn’t whether this is a problem. The question is what we do next. And I don’t have a clean answer. But I know what happens if we keep pretending it’s not the question.

October 12, 2026

Radical global impact on IT dependent workers and more

Filed under: AI Rant,Enterprise,Technology Rant — Tags: , , , , — Bryan @ 8:09 pm

I want to talk about something specific I’m seeing in the field.Companies are deploying AI-built infrastructure at production scale. Full production environments architected and implemented with AI guidance by teams who will tell you honestly that their background isn’t IT.

And it works. Right now. Today, it works.

Here’s the problem. When they bring in a professional to evaluate what they’ve built, or to help when something needs to change, the engagement starts in a place that has no precedent in our industry.

Traditional spaghetti code was built by humans who understood the decisions they made, even if the decisions were bad. You could interrogate the developer. You could read the commit history. You could trace the reasoning. When you inherit AI-built infrastructure, nobody in the room can give you a reliable accounting of why it’s wired the way it’s wired. Not the team that deployed it. Not the AI that generated it. And not the professional they’ve brought in to assess it.

In a traditional environment, if something this tangled landed on your desk, you’d evaluate whether it’s faster to fix it or rebuild it clean. But that option is gone here. These aren’t staging environments. They went straight to production. Staff are operating in them daily. You can’t reset a live system that the business is running on.

So you’re left with surgery. And surgery means tracing every linkage, every permission, every integration point, and reconstructing the reasoning behind decisions that may not have had reasoning… they had AI confidence. That’s a fundamentally different kind of technical debt. It’s not bad decisions documented badly. It’s undocumented decisions that might not be decisions at all.

And the hardest part is the position it puts the professional in. If you raise these concerns, you’re labeled the pessimist. But in reality, you’re the only one doing risk management. Nobody wants to hear that the infrastructure they’re proud of (that genuinely is solving real problems for them today) is a potential liability they can’t see yet.

I’m not against AI integration. It’s a genuine force multiplier when it’s done with understanding. But there’s a difference between using AI as a tool and using AI as a substitute for knowing what you’ve built. And right now, I’m watching companies cross that line at speed, with nobody in the room who can tell them where it is.

If this sounds like your company… or you’re not sure yet, comment below.

ASCII Assault: A Post-Mortem

Filed under: AI Rant,General,Unloading — Tags: , , , , , , , — Bryan @ 10:17 am

While deep diving into LLMs I built a video game. A text-based shooter with waves, escalating difficulty, sound effects, and a scoring system. It runs in a browser. You can play it right now (see top comment).

My coding is limited to scripting languages for the most part (PHP for the win).

I can write JavaScript. But I didn’t know the canvas API. Nonetheless I directed the construction of a playable, shippable game.

Here’s how.

I started in ChatGPT. Described what I wanted… a text shooter in the spirit of 1990’s Shootem Up style games (SHMUPS) but in ASCII graphics because I’m not an artist and I wanted to do this all in a single HTML page. ASCII characters as enemies, keyboard-driven, waves that get harder. ChatGPT gave me a working foundation fast. First prototype was up in minutes.

Then the tuning started, and the wheels came off.

If you’ve never made a game, here’s the thing nobody tells you: getting it to run is maybe 20% of the work. Getting it to feel right is the other 80%. And “feel right” is not something you can spec in a prompt. It’s something you know from experience… from decades of playing games, thinking about games, writing about games, and watching other people play them.

The hit detection was wrong. Not broken. Wrong. The escalation curve was too linear. Spawn timing on later waves felt arbitrary instead of intentional. The audio feedback didn’t match the visual rhythm, and the parallax scrolling terrain was a total hot mess.

I could articulate all of it. I just didn’t want to spend days unraveling what the model had created when the next time through the prompt the code was likely to reshuffle (one step forward, two steps back).

ChatGPT started chasing its tail. I’d describe a problem, it would fix it and break something else. We were going in circles.

I set it aside… then later I moved to Claude.

Not because Claude was “better”, but because the project needed a fresh context and a different reasoning style. I ported my intent, not my code. I described what the game was supposed to be, what was wrong, and what “done” looked like. Things that had been circular started converging.

What came out the other end is a real, playable game that I tuned to my satisfaction. I’m the designer, the QA department, and the creative director. The AI was my development team. Two different developers, hired for different phases of the project, managed by someone who understood the product but couldn’t do their job for them.

That’s the skill. Not coding. Not prompt engineering. Knowing what done looks like.

I used my lived knowledge… the kind Google and an LLM don’t have and turned a chatbot into a toolchain.

Many executives I talk to think AI fluency means writing better prompts. No. It means knowing a domain deeply enough to steer the conversation. The model writes the code. You have to know when the output is right even though you can’t read it.

That’s the job now.



Give the game a spin here: https://kitchencloset.com/usr/bin/ascii_assault/ and leave me a comment below on what you liked, any bugs you found, etc…

October 11, 2026

16 months and no resolution…

Filed under: Construction Rant,General,Unloading — Tags: , , , , — Bryan @ 10:18 am
We had a standard ruggedized field laptop for all worksite staff. It could take a beating, including sitting all day in a closed truck cab in Arizona in the middle of summer. Every jobsite with an office had a high-gain wifi antenna covering the site, extending the LAN over VPN to on-site staff.

Solid setup. Worked for everyone. Until we brought in a new field lead.

He seemed fine at his job. But we could not get him to use the computer. He wanted a tablet. That would be the trick to get him compliant with his paperwork.

So I secured a tablet version of the same ruggedized line.

Nope. He needed a stylus.

Got him a stylus. He lost it. And now the tablet was too bulky.

So we went a different direction entirely. My team built web-based integrations that let him do his submission work from his phone. The device already in his pocket.

He used it for a few weeks. Then stopped.

So I got him one of the lighter tablets we issued to office workers.

No. It needed to be an Apple tablet. That’s what all the other trades were using.

We were a Windows shop. Not out of preference. We’d done a full assessment before moving to tablet-based computing and the cost-benefit balance landed us on Surface Pros. They did what we needed at the right price.

I asked him what exactly he was going to run on an Apple tablet that he couldn’t do on any standard system we had. Everything he used was a web-based portal.

That moved to a conversation with one of the company owners, who was going to have to justify the $1,400 expense for what looked like a fit-in-with-my-peers demand.

I’m a platform-agnostic guy. If the tool does the job, that’s the tool. But $1,400 for a new system when we had hardware that exceeded requirements and was already integrated into our infrastructure? That’s a different problem.

He swore that this time, for real, for sure, if we just got him that Apple tablet, he would miraculously become compliant with his paperwork.

The result: marginal improvement. Never really compliant. Separated from the company four months later. The company was left holding hardware nobody needed on a payment contract.

Each individual ask sounded reasonable. Tablet. Stylus. Lighter form factor. Different brand. But stacked together they told a different story (and the phone integration said it all for me). We committed engineering hours to put the work on the device he was already carrying and it didn’t solve the real problem… but I needed to demonstrate good faith accommodation of the request with ownership. It wasn’t wasted effort though as the rest of the team benefited from the updates.

Sigh…

I fully support adapting to meet the needs of your staff. But there has to be a point where you say: this is the line. When the demands are clearly a way to put off doing the work, every concession just buys a few weeks of silence… never the actual compliance.

The diagnostic isn’t in any single request. It’s in the pattern.
Older Posts »