2,041 karma · joined July 9, 2014
Working on dev tooling @sentry. Formerly @emergetools (YC21, acq) @stripe and @kayak.
Never got around to that poster though. :(
If anyone is interested we open-sourced https://github.com/getsentry/launchpad which can produce a treemap visualization for Mach-O. I've been working on ELF support in my free time too but it's not finished.
From what I can tell looking at the codebase compared to Django's, the top-level modules are structured much better and more obvious for AI to discover them. And then inside each module is a descriptive README with lots of description and examples that are helpful to an agent (and human). Not sure why this is being written off as slop or arbitrary changes, it seems pretty obvious to me this is the direction of frameworks.
You are saying "if you leave the AI attribution in the PR/commit description, it HAS to be a slop PR that was not reviewed by a human beforehand". And I'm saying that's not true at all and you shouldn't assume that.
> was submitted by someone so lazy they couldn’t even edit the commit message. You can see the vibe coded PRs right away.
As others mentioned, this is very intentional for me now as I use agents. It has nothing to do with laziness, I'm not sure why you would think that? I assume vibe coded PRs are easy enough to spot by the contents alone.
> I would like to know when someone is trying to have the tool do all of their work for them.
What makes you think the LLM is doing _all_ of the work? Is it really an impossibility that an agent does 75% of the work and then a responsible human reviews the code and makes tweaks before opening a PR?
This used to be the case around Swift 4, but since then they've added so many features and keywords to the language. Now the simplicity and elegance is gone.
Also it seems like there was a marked change in the culture of Swift. It somehow attracted a lot of the "ackchyually" crowd which resulted in a lot of massively complicated features. I liked to occasionally browse the evolution docs and they got more and more complex over time.
I'm being pedantic AF because most people refer to AI slop as "low-quality or careless work". And AI is just a tool so it's possible to spend a lot of time making something of high quality with it. I get the outrage with respect to copyright and artist rights, but it certainly doesn't look like slop to me.
I have an endless list of blog posts to write and so little time :(
The main issue is that medicine and diseases come with so many "it depends" and caveats. Like right now my cat won't eat anything, is it because of nausea from the underlying disease, from the recent stress she's been through, from the bad reaction to the medicine she really doesn't like, from her low potassium levels, something else, all of the above? It's hard to say since all of those things mention "may cause nausea and loss of appetite". But to be fair, even the human vets are making their own educated guesses.
The small filesize issue is something we commonly see in games, was surprised to see it for Gmail.
And btw we open-sourced much of our analysis after being acquired by Sentry: https://github.com/getsentry/launchpad
Flame graphs I have a love/hate relationship with. The hierarchy is very useful, but the name and coloring can be very confusing and misleading. Most people I show them to think red == something bad, but the color is actually just for aesthetics.
The results of a diff-only review won't be very good. The good AI reviewers have ways to index your codebase and use tool searches to add more relevant context to the review prompt. Like some of them have definitely flagged legit bugs in review that were not apparent from the diff alone. And that makes a lot of sense because the best human reviewers tend to have a lot of knowledge about the codebase, like "you should use X helper function in Y file that already solves this".
> The job is to help the business solve a problem, not just to ship code. In cases where delivering code actually makes sense, then yeah you should absolutely be able to prove it works and meets the requirements like the OP says. But there are plenty of cases where writing code at all is the wrong solution, and that’s an important distinction I didn’t really understand until later in my career.
Although funnily enough, the meaning you interpreted also has its own merit. Like other commenters have mentioned, there's always a cost tradeoff to evaluate. Some projects can absolutely cut corners to, say, ship faster to validate some result or gain users.
Many times in my career, after understanding the problem at hand and who initiated it, I realized the solution is actually one of:
1) a people/organizational problem, not technical 2) doesn't make sense to code a complicated system when it could be a simple Google Sheet 3) the person actually has a completely different problem 4) we already have a solution they didn't know about
My issue with the OP is that it highly emphasizes delivering code. We are not meant to be code monkeys, we are solving problems at the end of the day. Many people I've met throughout my career forget that and immediately jump into writing code because they think that's their job.
Strong disagree here, your job is to deliver solutions that help the business solve a problem. In _most_ cases that means delivering code that you should be able to confidently prove satisfies the requirements like the OP mentioned, but I think this is an important nitpick distinction I didn't understand until later on in my career.
It's definitely gotten better like you said but I just prefer to work with the native platform code even if it's a bit of extra effort.
In practice though it's somewhat easy to workaround the lack of OTA with dynamic server configuration for clients.