Live data from Hacker News

AI, Ashby Engineering, and the future

ashbyhq.com

51–60 of 60 posts

Re: AI, Ashby Engineering, and the future

#51

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…

Author here! That opt out issue is definitely not intentional, I just gave it a quick try and it worked for me in a few different browsers. Feel free to ping me on colin AT ashbyhq.com with any additional details and I'll see if we can get a reproduction.

We only hire engineering managers that are deeply technical. This gives us more ability to work closely with engineers and make sure they're using new tools in the ways we want. It's not perfect. Sometimes, it goes wrong. But, that's why we continuously add tests and other tools to help us spot mistakes.

Re: AI, Ashby Engineering, and the future

#52
post #34

Earlier quoted context omitted.

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.

I may have been describing a competitor, Google Hire. It was rumoured to have been built with tech from Diane Greene's Bebop startup which was an ERP and generalized application builder.

Re: AI, Ashby Engineering, and the future

#53
post #3

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

Author here. This is valid feedback, thank you. This post was originally an internal post. Internally, I have credibility as "the guy that does his homework". That doesn't carry over to the broader internet!

I think you're right that the data presented doesn't prove or disprove the thesis that "customer issues remain broadly stable". I think it lends credibility to the idea that "AI didn't lead to an obvious and immediate slopfest of bugs".

As for the bumps, we've noticed them annually and we haven't yet found a solid reason why. There’s no correlation with customer growth, PRs shipped, or features shipped. It's likely a combination of various seasonal effects in our own hiring and customer onboarding. What isn't in this article: we've more than doubled our customer base in this time period, our customers are more mature and raise bugs more readily, we've got ~60% more engineers, and our product surface area has grown a lot too. I'm yet to land on a satisfying metric that normalizes bug rates in a changing environment.

Re: AI, Ashby Engineering, and the future

#56

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…

Author here. 100% agree with your sentiment. When we do performance reviews of engineers we take the time to comb over at least some of the PRs the engineer has written. We flag any patterns around code quality (regardless of whether it came from AI or not). This is on top of any other ongoing feedback we're giving. E.g. in a recent review I wrote I picked up on an engineer not splitting up React components aggressiv…

> When we do performance reviews of engineers we take the time to comb over at least some of the PRs the engineer has written.

Wait, whoever is reviewing the engineer isn't already familiar through exposure to – if not participation in – flow of work?

Re: AI, Ashby Engineering, and the future

#57

Earlier quoted context omitted.

Author here. 100% agree with your sentiment. When we do performance reviews of engineers we take the time to comb over at least some of the PRs the engineer has written. We flag any patterns around code quality (regardless of whether it came from AI or not). This is on top of any other ongoing feedback we're giving. E.g. in a recent review I wrote I picked up on an engineer not splitting up React components aggressiv…

> When we do performance reviews of engineers we take the time to comb over at least some of the PRs the engineer has written. Wait, whoever is reviewing the engineer isn't already familiar through exposure to – if not participation in – flow of work?

In general, yes. I believe there's a difference between writing a performance review based on your memory/notes of how someone was doing 6 months ago vs getting into the weeds of a sample of PRs/specs and reviewing those from a performance viewpoint.

Re: AI, Ashby Engineering, and the future

#58

Earlier quoted context omitted.

> When we do performance reviews of engineers we take the time to comb over at least some of the PRs the engineer has written. Wait, whoever is reviewing the engineer isn't already familiar through exposure to – if not participation in – flow of work?

In general, yes. I believe there's a difference between writing a performance review based on your memory/notes of how someone was doing 6 months ago vs getting into the weeds of a sample of PRs/specs and reviewing those from a performance viewpoint.

For sure. It's why review should be as continuous as anything one wants to improve. Annual review is a relic from the gold watch era.

Re: AI, Ashby Engineering, and the future

#59
post #50

Earlier quoted context omitted.

Because you're not just dicking around for funsies? It's fine if nobody uses your shit, but it's not fine if you have actual customers who depend on you. Maybe this is a paid feature that we're going to charge money for. Or we're going after a new market segment, or trying to take business from a rival. A new feature might have regulatory or legal requirements, somebody needs to understand all that. At the very least…

Your not going to know your classes, parameters, how data should actually be laid out in storage or represented in the application until you start writing anyway. It's always an iterative process.

Kind of, but not really. Those things are hard when you're learning, but they're pretty trivial after some experience.

I almost always have a pretty good idea of what I'm making and how I'm going to make it before I start.

Post reply on HN