Can't speak for anyone else, but for me, AI/LLMs have been firmly in the "nice but forgettable" camp. Like, sometimes it's marginally more convenient to use an LLM than to do a proper web search or to figure out how to write some code—but that's a small time saving at best, it's less of a net impact than Stack Overflow was.
I'm already a pretty fast writer and programmer without LLMs. If I hadn't already learned how to write and program quickly, perhaps I would get more use out of LLMs. But the LLMs would be saving me the effort of learning which, ultimately, is an O(1) cost for O(n) benefit. Not super compelling. And what would I even do with a larger volume of text output? I already write more than most folks are willing to read...
So, sure, it's not strictly zero utility, but it's far less utility than a long series of other things.
On the other hand, trains are fucking amazing. I don't drive, and having real passenger rail is a big chunk of why I want to move to Europe one day. Being able to get places without needing to learn and then operate a big, dangerous machine—one that is statistically much more dangerous for folks with ADHD like me—makes a massive difference in my day-to-day life. Having a language model... doesn't.
And that's living in the Bay Area where the trains aren't great. Bart, Caltrain and Amtrak disappearing would have an orders of magnitude larger effect on my life than if LLMs stopped working.
And I'm totally ignoring the indirect but substantial value I get out of freight rail. Sure, ships and trucks could probably get us there, but the net increase in costs and pollution should not be underestimated.
No matter how good or fast you are, you will never beat the LLM. What you're saying is akin to "your math is faster than a calculator" and I'm willing to bet it's not. LLMs are not perfect and will require intervention and fixing but if it can get you 90% there, that's pretty good. In the coming years, you'll soon find your peers are performing much faster than you (assuming you program for a living) and you will have no choice but you do you.
Fun story: when I interned at Jane Street, they gave out worksheets full of put-call parity calculations to do in your head because, when you're trading, being able to do that sort of calculation at a glance is far faster and more fluid than using a calculator or computer.
So for some professionals, mental math really is faster.
Beat an LLM at what? Lines of code per minute? Certainly not. But that's not my job. If anything I try to minimise the amount of code I output. On a good day my line count will be negative.
Mathematicians are not calculators. Programmers are not typists.
So now programmers add value when they write more code faster? Curious how this was anathema but now is a clear evidence of LLM-driven coding superiority.
The math that isn't mathing is even more basic tho. This is a Concorde situation all over again. Yes, supersonic passenger jets would be amazing. And they did reach production. But the economics were not there.
Yeah, using GPU farms delivers some conveniences that are real. But after 1.6 trillion dollars it's not clear at all that they are a net gain.
> I need to continue delivering at the same capacity with a significantly scaled-down team.
I'd start by thinking through how much of that "need" is real.
What is driving the things your team "needs" to accomplish? What hard external constraints are you operating under? What are the interaction points between your work and the rest of the organization? How much flexibility do you have? And, holistically, how much flexibility should you have?
After that, it's a matter of negotiation. Given some understanding of the real constraints as well as the personal/political factors driving your manager, how can you come up with a better approach for your team and your work? I personally found the book Splitting the Difference really useful for approaching these sorts of conversations, but I'm also not especially good at that sort of thing naturally!
Unless you have an absolutely awful relationship with your manager, a starting point would be asking these questions to them. The trick is to pose these as legitimately open-ended questions. I learned the value of this first-hand: if I'm trying to convince somebody about something, asking an open-ended question will either get them to rethink their beliefs or they will come back with an answer I didn't think of, and either way I got something valuable out of it.
At the end of the day, you need to find some way to have slack in your work, or the team will fall apart. Slack can come from changing what you're doing and how you're fitting into the broader organization, or it can come from factors the organization does not "see". That latter is where the real risk lies: that's the dynamic that results in unreasonable corner-cutting and then burns people out.
I should add that I have not been in this situation as a manager, but I have been in that situation as a lead with no formal, positional power. That seems similar enough to be a good staring point, but I'm sure it's different enough that you should take everything I say with a grain of salt!
One thing I've realized is that we talk about "plans" and "budgets" and "roadmaps" as something constant and immutable, but they're not. They're just decisions that the organization made. We can make different decisions! But that in particular might be a view that's more useful as a lead than as a formal manager, because it very much goes against the way most organizations are run. This realization changed my perspective on what's going on, but I suspect it would be impolitic to emphasize it when negotiating up the chain.
One more thing: when I've been in analogous situations, one of the difficulties I had was managing my own emotions. I'm still not especially good at that. But one thing that helped me was taking some concrete action to change things, even if it's small and symbolic. Just starting something—even if it means writing up some notes and setting up a meeting—immediately helped manage my own anxiety. It sounds obvious in hindsight, but it took me a while to recognize this! Now I have three coping strategies I reach for:
- write up my thoughts and feelings—sometimes notes to myself, sometimes as docs I can share with others
- talk to somebody—I got a lot out of having mentors to talk to in and outside my job; occasionally they gave me non-obvious advice I found useful, but mostly just talking through something really helped
- do just *one* concrete thing about whatever is worrying me
Honestly, writing comments like this is also a coping strategy! I've repeatedly written about topics like this online and it has really helped me deal with things and work through my own ideas and observations.
In your case, the answer could well just be leaving like others are suggesting. But, even if it is, trying to do something about it at your current place might still be worth the effort in the short term. Even if things don't work out and you leave, it can make you feel better in the short term, and it's a great chance to learn how to handle this kind of situation by actually trying something. (And, in hindsight, that whole paragraph is advice I needed to give to myself just now more than advice for you or anyone else :P)
> For example, if you’re making a game for a 24-hour game jam, you probably don’t want to prioritize clean code. That would be a waste of time! Who really cares if your code is elegant and bug-free?
Having worked on some 24-hour game jams and similar, I've found completely the opposite. It's when you're in a real hurry that you really can't afford bad code. Writing better code will make it easier to get it right, will put less pressure on my working memory, will let me try things faster and make those last-minute changes I wanted, will make adding features towards the end easier rather than harder and, crucially, will both reduce the chance that I need to do intense debugging and make debugging I need to do easier.
Working with good code just feels lighter.
The thing that breaks 24-hour projects isn't writing code too slowly, it's writing yourself into a corner or hitting some problem that derails your work, takes hours to solve or doesn't even get resolved until after the deadline.
A game jam isn't the place to try to squish all bugs, sure, but that's a question of what you're doing, not how. I still want to write good code in that situation because it makes my life easier within the time constraints, and because, even if I'm fine with some bugs, there are still lots of bugs that render a game unpleasant or unplayable.
I'll need to fix some bugs no matter what; I'd rather fix fewer, easier bugs than more, harder bugs!
The same thing applies to longer time horizons too. When you have more time you have more slack to deal with bad code, but that doesn't mean it makes any more sense to write it!
And, of course, once you get in the right habits, writing solid quality code becomes basically free... but, even if it really did meaningfully slow you down, chances are it would still be worth doing in expectation.
I second this. I've done lots of game jams and I think the "messy code" threshold for me is like, 1-2 hours away from the deadline at most, on files nobody else will touch. It depends on the type of cleanup, but factoring out common logic really doesn't take that long.
As the above comment says, in my experience bugs introduced from messy code are way more likely than the time savings of not cleaning up code.
The usual exception I'd make are things that like, mostly the same but not quite (e.g. a function to fade out a light over time vs a function to fade out a color over time). Often I find requirements for those diverge over time, so I'll just leave some repeated patterns across both.
Using a different algorithm is a change in what you're doing, not how you're doing it, so I'd see that as qualitatively different from writing bad code.
I think it's a misconception that writing good code must take longer than writing bad code. At least if you want it to vaguely satisfy some requirements.
If you start with lambda calculus you don't have effects in the first place, so there's nothing to eliminate. Lambda calculus and friends are perfectly reasonable languages for computation in the sense of calculation.
A better way to think about general-purpose functional programming is that it's a way to add effects to a calculation-oriented foundation. The challenge is to keep the expressiveness, flexibility and useful properties of lambda calculus while extending it to writing interactive, optimizable real-world programs.
Functional programming à la Haskell has always been about making effects controllable, explicit first-class citizens of the language. A language entirely without effects would only be useful for calculation.
The talk about "purity" and "removing side effects" has always been about shock value—sometimes as an intentional marketing technique, but most often because it's just so much easier to explain. "It's just like 'normal' programming but you can't mutate variables" is pithy and memorable; "it's a language where effects are explicitly added on top of the core and are managed separately" isn't.
I have a commercial microwave with exactly one dial[1]. It's great. It's more expensive than a "normal" microwave, but the UI is great, the construction is really solid and it's easy to clean. There's no external moving parts—no annoying rotating tray on the inside, and no visible latch on the door. It's clearly meant to take some abuse.
At first it was a bit annoying because frozen meals sometimes want you to run it at lower power and this microwave has no power setting. If that's a problem, I imagine there's some other similar model that does. But in practice, just running it at full power for shorter seems to work just as well.
It would look much nicer if it didn't have a cooking guide printed on it.
In Europe, I saw some consumer-grade microwaves with similarly minimalist designs, like these Gorenje microwaves[2] with two dials. I'd have gotten one of those, but I couldn't easily find them in the US. But I also did not look especially hard.
These commercial microwaves have a ceramic tray (transparent to microwaves) that the food sits on. It fills the entire bottom of the microwave. Underneath the tray is a small piece of metal bent into a particular shape attached to a spindle that rotates. The idea being that it spins around the reflected microwaves rather than the food itself.
Same principle in the combined oven/microwave from Siemens we have at home, except the microwaves come from the top. If you look well, you can even see the thing rotating.
Combination microwave + oven (with a single compartment) are win-win. In Japan, they're common and many people wonder why anybody would want a separate microwave and toaster oven: combining them takes less space and takes less time for a better result.
Those are all just decisions the companies made. For future games, the game developers and the companies licensing IP can simply make different decisions. If a large market like the EU creates strong incentives for them, they will make different decisions.
Now, this is not necessarily the case for existing games. Revisiting existing licensing deals can be needlessly difficult. But I'm assuming the proposed regulations will only apply to new games rather than trying to force changes retroactively.
I'm already a pretty fast writer and programmer without LLMs. If I hadn't already learned how to write and program quickly, perhaps I would get more use out of LLMs. But the LLMs would be saving me the effort of learning which, ultimately, is an O(1) cost for O(n) benefit. Not super compelling. And what would I even do with a larger volume of text output? I already write more than most folks are willing to read...
So, sure, it's not strictly zero utility, but it's far less utility than a long series of other things.
On the other hand, trains are fucking amazing. I don't drive, and having real passenger rail is a big chunk of why I want to move to Europe one day. Being able to get places without needing to learn and then operate a big, dangerous machine—one that is statistically much more dangerous for folks with ADHD like me—makes a massive difference in my day-to-day life. Having a language model... doesn't.
And that's living in the Bay Area where the trains aren't great. Bart, Caltrain and Amtrak disappearing would have an orders of magnitude larger effect on my life than if LLMs stopped working.
And I'm totally ignoring the indirect but substantial value I get out of freight rail. Sure, ships and trucks could probably get us there, but the net increase in costs and pollution should not be underestimated.
reply