Inside the Dark Factory: AI That Ships Code Solo

Uh, so why don't we talk about how Tessell uses the Dart Factory numbers-wise, first of all, and then we'll maybe look back as to, as to what we were doing before the Dart Factory existed.

Mm-hmm.

So when we think numbers-wise, what percentage of Tessell's pull requests today use the Dart Factory?

Yeah, so varies a little bit week over week.

Um, but for the last week, we are between 65 and 70%.

Uh, mind you, this is including, uh, pull requests that are building the Dart Factory using the Dart Factory.

Um, so there is a lot of those, as you can expect.

We are heavy users of it internally on our team.

Mm-hmm.

Um, the last time that I looked for the production part of our code base, so the stuff that is serving the registry, our web UI, um, our CLI, all of that kind of stuff, we are at about 40% of production PRs were raised using the Dart Factory.

And all of those 40% require a human review to some extent to-

Correct

... because they shouldn't.

Yes.

Our policy is that we only allow auto merge on, um, stuff that is in our research code base, stuff that is in our Dart Factory code base, and stuff that, um, our GTM team is building, uh, using the Dart Factory to help, uh, build out their own internal flows too.

And how about weekends? Does the Dart Factory work while we sleep?

Uh, oh, yes.

Uh, will happily work weekends and overnights, and as long as there work- there is work in the queue.

It feels like a little bit of the shift in my own thinking about this is less about what is the coding work that I think I can do over the course of the week, but what is the coding work that I can be able to effectively feed the queue over a long enough time? Because we respect linear blocking relationships and able to handle kind of subtasks and all that kind of stuff, I can actually sequence quite a fair amount of work before I go away for the weekend and come back to not a fundamentally different architecture, but a relatively different architecture over the course of the weekend.

Uh, so why don't we talk about how Tessell uses the Dart Factory numbers-wise, first of all, and then we'll maybe look back as to, as to what we were doing before the Dart Factory existed.

Mm-hmm.

So when we think numbers-wise, what percentage of Tessell's pull requests today use the Dart Factory?

Yeah, so varies a little bit week over week.

Um, but for the last week, we are between 65 and 70%.

Uh, mind you, this is including, uh, pull requests that are building the Dart Factory using the Dart Factory.

Um, so there is a lot of those, as you can expect.

We are heavy users of it internally on our team.

Mm-hmm.

Um, the last time that I looked for the production part of our code base, so the stuff that is serving the registry, our web UI, um, our CLI, all of that kind of stuff, we are at about 40% of production PRs were raised using the Dart Factory.

And all of those 40% require a human review to some extent to-

Correct

... because they shouldn't.

Yes.

Our policy is that we only allow auto merge on, um, stuff that is in our research code base, stuff that is in our Dart Factory code base, and stuff that, um, our GTM team is building, uh, using the Dart Factory to help, uh, build out their own internal flows too.

And how about weekends? Does the Dart Factory work while we sleep?

Uh, oh, yes.

Uh, will happily work weekends and overnights, and as long as there work- there is work in the queue.

It feels like a little bit of the shift in my own thinking about this is less about what is the coding work that I think I can do over the course of the week, but what is the coding work that I can be able to effectively feed the queue over a long enough time? Because we respect linear blocking relationships and able to handle kind of subtasks and all that kind of stuff, I can actually sequence quite a fair amount of work before I go away for the weekend and come back to not a fundamentally different architecture, but a relatively different architecture over the course of the weekend.