rDr4g0n

AI tech is hitting our lives harder and faster than any tech before, and this has social and psychological side effects. society at large will struggle to recognize this, much less find healthy andeffective ways to adapt.

the erosion of trust will be socially catastrophic.

remember a time where you might admire a photo not just for its beauty, but for the good luck and skill of the photographer who captured it?

photoshop made us skeptical about truth, but AI will simply make it hopeless to ascertain truth.

note that i use AI extensively. i am hyper aware of the way it has impacted me, my peers, and my career, and im deeply concerned about how it will impact everyone as it is increasingly made "non-optional" by the rich and greedy who stand to benefit most from it.

my technique to get a similar benefit is to write a quality PR description.

a good PR description should be compact and helpful. describing something complex in a compact and approachable way requires understanding.

the process of writing the description often leads me to understand hidden decisions the LLM made and occasionally uncovers bugs.

my PR descriptions separately answer the following questions:

Why is this change being made? a sentence or two about the problem, objective, etc, and a link to more detail (tickets, docs, etc) if available

What does this change accomplish? typically describes observable changes, requirements, etc. crucially this section avoids describing how the change is implemented. the act of separating what from how isn't new, but it's crucial in the LLM era

How does this change accomplish its goal? the answer to this question is "read the code", but the job of a PR description is to provide a quick hand drawn map before dumping the reviewer into the jungle. drawing a good "how" map requires understanding the jungle and the new path through it.

the risk with LLMs (or any outsource) doing the work is the loss of understanding. this exercise encourages understanding.

seasoned software engineers are experimenting with using AI to ship actually maintainable software with varying degrees of success (i am doing it, my peers are doing it. it actually can work. it requires immense budget and organizational support for experimentation)

patterns and best practices will emerge. old stuff will be rediscovered. some hard earned wisdom and knowledge will become obsolete while other hard earned wisdom and knowledge will be more valuable than ever.

some good "traditional" software engineers make terrible "AI-engineers" (or whatever the term will be) and will either grow and learn, try to fake it as long as they can, or leave.

lots of us will leave the industry because we're tired. we don't want this new thing. our work was fulfilling because reading and writing helped us learn and grow and become better. asking an LLM to "figure it out" followed by "ok, do it" (or, if you're company is actually funding you, creating loops that do that) robs you of the joy you used to feel.

we will realize that our passion and pride in our work was not really valued by employers. the value was us shipping shit that generates revenue for them.

the interview treadmill is fucking soul crushing.

we will leave and take 75% pay cuts. but our mindspace will belong to us again. we will struggle, but we will be happier.

This essay has nothing to say about LLMs (or "AI technology" as it calls it for simplicity), so yes "fear of AI" is ruled out.

But its core assertion is that AI companies intend to lock down control of LLMs through market forces, legislation, and cronyism, to ensure humans can only use them through the AI company walled garden. They want to control the tech, not permit the people to use it freely.

The goal is to stop the walled garden from forming, not to stop LLMs. Yes governments and good humans and bad humans will all use LLMs and cause harm, but LLMs are out and can't be undone. That's another topic, people argue endlessly over that topic already. im not weighing in there with this essay.

This essay says "hey, these companies are literally refining a product that is rental replacement versions of your job, and greedy ass business owners are definitely going to pay rent instead of pay you."

that should be terrifying to ALL of us. Its just software engineers being hit first, but that is because software is easily verifiable (verifiability being a significant requirement for today's LLMs to succeed).

regarding addiction, the government steps in to create laws around addictive substances, but it takes a LONG time for that to happen. ever heard of "gas station drugs"? the government cant keep up. social media companies have fucked us all over by deliberately refining their products for addiction (they call it engagement), and they're just now being tried for some of the harm. 10 years later.

AI is coming so fucking fast that our already weak and barely competent policy makers have no hope of keeping up. AI slop applies to policy too.

There should be fucking alarm bells ringing everywhere. regulatory capture and cronyism at AI speed is a new fucking threat to humanity, and were all just like ok with it? were arguing about tractors and how people have the right to make their own choices?

if my essay was too soft that is my fault. im a new writer and i failed to communicate my thesis well.

but the message i meant to portray is that AI wont kill people, but fucking AI companies will destroy humanity so they can get paid, and they have a unique and new tool that we as a species barely understand, and cannot defend against, and theyre charging the giant fucking deathstar up right the fuck now and pointing it directly at each and every one of us, and no one seems to give a shit.

thank you for sharing. im planning to leave software for the same reasons.

were you able to reclaim the space in your head that your software salary took away? like, are things clearer? do you feel like you "own" your thoughts and brainpower again? do you have more mental energy at the end of the day to pursue your own interests?

if i take a 75% pay cut, i really hope i can have my brain back again.

literally three principle engineers i know have done or are doing this. im planning to leave software entirely which is insane, but it has been making more and more sense for me personally.

i cant help but think there will be a mini exodus from big software companies, and im curious what thatll do to the industry.

i hope we are able to work through the problems of LLMs together as workers who own and control our tools, not as victims of a new predatory industry which locks the tools away in a walled garden they control and we pay rent to.

farmers had control of their tractors taken away from them but they were able to wrestle some of it back just a few years ago, so there is hope. it just seems unwise to wait and fight the AI companies after they have locked us out and ensured self hosted AI is regulated to uselessness.

thanks for the validation

i did touch only lightly on it with "Boycott their customers.". i had written a whole thing about greed and "the greedy men who profit by using AI to replace humans", but it seemed to muddle the focus on the peddlers of the product.

ill find a way to write more about the greed that motivates business owners to choose AI over humans. they certainly deserve to be called out.

thanks for the follow up. the much harder and more subtle bit i chose to only allude to in the essay is the idea of self hosting. using and controlling your own LLMs is how AI becomes a tool to empower humans.

locking LLM access behind a walled garden is how they serve as a means of profit and control, reserved for the "dont be evil" tech leaders.

i thought i hit on what you call "sanctity of human thought", but i suppose not. i believe that we individuals as a continuous thread of decisions and consequences and experience, are made "real" because of this. LLMs may have incredible breadth of knowledge (never mind the legitimacy of ther training corpus), but knowledge without experience is, well, academic. not real.

my next essays could touch any of these topics and many more which keep me up at night, and your suggestions are helpful.

i was worried an appeal to non-technical folks (i avoided even invoking the name "LLM" to avoid confusion) might be a little basic for the HN crowd, but honestly im not on any social media and I really just have this place to post stuff. I tried reddit but good lord lol

it may not land for you, but hopefully itll land for others. im just fucking tired and trying to do what i can out here.

i am interested in your suggestion to argue harder for what I feel we have lost. any ideas around that youd like to share?

perhaps the bigger issue is not the tech, but the force that propels it forward with little concern for the harm it inflicts. Amodei's own words:

> A race to the bottom, spurred by commercial incentives

Social media and big data minted a new scale of "race to the bottom". AI is an exponential step up in the tools for extracting value at scale.

Greed has been around since the beginning, but never so well supported and empowered as it is today.

If Amodei is still human, perhaps he will put his money where his mouth is and attack the source of the perverse incentive. Winning the battle is not the point. The point is to signal to policy-makers and the public that we should not assume corporate revenue-seeking preempts all.

Then again, Anthropic has a board and an upcoming IPO, so guess who's all talk and no meaningful action...

History has a lot to say about the ruling class benefitting from (and ensuring?) the working class cannot organize, because that is exactly when the workers have leverage.

workers that feel powerless and dont try to resist is great news for rulers who only serve to generate revenue.

AI is big data. AI companies generate the big data from obscene volumes of materials they did not produce. then they charge rent for access.

legally i have no fucking clue, but morally, this is stealing humanity to produce a profit.

realistically the toothpaste is outta the tube, so the second best option is accept LLMs, but do not enrich AI companies.

a teammate who exclusively writes slop PRs and copy/paste LLM responses to slack has demonstrated they can be replaced by an LLM integration to slack and github.

also, take some fucking pride in your work.

when llms write all the code, all we have left are the specs. ive found a lot of success applying software engineering discipline to spec writing and making it a human-only activity. from there hand the spec to LLM with a few guardrails around implemention and writing quality tests that prove the spec.

PRs review more quickly when you have human written spec diffs to orient you and guide (or skip) the code review.

a danger to avoid is writing specs which are basically just really bad code (prose is terrible code). you can work towards patterns to avoid this pitfall.

also, dont coflate spec with plan. spec is durable decisions. plan is execution to turn decisions into code. plan is disposable, dont check it in.

either way, find the human layer and dont use LLMs there. make all the important decisions in the spec, delegate the other decisions to the LLM.

i believe this is the new craft.

that said, i expect a small but significant exodus from software. a lotta folks came for the "programming" that is now being outsourced. were becoming so tired, just absolutely burning out.

i hope we will eventually realize its time to go, instead of giving up our souls for a fucking paycheck.

we can all debate the finer points but in any case "resist" is exactly the right message.

AI companies are racing to build empires on products built on the whole of human writing, charging rent to access it, then leveraging their scale to improve the model.

the big data era was a gold rush for greed. the AI era is has upgraded to a warp engine for greed.

the harms and manipulation of social media took ages to enter the social discourse, and are just now turning into legal action.

AIs warp-engine speed guarantees greed will fuel warp-engine scale harm before society catches up, and before America's greedy ass politicians are cornered into trying to do something.

resist fucking greed. if you gotta use LLMs, at least don't pay an AI company.

updated the comment. i meant four "concepts". i dont reason about my own thinking in terms of parameters.

LLMs can't "read the room" and infer how much context the audience already has, so they try include everything.

human conceptual thinking is very much a multi-dimensional graph, which relies on light "approximate" concepts that are "good enough". LLM AR token generation is extremely one dimensional and doesnt care about the "weight" of the concept behind a token.

LLMs hold billions of parameters in "mind" at once. humans hold like four "concepts".

This is the essential mismatch and the primary reason LLM conversation can be so painful and exhausting.

Explaining this and limiting "concepts" to four at a time tops is one of the very few AGENTS.md / system prompts I always use, and it has proven invaluable time and again.

Thinking traces show how effective this is at forcing the LLM to simplify its thinking.

[edit] Also, myself and nearly all of my peers are struggling to choke down the flaws of LLM tooling along with the benefits. the speed at which LLM adoption is being forced, without truly crafting them into quality tools first, is not ok, and not normal.

LLMs have stirred an inhumane hunger and fear. the tech is fine, but the way tech companies (creators and consumers) are behaving should be deeply questioned.

it's NOT normal. it's not ok.

"software engineer" covers a wide range of responsibilities. some engineers spend all their time contributing to the physics in a massive graphics engine. some spend most of their time as the sole maintainer of a web api that mostly plumbs together a bunch of services and provide data to UIs. some are frequently spitting out new services while other are maintaining 10 year old legacy codebases. the work we need to do, the tradeoffs we need to make, its just so vast.

now couple that with the wide range of variety (and dysfunction) that come from the business and organization. being a dev for a company which sells software is a whole different beast than being an in-house dev for a company which sells other products. startup, big org, old org, new org, strike team, the list goes on.

finally, engineers enjoy different aspects of building software more than others. the puzzle, the crafting, the api, the data structure, the architecture, solving end user needs, so many facets to what makes it enjoyable as a career.

this is a big reason why ai discourse online is so uneven and often unhelpful. were all assuming too much about what being a software engineer is; forgetting that my day-to-day can be wildly different than yours.

a lot of ai speedup comes from effective delegation of work. i do it, but i don't like it. it actively makes me feel tired in a way i don't feel when i do the work myself, or when i mentor and grow my team to do the work.

many other devs don't feel the way i do. some suddenly have these ai tools that make them feel more empowered and energized and excited.

llm's are genuinely a new computing paradigm because of their nature: plain human language as the interface. this is different enough that mapping our past computing concepts (like the evolution from assembly to C) may not hold as well as seem they should.

this all digs deep into who we are as individuals with specific desires, career history, goals, a specific role at a specific company. the part that's fucking beautiful and unique and human.

But if the aggressive industry-wide layoffs aren't enough of a clue, these giant ass companies (and the ai gatekeepers driving this shift) are not compatible with individual humans.

i dont mind llms as a tool, but im done with the perverse level of greed and inhumanity they seem to inspire in corporate leaders.

around my workplace we say if you're copy/pasting llm output, you're indicating an llm can do your job.

when you outsource thinking to AI, you get that magical speed up. the agent is making decisions for you, so things move at agent speed. it often makes decisions without telling you, and the final "here's the plan" output often requires you to understand the problem at great depth, which requires return to human speed, so you skim and just approve.

the trick is to be mindful, aware, and deliberate about what decisions are being outsourced. this requires slowing down, losing that absurd 10x vibe coding gain. in exchange, youre more "in-the-loop" and accumulate less cognitive debt.

find ways to let the agent make the boring decisions, like how to loop over some array, or how to adapt the output of one call into the input of another.

make the real decisions ahead of time. encode them into specs. define boundaries, apis, key data structures. identify systems and responsibilities. explicitly enumerate error handling. set hard constraints around security and PII.

tell the agent to halt on ambiguity.

a good engineer will get a 2x or 3x speedup without the downsides.

this is exactly what is happening. instead of building true AI culture around thoughtful adoption of AI strengths while defending against weaknesses, they're coming up with bullshit heuristics like "every repo has a CLAUDE.md", watching private token usage dashboards, and terrorizing everyone into doing it (or lose your job).

this leads to naive AI adoption, which is the worst of both worlds (no real speedup, out sourcing thinking, ai slop PRs, skill rot).

this author suggest its essentially the same risk https://www.poppastring.com/blog/what-we-lost-the-last-time-.... i feel its heightened because execs and leaders are absolutely salivating over the opportunity to fire thousands of humans with no regard for the cognitive debt that comes from outsourcing thinking to ai.

i love my 2x gains, still hands-on with problem, not losing context, not outsourcing thinking. just automating the boring parts.

apologies, usually I delete these kinda rants, but a combination of whiskey, skittles, and ai brain fry is telling me to leave this one up.

hey yall, try writing a few specs at the component/module/package level. define the api contract, types/interfaces, dependencies, package behavior. effectively do the same work you do writing code, but with a layer of "behavior statements" instead of code blocks.

define observable behaviors, let codegen workout most of the rest by implementing the contract.

decompose specs into proper units (a hundred lines or so), not god-awful, unreadable, vibe-coded, frankenstein documents. follow the software engineering best practices you've honed for the last 25 years.

you end up slowing down, sitting in the problem, figuring out "the right problem to solve", all the benefits of writing the code. but now you have a spec to iterate on, and the behavior statements in the spec generate code and tests from a single source of truth (each statement a provable assertion).

as bugs arise, trace back to the spec. changes often end up being a single line of text in the spec which cascades into an easy to review diff plus tests.

spec prose allows writing "why" and "how" together without code comments which go stale.

and lean on your type system to leverage opportunities to be terse, creating a spec which has fewer words, yet still produces strong correctness guarantees (aka, the spec can be shorter than the code, and still be readable).

bonus: versioning a spec is easy, so now you have a change signal when reviewing your peer's code changes. be more careful with major/minor bumps, skim patch bumps.

while many of my peers are taking the giant-ass sdd approach, shipping fast, and losing touch with the actual system behavior, ive been taking the approach outlined above with a modest 2x speedup in feature delivery (their speedup appears much larger), without losing touch with the underlying system.

i am working on large, complex, overgrown, legacy code, so i dont have the luxury of floating in a vibe coding cloud, miles above the scary jungle and tigers and lava and spike traps that i call home.

ive found this approach to be a brilliant balance of speed, incremental AI opt-in, hands-on to avoid context loss, and most importantly to me: maintainability.

i suspect a subset of "proper" ai-codegen software engineer tooling and flows will settle in this vicinity.

encourage folks to swiftly vibe-code prototypes, but then from there, let software engineers do what we do best: engineer software, and transform the protoypes into something maintainable.

Who contributed their work to open source (as a gift) with the expectation that their contribution would eventually be ground into a paste, fully stripped of attribution, and sold as a service?

Maybe something has materially changed?

It's much easier to fire an employee which produces low quality/effort work than to convince leadership to fire Claude.

When I began reviewing my teammate’s PRs with AI generated code in it, something started to feel weird. It took a bit, but I realized the problem: I am not reviewing the work my teammate did.

What are they even supposed to do with feedback on the code? It has to be translated by my teammate into the language of the work they did, which is the conversation they had with the AI agent.

But the conversation isn't the "real work": the decisions made in the conversation are the real work. That is what needs capture and review.

So now I know why code reviews are kinda wrong, what can we do to have meaningful reviews of the work my teammates have done?

What I landed on is aiming to capture more and more “work” in the form of a spec, review the spec, ignore the code. this isn't novel or interesting. HOWEVER...

For the large, messy, legacy codebases I work in today, I don’t like the giant spec driven development approach that is most popular today. It’s too risky to solely trust the spec because it touches so much messy code with so many gotchas. However, with the rate of AI generated code rolling in, I simply can’t switch context quickly enough to review it all efficiently. Also, it’s exhausting.

The approach I have been refining is defining very small modules (think a class or meaningful collection of utils) with a spec and a concise set of unit tests, generating code from the spec, then not reading or editing the generated code.

Any changes to the code must be made to the spec, and the code re-generated. This puts the PR conversation in the right place, against the work I have done: which is write the spec.

So far the approach has worked for replacing simple code (eg: a nestjs service that has a handful of public methods, a bit of business logic, and a few API client calls). PRs usually have a handful of lines of glue code to review, but the rest are specs (and a selection of “trust” unit tests) and the idea is that the code can be skipped.

AI review bots still review the PR and comment around code quality and potential security concerns, which I then translate into updates to the spec.

I find this to be a good step towards the codegen future without totally handing over my (very messy and not very agent friendly) codebases.

I see quite a few comments about how this is nothing new and it's easy to catch scammers, etc, etc.

Scamming may not be new, but a person using AI in this way is able to penetrate quite deeply into (long, tedious, time-consuming) interview process if folks aren't keeping an eye out for it (and this article, like many personal experiences, indicate that people aren't yet). Having an AI voice in your ear, rapidly providing you answers in real time is something new; at least in terms of how easily accessible it is.

It's amazing to me that folks have the audacity to come to interviews like this. I think some candidates genuinely feel that it is a reasonable thing to do along the lines of stuffing their resumes with keywords to get through the various recruiter filters. It's like hey, everyone in baseball is doping, so I have to do it to keep up!

The behaviors are obvious once you've seen them before, but as an engineer and not a "talent acquisition" person, I feel deeply uncomfortable implying that some candidate I'm interviewing is lying or cheating, so it took me a bit to speak up about it.

These types of articles need to continue to come out and the conversation elevated, if just to save some poor devs hours of interviews with candidates who were able to bluff their way through the less technical initial conversations.