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.