On NextWork, learners describe an AI project they want to build and we generate a step-by-step guide. That generation takes five to ten minutes, but sometimes a matching project already exists.
We built Instant Match to surface those projects before starting a new generation. The appeal was straightforward - if someone asks to build something we already have, they can start right away.
Building it, however, meant tackling an interesting technical question… how do we know if an existing project is the right one to offer?
Learners do not describe the same goal in the same words
Our first version stored completed projects alongside the prompts that created them. If another learner used the same prompt, Instant Match could offer the existing project.
That worked for exact matches, but it didn’t account for how our learners actually ask for projects. One learner might ask to “Build an AI assistant for my PDFs”, while another asks to “Chat with my PDFs”. The same project could help both of them, but Instant Match would read those two as different prompts. The second learner would have to wait for a new project to generate instead of being offered one we already had.
To catch requests like these, we added embeddings to compare the meaning of requests rather than their wording alone. This gave us a way to find projects that were similar, even when the prompts were phrased differently.
At first we set a high similarity threshold because we did not want to offer unsuitable projects. That protected against poor matches, but it also excluded projects that would have been useful. To solve this, we lowered the threshold to produce a broader shortlist, then added a language model to read each project’s content and decide which one best matched what the learner asked to build. This takes us to the next interesting challenge - evaluating a project’s compatibility with the learner’s request and environment.
Finding a project on the right topic is not always enough
A learner asking to “Set up monitoring for my app” could match two projects: one for apps running on EC2 using CloudWatch, and another for apps running on Kubernetes using Prometheus. Both are about monitoring, so in this scenario, we should find out more about the learner’s setup (e.g. whether they’re running the app in EC2 or Kubernetes) to recommend the best fit project. But when we tested this scenario, Instant Match would randomly choose any one of the projects without knowing the learner’s setup, risking giving instructions that wouldn’t actually work.
It turns out it was because our instructions gave the model conflicting guidance on how to approach this. One rule told it to choose the first project that fit any broad request (which the model follows), while another told it to decline if the choice depended on information the learner hadn’t provided.
We updated those instructions so we always check each shortlisted project’s required tools and setup first. If they require different setups and the learner hasn’t specified theirs, Instant Match will now decline the match so we can ask a follow-up question.
We found the same issue in a different form when someone asked, “Where should I start?” That is a request for help choosing what to learn, not a request to find a project. Instant Match had been treating it as the latter and making a recommendation before learning anything about the person’s interests or experience.
Those requests now open a conversation first. These updates to instant match help make sure that any learner who knows what they want to build can reach a project quickly, while someone who is still working out where to begin gets help making that decision.
A match should lead back to the original project
We also had to reconsider what happened after someone accepted a match. Originally, Instant Match created a copy of the project for every learner. That made sense for someone who wanted to edit another author’s instructions. But many learners simply wanted to follow the instructions.
Automatically making a copy meant two things for a learner’s experience:
Someone getting Instant Matched to a project they had already started could land in a fresh copy without their progress.
New completions on those copies wouldn’t count towards the original author’s project. We want authors to see when their work helps someone else learn. If you put care into a project, seeing people complete it is part of the reward: they found it useful enough to work through, and that activity should be visible on the project you created. Copying it automatically meant that connection was being lost.
To keep that progress and recognition together, we changed Instant Match to open the original project, just as it would open from a search result. Learners can return to their progress, and each completion contributes to the original project’s completion count. If a learner wants to change the original author’s instructions, we’re now building a feature where learner can create a copy when they choose to edit.
Final thoughts
Brandon first pitched Instant Match before his first day at NextWork, then carried it through to make it a feature in the product - shoutout Brandon!
The wider promise of Instant Match is that a project should not stop being useful when the person who generated it finishes. It should be able to help the next learner with a similar goal, while giving its original author a visible record of the people it has helped.
That changes what project generation can become, and also points towards a larger question for us: how do we make each project more useful over time, for the learner who creates it and for the people who come after them?