Live data from Hacker News

AI, Ashby Engineering, and the future

ashbyhq.com

31–40 of 60 posts

Re: AI, Ashby Engineering, and the future

#31
post #29

Earlier quoted context omitted.

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.

Bugs did exist, but bugs that come from AI generated code can be easily avoided if a good enough engineer designed it. Also, the rate at which AI generates code means that there's A LOT more bugs now than there used to be.

I'm sure the engineering teams of every company in the world is just "good enough engineers" and not, you know, regular devs who ship bugs at the same rate that has been now. And I'm sure your personal anecdote of "I saw a bug" shows that there's more bugs being shipped now.

Re: AI, Ashby Engineering, and the future

#32

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?

Benji Co-Founder & CEO here. Curious which areas of the product you've touched on that you're disappointed with? We have ample things we want to improve - but the reason folks are switching to us is that we're well ahead of competition on most dimensions. I also was an EM on the prior generation of products which let us to build Ashby. But it's a surprisingly broad product and so takes a long time to perfect.

Re: AI, Ashby Engineering, and the future

#34

> 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 t…

Co-Founder of Ashby here, just want to correct the record, that we were not targeting a mid-market ERP. We really wanted to build better hiring software. While our first customer was on our analytics-only product, it was built on a platform intended to be an ATS. We did build some abstractions/building blocks that are not hiring-software-specific (e.g., a workflow engine) because we recognized they allowed us to build rich features faster.

Re: AI, Ashby Engineering, and the future

#35

> 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 t…

“What happens to the SaaS markets when the cost of code approaches zero?” … “Few people truly grasp how hard bringing a software product to market is.”

Are these related? The difficulty of bringing a software product to market has never been that it takes time to produce code. We’ve had the concept of MVPs for decades and pre-AI companies have raised hundreds of millions off of no code prototypes.

YC has always preached that you launch. Launch today. Launch as soon as is humanly possible. And learn. And iterate. You get something into the market as soon as possible. Spending years building the perfect software has never been the strategy pursued by technology startups, and not because of the time it takes, but because you need users to know what to build.

I think we could even go as far as to counter your argument. We know that constraints are powerful. Constraints force us to focus. Imagine you decide to build an ATS. You spend a bunch of money on Claude Code to generate hundreds of features, every little idea you can think of, you include it. You launch with the most complete ATS on the market. Ashby can’t hold a candle to the depth of your software. Do you have a better chance of success than if you had launched with a much smaller surface area, experimented, found the right area of focus, and iterated according to user behavior?

I encounter a lot of vibe coded software products that people are launching and I am not precious about code, a good product is a good product whether it was hand crafted over a decade by a thousand well paid programmers or generated in an afternoon by Claude Code from a laypersons prompt. I can name one single vibe coded product I pay for that is genuinely good software. All that the AI age has done is show that most of us absolutely suck at building products, and that even with free code, what we produce is garbage.

“How could the market afford to build and sustain each offering?”

I think you’re conflating build and sustain here. Nothing fundamental about business has changed. Sustaining a business isn’t about being able to generate code. Even in a world where code is free, how could the market sustain 10,000 Ashbys? Where are the customers coming from?

As a concrete example: how many customers does Jira have despite Linear being better software in every single way? Would generating 1,000 more Linears change Jira’s market position? Or Microsoft Teams, Teams is awful, there are so many better options. Will generating 1,000 more better options change Microsoft Teams’s position?

Re: AI, Ashby Engineering, and the future

#36
post #34

> 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 t…

Co-Founder of Ashby here, just want to correct the record, that we were not targeting a mid-market ERP. We really wanted to build better hiring software. While our first customer was on our analytics-only product, it was built on a platform intended to be an ATS. We did build some abstractions/building blocks that are not hiring-software-specific (e.g., a workflow engine) because we recognized they allowed us to buil…

Apologies. When I met you in circa spring 2019 you described Ashby to me as mid-market ERP, which I had quite a few thoughts on given the amount of ERP work I had done. Sorry for droning on about ERPs to you, then.

Re: AI, Ashby Engineering, and the future

#37
post #35

> 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 t…

“What happens to the SaaS markets when the cost of code approaches zero?” … “Few people truly grasp how hard bringing a software product to market is.” Are these related? The difficulty of bringing a software product to market has never been that it takes time to produce code. We’ve had the concept of MVPs for decades and pre-AI companies have raised hundreds of millions off of no code prototypes. YC has always preac…

The P&L of every software company has an R&D expense (R) in a total cost (T). We can debate what R is, and R might be approaching 0, but it is not 0.

This does not mean that R is on the only cost (T-R grows over the life of the company). It does not mean that, even if R were 0, you could launch a product. But R is a real cost.

Re: AI, Ashby Engineering, and the future

#39
To me, if "you are responsible for what you write" is to mean anything in an org, it needs to come with teeth. If you are demonstrably _not_ responsible for what you write, that needs to be recognized and treated as underperformance. I've seen a couple orgs who had some flavor of "you are responsible for what you write" guidance, and they mostly fail to follow through on it. People who ignore that guidance and ship a lot of low quality stuff (code, design docs, PRs) survive perf cycles and tend to get shout outs from management for moving quickly. People who take it to heart will tend to look slower by comparison (their work may be better, but often not in ways that are legible or compelling to management), and may be less favorably viewed when it comes to raises, promos, and so on.

I have no reason to doubt the sincerity of the authors of that post (and enjoyed reading it), I just hope they have a good sense of how they're recognizing responsible and irresponsible use and taking that into account in a perf process.

Re: AI, Ashby Engineering, and the future

#40
post #35

Earlier quoted context omitted.

“What happens to the SaaS markets when the cost of code approaches zero?” … “Few people truly grasp how hard bringing a software product to market is.” Are these related? The difficulty of bringing a software product to market has never been that it takes time to produce code. We’ve had the concept of MVPs for decades and pre-AI companies have raised hundreds of millions off of no code prototypes. YC has always preac…

The P&L of every software company has an R&D expense (R) in a total cost (T). We can debate what R is, and R might be approaching 0, but it is not 0. This does not mean that R is on the only cost (T-R grows over the life of the company). It does not mean that, even if R were 0, you could launch a product. But R is a real cost.

“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.”

What proportion of T does R need to be to see thousands of Ashbys appear?

Ashby is a good example to discuss because it is serious software for serious businesses, it isn’t a calorie counting app. Serious business expects so much more out of their suppliers than software, Ashby is so much more than a bunch of code.

So, a thousand people generate their own ashbys, then what? Are companies like Shopify and Ramp going to trust their ATS to some person who generated some software in a day?

I agree that the cost of building software has gone down a lot and that lowers the barrier to entry for building a software business. I completely disagree that the market could support even 10x the number of companies in each vertical, let alone 100x or 1000x.

You could clone Ashby today and go to Ramp and offer them a 50% discount on whatever they’re paying Ashby and there is zero chance you win their business. You could clone Ashby and the add 10x the features and go to ramp and offer a 75% discount and there is zero chance of you winning their business.

Post reply on HN