navanchauhan

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 am finally getting close to my vision of `write once run everywhere with SwiftUI`. The idea is to create a drop-in replacement called OmniUI which will have different renderer backends (I currently have TUI w/ notcurses and Adwaita/GTK working)

s/import SwiftUI/import OmniUI/

As long as you aren't using Apple platform specific libraries like Vision, you should be good for the most part. I am going to make my Gopher browser (https://web.navan.dev/iGopherBrowser/) the first target. I have done some extra stuff like reimplementing CoreData/SwiftData to make it work on Linux.

I am going with Adwaita instead of pure GTK because I like the opinionated approach they have with their design language. I think the reason SwiftUI works is because you can get pretty looking apps without thinking too much.

Projects like adwaita-swift, and swift-cross-ui do exist, but I want my library to be a drop-in replacement. I don't want to be inspired by SwiftUI, I want to use SwiftUI everywhere!

Not affiliated with Sesame, but this is what the realtime models are trying to solve. If you look at NVIDIA’s PersonaPlex release [0], it uses a duplex architecture. It’s based on Moshi [1], which aims to address this problem by allowing the model to listen and generate audio at the same time.

[0] https://github.com/NVIDIA/personaplex

[1] https://arxiv.org/abs/2410.00037

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.

https://github.com/strongdm/attractor

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

It’s part of the “lore” that gets passed down when you join the company.

Funnily enough, the marketing department even ran a campaign asking, “What does DM stand for?!”, and the answer was “Digital Metropolis,” because we did a design refresh.

I just linked the website because that’s what the actual company does, and we are just the “AI Lab”

Domain Model (https://strongdm.com)

I would spend those $100 on either API tokens or donate to a charity of your choice. My interview to join this team was whether I could build something of my choosing in under an hour with any coding agent of my choice.

No local model out there is as good as the SOTA right now.

I think corporate incentives vs personal incentives are slightly different here. As a company trying to experiment in this moment, you should be betting on token cost not being the bottleneck. If the tooling proves valuable, $1k/day per engineer is actually pretty cheap.

At home on my personal setup, I haven't even had to move past the cheapest codex/claude code subscription because it fulfills my needs ¯\_(ツ)_/¯. You can also get a lot of mileage out of the higher tiers of these subscriptions before you need to start paying the APIs directly.

A few overnight “attractor” workflows serve distinct purposes:

* DRYing/Refactoring if needed

* Documentation compaction

* Security reviews

(I’m one of the people on this team). I joined fresh out of college, and it’s been a wild ride.

I’m happy to answer any questions!

I use a self hosted instance of [Isso](https://isso-comments.de) on my static site

https://web.navan.dev (Generated from my GitHub repo navanchauhan/navanchauhan.github.io )

Web because there is also gopher://gopher.navan.dev

I believe this is because you are logged in. You can generate a free API key (with very low limits) through Google AI Studio and use that to test it.

In an ideal world, this workaround would not be needed

¯\_(ツ)_/¯

Are the primitives not already there?[0]

I don't see why we cannot build an app that when connected to an external monitor switches to a "Desktop Environment". Maybe, even a hacked version of UTM[1] that exposes a fully functional OS on the monitor.

[0] https://developer.apple.com/documentation/uikit/presenting-c...

[1] https://github.com/utmapp/UTM

Endpoint Security Extension and Network Extension

I used `sandbox-exec` previously before moving to a better solution (done right, sandboxing on macOS can be more powerful than Linux imo). The way `sandbox-exec` works is that all child processes inherit the same restrictions. For example, if you run `sandbox-exec $rules claude --dangerously-skip-permissions`, any commands executed by Claude through a shell will also be bound by those same rules. Since the sandbox settings are applied globally, you currently can’t grant or deny granular read/write permissions to specific tools.

Using a proxy through the `HTTP_PROXY` or `HTTPS_PROXY` environment variables has its own issues. It relies on the application respecting those variables—if it doesn’t, the connection will simply fail. Sure, in this case since all other network connection requests are dropped you are somewhat protected but then an application that doesn't respect them will just not work

You can also have some fun with `DYLD_INSERT_LIBRARIES`, but that often requires creating shims to make it work with codesigned binaries

At least on macOS, there is a third way where you can control the network connection on the PID/binary level by setting up a network system extension and then setting up a content filter so you can allow/deny requests. It is pretty trivial to set this up, but the real challenge is usually in how you want to express your rules.

Little Snitch does this pretty well: https://www.obdev.at/products/littlesnitch/index.html

Yes, but at the same time having the 1 million context enabled is nice because the model is aware that they have more context left and actually perform better. [0]

[0] https://cognition.ai/blog/devin-sonnet-4-5-lessons-and-chall...

You have to specify `/model sonnet[1m]` to get the 1 million context version

Ultrathink still works

Hey, this sounds a lot like what we have been doing. We would love to chat with you, and share notes if you are up for it!

Drop us an email at navan.chauhan[at]strongdm.com