I’d recently been applying for plenty of jobs that were hosted on Ashby. They had a tiny link to a form where you could opt out of having your resume processed by their AI system. Only it never worked. Submitting the form displayed a spinner and did nothing. Not sure if that was intentional.
I’m starting to come around to the belief that vibe coding isn’t engineering. Not saying Ashby is vibe coding. The post certainly says they’re super serious about making sure everyone understands every line of change. I wonder how they manage that in practice.
There are few empirical studies on the effects of informal code review, what most of us do on GitHub and Codeberg, on error rates. It’s not much. But a little side line mentioned that the effect we do have on error rates disappears the more code you read per hour.
So you used to have the 80/20 rule. 20% of your dev team is doing 80% of the work. Now we have a tool that enables the 80% of the team that manages to squeak by without doing a whole lot to… write a whole ton of code that the 20% now have to review… only if they read too much it’s not going to do a whole lot.
So I dunno. Seems like that combined with the come wave of price hikes we might see orgs talking about rolling back their AI usage later this year.
I don't understand why people look at bugs and go "oh it must be AI". Did humans never write bugs? I've seen plenty of platforms where bugs like that were the norm, bad software engineering has always existed.
Most of the comments so far are responding to the first few paragraphs of this article. On reading further, I thought this was actually an unusually balanced take on how to use LLMs in a software org.
I can't help but cringe at the "cost of code is now zero" meme that this article repeats because in my experience the biggest cost of code was always the activities around the code - planning, communicating, reviewing, validating. This author, despite repeating the meme, seems to agree. Their emphasis on writing PR descriptions and specs for humans rhymes with my experience and it sounds like a nicer way to work than chasing some dark factory fever dream.
I also thought the "Two Modes of Working" section was useful. People get wildly different results from coding agents depending on how they use them, but I've not seen a lot of actual guidance on when to do X vs Y.
Personally, I've been using what the author calls "sidekick mode" since last October - before the supposed "AI got good now" threshold - and agree it's a more useful default for an engineer than "delegate mode".
> We have a blip in March / April every year; these cyclical patterns aren’t relevant to explain here.
The 'blip' post-AI is up ~30% for the months in question. There simply isn't enough data here to prove or disprove the thesis that "customer issues remain broadly stable" - you could equally argue something more along the lines of "AI engineering does not increase issues under ideal conditions but amplifies issues under external pressure."
"Not relevant to explain this stat" in an article entirely about using those stats to justify their AI policy is brazen, I have to give credit.
One other point of note is that the chart only goes back to January 2025, and only dilineates "majority AI" from "not majority". If the usage rate in January 2025 was at 45%, "issue rate remained roughly stable (with a giant asterisk) when moving from 45% to 51%" is not exactly a compelling story. There's no narrative I trust less than one created by cherrypicking data to lend itself an aura of faux objectivity.
It just sounds to me like there's probably a 20/80 split between your "new rockstars" who are using AI to make huge messes that others will have to clean up and your "malicious compliance" types who basically still actually do the work but run up the company credit card to put a patina of AI on their normal work so that they won't get fired.
But, like, this is a model you can embrace without AI. Have some people make messes, have others clean them up.
> Our thesis is that the cost of producing code is heading towards zero
This (correct) thesis should illicit an interesting question about the future of SaaS markets: What happens to the SaaS markets when the cost of code approaches zero?
Coincidentally, the company that authored this post is a perfect case study.
Few people truly grasp how hard bringing a software product to market is. The feature density required to even begin selling your product often requires more human capital than early stage investors are willing to underwrite. Some founders have the background to command those terms, but most have to wedge into a market with some very small insight.
I was at a dinner with the CEO of Greenhouse in 2021 and vividly recall him explaining just how deep the feature set of a new ATS needs to be to even enter the consideration set of a buyer.
One serendipitous way companies could enter these markets is by being founded in one market, and pivoting into another. Ashby didn't start as an ATS. They were originally targeting a mid-market ERP (a hot thesis at the time). Ashby is a prime example of a company that likely could not have entered their current market because of the sheer engineering resources required to break through (and kudos to them for doing it!)
But as the cost of code approaches zero, the deterrents of entering the market also drop to zero. The next Ashby could just pursue ATS from day one. In a sense, this is the entire story of humanity and especially software (consider the cost of building an ATS in 2012 when Lever was founded vs the cost Ashby faced in 2019).
But the slope of this change is unlike anything before it.
ATS, like many other markets, has a handful of big players and a long tail of smaller offerings. No matter how many long tail providers there are, the economics of entering a market suppressed that number compared to what can and will exist tomorrow. The cost of building an ATS a decade ago was literally orders of magnitude more than it is today.
In 2016 I heard a A16Z partner describe a future where every software market would have offerings in virtually every little niche one could imagine. Years before the LLM renaissance, this sounded insane. How could the market afford to build and sustain each offering?
I don't think companies are going to start building their ATS in house, but I do believe that cost of producing code is approaching to zero, and that means hundreds or even thousands of offerings will exist in every shape, way and form we can imagine.
Can anyone tell me why Ashby is so en vogue in SV and also the rest of the world? My company recently switched to it and as an EM I feel... disappointed? What's so special about it to have yet another hiring system with VC money?
As someone who has used Ashby pretty regularly over the last several years, I suspect I’m not alone in wishing they’d let the AI make the technical and product decisions.
It’s a product that feels like it’s designed and built by the C or D team. The slowness and bloat of Rippling with wild, fever dream interaction models and workflows that frustrate and confound.
(And enjoy fucking emailing them if you need anything at all: almost literally no self service paths exist in the app for account upgrades, adding on SAML etc. And I do mean that you have to email them—last I checked it’s a mailto: link, not even a form.)
> Our thesis is that the cost of producing code is heading towards zero. AI isn’t coming for our jobs, it’s coming for the mechanical parts of them: syntax, glue code, and the tip-taps of keystrokes. The parts that are less interesting, less challenging
The cost is heading to 0???? Do they not pay for Claude, Anthropic, OpenAI? Have they not seen the sudden price increases? Hosted locally LLMs still have electrical and server costs.
I’d recently been applying for plenty of jobs that were hosted on Ashby. They had a tiny link to a form where you could opt out of having your resume processed by their AI system. Only it never worked. Submitting the form displayed a spinner and did nothing. Not sure if that was intentional.
I’m starting to come around to the belief that vibe coding isn’t engineering. Not saying Ashby is vibe coding. The post certainly says they’re super serious about making sure everyone understands every line of change. I wonder how they manage that in practice.
There are few empirical studies on the effects of informal code review, what most of us do on GitHub and Codeberg, on error rates. It’s not much. But a little side line mentioned that the effect we do have on error rates disappears the more code you read per hour.
So you used to have the 80/20 rule. 20% of your dev team is doing 80% of the work. Now we have a tool that enables the 80% of the team that manages to squeak by without doing a whole lot to… write a whole ton of code that the 20% now have to review… only if they read too much it’s not going to do a whole lot.
So I dunno. Seems like that combined with the come wave of price hikes we might see orgs talking about rolling back their AI usage later this year.
I don't understand why people look at bugs and go "oh it must be AI". Did humans never write bugs? I've seen plenty of platforms where bugs like that were the norm, bad software engineering has always existed.
Most of the comments so far are responding to the first few paragraphs of this article. On reading further, I thought this was actually an unusually balanced take on how to use LLMs in a software org.
I can't help but cringe at the "cost of code is now zero" meme that this article repeats because in my experience the biggest cost of code was always the activities around the code - planning, communicating, reviewing, validating. This author, despite repeating the meme, seems to agree. Their emphasis on writing PR descriptions and specs for humans rhymes with my experience and it sounds like a nicer way to work than chasing some dark factory fever dream.
I also thought the "Two Modes of Working" section was useful. People get wildly different results from coding agents depending on how they use them, but I've not seen a lot of actual guidance on when to do X vs Y.
Personally, I've been using what the author calls "sidekick mode" since last October - before the supposed "AI got good now" threshold - and agree it's a more useful default for an engineer than "delegate mode".
> We have a blip in March / April every year; these cyclical patterns aren’t relevant to explain here.
The 'blip' post-AI is up ~30% for the months in question. There simply isn't enough data here to prove or disprove the thesis that "customer issues remain broadly stable" - you could equally argue something more along the lines of "AI engineering does not increase issues under ideal conditions but amplifies issues under external pressure."
"Not relevant to explain this stat" in an article entirely about using those stats to justify their AI policy is brazen, I have to give credit.
One other point of note is that the chart only goes back to January 2025, and only dilineates "majority AI" from "not majority". If the usage rate in January 2025 was at 45%, "issue rate remained roughly stable (with a giant asterisk) when moving from 45% to 51%" is not exactly a compelling story. There's no narrative I trust less than one created by cherrypicking data to lend itself an aura of faux objectivity.
A “blip” that we have to take their word on, though the relative jump from the 1 prior year wasn’t as high as this one. Bad stats juking
It just sounds to me like there's probably a 20/80 split between your "new rockstars" who are using AI to make huge messes that others will have to clean up and your "malicious compliance" types who basically still actually do the work but run up the company credit card to put a patina of AI on their normal work so that they won't get fired.
But, like, this is a model you can embrace without AI. Have some people make messes, have others clean them up.
> Our thesis is that the cost of producing code is heading towards zero
This (correct) thesis should illicit an interesting question about the future of SaaS markets: What happens to the SaaS markets when the cost of code approaches zero?
Coincidentally, the company that authored this post is a perfect case study.
Few people truly grasp how hard bringing a software product to market is. The feature density required to even begin selling your product often requires more human capital than early stage investors are willing to underwrite. Some founders have the background to command those terms, but most have to wedge into a market with some very small insight.
I was at a dinner with the CEO of Greenhouse in 2021 and vividly recall him explaining just how deep the feature set of a new ATS needs to be to even enter the consideration set of a buyer.
One serendipitous way companies could enter these markets is by being founded in one market, and pivoting into another. Ashby didn't start as an ATS. They were originally targeting a mid-market ERP (a hot thesis at the time). Ashby is a prime example of a company that likely could not have entered their current market because of the sheer engineering resources required to break through (and kudos to them for doing it!)
But as the cost of code approaches zero, the deterrents of entering the market also drop to zero. The next Ashby could just pursue ATS from day one. In a sense, this is the entire story of humanity and especially software (consider the cost of building an ATS in 2012 when Lever was founded vs the cost Ashby faced in 2019).
But the slope of this change is unlike anything before it.
ATS, like many other markets, has a handful of big players and a long tail of smaller offerings. No matter how many long tail providers there are, the economics of entering a market suppressed that number compared to what can and will exist tomorrow. The cost of building an ATS a decade ago was literally orders of magnitude more than it is today.
In 2016 I heard a A16Z partner describe a future where every software market would have offerings in virtually every little niche one could imagine. Years before the LLM renaissance, this sounded insane. How could the market afford to build and sustain each offering?
I don't think companies are going to start building their ATS in house, but I do believe that cost of producing code is approaching to zero, and that means hundreds or even thousands of offerings will exist in every shape, way and form we can imagine.
Can anyone tell me why Ashby is so en vogue in SV and also the rest of the world? My company recently switched to it and as an EM I feel... disappointed? What's so special about it to have yet another hiring system with VC money?
where did it come out of all of sudden. they must have a killer sales dept
As someone who has used Ashby pretty regularly over the last several years, I suspect I’m not alone in wishing they’d let the AI make the technical and product decisions.
It’s a product that feels like it’s designed and built by the C or D team. The slowness and bloat of Rippling with wild, fever dream interaction models and workflows that frustrate and confound.
(And enjoy fucking emailing them if you need anything at all: almost literally no self service paths exist in the app for account upgrades, adding on SAML etc. And I do mean that you have to email them—last I checked it’s a mailto: link, not even a form.)
Yeah expect the experience of using Ashby has just been declining. So that’s that.
> Our thesis is that the cost of producing code is heading towards zero. AI isn’t coming for our jobs, it’s coming for the mechanical parts of them: syntax, glue code, and the tip-taps of keystrokes. The parts that are less interesting, less challenging
The cost is heading to 0???? Do they not pay for Claude, Anthropic, OpenAI? Have they not seen the sudden price increases? Hosted locally LLMs still have electrical and server costs.
When people write stupid stuff like that, can you trust anything they say?
I believe not. It shows they dont truly understand the nuance of what they are talking about.
Just by the headline: are they doing layoffs?
UPD: surprisingly not