JeremyHerrman

looks like they brought back the glowing apple logo on the lid for the first time in a decade!

the older macbooks used the display's backlight to illuminate the logo, but since these new OLED displays light up individual pixels I wonder how they're lighting it up now...

woah this looks great

One annoying trend in frontier models which contributes to the brainrot is:

- agent loops for a long time (minutes to hours), writing a lot of code

- agent gives high level summary of the outcome of the work, not the work itself, i.e. "Implemented and pushed feature XX. Focused tests and checks passed."

- requires detailed review of the large changes which can be exhausting, so just accepting it becomes easier

I really wish the models would explain more of the "how" and "why" of the implementation decisions. To combat this, I usually to bug the agent to discuss more including what assumptions it made and alternatives it considered.

Sure, this can be added to AGENTS.md but I view overengineered AGENTS.md as an antipattern and can work against us especially given the rapid advancements of the models.

What does seem to work is planning first via a very synchronous back and forth with an expensive model before tasking 1+ cheaper models to implement in parallel, then getting an expensive model to review while I look over things manually.

I had the same exact thought from the paragraph above that when reading:

> the writer derives its field count from Object.keys().length while skipping the sentinel

AI can be a tool for the software craftsman too!

Just keep a high bar for quality at whatever abstraction level you're working at - whether that's machine code, assembly, low or high level languages, or even wrangling agents.

I've been coding for 25 years and I've never been more excited and less sad to build projects I've been dreaming of but haven't had enough time to do.

> "GitHub has had 1125 incidents since February 2016, implying a monthly incident rate of 24"

1125 incidents / 126 months ≈ 8.9 incidents per month, not 24

still terrible, but why such an obvious error in the first sentence...

having worked at the intersection of CAD/CAM automation & actual factories, I'm disappointed with the lack of real information on what their product actually does.

Going from bits to atoms is _hard_ for a ton of reasons, and their example prompt "Prepare this for manufacturing" is a huge red flag IMO. That said, I wish them luck, we need fresh blood in this slow moving industry.

love his writing style. pure opposite of slop, oozing with humanity

Gemini 2.5 Flash-Lite has been my go to for cheap document processing at scale (especially with 50% off batch mode), but they are really boiling the frog with pricing increases with each version:

gemini-2.5-flash-lite: $0.10 input / $0.40 output

gemini-3.1-flash-lite: $0.25 input / $1.50 output

gemini-3.5-flash-lite: $0.30 input / $2.50 output (a 6.25x increase over 2.5!)

Now watch them deprecate Gemini 2.5 Flash-Lite in the coming months...

Another happy user of Handy here!

After seeing so many *subscription based* transcription apps all wrapping *open source models*, finding Handy was a real delight and I'm happy to see the author keep on building!

> This machine specs reminds me of how awful '90s laptop screens, based on a passive matrix, were. Definitely something I don't miss from that era.

While the 1991 Apple PowerBook 100 did have a passive matrix display, the machine it was based on, the Macintosh Portable from 1989, had a crisp active matrix running at 640×400 (even higher resolution than the compact Macintosh desktops with 512×342).

Interestingly Apple tasked Sony with designing the PowerBook 100 by taking the Macintosh Portable and slimming it down as much as possible. They shaved over 10lbs by moving away from the lead acid battery, dropping the floppy drive, and moving to a passive matrix display.

it's tough for people here to admit, but AI is good at summarizing and that includes commit messages and PR fields

but that does NOT mean you get to skip understanding the code & whipping the AI in line during implementation

my preferred workflow:

- think hard about the problem before touching the keyboard

- back and forth with the AI, swatting down bad implementation ideas and poking holes

- settle on a detailed implementation plan

- let the AI go for however long it needs to (usually minutes, sometimes hours)

- review, iterate, test

- "this looks good, commit in focused chunks and create a PR"

- review commits & PR summary, hand edit for clarity