There has never been a more fertile environment for motivated learners to do more with less, and yet we still have a bias as an industry to seek the more experienced hand versus the energetic one.
The one thing they had was enthusiasm, but even the most committed and energetic junior hire cannot touch the productivity of AI on most of the work junior software devs are handed.
People are focused on absolute llm accuracy, but time-to-90%-there for AI vs junior dev is seconds to hours/days.
- Linus Torvalds wrote Linux at 21
- Steve Wozniak built Apple I at 25
- Palmer Luckey created Oculus VR at 20
- Vitalik Buterin designed Ethereum at 19
- Mark Zuckerberg coded Facebook at 19
If we view the person we are looking to hire as a "junior dev", a "junior dev" is what you will get. But if you seek a young, competent software dev—one you might find.
I've worked at companies that had been in operation for 4 years that had multiple developers work on it and was only at 40-50k.
My current project is at about 200k.
One company had a monolith with 20-30 people working on it 360k with a few microservices to start replacing monolith features being between 5-20k each.
It's not a ridiculous small code base, it's about average for a lot of small to medium size companies.
Just to be sure, are you talking about tokens or LOC?
I've never calculated the tokens for the codebases I work with but usually a 2k token output is fairly short one, like a small sized file on your average PL. So I am extrapolating 200k to 200 files.
Since you seem to like metaphors maybe this helps you understand my point: If they stop fertilizing there won't be any grass to harvest.
To make myself even clearer: They're (and you I guess) assuming other companies will hire and train the juniors for them, but it's short-sighted. If everyone did it how are they going to learn?
To be fair, this is a small software firm that famously runs lean, and has been outsourcing junior-level work to contractors for a while. See: "no meetings, no deadlines, no fulltime employees" https://sahillavingia.com/work
I can totally see AI-assisted code editors being more effective than back-and-forth with a contractor to define a job
that's great. Amazing. Does it mean Gumroad will drop its high prices now when it no longer needs to pay to humans? Because that's what actually be interesting news.
"How do you know someone's AI hypeman? Don't worry, they'll tell you"
Though when reworded, it sounds less palatable if you have people-oriented business morals.
"Why would they delight their customers when they can delight themselves?"
I like to do right by customers, and if we can both win, it's better than just me winning. Customers know when they're not winning, which decreases goodwill and your business' future prospects.
Do you have any more info about what tax troubles it resolves to use gumroad instead of Shopify? I’m just curious - I run a Shopify store but have never really felt the tax situation was overly complex and assumed I’d have a similar tax process when using a service like gumroad.
Every country that you sell your product in expects taxes on those products to be collected. Every city, every state in the United States has its own tax situation and nexus that needs to be followed, applied, paid to.
The __actual__ tax situation for SaaS and similar is incredibly complicated and I suspect / feel that a lot of small SaaS businesses and/or creators are simply ignoring it.
The way he talks about Deep Research (which came out this week) as a core part of the workflow is the clearest tell that this is engagement bait. "No longer hiring junior or even mid-level software engineers"...as of what, 4 days ago? Gumroad famously has no full-time employees and a tiny team. So he went from not hiring junior engineers, to using AI and also not hiring junior engineers.
The treadmill needs to be there. From junior to senior to staff to principal and so on. Agreed, all my previously written code is sitting some bankrupt startup's github which will never see the light of day but those years have made me what I am today.
I found that Windsurf's approach of automatically navigating a codebase is very close to that. But if you really need everything to be in the context at once, Gemini 2 is pretty much there already, except for maybe the largest codebases.
Sometimes I wonder if we are the last generation that can still code by hand, and if more companies start to implement the same hiring rules as this guy, soon there will be no more junior devs since nobody can get a job, so give it 10 years and the amount of senior devs will be a finite resource that will slowly die out.
Can someone help me better understand the ultimate goal here? I'm thinking through the AI influence and how it would replace the engineers at my company and fail to see it. However, that is likely just pure ignorance on my part and I'm likely just missing the obvious.
Say someone from the business side wants an external Api implemented into some ingestion pipeline. What would this look like without engineers?
I guess a new industry of "prompt engineers" comes to fruition that is just a middle man between the business and the AI. Because we know for 100% certainty that zero executives are going to spend the time to interface with these chat prompts to build the ingestion pipeline. The prompt engineers will just be what we called application developers.
If I was doing anything I would be hiring more junior/mid-level since they could be supported more with AI. And reducing the amount of seniors I hired.
It's not AI replacing your jobs, it's people who have the agency to do that. This is a choice. By a person. It's not because technology and, "oh well, what can you do?"
As a customer of Gumroad I'd be cautious about trusting such a system.
As a senior+ engineer, I have no interest in working for a company that doesn't hire junior or midlevel engineers. Mentoring the next generation is not only one of the most rewarding parts of my career, it also levels me up.
A few of our mid-level engineers started sending in PRs with worse than usual code in the last few months. It all compiles, but:
- There's a bunch of missing edge cases and requirements (details that don't end up on tickets but have been discussed)
- Sometimes we see completely useless codepaths. If statements and function calls that don't lead anywhere, or don't need to be called.
- We follow a few very specific patterns for code safety reasons and suddenly it looka like those are being completely disregarded.
- Our integration tests started being super flaky.
After several one-on-ones with them, we realized they were using some AI tool. No clue which one.
I know that these tools are going to get better, but I fear that junior/mid-level developers are going to handicap their development if they use them like they do now.
Code quality also suffers. I'm also afraid that in the short to medium term codebases are going to get _a lot worse_ introducing some very expensive tech debt.
On the bright side, I know now that I don't want to work at Gumroad. I already spend a huge amount time reviewing PRs. I don't want to waste even more because someone didn't prompt an AI accurately enough. What a waste of time and resources.
The quality of a PR is a reflection of the author not the tools the author uses. The last thing an engineer should do before sending out a PR is to review it themselves. A PR is a work product with their name on it, and is a reflection of their ability. This was true before LLM tools, and should be true after.
The trouble with AI and junior engineers is that they tend not to have the skills to tell what is good or bad. It used to be the same problem with code taken from stack overflow with no understanding.
It's surprisingly hard to reliably catch either issue in code review. Indeed it's hard to do code review that catches the majority of any class of problem
I don't have any evidence for it, but I feel that watching someone (or something) perform a task has less pedagogical value that performing that task oneself.
Same for attention, it's easier let your mind wander if you're e.g. taking the back seat while you're pair programming.
AI tools also don't really "reason", do they? Even if you use a reasoning model, they perform the most statistically likely steps with the context and instructions that they're provided, so you lose that "deliberateness" that enables you to best understand the problem that you're solving.
> The last thing an engineer should do before sending out a PR is to review it themselves. A PR is a work product with their name on it, and is a reflection of their ability.
Right, but your understanding of a PR that you're reviewing is different when you review your own work vs. when you review someone else's, right? For me personally, I have to expend more effort reviewing someone else's work.
If you can see how all of this adds up, I hope you understand how this leads to AI being more of a handicap than a tool.
All the "AI software engineer" hype is about one thing: suppressing developer wages. Steve Jobs used to do this covertly, to some extent, with his "no cold call" anti-poaching agreements.
It's a multi-prong attack. One angle is the interest rates and mass layoffs. Another angle is AI. There are more ridiculous ones, such as this "study" that claims 10% of devs do literally no work: https://x.com/yegordb/status/1859290734257635439 - I expect many such studies to be conducted and generously funded by the industry in the coming years.
The big irony is how all this talk will lead to a decrease in the software engineer supply. Why would anyone choose a career that's about to die?
68 comments
[ 4.0 ms ] story [ 117 ms ] threadAlso possibly, good would-be-junior-devs find something more productive to do.
People are focused on absolute llm accuracy, but time-to-90%-there for AI vs junior dev is seconds to hours/days.
These people were exceptional outcomes, where luck and hubris met sufficient competency. You cannot argue the general case from exceptions.
It's all just a bunch of rehashed corpospeak language anyway.
"WE'RE GOING ALL IN ON AI"
My current project is at about 200k.
One company had a monolith with 20-30 people working on it 360k with a few microservices to start replacing monolith features being between 5-20k each.
It's not a ridiculous small code base, it's about average for a lot of small to medium size companies.
I've never calculated the tokens for the codebases I work with but usually a 2k token output is fairly short one, like a small sized file on your average PL. So I am extrapolating 200k to 200 files.
(That is actually a very serious problem in quite a few banks)
To make myself even clearer: They're (and you I guess) assuming other companies will hire and train the juniors for them, but it's short-sighted. If everyone did it how are they going to learn?
I can totally see AI-assisted code editors being more effective than back-and-forth with a contractor to define a job
"How do you know someone's AI hypeman? Don't worry, they'll tell you"
Why would they give that money away rather than keeping it as profits?
Though when reworded, it sounds less palatable if you have people-oriented business morals.
"Why would they delight their customers when they can delight themselves?"
I like to do right by customers, and if we can both win, it's better than just me winning. Customers know when they're not winning, which decreases goodwill and your business' future prospects.
But if you modify it to why not use paddle.com or polar.sh? Then i actually dont know.
The __actual__ tax situation for SaaS and similar is incredibly complicated and I suspect / feel that a lot of small SaaS businesses and/or creators are simply ignoring it.
It would be a reason for me to not rely on their code, for risk of it becoming unmaintainable.
Now CEOs instead say "we are replacing engineers with AI" and the stock price shoots up.
Quite a grift we have going on.
Sometimes I wonder if we are the last generation that can still code by hand, and if more companies start to implement the same hiring rules as this guy, soon there will be no more junior devs since nobody can get a job, so give it 10 years and the amount of senior devs will be a finite resource that will slowly die out.
Say someone from the business side wants an external Api implemented into some ingestion pipeline. What would this look like without engineers?
For the record, this is an honest question
As a customer of Gumroad I'd be cautious about trusting such a system.
The US tech industry is committing slow suicide.
All Senior Engineers were at one point Junior/Mid-Level who had other more Senior Engineers to learn from. :)
That said, every company is different -- maybe it works for Gum Road.
- There's a bunch of missing edge cases and requirements (details that don't end up on tickets but have been discussed)
- Sometimes we see completely useless codepaths. If statements and function calls that don't lead anywhere, or don't need to be called.
- We follow a few very specific patterns for code safety reasons and suddenly it looka like those are being completely disregarded.
- Our integration tests started being super flaky.
After several one-on-ones with them, we realized they were using some AI tool. No clue which one.
I know that these tools are going to get better, but I fear that junior/mid-level developers are going to handicap their development if they use them like they do now.
Code quality also suffers. I'm also afraid that in the short to medium term codebases are going to get _a lot worse_ introducing some very expensive tech debt.
On the bright side, I know now that I don't want to work at Gumroad. I already spend a huge amount time reviewing PRs. I don't want to waste even more because someone didn't prompt an AI accurately enough. What a waste of time and resources.
It's surprisingly hard to reliably catch either issue in code review. Indeed it's hard to do code review that catches the majority of any class of problem
Same for attention, it's easier let your mind wander if you're e.g. taking the back seat while you're pair programming.
AI tools also don't really "reason", do they? Even if you use a reasoning model, they perform the most statistically likely steps with the context and instructions that they're provided, so you lose that "deliberateness" that enables you to best understand the problem that you're solving.
> The last thing an engineer should do before sending out a PR is to review it themselves. A PR is a work product with their name on it, and is a reflection of their ability.
Right, but your understanding of a PR that you're reviewing is different when you review your own work vs. when you review someone else's, right? For me personally, I have to expend more effort reviewing someone else's work.
If you can see how all of this adds up, I hope you understand how this leads to AI being more of a handicap than a tool.
It's a multi-prong attack. One angle is the interest rates and mass layoffs. Another angle is AI. There are more ridiculous ones, such as this "study" that claims 10% of devs do literally no work: https://x.com/yegordb/status/1859290734257635439 - I expect many such studies to be conducted and generously funded by the industry in the coming years.
The big irony is how all this talk will lead to a decrease in the software engineer supply. Why would anyone choose a career that's about to die?