This is an exceptional setup, thank you for sharing it! I have a few questions:
1. This setup seems work-heavy. Are there any personal AI workflows that you've implemented to advance your personal goals / hobbies?
2. As one of the few people with a software factory, how well do you think it works in practice? Do you implement any rule that lets the agents to work on tickets only up to a certain complexity, or do you let the human review be the gatekeeper?
3. As CTO, how do you weigh implementing these agent workflows for yourself versus implementing them team-wide? Do you see your setup as a testbed of ideas for your team?
On a meta note, I love seeing others share their setups and I'll probably do the same later.
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.
I very intentionally have all memory turned off for chat. The amount of times I want to discuss an approach for it to pull memory out and have that steer the decision making is so obnoxious
Reminds me few months ago I asked it about a TV model specs, then later I was doing a UI for something, response was “I modified xyz and now should works perfectly with the HDR in your TV model!!”
When casually a friend asks you to ask your Claude something about topic you chatted about earlier and then Claude brings back a secret you didn't want anyone to know yet.
Yes you can set up a project and then ask a question, but this is tedious.
I understand the need for it to be in Siemens NX, but do they really run it in Windows VMs? As far as I know NX isn't certified to run in VMs without Nvidia GPU passthrough (aka Macs). It seems more sensible to maintain a fleet of Windows desktops specifically for CAD and industrial control.
Yeah, a couple years ago (sorry, no citation handy) I wasn't too surprised to learn that a Windows desktop can run faster in a VM on Intel Mac hardware than directly on a similarly-priced PC.
That was my experience during the Intel Mac era, when I did a lot of Windows development inside of a Mac VM.
IMO, the reason is all of the 3rd party fluff and poorly-written drivers that come with Windows PCs: Apple takes driver stability very seriously, and the drivers on a Windows VM are as vanilla (no fluff or features) as possible.
So this is all pure speculation, but seeing as they are a hardware company I wonder if they have some sort of internal only server chassis to house apple motherboards for their backend, tolerate asahi linux for this? No real external market for apple servers so they don't develop it past "Ok for internal use"
The more I think about it the more I doubt it, even if you make your own hardware it is hard to compete with a commodity server, but it is an interesting thought.
Update: or perhaps they do, a sibling comment had a picture of such.
Your public website / blog? Sometimes you want services that are accessible publicly, like your observability and logging servers (eliminates the VPN point of failure).
I have multiple public sites that are running through vpn+reverse proxy, for example, vaultwarden, and it’s more secure because in the reverse proxy I can have rules to pass the connection to specific end points so clients can access it securely but the actual webpage is locked behind SSO. I never encountered a VPN failure, if the connection is up it is up, and it’s an encrypted tunnel too. Another example, if you use something like coolify, you can pair it with another reverse proxy on top of traefic one builtin, and if you browse that service in coolify, your packet is going through an encrypted link all the way to the docker image behind coolify.
Last time I used DDNS i think was around 2012 in an NVR where I needed to access some cameras publicly.
I own one and there's nothing shameful about it. It's basically CNCed to Apple's standards, just without the logo. The cool thing is since Studio Displays work on Windows too, with Thunderbolt motherboards you can have a setup that's visually the same as a Mac but is actually a PC.
P.S. Does anyone know how well Studio Displays now work on Linux? The best I could get it to work was on Ubuntu, where it basically worked out of the fresh install. X11 KDE on Fedora was a close second. Couldn't get it working on Wayland whatsoever.
I have a suspicion most of these types of agent-targeted SaaS will die out once the human equivalents implement their agent layers / MCPs.
Agents having no way to pay for their use is one thing; lack of deep integration within the business domain is another (e.g. if you're a Git provider, you'd probably want to offer CI/CD, PR workflows, release management, publicly discoverable repos etc., and boom - you just copied GitHub)
We're actually meant to be less of a consumer product than i think you mean by this (but i may have misunderstood).
We're more targeting enterprise as storage infrastructure provider – selling directly to platforms who generate a bunch of code and need a place to put it.
There's probably still going to be a box of hard drives in a datacenter somewhere, it does make sense to have a layer to manage the agent interface, rather than letting agents completely loose on all your storage.
Agreed, but I'm making a distinction between the platform (whether it be Cloudflare Moltworker or a Mac Mini), which a human chooses for the agent to run on (for now), and tools designed to be discovered and consumed by the agents themselves (e.g. code.storage, AgentMail).
I'm so sorry for you and your wife's loss. At the same time, I'm struck by how strong your wife and you are navigating this tough situation. From an Internet stranger to another, may the loving memories of your daughter live on.
1. This setup seems work-heavy. Are there any personal AI workflows that you've implemented to advance your personal goals / hobbies?
2. As one of the few people with a software factory, how well do you think it works in practice? Do you implement any rule that lets the agents to work on tickets only up to a certain complexity, or do you let the human review be the gatekeeper?
3. As CTO, how do you weigh implementing these agent workflows for yourself versus implementing them team-wide? Do you see your setup as a testbed of ideas for your team?
On a meta note, I love seeing others share their setups and I'll probably do the same later.
reply