Yeah, spatial reasoning has been a weak spot for LLMs. I’m actually building a new code exercise for my company right now where the candidate is allowed to use any AI they want, but it involves spatial reasoning. I ran Opus 4.6 and Codex 5.3 (xhigh) on it and both came back with passable answers, but I was able to double the score doing it by hand.
It’ll be interesting to see what happens if a candidate ever shows up and wants to use Deep Think. Might blow right through my exercise.
I had an issue with one of my Sprites (Fly.io also runs sprites.dev) and the CEO responded to me personally in less than 10 minutes. They got it fixed quickly.
I was a free customer at the time. I pay for it happily now.
Sure, that’s one solution. You could also Isle of Dr Moreau your way to a pelican that can use a regular bike. The sky is the limit when you have no scruples.
Ironically, I find LLMs far better at helping me dive into unfamiliar code than at writing it.
A few weeks ago a critical bug came in on a part of the app I’d never touched. I had Claude research the relevant code while I reproduced the bug locally, then had it check the logs. That confirmed where the error was, but not why. This was code that ran constantly without incident.
So I had Claude look at the Excel doc the support person provided. Turns out there was a hidden worksheet throwing off the indices. You couldn’t even see the sheet inside Excel. I had Claude move it to the end where our indices wouldn’t be affected, ran it locally, and it worked. I handed the fixed document back to the support person and she confirmed it worked on her end too.
Total time to resolution: 15 minutes, on a tricky bug in code I’d never seen before. That hidden sheet would have been maddening to find normally. I think we might be strongly overestimating the benefits of knowing a codebase these days.
I’ve been programming professionally for about 20 years. I know this is a period of rapid change and we’re all adjusting. But I think getting overly precious about code in the age of coding agents is a coping mechanism, not a forward-looking stance. Code is cheap now. Write it and delete it.
Make high leverage decisions and let the agent handle the rest. Make sure you’ve got decent tests. Review for security. Make peace with the fact that it’s cheaper to cut three times and measure once than it used to be to measure twice and cut once.
It’s been a lot of fun watching her subscriber count go through the roof. She’s outrageously talented.
It’s also funny because usually it’s hard to reproduce what a musician does. I can listen to someone play guitar, but there’s so much nuance to how it’s played that you need to be pretty good to reproduce it.
But so much of her music is code, and she shows you the code, so she’s really teaching you how to reproduce what she’s doing perfectly. It’s awesome for learning.
I’ve seen experienced software developers make impressive stuff with AI. I haven’t seen anything interesting made with AI by non-developers. They make a landing page or something. It’s just… barely anything. It’s a nothing of a project.
We use AI a lot at work, and the developers are vastly better at getting AI to do what we need than the non-developers. AI is a tool, and like any tool, it takes effort to learn how to use it effectively. And so far, the skills to use AI effectively are something I’ve only seen in software developers.
I don’t think product people are going to replace devs. Ever. I agree that I think a dispersal is more likely than an outright crash.
I was the first dev at my current company to experiment with Claude Code back when it first came out. Some of my coworkers tried it, and some didn’t like it at all.
But now literally all of us are using it. The company gives us a $100 monthly stipend for it. We’re a small dev team, but our CEO is thrilled. He keeps bragging about how customers are gobsmacked by how quickly we’re delivering new features and he’s been asked if we’ve made a ton of hires in the last year. We’re actually down two developers from when I started.
I don’t love the code it writes, but the speed is unbeatable. We still need devs, and I don’t think that’s ever going to change. But we don’t need as many devs. We’re shipping like crazy with a small team. I don’t think more people would speed us up much at all.
Where I work, we hired a developer that was supposed to be familiar with SQL. It turns out, he can't even write simple queries (and spends 0 time outside of work getting up to speed).
The director purchased a subscription to Claude and will most likely get rid of him at the beginning of the new year, because the job can pretty much be automated at this point.
Many Marketing/copyrighting people have also been laid off over the last year due to the same reasons.
"I don’t love the code it writes, but the speed is unbeatable. We still need devs"
I think this will be the problem going forward: Less positions to fill and the same amount of potential candidates. You will need to have more experience and credentials to compete.
This is what I'm seeing in the design market. With Figma Make, you can write a prompt, tell it to use your design library, generate a flow, and then hand it off to developers and say "Hey, look at this, can you implement this?". Alternatively, you can use Cursor/Claude Code/Codex to pull in Figma design system elements via MCP, and generate flows that way. You can push features so much faster with the same or fewer people, and lets be honest, pushing more features in less time is the #1 metric at a lot of companies even if they claim otherwise.
I find it to be sometimes easier to utilize my Figma library to design what I want as I generally don't have to do rework. It gets annoying after awhile to waste tokens and context dealing with stupid small things like "Hey, the icon in the icon button is wrong." if you do prompting. Pulling in the same icon & icon button through a MCP is generally easier.
Presumably you can iterate on and manually tweak the design first, which is much quicker and less cumbersome than iterating on and tweaking the design when it's in clunky HTML/CSS/JS form and all the non-vector graphical assets are flattened/cropped etc.
I own a small agency and it’s the same for me, but that doesn’t explain the urgency nor the layoffs in the big companies. Yes we are not hiring juniors, but we still hire seniors because they are now more productive. That’s not what we are seeing in big companies.
To me it’s the cumulated effects of many things happening coincidentally:
- Massive offshoring
- Money becoming scarce after the ZIRP era and in the recession except for AI investments
- Near monopoly positions that allow layoffs as a strategy to push stock price, without penalty for the decline in quality (enshittification)
- Cherry on the top, LLMs being able to do the work of juniors when used by seniors
If it was only about AI productivity we wouldn’t see this urgency.
> I can't think of a single time where having someone else review my work or give me feedback is a meaningfully bad thing
I have ample examples, unfortunately. I had a coworker whom I liked as a person, but had a nasty habit of using PRs as a way to hijack all decision making. He’d leave PR feedback for his personal preferences and mark them as “changes requested.”
Everyone feels like an asshole giving an approval when someone has requested changes, so you had to comply with all of his preferences if you wanted to merge your code.
I’ve had several companies where I submitted a PR and had someone say, “You’re guarding against an edge case that won’t happen. This is over engineered. Remove it.”
And it made it less than a week in production before we hit the edge case that I’d been forced to neglect.
I had a team come to me with a request, so I built it. They were thrilled. Then another engineer was like, “I don’t like (some technical detail). You need to change (major architectural decision).”
I gave the re-architected version to the team who requested it and they said, “Wait, I loved what you built before. What is this? I don’t want this!”
This post resonated with me pretty hard. Hire good people and deputize them to make decisions. You’ll end up with something good more often than not. I’ve never seen design-by-committee produce a great product.
I’ve had too many experiences with seeing decent contributions get worse and worse as they go through successive rounds of feedback.
> I’ve had too many experiences with seeing decent contributions get worse and worse as they go through successive rounds of feedback.
This is a great observation. Having a PR feedback process that involves everyone commenting on every tiny decision is a guaranteed way to end up with "design by committee" syndrome. Everyone feels obligated to push their little agenda, no matter how insignificant it may be. The end result is what the original article tries to explain: When everyone is responsible for every PR, no one is really responsible for any PR. The quality and suitability of the code are not proportional to the volume of feedback the pull request receives. There is a sweet spot, and beyond that, quality and development velocity deteriorate quickly
It’ll be interesting to see what happens if a candidate ever shows up and wants to use Deep Think. Might blow right through my exercise.
reply