HN user
Building AI for support at www.assembled.com
Fascinating! Hadn't heard of speech-core before, but will check it out if we are thinking about adding voice (though right now are focused on some more core-platform specific things like allowing for multiple changesets in a single session and adding memory across runs)
(Author here) I stand by this comment and I think it’s really important for engineers to recognize that everyone has different places where they gain and lose energy.
My team and I have been extremely lucky in hiring Joe, our excellent head of engineering, and an extremely strong set of engineering managers. Not to mention incredibly strong product and user experience management.
I think it’s pretty obvious that my approach wouldn’t work if I didn’t have this bench of talented managers, but because I do it affords me the luxury to spend time doing things that I love and which are also valuable to the company.
In general, I wrote this article because I think that the classical approach to engineering management isn’t the only path you need to take, and a lot depends on the team you work with (thankfully we have a team that complements each other really well).
(Author here): I hear what you’re saying, though I’ve never “crowed about regularly checking code in on Saturdays and Sundays” and I think that’s a false characterization of my article.
Do I love to code? For sure. Is it something I do on the weekends? Generally yes because it’s something incredibly fun for me, and it gives me a lot of energy. Now, is it an expectation I have of my team? No, it’s not because I want a sustainable pace for the team and I recognize not everyone has the same relationship with work or coding as I do.
And on the “circumventing process” bit — what I shared wasn’t an example of blowing past legal/security review recklessly. It was a case where I, as someone with full context, could quickly build something safe and unblock a customer, going through our normal code review and deploy process. I don’t expect anyone (myself included), to have any exceptions to this.
Very true, and I promise we didn’t solve P vs NP over lunch :). We just got much better at not exploring useless parts of the tree
From the API standpoint, it makes a lot of sense for us to be able to provide different types of providers. And we've found also that different models/providers are better at different types of tasks. For example, the Gemini models have really great latency, which are good for specific types of tasks that are very latency sensitive, but we've found reasoning to be quite strong with OpenAI/Anthropic.
To be clear, we still hire engineers who are early in their careers (and we've found them to be some of the best folks on our team).
All the same principles apply as before: smart, driven, high ownership engineers make a huge difference to a company's success, and I find that the trend is even stronger now than before because of all the tools that these early career engineers have access to. Many of the folks we've hired have been able to spin up on our codebase much faster than in the past.
We're mainly helping them develop taste for what good code / good practices look like.
In my experience, it still does take quite a bit of time (minutes) to run a task on these agentic LLMs (especially with the latest reasoning models), and in Cursor / Cline / other code editor versions of AI, it's enough time for you to get distracted, lose context, and start working on another task.
So the benefit is really that during this "down" time, you can do multiple useful things in parallel. Previously, our engineers were waiting on the Cursor agent to finish, but the parallelization means you're explicitly turning your brain off of one task and moving on to a different task.
Some engineers on my team at Assembled and I have been a part of the alpha test of Codex, and I'll say it's been quite impressive.
We’ve long used local agents like Cursor and Claude Code, so we didn’t expect too much. But Codex shines in a few areas:
Parallel task execution: You can batch dozens of small edits (refactors, tests, boilerplate) and run them concurrently without context juggling. It's super nice to run a bunch of tasks at the same time (something that's really hard to do in Cursor, Cline, etc.)
It kind of feels like a junior engineer on steroids, you just need to point it at a file or function, specify the change, and it scaffolds out most of a PR. You still need to do a lot of work to get it production ready, but it's as if you have an infinite number of junior engineers at your disposal now all working on different things.
Model quality is good, but hard to say it's that much better than other models. In side-by-side tests with Cursor + Gemini 2.5-pro, naming, style and logic are relatively indistinguishable, so quality meets our bar but doesn’t yet exceed it.
Thanks for the suggestion -- I'll take a look into adding this!
Author here: Yes, there are certain functions where writing good tests will be difficult for an LLM, but in my experience I've found that the majority of functions that I write don't need anything out of the ordinary and are relatively straightforward.
Using LLMs allows us to have much higher coverage than if we didn't use it. To me and our engineering team, this is a pretty good thing because in the time prioritization matrix, if I can get a higher quality code base with higher test coverage with minimal extra work, I will definitely take it (and in fact it's something I encourage our engineering teams to do).
Most of the base tests that we use were created originally by some of our best engineers. The patterns they developed are used throughout our code base and LLMs can take these and make our code very consistent, which I also view as a plus.
re: Complacency: We actually haven't found this to be the case. In fact, we've seen more tests being written with this method. Just think about how much easier it is to review a PR and make edits vs write a PR. You can actually spend your time enforcing higher quality tests because you don't have to do most of the boilerplate for writing a test.
Assembled | Software Engineer, Product Manager | San Francisco or New York | Full-time
Assembled helps customer support teams resolve issues with the right agent, providing the right answer, at the right time. Over 300 industry leaders, including Etsy, Stripe, and Georgia's Department of Human Services, use Assembled’s workforce management and LLM-powered automation products to make optimal staffing decisions, improve productivity, and reduce wait times. Support is a $33b software market expected to accelerate due to AI adoption - and we’re positioned to become a leader.
For some more info, check out our blog post on Reciprocal Rank Fusion and Hybrid Search: https://www.assembled.com/blog/better-rag-results-with-recip... or some Q&A with our early employees that highlight what life is like at Assembled: https://www.assembled.com/blog/100-assemblers-and-counting-a...
Our open roles include:
- Software Engineer: https://boards.greenhouse.io/assembled/jobs/4957681004
- Product Manager: https://job-boards.greenhouse.io/assembled/jobs/4101414004
- And more: https://www.assembled.com/careers-at-assembled
Assembled (https://assembled.com/) | San Francisco, CA | Software engineer -- Assist, Product Manager -- Assist
Help us build an AI issue resolution engine for customer support. We work with some of the top brands in the world in customer support (Stripe, Etsy, Robinhood, DoorDash, etc.) and we're building a new AI product to streamline support workflows.
You'd be one of early people on our AI product and you'd work directly with me (CTO & Co-founder) to shape the early stages of development on the product. Read more about how our team operates here: https://www.assembled.com/blog/a-conversation-with-the-team-.... We recently posted on Hacker News about some of the techniques we use to improve accuracy of our responses: https://www.assembled.com/blog/better-rag-results-with-recip...
Apply here: https://boards.greenhouse.io/assembled/jobs/4957681004 or email me at john (at) assembled.com
It's a good call out -- we use smoothing parameters that are closer to what you see in the academic articles (they're tuned slightly, but not much).
We used 1/Rank in the article for simplicity purposes, though I can see why this might be confusing to an astute reader.
Author here: you're for sure right -- it's not a problem with RAG the theoretical concept. In fact, I think RAG implementations should likely be specific to their use cases (e.g. our hybrid search approach works well for customer support, but I'm not sure if it would work as well in other contexts, say for legal bots).
I've seen the whole gamut of RAG implementations as well, and the implementation, specifically prompting and the document search has a lot to do with the end quality.
Assembled (https://assembled.com/) | San Francisco, CA | Software engineer -- AI & New Products, Product Manager -- AI & New Products
We're hiring a frontend focused engineer and a product manager to join our New Products Team. We work with some of the top brands in the world in customer support (Stripe, Etsy, Robinhood, DoorDash, etc.) and we're launching a new AI product to streamline support workflows.
You'd be one of early people on our AI product and you'd work directly with me (CTO & Co-founder) to shape the early stages of development on the product. Read more about how our team operates here: https://www.assembled.com/blog/a-conversation-with-the-team-...
Apply here: https://boards.greenhouse.io/assembled/jobs/4957681004 or email me at john (at) assembled.com
Assembled (https://assembled.com/) | San Francisco, CA | Software engineer -- AI & New Products
We're hiring a frontend focused engineer to join our New Products Team. You'd be one of the first engineers working on our AI product that assists customer support agents and automates common workflows. You'd report into me (CTO & Co-founder) and would get to shape the early stages of development on the product. Read more about how our team operates here: https://www.assembled.com/blog/a-conversation-with-the-team-...
Apply here: https://boards.greenhouse.io/assembled/jobs/4957681004 or email me at john (at) assembled.com
Appreciate it Max! We definitely had some challenges initially, but going into full startup mode helped us get way deeper with users and iterate more quickly
Assembled | Software Engineer, Senior Software Engineer, Engineering Manager, UX Developer | Full Time | SF, NYC
We're transforming customer support for the most modern companies in the world. Our customers include Stripe, Etsy, Zoom, and Asana among others. We solve deep technical and algorithmic problems (how do you forecast support demand, how do you schedule thousands of agents within shift constraints, etc.) while priding ourselves on our user experience.
If you're interested in working in a dynamic, fast paced environment with lots of ownership, you'd be a great fit!
We target 90th percentile compensation across all roles against companies of similar size/funding.
Assembled | Software Engineer, Senior Software Engineer, Engineering Manager | Full Time | SF, NYC
We're transforming customer support for the most modern companies in the world. Our customers include Stripe, Etsy, Zoom, and Asana among others. We solve deep technical and algorithmic problems (how do you forecast support demand, how do you schedule thousands of agents within shift constraints, etc.) while priding ourselves on our user experience.
If you're interested in working in a dynamic, fast paced environment with lots of ownership, you'd be a great fit!
We target 90th percentile compensation across all roles against companies of similar size/funding.
Zinc is still running! Xiang Li (https://www.linkedin.com/in/xli88/) is at the helm and pushing it to bigger and better things.
For why we took VC funding for Assembled: the full explanation is probably worth its own article. But the short answer is that the space and the opportunity are really big in customer support and the money helps us move much faster.
Author here: to be clear, I asked if it was OK to start later after the family vacation, but my manager said I could just start earlier and take the family vacation as a large amount of PTO. There wasn't anything malicious there.
Thanks Gordon, those were good times =)
Author here: I started by making really small patches at the beginning and building up credibility with the team. For example, one of my earliest commits was just to add better verbiage on migrations (https://github.com/rails/rails/commit/b4c99ea0a4d7e5223fa1b2...). Eventually the core team saw my name enough that my pull requests could get more complex.
I'm a bit biased (I work at Assembled and used to work at Stripe), but Jen's story is awesome. From learning SQL to then doing sales ops and support at Stripe and finally leading quite a few business functions at Assembled is really inspiring.
Assembled | Frontend Software Engineer | San Francisco, CA | Full-time
Assembled (https://www.assembled.com/) aims to transform and elevate customer support and provides the tools for modern organizations to do so in a scalable way. Our workforce management platform helps teams solve forecasting, scheduling, and analytics in order to provide great experiences for their customers. We're a small team (8 total, 5 engineers) but already work with some of the most progressive organizations in the world, including iconic technology companies like Google and Stripe and renowned retail brands like Harry's and Glossier.
Some examples of our recent work include:
- Improving performance of our team calendar with better lifecycle management
- Connecting Webflow's CMS to templated pages for our blog
- Upgrading drag-and-drop UX to speed up schedule management
Our frontend stack consists of React, Flow, Figma, and Webflow, but we don't require any prior experience with any of them.
If this sounds exciting, please send us a note with a bit about yourself to careers@assembled.com.
We run into this for customer support (www.assembled.com) and one of the things we've learned is that the ability to solve the fully constrained problem in the real world is not quite enough, at least for our customers.
Quite often, people are looking for the right set of constraints to apply so they're kind of running a meta problem on top of the NSP. How many back-to-back shifts should I allow? Should people's shifts always start at the same time? Can I give some people regular 9-5 schedules? All of the above questions will decrease the strict optimality of the solution, but increase the happiness and long term retention of your workforce. Thus, the question really become, how much do each of these cost in terms of optimality and what are the tradeoffs.
We've found that developing a very fast heuristic algorithm for the NSP allows people to iterate quickly on these types of questions (even though it's not quite as optimal as a SAT solver). We use a greedy algorithm with a heuristic that is relatively specific to our problem domain to ensure that we have a reasonable combination of speed and optimality.
Thanks, very much appreciate it =)
If I hire Assembled to help with support, what can they provide?
Obviously, they will have zero knowledge of the product. What can Assembled help with here?
These are very good questions and they raise a very valid point: Assembled will not have deep knowledge of your product (at least not as deep of a knowledge as your own support agents). However, we do have deep knowledge about how support teams are run in general. We've talked to hundreds of support teams, large and small, and are knee deep in the customer service industry.
Our product doesn't answer front line support questions, but rather helps you manage agent schedules and determine the best times to staff your agents. To do this, we forecast support volume, and correspondingly, how many agents are required to handle that volume. This is important because a large part of great customer support is how quickly you're able to respond.
This is a much different way to improve support than by just answering questions. We try to make your team more efficient without the need to hire more people. The cool thing here is that you can still layer on deflection systems (to reduce ticket volume) and enhance agent performance (via QA systems) in addition to what we do.
+1, very much agree with this. AI-driven chatbots are a piece of the puzzle for many of our users -- they cover commonly asked questions and can deflect a lot of questions. But it’s still just a portion of the work (even if a majority of volume). For example, a lot of “hard” support questions involve jumping between systems and following complicated (often nonexistent) procedures, even aside from models that understand intent.
Also to be fair to our team, we do have a bunch of problems that we no longer think of as AI, but are still super algorithm-intensive: forecasting, modeling of queues, and schedule optimization.
Thanks for the kind words! We've definitely seen a ton of small companies that started out with spreadsheets and internal tools. That's why we wanted to mimic the ease of use of Google Sheets while providing out-of-the box features that support teams usually ask for, like forecasting.