5 ms·

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 h

by noosphr 9mo 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 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 https://github.com/strongdm/cxdb There's a bunch more under the same org but it's years old.

yomismoaqui 9mo ago
I don't know if that is crazy or a glimpse of the future (could be both). PS: TIL about "Canadian girlfriend", thanks!
simonw 9mo ago
There's actual code in this repo: https://github.com/strongdm/cxdb https://github.com/strongdm/cxdb
- lunar_mycroft 9mo ago
  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.
  - simonw 9mo ago
    Out of interest, what anti-patterns did you see? (I'm continuing to try to learn Rust!)
    - lunar_mycroft 9mo ago
      To pick a few (from the server crate, because that's where I looked): - The StoreError type is stringly typed and generally badly thought out. Depending on what they actually want to do, they should either add more variants to StoreError for the difference failure cases, replaces the strings with a sub-types (probably enums) to do the same, or write a type erased error similar to (or wrapping) the ones provided by anyhow, eyre, etc, but with a status code attached. They definitely shouldn't be checking for substrings in their own error type for control flow. - So many calls to String::clone [0]. Several of the ones I saw were actually only necessary because the function took a parameter by reference even though it could have (and I would argue should have) taken it by value (If I had to guess, I'd say the agent first tried to do it without the clone, got an error, and implemented a local fix without considering the broader context). - A lot of errors are just ignored with Result::unwrap_or_default or the like. Sometimes that's the right choice, but from what I can see they're allowing legitimate errors to pass silently. They also treat the values they get in the error case differently, rather than e.g. storing a Result or Option. - Their HTTP handler has an 800 line long closure which they immediately call, apparently as a substitute for the the still unstable try_blocks feature. I would strongly recommend moving that into it's own full function instead. - Several ifs which should have been match. - Lots of calls to Result::unwrap and Option::unwrap. IMO in production code you should always at minimum use expect instead, forcing you to explain what went wrong/why the Err/None case is impossible. It wouldn't catch all/most of these (and from what I've seen might even induce some if agents continue to pursue the most local fix rather than removing the underlying cause), but I would strongly recommend turning on most of clippy's lints if you want to learn rust. [0] https://rust-unofficial.github.io/patterns/anti_patterns/borrow_clone.html https://rust-unofficial.github.io/patterns/anti_patterns/bor...
      - drekipus 9mo ago
        This is why I think AI generated code is going nowhere. There's actual conceptual differences that the stotastic parrot cannot understand, it can only copy patterns. And there's no distinction between good and bad code (IRL) except for that understanding
- socialcommenter 9mo ago
  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 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.
ebhn 9mo ago
That's hilarious
jessmartin 9mo ago
They have a Products page where they list a database and an identity system in addition to attractors: https://factory.strongdm.ai/products 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.
ares623 9mo ago
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.
- simonw 9mo ago
  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.
  - ares623 9mo ago
    I will look forward to that blog post then, hopefully it has more details than this one. EDIT nvm just saw your other comment.
  - ucirello 9mo ago
    Justin never invites me in when he brings the cool folks in! Dang it...
  - oidar 9mo ago
    Is this the black box folks you mentioned?
    - simonw 9mo ago
      It's the dark factory people, yeah: https://news.ycombinator.com/item?id=46739117#46801848 https://news.ycombinator.com/item?id=46739117#46801848
  - shimman 9mo ago
itissid 9mo ago
So I am on a web cast where people working about this. They are from https://docs.boundaryml.com/guide/introduction/what-is-baml 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/cb0a68b3df72f2d46746f3ba2ee74afe 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...
touristtam 9mo ago
So paste that into a 'chat' and hope the link doesn't blow up in your face?
- alsetmusic 9mo ago
  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.
lukebuehler 9mo ago
The spec is pretty good! Within a day, Codex has written a good chunk of the attractor stack for me: https://github.com/smartcomputer-ai/forge https://github.com/smartcomputer-ai/forge

by noosphr 9mo ago

yomismoaqui 9mo ago

I don't know if that is crazy or a glimpse of the future (could be both). PS: TIL about "Canadian girlfriend", thanks!

simonw 9mo ago

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

lunar_mycroft 9mo ago
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.
- simonw 9mo ago
  Out of interest, what anti-patterns did you see? (I'm continuing to try to learn Rust!)
  - lunar_mycroft 9mo ago
    To pick a few (from the server crate, because that's where I looked): - The StoreError type is stringly typed and generally badly thought out. Depending on what they actually want to do, they should either add more variants to StoreError for the difference failure cases, replaces the strings with a sub-types (probably enums) to do the same, or write a type erased error similar to (or wrapping) the ones provided by anyhow, eyre, etc, but with a status code attached. They definitely shouldn't be checking for substrings in their own error type for control flow. - So many calls to String::clone [0]. Several of the ones I saw were actually only necessary because the function took a parameter by reference even though it could have (and I would argue should have) taken it by value (If I had to guess, I'd say the agent first tried to do it without the clone, got an error, and implemented a local fix without considering the broader context). - A lot of errors are just ignored with Result::unwrap_or_default or the like. Sometimes that's the right choice, but from what I can see they're allowing legitimate errors to pass silently. They also treat the values they get in the error case differently, rather than e.g. storing a Result or Option. - Their HTTP handler has an 800 line long closure which they immediately call, apparently as a substitute for the the still unstable try_blocks feature. I would strongly recommend moving that into it's own full function instead. - Several ifs which should have been match. - Lots of calls to Result::unwrap and Option::unwrap. IMO in production code you should always at minimum use expect instead, forcing you to explain what went wrong/why the Err/None case is impossible. It wouldn't catch all/most of these (and from what I've seen might even induce some if agents continue to pursue the most local fix rather than removing the underlying cause), but I would strongly recommend turning on most of clippy's lints if you want to learn rust. [0] https://rust-unofficial.github.io/patterns/anti_patterns/borrow_clone.html https://rust-unofficial.github.io/patterns/anti_patterns/bor...
    - drekipus 9mo ago
      This is why I think AI generated code is going nowhere. There's actual conceptual differences that the stotastic parrot cannot understand, it can only copy patterns. And there's no distinction between good and bad code (IRL) except for that understanding
socialcommenter 9mo ago
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 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.

ebhn 9mo ago

That's hilarious

jessmartin 9mo ago

They have a Products page where they list a database and an identity system in addition to attractors: https://factory.strongdm.ai/products 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.

ares623 9mo ago

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.

simonw 9mo ago
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.
- ares623 9mo ago
  I will look forward to that blog post then, hopefully it has more details than this one. EDIT nvm just saw your other comment.
- ucirello 9mo ago
  Justin never invites me in when he brings the cool folks in! Dang it...
- oidar 9mo ago
  Is this the black box folks you mentioned?
  - simonw 9mo ago
    It's the dark factory people, yeah: https://news.ycombinator.com/item?id=46739117#46801848 https://news.ycombinator.com/item?id=46739117#46801848
- shimman 9mo ago

itissid 9mo ago

So I am on a web cast where people working about this. They are from https://docs.boundaryml.com/guide/introduction/what-is-baml 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/cb0a68b3df72f2d46746f3ba2ee74afe 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...

touristtam 9mo ago

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

alsetmusic 9mo ago
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.

lukebuehler 9mo ago

The spec is pretty good! Within a day, Codex has written a good chunk of the attractor stack for me: https://github.com/smartcomputer-ai/forge https://github.com/smartcomputer-ai/forge