41–50 of 60 posts
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,…
Why read article with human brain if not written by human brain?
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?
> 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 a…
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…
E.g. in a recent review I wrote I picked up on an engineer not splitting up React components aggressively enough and over-relying on deeply nested ternaries. In that same review I also commended the engineer for being particularly excellent at explaining complex bugs to our support people and called out one example of a nasty race condition.
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 customizab…
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.
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.
To answer your question: I mainly used Lever before and it was more or less OK, just like Ashby is OK. So, I'm not saying it's a bad product, it's probably a good product. I just don't see it "so much better" to justify a switch from Lever from my point of view. Both are "good enough" from an hiring manager perspective (or at least, my perspective).
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.
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, someone wants this new thing for a reason. You can't just guess, you actually have to talk to people and understand the problem domain lol.
Earlier quoted context omitted.
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.
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…