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