Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AI, Ashby Engineering, and the future

ashbyhq.com

Post reply on HN
Print view View original

21–30 of 60 posts

Re: AI, Ashby Engineering, and the future

#21

Post by jpalawaga »

brettgriffin wrote: post #13

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

I suspect the ceo of greenhouse wasn't saying 'and there will never be another new ats again.' that's a ridiculous thing to say, as evidenced by the fact that greenhouse and lever both cropped up.

the reality actually is, you DO need depth in order to close lucrative enterprise contracts.

but startups will use anything. you use early money/traction to fund the deeper features. that's saas/startup 101.

anyhow, saas just means the second "s" matters more. maybe software gets cheaper (that's actually an unproven hypothesis), but service encompasses many dimensions. the most lucrative contracts won't be eaten by fly-by-the-night operations almost by definition. any startup that knows the words 'vendor risk' will tell you.

Re: AI, Ashby Engineering, and the future

#22

Post by brettgriffin »

jpalawaga wrote: post #21
brettgriffin wrote: post #13

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

I suspect the ceo of greenhouse wasn't saying 'and there will never be another new ats again.' that's a ridiculous thing to say, as evidenced by the fact that greenhouse and lever both cropped up. the reality actually is, you DO need depth in order to close lucrative enterprise contracts. but startups will use anything. you use early money/traction to fund the deeper features. that's saas/startup 101. anyhow, saas ju…

He didn't say there wouldn't be competitors. He was actually acknowledging the competitors exist, but he was expressing how none of them are in the consideration set of Greenhouse's buyers because they lacked an enormous number of features that Greenhouse had. My point is, at least behind closed doors, he and most CEOs would admit that their features are an eroding defense as the cost of code approaches zero.

Re: AI, Ashby Engineering, and the future

#23

Post by cute_boi »

agentultra wrote: post #5

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

These job portals are getting out of hand. These days, forget AI scans, recruiters are asking me for SSN and all sorts of personal information. I have been refusing to provide it so far. But many people do provide it, which puts people like me at a disadvantage.

Re: AI, Ashby Engineering, and the future

#24

Post by habinero »

tayo42 wrote: post #18
samstokes wrote: post #16

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

Writings code has been viewed as an expensive part of development for a while. That's why the coding interview script the industry has adopted requires you to to not write any code until you suffenciently planned the whole problem.

No? You do that to make sure everyone understands and agrees on what to build.

Writing code is the easy part. Figuring out what your new feature or product should do is the hard part.

Re: AI, Ashby Engineering, and the future

#25

Post by tayo42 »

habinero wrote: post #24
tayo42 wrote: post #18

Earlier quoted context omitted.

Writings code has been viewed as an expensive part of development for a while. That's why the coding interview script the industry has adopted requires you to to not write any code until you suffenciently planned the whole problem.

No? You do that to make sure everyone understands and agrees on what to build. Writing code is the easy part. Figuring out what your new feature or product should do is the hard part.

Because the assumption is code is expensive to generate. Otherwise why would you put all the upfront effort into all of the planning?Just write some code and iterate on where it goes.

Re: AI, Ashby Engineering, and the future

#27

Post by abhikp »

georgespencer wrote: post #2

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…

Ashby Co-founder & VPE here, happy to chat if you have time to share feedback, abhik AT ashbyhq ᐧ com.

We had to build a lot of product in a short period of time to be a viable option to replace incumbent ATSes who had fought off many startups (and it couldn't be buggy or unreliable). The startups that focused on simplicity and usability just never made it. So, we focused on building something flexible and customizable first, with usability being something we wanted to make excellent second. You probably felt that over the past few years, and I'm sorry you did. We've been working hard to improve it, especially in the past year (e.g., you can self-serve account downgrades and some product upgrades now!).

Still more work to do, but thanks for putting up with some of our deficiencies :)

Re: AI, Ashby Engineering, and the future

#29

Post by saadn92 »

square_usual wrote: post #15
agentultra wrote: post #5

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

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.

Re: AI, Ashby Engineering, and the future

#30

Post by samstokes »

tayo42 wrote: post #25
habinero wrote: post #24

Earlier quoted context omitted.

No? You do that to make sure everyone understands and agrees on what to build. Writing code is the easy part. Figuring out what your new feature or product should do is the hard part.

Because the assumption is code is expensive to generate. Otherwise why would you put all the upfront effort into all of the planning?Just write some code and iterate on where it goes.

Code being expensive would be one reason to plan, but hardly the only one. Some other reasons: cost of failure (don't leak customer PII), maintenance, unclear requirements, unclear success criteria.
Post reply on HN