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.
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.
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.
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
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?
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.
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.
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'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.
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.
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?
My father was a machinist for 25 years, then went into education for trade skills programs. One thing he tirelessly hit on with anyone who would listen was the mid to long term impact of the erosion of manufacturing and trade skills in America. This erosion was due in part to economics, raising kids to eschew blue collar jobs, and finally automation. Indeed, one of his later projects while still a machinist at Eveready Battery was working on automated production lines. His point relating to automation, other than the fact that not everything can or necessarily needs to be automated, was that automation still requires skilled labor, and in his experience, abandoning the next generation of workers results in a crisis of competency and ingenuity. Attrition of a workforce to install, maintain, improve, and integrate machines is a recipe for disaster down the line. Attrition of experts in systems and processes means we will have trouble innovating and reacting to changes in the world, and increases our reliance on black boxes– which provide the same capabilities to your competitors, by the way– and the jackals that sell them to us. My father was not opposed to automation; in fact, he appreciated that it sometimes made his job safer, or more productive, or less strenuous. However, he watched delusional and myopic managers with dollar signs floating in their eyes chasing their tails relentlessly for more and more automation with fewer and fewer people with the knowledge, skill, and responsibility to clean up their constant messes and keep the thing running.
No one gives a shit about Gumroad, but I fear similar problems in this industry at large. We have entered a time when we all feed from the same exorbitantly expensive, increasingly less nutritious, thin, gray gruel and will be fucked when the tap it comes from clogs or gets shut off.
I think its a risk with any skillful industry. I heard the same comment in Experimental High Energy Physics. A top dog (for lack of better word) at CERN advocated for automating all of the effort to do the statistical analysis across all the different new particle searches. It did not come to be and at least I heard from my advisor that it would result in too many Physicists not really knowing their own craft.
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.
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.
