Infinite Velocity
What if your organization were finally able to deliver anything it wanted, as fast as it could imagine it?
Wish Granted.
Let’s imagine we exist in the Sweet Spot world.
Many of these may not be actually true, but in order to present the hypothetical argument I’m about to make, let’s imagine that they are, in fact, true:
- LLMs are just smart enough to help people do their jobs without replacing them entirely.
- LLMs are so smart that they are able to confidently do most jobs very quickly with minimal supervision (while at the same time leaving that first bullet point also true).
- Using exclusively LLMs as your work tool of choice for long stretches of time does not gradually erode your ability to empathize with other human beings or make good decisions about software.
- The people who build and sell LLM tools have humanity’s best interests in mind and will continue to be exactly this altruistic for the foreseeable future.
- The environment and economy hold fast. A vibrant middle class remains, the economy booms, maintaining a large consumer base to support further growth across every technological field.
- We don’t experience a butlerian jihad or any other large social (sidenote: I had to delete a whole multi-paragraph tirade, here, deleting a bunch of words like “robber baron capitalism”, “guillotine”, and “a small valley filled with some of the worst people I’ve ever met”, I don’t need to rehash this topic, I’m sure you’ve seen plenty of it.) .
Okay, so, that may seem laughably optimistic as an outcome, but here we are. The ideal future.
Anyone can talk to the LLM until a patch is fully formed, and your LLM-augmented senior developers can tinker with, deeply analyze and approve those ideas in minutes.
Gone are the sad days where engineers are delivering a paltry PR per day. Your best engineers are spending all of their time using their LLM-augmented intuition to rapidly push four, five - nay, dozens of patches a day, directly into production.
Engineering is now free, or effectively free.
After that, you quickly discover that the barriers to shipping at the speed of thought are not just engineering barriers: they’re also human barriers. Much of your organization was devoted to prioritizing, planning, designing - all of that out the window now that features can be prototyped and shipped instantly.
There’s no need to prioritize or plan when engineering is free: simply do everything, all the time.
The designers are the next bottleneck, but they’ve become very fast, too - using the new LLM-enabled (sidenote: “Ligma”) they can use their expert judgement to spin ideas into fully formed UI designs in what seems like no time at all.
The bottleneck after that? Product leadership, obviously. Presented with dozens or hundreds of new ideas a day, leaders can’t keep up with the amount of ideation that’s happening. Vision and strategy is going to have to go by the wayside. LLMs can help, here, too: decision making must be unshackled from human bottlenecks. Everything can be A/B tested. There’s no reason to stand in the way of anything, so long as users keep favorably responding to the increasing number of (sidenote: Net Promoter Score: that thing where you rate on a scale of 1 to 10 how likely you are to recommend a company to somebody, a common practice with people who’ve abrogated their responsibility for product development in favor of growthhacking.) surveys they’re receiving, average revenue per user is increasing, monthly active users are going up, churn is improving, and your company continues to score well on the Bilmer-Chuckley user enrichment scale.
With the new tightly optimized pipeline, a whole experiment can go from the ideation phase, through design, get baked into a UI, shipped to the development team, and launched in under a day. Patches are sourced from every team in your company. Product, design, customer support - anybody who’s got skin in the game can kick off this process, make changes to the product that they desire and have them delivered, along with a test suite maintaining that everything still works and ample (sidenote: of course, only the LLMs will bother to read the documentation: attempts to understand how your product works just create another bottleneck.) .
Finally: everyone in your company is a rockstar who can proactively change the game by engaging with stakeholders, addressing low-hanging fruit and delivering customer value at scale.
This is the dream of Silicon Valley. You’ve achieved infinite velocity.
Product Stability Is Somehow Decreasing?
Every change is going through intensive senior developer analysis, thoughtful review, and intense unit testing. Senior developers are empowered to make large, impactful refactors to the codebase. Still, somehow, outages and weird errors are proliferating faster than ever. What gives?
Well, for one thing, the product is now an intensely moving target. That velocity is working, and the product is becoming huge, and it’s becoming huge fast.
It’s impossible to deliver new features and functionality without coordinating with all existing features and functionality, and the space of all existing features and functionality gets larger and larger every single day. The LLM is very confident that it can ship things without breaking anything, and the humans whose job it is to review it all… depend so much on the LLMs to get their job done that they no longer understand the newly gargantuan underlying systems.
Nobody alive understands how that feature works, not even the developer who shipped it, because it was the third thing out of six that they reviewed that day.
The complexity of the system is increasing faster than even LLM-aided understanding of the system can manage.
This would never happen in real life, obviously.
Now, technically, a team of curators could be convinced to carefully, thoughtfully prune their systems to maximize stability and protect a stable system core -
There’s nothing product design loves more than removing features and functionality. Removing configuration options. Removing underperforming components. Products do that all the time, right? They’re definitely not cramming in new features, day after day, running an endless treadmill of trying to be all things to all people, growing and growing eternally.
Thoughtful curation and pruning, of course, exist in opposition to the idea of infinite velocity. Velocity isn’t about care, thought, craftsmanship, it’s about delivering as much as possible, as fast as possible. If it makes the line go up, it stays in the product.
The Metrics Are Somehow Getting Worse?
Each individual feature A/B tests well, and yet overall product satisfaction seems to be diminishing?
Well, for one thing, every other company in the world has also embraced infinite velocity, so the best case scenario for the infinite velocity regime is treading water, maintaining your existing relevance in the face of the unyielding drumbeat of a brutal industry.
The human factor is getting weird, though: people are growing bitter with the constant NPS surveys. People don’t like being A/B tested on. They feel angry that the product is changing in unusual ways every time they boot it up. They don’t like the stability issues. They don’t like being experimented on.
The product they love is also a moving target, and they can feel it constantly shifting, optimizing for engagement at all costs. The algorithm wants nothing less than 100% of their attention and money, and they notice, and they’re becoming angry.
Few companies measure user trust.
Every A/B test, every stability issue, every unwanted new feature, every thing intended to appeal to everyone but not you, specifically brings the product a little closer to breaching the trust thermocline.
The Trust Thermocline
So, Twitter has become essentially a closed-loop ecosystem nowadays, and linking the original tweets about this is increasingly hard, so images:
Like Meta, or Twitter, the product is so optimized for engagement and so widely distrusted by users that it hollows itself out from the inside, collapsing like a dying star, itself populated only by scattered LLMs designed to pretend to be users in order to boost engagement.
All of the Employees are Exhausted and Unhappy?
One of the worst things about the infinite velocity workplace is imagining working there.
Sure, the AI revolution could power a dramatically shorter workweek - but it doesn’t seem that companies are imagining “a slightly faster pace of development and happier employees”, does it? It seems like companies are imagining hyper-efficient employees doing two or three or five jobs for the price of one. Doesn’t that sound fun?
What if, instead of designing software, it was your job to have long conversations with AI agents, do code reviews, and attend meetings all day long?
I might be one of the remaining folks in tech old enough to remember George Jetson’s white collar job of pushing a button.
This was presented as a joke about the future: despite George’s job being technically, very easy, George still manages to hate his job.
I’m going to say it: I enjoy building software. I like digging in to tough technical problems. I like thinking about how to solve things. Being presented with a new unique and difficult puzzle to solve regularly is exhausting and difficult, but ultimately I believe that the job of a software developer can be enjoyable, particularly if one of the things you care about developing is your enjoyment of your job.
At my work, I have occasionally pitched a philosophy of something I call joy-driven development: sometimes you have to do something the hard way, needlessly reinvent a wheel, build an over-complicated system component, wildly overengineer a system that doesn’t call for it - not because that’s the best thing for the product, not because that’s the best thing for velocity, but simply because damn it, it’s fun, and developers who are having fun are engaged, and playful, and creative, and more productive, and whoops you accidentally shipped something vibrant and full of heart.
Building something neat is an antidote for burnout.
Maybe by being weird and sloppy and human you ended up building The Metaverse People Actually Like, rather than going to market with the blandest, most broadly appealing product ever conceived.
i don’t know how this picture got here it definitely isn’t related to what I’m saying
I tolerate code reviews. I certainly don’t relish the idea of doing way, way, way more of them.
If I’m going to work, I’ve been relatively happy finding work that’s at least passably enjoyable. The struggle itself towards the heights is enough to fill a man’s heart. One must imagine Sisyphus happy.
Paperclip Maximization and You
I don’t meaningfully own the company where I work. Its goals align with my own only insofar as it remains:
- Able to continue employing me.
- A nice place to work.
- More good than evil.
I’m willing to be a little flexible on those last two points, because, y’know…
A company at infinite velocity, though, quickly becomes a paperclip maximizer: maximizing revenue for the owners as efficiently as possible.
Many companies have values, you know, embodying the Six Sigmas: teamwork, insight, brutality, male enhancement, handshakefulness, and play hard. It’s important, though, to always be aware of the secret actual corporate value: maximize shareholder value at all costs or be replaced by someone who will.
Never make the mistake of accidentally forgetting that this is the secret actual corporate value, the beating heart of every company, the dark voice whispering in the ears of management.
To be honest, I don’t think I want that ethos to have access to infinite effectiveness. All that does is concentrate more money in the hands of people who already have entirely too much money. I don’t want to be a cog in a machine that’s the opposite of Woody Guthrie’s guitar.
I’m not convinced that enabling businesses to do business faster necessarily makes our lives better.
Perhaps There is a Healthy Middle Ground
You’re probably going to read this article and think “wow, this is an extremely anti-LLM stance” - but, uh, I can’t help myself, I use the damn things all the time.
I also, controversially, eat meat. It turns out that you can have a moral objection to a thing and still do it. With age comes an increasing comfort with a certain baseline level of hypocrisy. Using and developing LLMs is wrong. Still doin’ it.
I was on this relatively early, too - 5-6 years ago I was baking Tensorflow into a primitive music generator to produce weird, borderline unlistenable music and lots of it. I used the earlier, very weird and abstract GAN generators and my own GPU - with human-powered paint-overs - to build a playing card game. I built a very stupid CAPTCHA.
Ultimately it’s hard to pull myself away from the problem that, under all of the extractive capitalism, the technology is kinda neat.
So Many Valid Use Cases
First of all, there are a wide variety of problems that I am called upon to solve in day-to-day work that aren’t, in fact, fun puzzles. The ratio of “puzzle” to “drudge” can vary widely from day to day.
Sometimes MongoDB has slightly changed the parameters to an important database interface we use, and the job is to look at every single place in the codebase where we use those parameters and make a subtle adjustment that’s just complex enough that it can’t be a find-and-replace.
Sometimes I have to write OpenAPI spec YML to document an interface that I’ve already described in depth with integration tests and route definitions. I hate writing OpenAPI spec.
Sometimes I’m learning a new, publicly documented technology and I have a lot of questions and I would very much like an infinitely patient and often mostly correct-ish teacher to help walk me through it with examples and clarifications.
Sometimes I’m starting a debugging puzzle and I want a machine to flag a couple of potential contributing problems to get the ball rolling. Sometimes I’m stuck and I want a machine to suggest something I haven’t tried yet. Sometimes I want a rubber duck without bothering a co-worker.
Sometimes I want to run my code by an impartial third party before I show it to my co-workers. Sometimes I want someone to explain the PR to me. Sometimes I don’t want to write the whole test, just the code that passes the test.
Sometimes I’ve just written an article or blog post, and since I don’t usually get much engagement or praise from the cold and unfeeling internet, I want Dr. Flattery the Always Wrong (sidenote: I stole “Dr. Flattery the Always Wrong Robot” from YouTuber Angela Collier because I think it is an extremely funny turn of phrase) to tell me that it’s very thoughtful and that my points were well-constructed , and also that on line 38 I accidentally said “and and”.
I Have The Good Sense To Be Embarrassed About This
For me, the ideal output of “Curtis + LLMs” is just “Curtis seems unusually fast and effective”. The illusion of humanity must be maintained at all times, and to accomplish this I guard the exit ports of my output zealously. Partially that’s because I find AI output unbearably tacky, now that the whole world is aware of exactly what it looks like.
I put extra effort into my writing, now, to be weirder. To be more human. To phrase things unusually. I don’t use em-dashes anymore. I’m dropping emoji.
If you’re reading something I wrote, I wrote it. I thought about it. The words came out of my keyboard. I can guarantee to you that at least one person cared enough about this content to think about it. That has to be true, because if that ever, for a moment, didn’t seem like it was the case, you wouldn’t trust anything from me, anymore.
Seeing generative content from a human quickly breaches their trust thermocline. If they didn’t care enough to write this, should you care enough to read it?
I’m careful about how I use LLMs because I have a brand, too. Work that comes from me has met a real - admittedly low - but a real quality bar.
Rules Won’t Save Us
Do you hear that weak-ass rationalization? It sucks.
Everybody and their goddamned rules.
“I never use a LLM without checking the output first.”
“I never let LLM code go into production without thorough code review.”
“I never let other humans see non-human output.”
But I knew this could be addictive so I set myself some rules.
If you’ve ever experienced addiction, you know how this story goes.
I would never have Kratom two days in a row. There always had to be a day in between.
And I would make sure to rotate the strains so I wouldn’t develop a tolerance.
And under no circumstances would I ever even think of taking Kratom more than once a day.
You see, I’ve seen these sad stories online of these addicts who were taking Kratom every day and they were addicted to the drug, and - pfft - I’m smarter than them. That could never happen to me, no way.
I could have my cake and eat it, too.
If it were legal for companies to give workers (sidenote: which, you know how the USA is, is coming any day now) to make them work faster, they absolutely would, no question.
I’m sick of hearing why you think you won’t get suckered by the alluring machine that your job is (sidenote: depending on how “cool” your office is, this mandate might be a gentle suggestion or a strict mandate, but the message is the same, no matter how chill: adapt or die.) to mandate that you use.
I’ll take the office meth. I must remain employed.
You will, too.
That’s why I don’t want to hear you talking about it, about the cool things you managed to get it to do on your behalf, about your particular rules for keeping it from destroying you or your product.
You’ll become dependent on it.
You’ll trust it too much.
It will make you worse.
It will happen to me, too.
Even knowing that this will happen won’t make me smart enough to prevent it from happening.
We will achieve infinite velocity.
And the system will shake itself apart. And we’ll be back to square one.
The next time, we will build it a little bit more carefully.
Maybe Being Forced To Prioritize and Plan Was Secretly A Good Thing All Along
That’s right, I’m putting my career at risk by advancing the theory that maybe too much velocity… bad?
You’re familiar with the idea that constraints breed creativity, yes? I believe that may also apply in the larger sense, that constraints on productivity may also need, in some sense, to exist.
Velocity exists in contrast with care, with thoughtfulness, with taste, with craft. As professionals, we’re expected to balance these things - to take shortcuts when necessary, but ultimately to be meaningfully engaged in the act of creation.