Do you ever get tired of playing this “visibility,” “impact,” “promo politics” game and think, “I came into this industry because I like computers, not… whatever this is”?
1,910 karma · joined June 2, 2019
Plus the JS/Python dependency ecosystem is tiring. Yeah, I know there’s uv now, but even then I don’t see much reason to suffer through that when opting for an actually type-safe language costs me almost nothing.
Dynamic languages won’t go anywhere, but Go/Rust will eat up a pretty big chunk of the pie.
Go is positioned really well here, and Steve Yegge wrote a piece on why. The language is fast, less bloated than Python/TS, and less dogmatic than Java/Kotlin. LLMs can go wham with Go and the compiler will catch most of the obvious bugs. Faster compilation means you can iterate through a process pretty quickly.
Also, if I need abstraction that’s hard to achieve in Go, then it better be zero-cost like Rust. I don’t write Python for anything these days. I mean, why bother with uv, pip, ty, mypy, ruff, black, and whatever else when the Go compiler and the standard tooling work better than that decrepit Python tooling? And it costs almost nothing to make my scripts faster too.
I don’t yet know how I feel about Rust since LLMs still aren’t super good with it, but with Go, agentic coding is far more pleasurable and safer than Python/TS.
Popular music tends to be generic. Popular content is mostly brainrot these days. Popular software is often a bloated mess because most users’ lives don’t revolve around software. They use software to get something done and move on.
I never understood the appeal of “craft” in software. Early computer pioneers were extremely limited by the tech of their time, so the software they hacked together felt artsy and crafty. Modern software feels industrial because it is industrial - it’s built in software factories.
Industrial software engineers don’t get paid to do art. There are research groups that do moonshot experiments, and you can be part of that if it’s your thing. But lamenting the lack of craft in industrial software is kind of pointless. Imagine if we’d stopped at crafty, handmade auto engines and never mass-produced them at scale. We don’t lament “crafty engines” anymore. If you want that, go buy a supercar.
Point is: AI is just another tool in the toolbox. It’s like Bash, except calling it that won’t pull in billions of dollars in investment. So “visionaries” call it ghost in the machine, singularity, overlord, and whatnot. It produces mediocre work and saves time writing proletariat software that powers the world. Crafty code doesn’t pay the bills.
But I’m not saying we shouldn’t seek out fun in computing. We absolutely should. It’s just that criticizing AI for not being able to produce art is an old thing. The goalpost keeps shifting, and these tools keep crushing it.
I don’t use AI to produce craft, because I don’t really do craft in software - I have other hobbies for that. But I absolutely, proudly use it to generate mediocre code that touches millions of people’s lives in some way.
I replaced a whole bunch of these with one shot prompts for shits and giggles.
Students would often abuse it since there’s no adult in the room to teach them how to behave. I guess this is one hard way to f around and find out. But this is by no means condoning this sort of behavior.
Point is, LLMs made the situation more dire: it’s cheap to generate code, whereas reviewing still scales sublinearly. The only way to prevent this is by being rude to people who are rude to you.
A lot of energy is being spent on making reviews faster, when reviews are intentionally meant to scale sublinearly. The goal should be: how can we make the process more convenient and less error-prone?
Code review is the last line of defense we have against our systems being invaded by the massive amount of slop that’s getting generated left and right.
Instead of trying to automate the code review process, maybe we should spend more energy on making the scaffolding around it better: better diff tools, semantically grouped files (as Devin mentioned), and better UI for large diffs (GitHub’s UI is horrible for anything beyond a thousand lines).
Code review is the only thing that has kept this house of cards from falling over. So undermining its importance makes me question the hype around LLM tooling even more. I’ve been using these tools since their inception as well, but with AI tooling, we need to hold on to the best practices we’ve built over the last 50 years even more, instead of trying to reinvent the wheel in the name of “rethinking.”
Code generation is cheap, and reviews are getting more and more expensive. If you don’t know what you generated, and your team doesn’t know either because they just rubber-stamped the code since you used AI review, then no one has a proper mental model of what the code actually does.
So when things come crashing down in production, debugging and investigation will be a nightmare. We’re already seeing scenarios where on-call has no idea what’s going on with a system, so they page the SME—and apparently the SME is AI, and the person who did the work also has no idea what’s going on.
Until omniscient AI can do the debugging as well, we need to focus on how we keep practicing the things we’ve organically developed over such a long time, instead of discarding them.
No matter how much progress we make, as long as reasoning about complex systems is unavoidable, this doesn’t change. We don’t always know what we want, and we can’t always articulate it clearly.
So people building software end up dealing with two problems at once. One is grappling with the intrinsic, irreducible complexity of the system. The other is trying to read the minds of unreliable narrators, including leadership and themselves.
Tools help with the mechanical parts of the job, but they don’t remove the thinking and understanding bottleneck. And since the incentives of leadership, investors, and the people doing the actual work don’t line up, a tug-of-war is the most predictable outcome.
It’s better to be on top of the interface than the implementation. But at the same time, brittle systems caused by overly rigid interfaces are a real thing. In that case, interface exploration can be done by a human with assistance from LLMs, but allowing an LLM to arbitrarily explore and make changes to the interface sounds like a recipe for disaster.
On top of that, Hyrum’s law doesn’t go away just because your software has explicit contracts. In my experience, as more people start losing their agency over the code they generate, the system accumulates implicit cruft over time and other code starts depending on it.
Also, reliability is a reasoning problem. So operational excellence becomes scrappy with this way of working. It works for some software, but I don’t know whether this push to YOLO it is actually a good thing. C-levels are putting immense pressure in many big companies for everyone to adopt these tools and magically increase productivity while decreasing headcount to please investors. Not going too well so far.
A good interface doesn’t magically make vibe-coded implementations with little oversight usable. Rewriting it over and over again in the same manner and expecting improvement is not the kind of engineering I want to do.
Also, weird, seems like I don't see the encoding issue on the segal's law.
Yeah, the idea was that since RSS is still considered niche by the broader audience, those who are looking for it will probably find it just fine.