navanchauhan

I used to think so too, but now I usually just have Muse or another AI agent on my box do those things for me. I should maybe create a slimmed down API first *arr stack equivalent then hmm

apg?

Technically, it is on GitHub in my swift-omnikit library. But, this library is only meant to be consumed by me for now.

I plan on separating out the UI portions to its own repo and then polish it up

I have been building a drop in replacement for SwiftUI that can render with different renderers (TUI for now and GTK/Adwaita very soon). This will be such an awesome demo use case for it.

Congratulations on getting this out!

I thought YouTube had native RSS feeds for channels?

> What do you show to new folks when they join your team?

I think this is an interesting question because we have not fully figured out the best way to onboard people to our codebases. Each person is responsible for multiple codebases (yay microservices!), and no one else commits to a repository while they have dibs. We also have conventions for how agents write documentation around deployments and validations.

In theory, when a new person joins the team or is handed a repository, they can throw some tokens at the codebase, interrogate it, and ask questions about how things are implemented.

> But what is the result of your work?

The end result is a final, working codebase. The specs and sprint plans are also committed to the repository for posterity, so agents in a fresh session can see what work has been completed and the trajectory we are moving toward.

The model could start building on top of things it had successfully built before instead of just straight up exponential error propagation

Using models to go from spec to program is one use case, but it’s not the whole story. I’m not hand-writing specs; I use LLMs to iteratively develop the spec, the validation harness, and then the implementation. I’m hands-on with the agents, and hands-off with our workflow style we call Attractor

In practice, we try to close the loop with agents: plan -> generate -> run tests/validators -> fix -> repeat. What I mainly contribute is taste and deciding what to do next: what to build, what "done" means, and how to decompose the work so models can execute. With a strong definition of done and a good harness, the system can often converge with minimal human input. For debugging, we also have a system that ingests app logs plus agent traces (via CXDB).

The more reps you get, the better your intuition for where models work and where you need tighter specs. You also have to keep updating your priors with each new model release or harness change.

This might not have been a clear answer, but I am happy to keep clarifying as needed!

This was an experiment that Justin ran: one person fresh out of college, and another with a long, traditional career.

Even though all three of us have very different working styles, we all seem to be very happy with the arrangement.

You definitely need to keep an open mind, though, and be ready to unlearn some things. I guess I haven’t spent enough time in the industry yet to develop habits that might hinder adopting these tools.

Jay single-handedly developed the digital twin universe. Only one person commits to a codebase :-)

No. But, I do ask questions (in $CODING_AGENT to always have a good mental model of everything that I’m working on though.

I think this comment is slightly unfair :(

We’ve been working on this since July, and we shared the techniques and principles that have been working for us because we thought others might find them useful. We’ve also open-sourced the nlspec so people can build their own versions of the software factory.

We’re not selling a product or service here. This also isn’t about positioning for an acquisition: we’ve already been in a definitive agreement to be acquired since last month.

It’s completely fair to have opinions and to not like what we’re putting out, but your comment reads as snarky without adding anything to the conversation.

You're absolutely right ;)

Your intuition/thinking definitely lines up with how we're thinking about this problem. If you have a good definition of done and a good validation harness, these agents can hill climb their way to a solution.

But you still need human taste/judgment to decide what you want to build (unless your solution is to just brute force the entire problem space).

For maximal leverage, you should follow the mantra "Why am I doing this?" If you use this enough times, you'll come across the bottleneck that can only be solved by you for now. As a human, your job is to set the higher-level requirements for what you're trying to build. Coming up with these requirements and then using agents to shape them up is acceptable, but human judgment is definitely where we have to answer what needs to be built. At the same time, I never want to be doing something the models are better at. Until we crack the proactiveness part, we'll be required to figure out what to do next.

Also, it looks like you and Danvers are working in the same space, and we love trading notes with other teams working in this area. We'd love to connect. You can either find my personal email or shoot me an email at my work email: navan.chauhan [at] strongdm.com