steveruizok

This is an incredible price. Lucky students.

Author here. tldraw is not an open source project. It used to be but we switched to a commercial license for our v2 in 2023. The old v1 is still available under MIT; and I try to put as much as we can under MIT license where it makes sense, but the core needs to be licensed in a way that allows us to sell it. We've always been majority source available and still accept community contributions, even though the default is to close external PRs. I care about OSS. I wish the economics of it made sense for us.

> Think about it: when/if this company grows to a larger size, if they can’t handle AI slop from contributors how can they handle AI slop from a large employee base?

god help us

(author here) Code quality matters a lot—we make an SDK, we sell our code. I'm writing my own code with the assistance of AI tools. When I'm asking an agent to step in, I can recognize when the tools are producing poor results, I can pause the work, correct it, or take the wheel in order to get things going in the right direction. Programming is still important, quality and care perhaps more important than ever, given how much of it we can do when tool-assisted.

(author here) To be fair, we also were getting plenty of poor PRs that implemented well-described issues. Or hey, maybe they were poor and maybe they weren't, but they were someone else's "claude please fix" and I don't think it's important for me to review them.

But you're right about the todos... except that the majority of times my little /issue command actually produces really great issues and digs up root causes very well. I still need to read and bless them though. Maybe we need a "potentially slop" label.

OP here: /s

Hey, OP here. Shitty issue command is fine in a world where I have time to review it and expand it, just like I would have before; except now, there's a 80% chance that actually the AI got it right and I have a well-researched issue that can be immediately worked on. The only problem is if someone without any content comes by and feeds it into cursor to make a PR.

Maybe it would have been better to keep the original no-body "fix truncate in sidebar text" style issues, though I quite like my little /issue command. I'm sure I'll have something else in a month.

Reviewing code is much less of a burden if I can trust the author to also be invested in the output and have all the context they need to make it correct. That's true for my team / tldraw's core contributors but not for external contributors or drive-by accounts. This is nothing new and has up to now been worth the hassle for the benefits of contribution: new perspectives, other motivations, relationships with new programmers. It's just the scale of the problem and the risk that the repo gets overwhelmed by "claude fix this issue that I haven't even read" PRs.