Thanks for building it! Looking forward to seeing how it - and people's setups - evolve.

1. As a co-founder, there is not much time for hobbies and that is part of the deal. Plus local inference is my hobby, at least at this point in the game. The free time I do get I prefer to spend offline and outside with my partner. I have asked Claude for relationship advice (which it is good at) but no workflows around this (and I think that would not go down well).

2. Early days, the tooling is not quite there yet. I think this is the future of engineering, the days of hand-crafting code - and probably reading it - are gone forever. It generates a LOT of tokens, but that is OK when they are cheap enough as long as the result is consistent. Speed is not so important which is great for local inference - can leave it running overnight and come back to a bunch of completed work even if it took hours.

I manually tag a ticket for automation in Linear. Experimented with having a separate skill that looks for automatable tickets and auto-tagging them, worked well, but having enough work for it to do is not the bottleneck compared to 1) having enough triaged, well-written work ticketed out, 2) reviewing its output. There's articles out there about arranging work into tiers based on complexity/risk, with the lower-end being fully automated to free up time for humans to focus on the high-end. Not had time to work on this much but that's probably where I will go.

A second human has to approve every PR in our repos (good practice and also a requirement for SOC2, which will impede any fully-automated pipeline adoption in regulated industries). I also do a first-read of the draft PR to make sure it is good quality, as I am ultimately responsible for the work my agent creates and to shift the responsibility of first-look (for any AI output) to another person is disrespectful to their time and inefficient.

Hence "glass-factory" as the "Dark Factory" pattern is a black box with no human intervention, but I think that is not something suitable for how teams build software products for real users presently, at least in the near future.

3. Forcing something on people is a good way to have them reject it. I hire professionals to achieve a goal and they have agency in how to achieve it. I encourage everyone to share their work internally (demos, repos, etc) and things that are truly beneficial to people's workflows gain traction quickly. As a result we have many experiments and a culture of rapid innovation that encourages people to try new things.

Negatively, this creates a proliferation of wheel re-inventing that eventually benefits from consolidation (eg. do we really need 3 people's personal apps monitoring ETL pipelines). But we are also in this emerging age of personal software where it seems to make most sense to consolidate at the API or documentation layer and let people - engineers and even business-side now - continue to vibe-code their own workflow-specific apps.

The precedent has been to build generalized software for an audience as it was expensive and time consuming to build, but when software is cheap and fast to build it may make more sense for the user-facing application layer to be made up of many small ephemeral applications that are only useful for one individual, that change rapidly as their needs change.

tl;dr: Not forcing anyone to use it as it's still experimental, yes personal experimentation is hopefully the basis of successful ideas that will be adopted by the team when they provide real benefits to their work.

Thanks! No repo yet, it's very specific to my use case. I'll update here if I ever publish something, but here's a summary that should be enough to vibe-code something similar.

The audio UI (AUI) is a small client that consumes the event stream the factory puts out (same one the TUI client uses), it runs on my desktop machine which has speakers connected. It works fine on good laptop speakers, but it benefits from a good subwoofer as it works best with sounds that are on the edge of perception.

A low rumble at a base of 55hz plays through the subwoofer to indicate that the factory is active and idle, low enough to fade into the background but noticeable in its absence (ie. the factory isn't running). A heartbeat on the feed announces the tok/s volume every few seconds which adds harmonics on top of the 55hz, 0.5hz at a time with a 15hz cap on the swell so it accelerates gracefully. Loudness is increased with parallel tasks, creating an X and Y axis (tasks x token volume). This creates a non-intrusive but interpretable signal for factory activity that becomes intuitive and subconscious. The rumble sounds like a distant car idling, warm and comforting so it doesn't become fatiguing over a whole day (research on low frequency brown noise shows it is good for reducing anxiety and improving sleep).

Events trigger sounds. Sounds for previously unseen events are generated with an LLM and numpy (eg. "make a video-game style sound effect suitable for an {announcement that a PR has merged successfully}") to output a waveform and save it to a lookup table so they are consistent over time. Each sound has a rate limit and a cooldown period so it does not become annoying. This table can be tweaked manually if generated sounds are not good. A mixer module controls the levels so that important sounds are louder and less important or frequent ones blend in the background more.

The human brain is primed to interpret environmental sounds so you quickly learn what each sound means and it becomes almost subconscious to follow what is going on at a level that is deeper and faster than interpreting text output. New sounds definitely trigger alertness and I can go see what just happened. Just playing sound effects gets annoying quickly so it becomes almost a composition exercise to create a long-form soundscape that is novel enough to communicate but not fatiguing (I don't have any musical abilities).

Some events can trigger text-to-speech (TTS) via whisper, eg. when a draft PR is ready for review it plays the sound effect (a chime) and announces the ticket number and title is ready. A blocked step is a dull thud and a 5-10 word description of what's blocking it. There are "quiet hours" where it does not speak, and when it wakes up it gives me a spoken digest of everything it did overnight and what needs my attention.

I connected Piper so I can talk back to it ("factory, what just happened?") but mainly to see if I could. I haven't built a habit around it, I got into this job because I prefer typing anyway.

A lot of this is based on ideas from ambient music (Brian Eno etc), the MIT Media Lab's work on ambientROOM (1997): https://tangible.media.mit.edu/project/ambientroom/ and a somewhat unfashionable belief in Steven Levy's hacker edict that "You can create art and beauty on a computer". LLMs have made it possible for me to build out ideas that have been floating around in my head for a long time. This is an exciting time to experiment and build new ways of doing things. Hope this inspires you to build something similar.