We're in the jQuery Era of AI
The argument about code quality is downstream of the real shift. The job changed.

I keep scrolling past the same argument on LinkedIn.
One camp says AI is destroying code quality. They post screenshots of obvious slop — repeated boilerplate, hallucinated APIs, confidently wrong syntax — and ask if this is what the future of engineering looks like. The other camp says AI is the best thing that's happened to development in a decade. They post throughput stories — features shipped in an afternoon, side projects built over a weekend, codebases cleaned up faster than ever before.
Both camps are right about what they're seeing. Junior developers are shipping slop. Senior engineers are shipping more, faster, and better than they used to. Same tool, opposite outcomes.
Meanwhile I've been doing something I didn't quite expect. I'm shipping side projects in stacks I would not have touched a year ago. I'm not a Rust developer. I'm not a Go developer. I'm not really anything anymore in the old "what's your stack" sense. The work just gets done.
So I've been thinking about why both LinkedIn camps are looking at the same thing and seeing opposite stories. And I think they're both watching the wrong thing.
The argument about code quality is downstream. The real shift is that we don't write code anymore — we engineer the AI that writes it. Our job is the harness.
The Shift No One's Naming
Let me say what I mean.
The slop is real. I'm not arguing it isn't. But the cause isn't AI. The cause is that most people are handing AI a broad prompt and letting it do whatever it wants.
Garbage in, garbage out. That's the oldest rule in computing. AI didn't break it. AI just made the rule visible at a scale we hadn't seen before, because the cost of asking dropped to nearly zero.
Here's the shift. The job is no longer writing code. The job is:
- Defining what you want.
- Building the system that verifies AI delivered it.
- Managing that system as AI keeps improving.
That's the harness. Specs the model can read. Tests it can run. Feedback loops it can close. Guardrails it can't escape. When you build that right, code quality stops being a coin flip. It becomes an emergent property of how well you defined the work.
I've written about the practice in Harness Engineering. I've written about the feedback-loop pattern in The Ralph Wiggum Loop in Production. What I haven't said out loud — the thing those posts assume but don't argue — is the why.
The why is this:
Good developers aren't shipping better code because they're better at AI. They're shipping better code because they're better at telling AI what they want and checking that it did.
That's the whole game. The juniors shipping slop aren't bad at coding. They're bad at specifying. They're handing AI a vague request and trusting the output. The seniors shipping clean code aren't better at prompting — they're better at constraining. They wrote the spec. They built the test. They closed the loop. The AI executed inside a frame that made it hard to fail.
Same tool. Different harness. Different outcome.
If you take nothing else from this post, take this: when AI ships bad code, look at the harness first.
The Language-Agnostic Side Effect
Something I noticed once I started thinking this way: the output language matters less than it used to.
Once your job is the harness, the harness travels. The same patterns work whether AI is shipping Rust, C, Python, or assembly. Define the work. Test the output. Iterate. The harness doesn't care what language is inside it.
I've spent my working life crossing trades — auto body, mechanical engineering, machining, sales, software. Every switch meant learning a new language from scratch. The skills carried over but the vocabulary didn't. I had to start over each time.
AI made that flexibility true at the code level too. I'm not a Rust developer or a Go developer or a C developer. I'm an engineer who builds the system around whatever the AI ships. I haven't built everything. But I feel more confident than ever that I could figure out whatever I needed to.
That's the part that's hard to explain to people who haven't felt it yet. It's not that I know more. It's that the activation cost of trying dropped to nearly nothing. When the cost of trying is low enough, you just try.
We've Been Here Before
The thing that helps me stay calm about all of this is that we've lived this pattern before.
When jQuery came out, it democratized the web. Suddenly anyone could make a page do things. Animations, AJAX requests, DOM manipulation that used to require knowing the difference between three browsers' quirks — all of it became a one-liner. The barrier collapsed.
And the web got worse before it got better.
Copy-pasted spaghetti. Plugins on top of plugins. Code nobody could maintain. JavaScript files that grew to ten thousand lines because nobody knew how to organize them. People who had no business shipping production code were shipping production code, and the web reflected it.
Then better tools came out of the chaos. React. TypeScript. Build pipelines. Component libraries. The ecosystem matured around the mess. The spaghetti era ended — not because people got better at writing code, but because the tools made it harder to write the bad version.
That's where we are now with AI. Everyone can ship. The output is messy. People who shouldn't be shipping production code are shipping production code, and the codebases reflect it.
This is the same thing as the jQuery days, just in a new context. We've been here before. The pattern says we come out the other side. Better tools will emerge. The ecosystem will mature. The harnesses I'm writing about today will become standard practice — boring, taken for granted, the default way to work — and the slop era will look the way the jQuery era looks now. A phase we passed through.
What This Means for Developers
So here's what I'd say to the developers arguing about code quality on LinkedIn:
Stop. The argument is downstream of the real lever. The real lever is the harness. Define what you want. Build the system that verifies AI delivered it. Manage it as AI gets better. That's the work.
The short term is going to be weird. Smaller companies will ship things that used to require entire teams. Better products will come out of three-person shops. Worse products will come out of the same shops next door, because the tools that empower experienced engineers also empower people who shouldn't be shipping. That asymmetry resolves the way it always has — through tooling, discipline, and time.
The long term is interesting. Most of the work won't be writing code. Most of the work will be designing the conditions under which AI writes the right code. That's a real craft. It rewards the same skills the best engineers have always had — clarity about requirements, taste in design, discipline in verification. It just expresses them differently.
The developers arguing about code quality are arguing about the wrong thing. The job changed. We're not coders anymore — we're engineers of the systems that let AI ship reliably. The sooner you realize that, the sooner you stop being surprised by the slop and start building past it.
If you're somewhere in this transition — building harnesses, shipping in languages you didn't think you'd touch, or watching the LinkedIn argument go in circles — I'd genuinely like to hear what you're seeing.
— Bill John Tran