Our conversation with Adam Engst continues with an exploration of  how AI can help non-programmers build sophisticated software by following professional development practices. Adam explains using specifications, architecture documents, and AI-guided decisions to create reliable apps, then examines the approach his app, SetShot, takes to macOS settings, privacy, security, user feedback, Cloudflare, GitHub, and minimizing sensitive data collection. 

💾

💾

Adam Engst looks back at HyperCard as an early tool that democratized software creation, then connects its legacy to today’s AI-assisted development. He outlines how Claude helped turn an idea for tracking macOS setting changes into a working Mac app, SetShot. Adam discusses Xcode, GitHub, rapid iteration, and the value of visual feedback in his development process, and how AI lowers programming barriers without eliminating the need for thought, judgment, and effort. 

💾

💾

Vlad Fedorov (Hacker News):

On August 17, GitHub experienced an outage that lasted 7 hours and 47 minutes. It disrupted github.com, authentication, GitHub Actions, APIs, pull requests, issues, and Copilot, affecting developers and organizations around the world.

[…]

Neither outage was caused by a code or configuration change. Both incidents were capacity failures at their core. We failed to scale critical components before demand exceeded their capacity. Since April, monthly commits have grown from 1.4 billion to 2.9 billion. That growth explains the pressure on our systems, but it does not excuse these outages.

[…]

As part of the reliability commitments we made earlier this year, we have focused on three priorities: adding capacity, improving efficiency, and removing architectural bottlenecks. We have since added more than 3 million CPU cores, 120 petabytes of high-speed storage, and significant network capacity. We installed as much hardware as available power allowed in our existing data centers while accelerating our migration to Azure.

Alejandro Forero Cuervo:

This is the wrong way to think about this because there’s no such thing as infinite capacity. A large distributed system will be simultaneously mostly idle and (in some subcomponents) overloaded. The root cause is not “a component didn’t have enough capacity (because of auto scaling failures)”, but rather “this complex system collapses (rather than degrade gracefully) when demand exceeds capacity”.

When components reach capacity limits, the excess traffic of the lowest priority should be rejected. Rejected traffic should not be retried — in fact, not only should clients not retry these errors, these errors should cause client-side throttling. Traffic isolation should be applied — if the cause of the overload is a single client/customer system, no other system should be affected.

Nearly a decade ago I wrote about some of the techniques we applied at Google to implement these protections. Most other large internet services have since copied them, afaik.

Previously:

• Mac App Store Review Times Increasing