← Back to context

Comment by noosphr

20 days ago

I was looking for some code, or a product they made, or anything really on their site.

The only github I could find is: https://github.com/strongdm/attractor

    Building Attractor

    Supply the following prompt to a modern coding agent
    (Claude Code, Codex, OpenCode, Amp, Cursor, etc):
  
    codeagent> Implement Attractor as described by
    https://factory.strongdm.ai/

Canadian girlfriend coding is now a business model.

Edit:

I did find some code. Commit history has been squashed unfortunately: https://github.com/strongdm/cxdb

There's a bunch more under the same org but it's years old.

I was about to say the same thing! Yet another blog post with heaps of navel gazing and zero to actually show for it.

The worst part is they got simonw to (perhaps unwittingly or social engineering) vouch and stealth market for them.

And $1000/day/engineer in token costs at current market rates? It's a bold strategy, Cotton.

But we all know what they're going for here. They want to make themselves look amazing to convince the boards of the Great Houses to acquire them. Because why else would investors invest in them and not in the Great Houses directly.

  • The "social engineering" is that I was invited to a demo back in October and thought it was really interesting.

    (Two people who's opinions I respect said "yeah you really should accept that invitation" otherwise I probably wouldn't have gone.)

    I've been looking forward to being able to write more details about what they're doing ever since.

  • 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.

  • > The worst part is they got simonw to (perhaps unwittingly or social engineering) vouch and stealth market for them.

    Lol. Any time I see something ai related endorsed by simonw, I tend to view it as mostly hype, and I have been right so far.

    • Can you give an example? His writing seems pretty grounded to me. He's not out there going on podcasts claimed that LLMs are going to cure cancer, afaik.

There's actual code in this repo: https://github.com/strongdm/cxdb

  • Amusingly, it appears the README (that would be code, right?) has hallucinated the existence of a docker image - someone filed an issue at https://github.com/strongdm/cxdb/issues/1

    In-house employees don't read code or do code reviews, so presumably they don't raise issues either. I guess the issue was picked up by an astute HN reader.

  • I've looked at their code for a few minutes in a few files, and while I don't know what they're trying to do well enough to say for sure anything is definitely a bug, I've already spotted several things that seem likely to be, and several others that I'd class as anti-patterns in rust. Don't get me wrong, as an experiment this is really cool, but I do not think they've succeeded in getting the "dark factory" concept to work where every other prominent attempt has fallen short.

They have a Products page where they list a database and an identity system in addition to attractors: https://factory.strongdm.ai/products

For those of us working on building factories, this is pretty obvious because once you immediately need shared context across agents / sessions and an improved ID + permissions system to keep track of who is doing what.

I don't know if that is crazy or a glimpse of the future (could be both).

PS: TIL about "Canadian girlfriend", thanks!

So paste that into a 'chat' and hope the link doesn't blow up in your face?

  • I scanned through the documents in the repo (I would never have an agent execute code from a URL) and I didn't find anything suspicious. I had Claude build the app according to the specs and I have a working AI agent at the end that uses my Claude API key. Whether this turns out to be advantageous longterm remains to be seen, but the toy weather app I asked it to build was higher quality than the ones that I had Claude build by itself.

    The specs totaled ~6000-7000 lines. I'm sorta in awe of how much detail they provided. I've not supplied specs longer than about one page when telling an agent to build something.

    It used a ton of tokens building in Typescript. I had to add money to my account to finish it in one night. I might ask it to build in Rust or Go, we'll see. Anyway, it's interesting even if it isn't clear that that it's useful. I'll have to try it a bunch to know.

So I am on a web cast where people working about this. They are from https://docs.boundaryml.com/guide/introduction/what-is-baml and humanlayer.dev Mostly are talking about spec driven development. Smart people. Here is what I understood from them about spec driven development, which is not far from this AFAIU.

Lets start with the `/research -> /plan -> /implement(RPI)`. When you are building a complex system for teams you _need_ humans in the loop and you want to focus on design decisions. And having structured workflows around agents provides a better UX to those humans make those design decisions. This is necessary for controlling drift, pollution of context and general mayhem in the code base. _This_ is the starting thesis around spec drive development.

How many times have you working as a newbie copied a slash command pressed /research then /plan then /implement only to find it after several iterations is inconsistent and go back and fix it? Many people still go back and forth with chatgpt copying back and forth copying their jira docs and answering people's question on PRD documents. This is _not_ a defence it is the user experience when working with AI for many.

One very understandable path to solve this is to _surface_ to humans structured information extracted from your plan docs for example:

https://gist.github.com/itissid/cb0a68b3df72f2d46746f3ba2ee7...

In this very toy spec driven development the idea is that each step in the RPI loop is broken down and made very deterministic with humans in the loop. This is a system designed by humans(Chief AI Officer, no kidding) for teams that follow a fairly _customized_ processes on how to work fast with AI, without it turning into a giant pile of slop. And the whole point of reading code or QA is this: You stop the clock on development and take a beat to see the high signal information: Testers want to read tests and QAers want to test behavior, because well written they can tell a lot about weather a software works. If you have ever written an integration test on a brownfield code with poor test coverage, and made it dependable after several days in the dark, you know what it feels like... Taking that step out is what all VCs say is the last game in town.. the final game in town.

This StrongDM stuff is a step beyond what I can understand: "no humans should write code", "no humans should read code", really..? But here is the thing that puzzles me even more is that spec driven development as I understand it, to use borrowed words, is like parents raising a kid — once you are a parent you want to raise your own kid not someone else's. Because it's just such a human in the loop process. Every company, tech or not, wants to make their own process that their engineers like to work with. So I am not sure they even have a product here...