Jonathan Joelson

@jjoelson
213 Followers
357 Following
989 Posts
iOS developer, basketball fan, Brooklyn based.
Bloghttps://blog.joelson.co
Email[email protected]

Thanks to everyone who came out for LIVE near WWDC 2026!

And a big thank you to everyone who made the show possible: our sponsors @MartianCraft @OmniGroup, the Breakpoints, and volunteers from @Techtonica and the developer community!

We all had a great time performing and celebrating 25 years of James Dempsey and the Breakpoints, and hope you did too!

A recording of the livestream is available at https://livenearwwdc.com/livestream

Hot take: generating commit messages or PR descriptions is one of the *worst* use cases for AI in programming.

The most important thing to know about any code change is the *intent* behind it. A given change is either correct or a bug depending on the underlying intent. AI will happily rationalize any change with a fake but plausible intent.

If the intent is obvious from the change then I don’t need the message. If it’s not, then I really need the message to not be generated based on the diff.

Nebula is probably my favorite new platform in the past decade. The content and curation are peak. I wish I could work on their Apple apps, especially their tvOS app because it has occasional reproducible glitches and is otherwise great.

@droidboy @peter @fishidwardrobe In my experience, the people who vibe code PRs also use AI to generate the descriptions, the Jira tickets, and everything else that used to contain useful information.

Nothing but a direct human to human conversation with the person in question enables me to figure out what it is they’re actually attempting to do. 😅

@droidboy @peter @fishidwardrobe Social disrespect aside, I would say it’s nigh impossible to actually review the PR. It’s difficult to know if a change is doing what it is intended to do if the intention isn’t clear.

FWIW this is not hypothetical. I occasionally need to review vibe-coded PRs, and close to 100% of the time I need to pause the review and have a conversation or Slack chat with the author to figure out what problem they’re actually trying to solve.

@peter btw AI seems fit this paradigm perfectly:
- Every terrible app that I used two years ago is still terrible today
- Excepting an occasional AI psychosis case, most good apps that I used two years ago are still good today
@peter This is why the consulting model for building software tends to produce poor results imo: you’re explicitly deciding that continuity in who is building and maintaining this system is unimportant.

@peter The single most important structural thing any software organization can do is to figure out how to hire and retain talented people.

If you can do that (and it’s not easy!) then whatever methodologies and ways of working those folks come up with will work fine.

@peter Like many things in software development, a talented and diligent software developer will produce great software without necessarily needing to write a ton of tests, and a bad developer will not have the ability to write useful tests.

I’ve found that hard and fast rules like “you need x% coverage” or “you need to use agile” or whatever are complete BS. The bottom line is that talented people will do good work and talentless people will fuck everything up.

@droidboy @peter @fishidwardrobe I’ve also posted recently about how managing your changes manually can be incredibly beneficial for clarifying your own thinking, in the same way that writing down your thoughts can be:
https://mastodon.social/@jjoelson/116687418743074401