localbuilder

This is fascinating work, amazing job to the team!

Does SwiftUI have properties that uniquely make this type of interpreted system possible, or could it also use UIKit under the hood? On the surface, it seems like UIKit might be more difficult since you’d probably need to parse all of the obj-c header files in addition to the .swiftinterface.

Very cool stuff, excited to follow along how you all develop the product!

> There’s one issue with this, you’ll have to be careful to keep the “N – 1” interactions updated whenever you make some changes because you will be “simulating” something that will never happen again in your agent.

This is the biggest problem I've encountered with evals for agents so far. Especially with agents that might do multiple turns of user input > perform task > more user input > perform another task > etc.

Creating evals for these flows has been difficult because I've found mocking the conversation to a certain point runs into the drift problem you highlighted as the system changes. I've also explored using an LLM to create dynamic responses to points that require additional user input in E2E flows, which adds its own levels of complexity and indeterministic behavior. Both approaches are time consuming and difficult to setup in their own ways.

Yeah constant visibility is a great practice. I’ve used todo lists in a notebook in a similar way, constantly open on my desk so I can always be auditing my progress on things

Nice, I’ve used simple notes in markdown in the past also. Definitely a simple and effective way to make sure you're on top of everything.

I like that practice. That way you’re always conscious of everything in flight and stuff isn’t slipping through the cracks. Will be looking into that system more

Yeah no specific definition of tool, just curious how people organize their projects at smaller scales. But a wiki and version control makes sense to keep things lightweight. I could definitely see heavier tools definitely add too much overhead at that stage

We’re addressing a different use case from Calendly. Our focus is on automating meeting scheduling for internal teams. We add the most value to projects that have several stakeholders and require discussion across a lot of different teams.

Calendly is more external facing, it’s a great tool for scheduling meetings with people that aren’t in my organization such as inbound sales prospects

You can probably achieve similar results if you setup your own agent in front of a calendar MCP server, but it took a lot of prompt and tool response refinement to start seeing consistent results. Scheduling larger groups of people, or people across different time zones are some examples of things we needed to optimize for individually.

Our goal here is to offer a turn-key solution that drops into your existing tools and just works out of the box, so you don’t need to build any of those integrations yourself