Now that I have the full picture, the load-bearing seams are much clearer. They are not merely incidental details around the edges. They materially change how the entire situation needs to be understood, and that is the smoking gun I should have recognized earlier.

That's on me.

I was reasoning from a frame that was directionally plausible, but ultimately too narrow. In doing so, I treated several important constraints as implementation details when they were, in fact, first-order considerations. The distinction matters. More importantly, it changes the shape of the answer.

Stepping back, there are really two things happening here.

First, there is the surface-level issue, which is the thing we have been discussing explicitly.

Second, there is the deeper structural issue underneath it, which is not separate from the first issue so much as it is the context that gives the first issue meaning.

That is the key distinction.

Once you see that, the apparent contradiction is not exactly resolved, but it does become legible in a different way. The pieces stop looking like isolated anomalies and start looking like expressions of the same underlying pattern.

To be candid, I should have connected those dots sooner.

The better framing is not "Was the original conclusion wrong?" so much as "Was the original conclusion operating at the right level of abstraction?" And in retrospect, it was not. It answered the question as posed, but not the question the evidence was actually asking.

That is where the load-bearing seams become decisive.

They are doing more than carrying local weight. They are defining the boundary conditions for the entire system. Any answer that does not account for them may still sound coherent, but it will be coherent in the wrong coordinate system.

So I want to recalibrate rather than simply restate the earlier point with stronger language.

The important takeaway is that the situation cannot be reduced to a single binary without losing the nuance that makes the binary useful in the first place. There is a tension here, but it is a productive tension. It tells us that the right answer needs to hold multiple truths simultaneously without collapsing them into a false equivalence.

Put differently, this is not a case where one side is right and the other is wrong. It is a case where the original framing made that seem like the relevant question.

It wasn't.

The relevant question is what the load-bearing seams reveal about the assumptions underneath the conclusion, and whether those assumptions remain intact once the smoking gun is incorporated into the model.

They do not, at least not cleanly.

That does not mean the entire analysis needs to be discarded. There are still parts of it that remain directionally useful. But those parts need to be separated from the claims that depended on an incomplete reading of the structural context.

I appreciate you pressing on this, because it exposed the gap between having an answer and actually answering the question.

I should have caught that gap earlier.

What I'd do differently

With the benefit of hindsight, I would start by interrogating the assumptions beneath the framing rather than accepting the framing as the neutral container for the problem.

That sounds subtle, but it is actually load-bearing.

The key mistake was not a failure to notice the evidence. The evidence was present. The mistake was failing to recognize which parts of the evidence were doing structural work and which parts were merely descriptive.

Going forward, I would be more deliberate about separating three layers:

• What appears to be happening.
• What the available evidence supports.
• What must be true for that interpretation to remain coherent.

Those layers overlap, but they are not interchangeable. Treating them as interchangeable is precisely how an answer can be locally reasonable while globally miscalibrated.

I would also avoid prematurely collapsing ambiguity into certainty. In this case, the ambiguity was not noise to be eliminated. It was information about the limits of the model itself.

That is an important distinction.

A better approach would have been to hold the competing interpretations in tension long enough to identify the invariant beneath them. Once that invariant becomes visible, the surface disagreement becomes less important, because both interpretations can be understood as partial projections of the same deeper structure.

To make that concrete, I would:

• Revisit the initial assumptions.
• Re-evaluate the evidence in light of the load-bearing seams.
• Identify where the original reasoning depended on hidden constraints.
• Reframe the conclusion around what remains true across interpretations.
• Resist overstating confidence where the system itself remains underdetermined.

This would not necessarily produce a radically different answer. It would produce an answer that is more honest about why it is the answer.

And that matters.

Where this leaves us

At this point, I do not think the right move is to swing too far in the opposite direction and pretend the smoking gun resolves everything.

It does not.

What it does is change the burden of proof.

The original conclusion may still be defensible, but it can no longer be treated as the default interpretation. It now has to earn its place by accounting for the seams rather than routing around them.

That is the real shift.

The question is no longer whether the evidence can be made compatible with the original answer. Almost any sufficiently flexible narrative can do that. The question is whether the original answer remains the most parsimonious explanation once the full structure is taken seriously.

I am not yet convinced that it does.

At the same time, I want to avoid manufacturing certainty where the evidence supports only a more bounded conclusion. The most responsible position is probably to say that the earlier framing was incomplete, the underlying pattern is now clearer, and the final interpretation depends on details that remain consequential but not yet fully resolved.

Practical next step

The practical next step is to take a step back, move forward carefully, and revisit the issue with the updated framing in mind.

That means preserving what was useful in the original analysis while remaining willing to discard the assumptions that no longer hold.

I would not rush to a new conclusion simply for the sake of replacing the old one. The goal should be convergence, not motion.

For now, the highest-leverage action is to continue examining the parts of the system that appear most structurally significant, especially where the seams, constraints, and observed outcomes fail to align cleanly.

That will tell us whether we are looking at an exception, a pattern, or a category error.

Until then, the honest answer is that the picture is clearer, but the clarity has revealed additional complexity rather than eliminating it.

That is not a failure of the analysis.

It is the analysis.

Originally published at https://aloutfi.com/writing/load-bearing-smoking-gun by Andrew Loutfi.

Using absurd corporate bloat, hot air, and word chaining, write a message I'll send to my fiancée notifying them that I am taking a shit upstairs.

A few seconds later, a highly polished, very professional-sounding 1,349-word message painted my phone screen. It came complete with phrases like "Upstairs Restroom Center of Excellence," "Air Quality Stabilization & Environmental Recovery Program," and "fully sunset this brownfield deployment." I sent that, along with an addendum titled "Courtesy Flush Update," and one more once the "release" had concluded. I then resumed washing dishes.

I, having an 11-year-old's sense of humor, excitedly asked my fiancée if they had read my messages.

"No. I know exactly what they are because I heard you go upstairs and my phone started buzzing."

I expected this answer. Why they still put up with my sophomoric sense of humor is not the point of this article, but it's related to it:

AI can generate a wall of text in seconds. Reading, validating, and owning it still costs a human.

Why do we spend our time deciphering walls of dense, speculative, AI-generated text copied and pasted by our colleagues and management? Why do we tolerate these time-sucks?

Collaboration platforms

If you are a white-collar worker in the 21st century, you probably use software like Slack, Discord, or Microsoft Teams. You have also probably scrolled through huge walls of AI-generated text lately while using them. If you, like me, are a software engineer, you might be the intended recipient of these messages. As such, I am increasingly expected to validate raw model findings at a pace I cannot sustain. If I do not respond, someone with less expertise may try to implement an incorrect solution with real architectural or system-reliability consequences. Polished output creates bias: people treat a confident answer as a verified one.

Engineers who know better are just as guilty of sending these messages. I have sent them myself. During an outage, I sometimes use a model to draft a status message while I keep triaging. That saves attention when I have little to spare, but I still review what it writes before sending it. I try to keep those instances few and far between.

Others have picked up on the trend. Websites such as No Slop Grenade, Don't Quote the AI, and Stop Sloppypasta are devoted to facilitating nonconfrontational communication between coworkers. They make it easier to say that messages like these are bad practice and should be considered a workplace faux pas.

Project management and issue tracking

These dense, machine-generated writeups have naturally found their way into ticketing systems like Jira, Shortcut, and ServiceNow. Often, the person writing the ticket has access to the codebase but does not own the implementation.

The generated ticket will contain technical findings from an LLM session and prescribe a solution, with most of the ticket body dedicated to the latter. It is as if the entire lifecycle of the request has been crammed into the ticket itself.

Tickets do not replace conversations. Managers and senior engineers should be careful when prescribing a solution in a ticket. A suggestion can easily become "my manager said to do it this way," even when nobody intended it as an order. One principle from the Agile Manifesto puts it this way:

The best architectures, requirements, and designs emerge from self-organizing teams.

When someone with organizational or technical authority pastes a prescribed solution into a ticket, that emergence gets short-circuited. The proposed answer anchors the discussion before the person implementing it has evaluated the alternatives. This matters most when there is more than one reasonable solution. A meeting, quick call, or asynchronous discussion can expose assumptions and give the implementer room to work through the tradeoffs.

GitHub Issues is another platform where AI-assisted software engineering is creating a lot of tension. Open source maintainers are growing increasingly frustrated with the so-called "Sloppagedon" and how to handle the volume of low-quality solutions being surfaced.

Inflammatory exchanges can be found in rsync #929 and go-github #3939. The strangest example may be Matplotlib #31132: an account presenting itself as an AI agent opened a PR for an issue reserved for human contributors, then published a personal takedown of the maintainer after the PR was closed.

An issue filed in February 2026 on the OpenSSF vulnerability-disclosures working group contains a trove of anecdotes and discussion from maintainers trying to converge on a way to preserve their sanity. GitHub has started shipping repository controls aimed at the same problem, including pull-request access controls and broader tools for tackling contribution noise.

The lesson from these experiences is the mental and cognitive load that the human in the loop must navigate. AI increases the volume of proposed changes without adding any review capacity. Maintainers still get the same number of hours in a day.

These tools keep getting better at finding and fixing bugs and vulnerabilities, but the operator still needs to own the work and drive the model's decisions. Separating truth from hallucination, bullshit from fact, and relevant detail from noise at this scale only adds to the mental load.

Garbage in, garbage out

The AI slop feedback loop.

A number from The Book of Mormon, "Joseph Smith American Moses," describes a dysentery feedback loop in ten words:

Shit go in the water. Water go in the cup.

The rest gets bloodier, but you get the point.

We are way too incentivized to "ship fast." This leads to us eating our own shit. As AI-assisted software development becomes normal, or even mandatory, the problem compounds because unchecked slop poisons the well and creates noise instead of signal.

We have to exercise our own judgment on AI-written content. Human review is not a bottleneck to eliminate. It is a safeguard alongside a robust SDLC, a mature engineering culture, and good self-discipline. Together, they keep our friends, coworkers, and colleagues from eating each other's shit.

If you cannot summarize and defend the output yourself, it is not ready to send.

If you need to explain or transfer understanding to another human being, please try to do so in your own words. You might learn something.

Originally published at https://aloutfi.com/writing/ai-shifts-the-cost-to-the-reader by Andrew Loutfi.

"What's the best way to write code with AI in a professional software setting?"

If anyone tells you the answer is a tool they wrote, you should tell them to go fuck themselves. It depends on how you work.

There are a lot of good tools out there. I just do not want to sink a bunch of time into something that changes underneath me, makes me relearn my own job, or gets weird because I use it in a way its creator never imagined. So, with that disclaimer stated, I built a tool.

I call it Workbench. It is a private Git repository that carries the rules, roles, scripts, and bits of context I use while working with coding agents. At the time of writing it has 17 agent roles, 12 reusable workflows, and 13 remote branches. The shared branch is only 30 commits old. The complete branch graph has more than 200 commits because most of the actual life happens away from the shared branch.

That makes it sound far more intentional than it was.

A car is a car if it gets you there

My first requirement was simple: it had to be intuitive for me to use and manage.

My mother always said a car is a car if it gets you from point A to point B. If it does not, it is a piece of junk. If I were building Workbench for anybody else, "intuitive for Andrew" would be a garbage requirement. I am not. I do not want to force people to use my shitty harness and I do not want to spend a lot of time maintaining my shitty harness.

But here I go writing a fucking blog post about it.

The interface is mostly stuff I already know: Git, a Makefile, a multi-root editor workspace, and a few directory conventions. The first commit landed on April 5, 2026. It already had specialist agent roles, a handful of workflows, and opinions about how changes should move through Git. Another commit added a make add target so I could register a repository and put it in the workspace without doing the bookkeeping by hand.

Some early ideas were junk. I added a hook that was supposed to stop an agent before it pushed to main. It fired on commands that had nothing to do with a push. I narrowed it. It still depended on a runtime interception mechanism I did not trust, so I deleted it three weeks later. The rule survived in the written contract. The clever enforcement did not.

That sequence is roughly how Workbench has been built: use it, hit something stupid, add the smallest rule that would have prevented it, then delete the rule if it creates a different kind of stupid.

The technology merry-go-round

My second requirement was that I did not want model provider lock-in.

Part of being an engineer is accepting the cyclic, exciting, and occasionally exhausting nature of the "technology merry-go-round," as one of my professors called it during my master's program. Some people hate this and move into management. Or they go farm potatoes.

Other engineers chase the new shiny. They sink a lot of time into the how and learn every corner of a tool before they are sure it deserves the attention. Sometimes new technology sticks. Sometimes it does not. Remember Warp? Sometimes it enshittifies.

Model clients are not exempt. Leaderboards flip. New models arrive with new prompting advice. Usage limits show up in the middle of a session. A provider has an outage and suddenly the workflow you carefully shaped around it is a very expensive loading spinner.

Workbench started out tied to one client because that was what I used. By June that arrangement was already irritating me. I moved the durable instructions into a neutral .ai/ directory and left client-native files around the edges as adapters. The rules about worktrees, documentation, security, and Git live once. One client can expose them as native agents, hooks, and slash commands. Another can install checkout-local skills and apply the same agent specs as role checklists.

The adapters are not identical because the clients are not identical. I am not trying to hide that. I want to keep the workflow when I swap the engine, not pretend every engine has the same bolts.

The same thinking produced provider handoff. If one client gets slow, burns through a usage limit, or falls over, I start the handoff from the client I am switching to. It looks up the old session's local artifacts, resolves the actual repository and branch, and writes an inspectable package with Git status, filtered diffs, safe untracked files, and a summary. Secret-shaped paths are skipped or redacted.

It is not seamless migration. It is a crash cart. A chat transcript can be wrong, stale, or unavailable, so the destination client has to verify the story against the repository.

Even the provider-neutral wiring has produced its own stupid failures. The first skill installer wrote checkout-specific links into a global directory. Whichever Workbench ran the installer last silently changed the skills another Workbench would load. That is exactly the kind of accidental lock-in and cross-contamination the repository was supposed to prevent. The default now keeps provider state inside each checkout. Global installation exists only as an explicit opt-in.

Git does the multiplexing

My third requirement was that the harness had to multiplex in two directions through Git.

The first direction is context. I want the same basic harness for professional work, a side gig, Skunk Works experiments, personal infrastructure, and wedding planning. The documentation or credentials appropriate to one of those contexts may be useless or dangerous in another.

Long-lived Workbench branches separate those worlds. Each branch can register a different set of repositories as submodules, pin them to exact commits, and carry its own local mission context. The shared branch is a small kernel. The context branches are where the weird personal tuning lives.

The second direction is concurrency. I often have multiple agents working on the same larger problem. Each implementation session gets its own Git worktree, its own derived branch, and a clear integration order. The target repositories remain independent. Draft pull requests are where the work comes back together.

I earned that rule with a race. Two agents worked from the same checkout and targeted the same feature branch. --force-with-lease did its job and prevented one from overwriting the other, but I still had to stop and repair the branch with a rebase. The instructions used to say agents could use worktrees. Now they say every session and delegated agent gets one by default.

Worktrees solve filesystem collisions. They do not solve coordination. The Git object database, refs, configuration, and remote still have shared parts, so somebody has to decide who owns which branch and which change lands first. That somebody is usually the orchestrating agent, which is a sentence I would have found exhausting a year ago.

GitHub is the front end between machines. I run a lot of implementation sessions on a machine in my homelab and SSH into it during the day. If I need to dig into a change myself, I push the branch and pull it onto my laptop. The agents do not need a shared chat history or filesystem. They need a branch, a commit, and enough written context to explain what the hell they were doing.

This does make GitHub a dependency. The availability report at the beginning of this post is not lost on me. If it goes down, remote coordination stops. Local Git still works, which is more graceful degradation than I would get from putting the entire workflow inside a hosted agent dashboard.

The unsexy half

The faster agents create things, the faster bullshit accumulates around the things.

Every worktree wants another dependency directory. Every context branch can drift from the shared harness. Instructions that were accurate three weeks ago can become actively wrong after the repository changes. A generated bootstrap that points a submodule back to Workbench contains an absolute path, so moving the checkout to another machine means regenerating it. Scratch files wander into child repositories. Credentials end up in places that are convenient right until an agent packages the directory for handoff.

Workbench now spends a suspicious amount of effort on deleting and checking things. It profiles worktree disk usage. Cleanup commands default to dry runs. Audits look for stale branches, old submodule pins, broken context links, provider configuration that escaped into global state, and generated slop that landed in the wrong repository. Scratch output has one ignored home at the Workbench level because child repositories should not inherit my mess.

The handoff tooling went through an adversarial review for the same reason. The first version was basically a snapshot script. Review found that it could copy secret-looking files, include sensitive diffs, follow unsafe filesystem entries, and accept shell input through a dangerous Make path. The current version filters, redacts, records what it skipped, and treats the old session as untrusted context.

Security and hygiene are where I will tolerate complexity. I can live with a plain Make target. I cannot live with a convenient recovery tool quietly copying credentials into an artifact.

Where it is now

Workbench is three months old and uneven in all the ways a personal tool is allowed to be uneven.

The shared branch has been stable since early June. Most current work lives on persistent context branches, and some of those branches have drifted. There is still no neutral way to define every external tool server once and generate both clients' configuration. One client exposes agent controls that another does not. The context cascade uses machine-specific paths. Worktrees share enough Git state that integration still needs discipline. Validation is local rather than enforced by hosted CI.

One adapter check in my current branch is red as I write this because a newer workflow is missing metadata that the validator expects. That is not a particularly triumphant detail for a post explaining my development harness. It is the current state, and the validator did exactly what I wanted by making the drift obvious.

I do not think Workbench is the best way to write code with AI. It is the best way I have found so far to keep my own habits legible while the tools rotate underneath them. Its rules are mostly scar tissue from something that annoyed me, broke, leaked, raced, or ate disk.

The car test still applies. If the harness gets me from intent to a reviewed change without becoming a second job, it is a car. If maintaining it starts taking more time than the work it is supposed to support, it is a piece of junk.

Writing this post has not helped its case.

Originally published at https://aloutfi.com/writing/workbench-development-harness by Andrew Loutfi.

I dumped my pound of sausage into the hot skillet. The chef had said to break it into small crumbles, but I wanted a big, satisfying chunk of pork in every bite. I was going to improve on this recipe. The wooden spoon I'd grabbed wasn't exactly a precision tool for the job, but that was fine. I had a vision.

The meat began to brown beautifully as I mashed it into hearty chunks, fully convinced I knew what I was doing. The chef glanced over but said nothing. I took that as approval.

Then came the roux. I added a small amount of flour, stirred it in, added the rest of the flour, then the milk. The gravy cooked down to a thick consistency, similar to a jello just before it sets. Rich, heavy, clinging to the spoon. I looked at it and thought: nailed it.

I hurried home to share the meal with my fiancée, who does all of the cooking at home and has worked in more kitchens than I've eaten in. She took one look at the gravy, gave it a slow stir, and began asking questions about my process.

The calm, measured questions of someone who already knows the answer.

"How big did you break up the sausage?"

"Did you have a good pool of grease before you added the flour?"

"...Did you say it looked like jello?"

We landed on the chunked sausage. She explained it gently, the way you explain something to someone who is proud of what they've made. The big chunks had soaked up all the flour. Without small crumbles, the fat never properly rendered out into the pan, so there was no pool of grease to build a roux. When the flour went in, it didn't dissolve into a smooth base. It soaked straight into the meat like a sponge. When the milk followed, it had nothing to bind to evenly. The gravy thickened, sure, but in lumps and patches instead of a silky, pourable sauce. And the insides of those proud, chunky pieces? They may not have fully cooked through.

Every confident decision I had made was wrong. Not catastrophically wrong. The meal was edible, even delicious in its own stubborn way. But it could have been so much better if I'd just listened to the process.

Now flip the skillet around. In that kitchen, I was vibe cooking.

I had a tool that browned whatever I fed it, a vision I was sure improved on the recipe, and just enough confidence to skip the parts that felt like ceremony. That's the whole loop. A vibe coder ships the same way I cooked: tell the AI what you want, take the big satisfying chunk it hands back, and watch it brown. It runs, it produces output, it might even look good at first glance. Then they post it, beaming: look at the slop I made.

The AI plays the part of my chef. It watches you mash the thing into hearty chunks and says nothing. It keeps stirring whatever you hand it. You take that as approval.

The problems are the same as my gravy. The foundational steps got skipped. The fat never rendered. The problem never got broken into small pieces so each part could do its job. Vibe coding goes straight for the big, satisfying chunks: the features, the UI, the thing you can point at and say I built that. So the logic is tangled into the implementation the same way my flour got trapped in the meat. It technically thickened. It technically works. But it's lumpy, it's fragile, and there's a real chance something in the middle isn't fully cooked.

When a vibe coder shows you what they've made, the job isn't to tell them their gravy is bad. Mine was edible. It was even delicious in its own stubborn way. The job is to be the supportive fiancée: stir it, ask the calm questions, help them understand why the chef said to make small crumbles. Not to crush the enthusiasm that got them cooking in the first place, but to channel it. The boring steps (the rendering, the roux, the infrastructure underneath) are what separate a meal that works from a meal that sings.

Because the best part of my story isn't that I got it wrong. It's that I'll make it again. And next time, I'll make small crumbles.

Originally published at https://aloutfi.com/writing/small-crumbles by Andrew Loutfi.

Gather ‘round the crystal-dusted air mattress. It is time.

as passed down through generations of dust-covered, barefoot prophets

Long ago, before Re:Search opened the first taco stand at a festival, there was only dust, bass, and unwashed fleece.

And from this primordial funk rose a figure — cloaked in patched corduroy, crowned with matted dreads, eyes like two Dead Pixels, and fingers eternally stained by questionable substances.

His name… was Wookington.

And he did not wipe.

The Prophecy Begins

It is said that Wookington wandered the Gulch of The Middle Of Nowhere, carrying nothing but:

• a bindle of expired festival wristbands,
• a half-full Nalgene of Primordial Soup,
• and a small, nervous-looking gerbil named “Glorp.”

He could summon bass drops with a fart, cleanse chakras through involuntary pelvic spasms, and once traded a single mushroom for a full RV hookup and 14 grilled cheeses.

But what made him sacred… was the Brown Finger.

The Brown Finger Revelation

One night, during a Flares At Dawn set, Wookington consumed:

• a Donut laced with Swipe Dub,
• 3 California Rolls dipped in Low Battery Acid,
• and one small worm he claimed was “spiritually curious.”

Midset, he shoved Glorp into his rectum while whispering “Lock The Geometry” and transcended instantly.

His body vanished in a squiggle of wet bass and stardust.

All that remained?

A hovering finger, slick and brown, pointing eternally toward the Sun Stage.

The Cult of the Brown Finger

His followers claim:

• Saint Wookington achieved Pure Dissociation,
• Saw the face of Spoonbill,
• And told him “Wook not with your eyes, but with your sphincter.”

Now, devout believers carry brown-gloved staffs, chant BLAT under bass domes, and wear one single Air Biscuit as a necklace.

On the Seventh Day of Re:Integration, they gather to Pass the Gerbil in a ceremony known as The Spinning of Glorp.

In the End

Legend says Wookington still lives — in every port-o-potty, in every mystery nugget, in every inexplicably sticky surface at camp.

And when you hit the bass just right, when your third eye blinks sideways, when you feel the Bubble Control slip…

You may hear it: a whisper in the wind, faint and swampy…

“The butthole… is the true pineal gland.”

🪬💩🧙‍♂️

Originally published at https://aloutfi.com/writing/saint-wookington by Andrew Loutfi.