No Codex, Claude, or Pi... now you have peaked my interest with your setup :P

Solving hard problems will be the only thing that separates you from others. Your mindset and tools should be a trade secret at this point.

They have no understanding of (nor any desire to understand) what they're doing, but they are being given kudos by management for their "initiative" to solve the organization's "big problems." Guess who will be asked to clean up the mess if (when) it blows up.

It's getting cheaper and cheaper to kick the can down the road, and standing in front of that risks making you look like a dinosaur. It's going to be an interesting few years...

1. The value of software is tending towards nil while it's ever easier to tailor bespoke solutions.

That suggests to me that I'm losing less by sharing, and it's probably not even going to be taken wholesale and kept verbatim.

2. The labs have already trained on everything and will keep on doing so.

Therefore continuing to contribute to OSS doesn't just benefit my own future self but the entire ecosystem.

(Yes, I need to get over how it appears a select few are making off with the lion's share but that only differs in degree in comparison to the past)

At least now the cards are being shuffled elsewhere...

Unless you are a solo founder running your own company by yourself (in which case ignore the rest of this comment!), then your fundamental job security is likely to be predicated on the survival of your company as well as the survival of your own individual job itself.

From the company-survival POV, all companies are engaged in competition (unless they have a total monopoly).

Therefore I ask you to consider the competitive scenario, of whether a competitor to your company who adopts a more collaborative culture, might be more likely to outcompete your company (assuming everyone you work with in your own company adopts a similarly "dick"-ish stance, to use your own words), and therefore you lose your job due to being out-competed, rather than due to internal politics or due to a failure to guard your personal expertise?

Maybe you say -- I don't care if my company is out-competed, I'll just get another job. Ok fair enough, but might it not be possible that, in a future job interview, they may ask you for examples of collaboration? And if you commit to a monk-like devotion to solitude and privacy, then maybe you are undercutting your own future hireability?

There are no free lunches [1]. By optimizing for one thing (what you view as protecting yourself), you might be sabotaging another dimension (your company's overall competitiveness, or your future hireability).

Anyway, nobody knows shit about shit. I certainly don't pretend to be an authority, but I would caution you to avoid coming to a hasty conclusion, especially since it seems emotions are involved and possibly clouding your judgement. You may also consider whether this decision to protect yourself in this way, is in itself a premature (micro?) optimization of a sort, and if whether you might be failing to optimize on a more macro level.

[1] https://en.wikipedia.org/wiki/No_such_thing_as_a_free_lunch

  People might think I'm a dick, I don't care, my tools, my knowledge, my job security.

[1]: anywhere from the fathomable "my harness didn't come up in my layoff email nor in any of my failed interviews following that" to the realistic "the entire concept of employment shifted under our feet so quickly and so profoundly that a dash of solidarity & luck outweighed even the shrewdest preparations".

You need to consider how they were able to do that. For many people, it’s because they had highly paid, secure jobs that essentially funded their open source activity.l, even if only as a side project or personal project. If you take away that security and reliable funding, you destroy the environment that supported people sharing like that.

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.

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.

I was wondering if other employers are asking their SWE to do the same?

I do work mainly on my desktop, but let's say I'm traveling right, I'd have to turn it off and was missing access to some pretty important information, so I ended up getting a VM and hosting some of those things on there instead. I still use both, but things I want available, I'll host it on my "homelab" and secure both machines via tailscale. it's pretty easy and it ensures that only my phone, my main mac, and my homelab have access to each other and nothing else.