I doubt that many data centers or enterprises are interested in building phone clusters. I hope that this project will produce something that homelabs and self-hosters can build with 3D printers. That seems like the most probable end consumer.
GitHub Issues before PRs is a great approach. The ghostty project takes that one step further: GH _discussions_ before GH issues. Only maintainers can make issues.
I supervise the contributions that juniors make to our codebase. To do this effectively, I use three tools:
1. Scoping. I give juniors projects that are big enough to be valuable, but not so big that they get lost.
2. Instruction. I give juniors frequent, bite-sized lessons related to their tasks. In this, I invest in their skills.
3. Linting. Anything that could be considered a “nit” in a code review is relegated to machine lints. For example, I will never talk about formatting in a code review. That is solved by tooling.
This article makes me wonder if there’s some sort of machine-readable lint for costly abstraction? In a TS project, is there some way to say, “the shadow DOM under this component is too deep.” Or “this object’s inheritance tree is too long.”
Or for zero/cost abstraction languages, is it feasible/productive to lint “this packages dependency tree is too deep”?
How do you identify abstractions that are too leaky to be helpful?
This is exactly what stood out to me, too. Before this Tweet, my feelings towards Coinbase were completely neutral. After this Tweet, I want nothing to do with it.
> Over the past year, l've watched engineers use Al to ship in days what used to take a team weeks. Nontechnical teams are now shipping production code and many of our workflows are being automated.
> The database can be dumb and fast because the application layer is smart and careful.
I’ve always baked important invariants directly into the database with constraints and triggers. Maybe this is because I work on internal apps, where the data is more important than the presentation. Maybe it’s from my functional programming experience and some need to make invalid states unrepresentable.
Regardless, I believe that the data layer should be the most carefully designed part of an app.
This creator has fascinating insights into design and UX. This team’s synthesis is more insightful and professional than anything else I have been able to casually consume.
This particular video argues against the notion of a “happy path.” In reality, “edge cases” are just as valid _states_ as the “happy path.”
At work, I am rewriting a Salesforce Implementation that failed largely due to poor UX. The first solution was built by contractors who later ditched. They built the “happy path.” After they left, I had to support the software. When we launched, I had conversations with users EVERY DAY where I had to say, “sorry, we didn’t plan for that edge case.” It turns out that edge cases aren’t really “edge” at all. It was just a poorly designed system.
Watching this video made me redouble my efforts to plan for every state. I want to be able to respond to support questions with, “we designed for that.”
What do you think? How can we balance good design with time and money requirements? Any thoughts about the video’s suggestions at the end?
Super cool idea, and “Layer 8” is a dope name. “EZThrottle” is not nearly as catchy lol. But who am I to judge? I haven’t built anything like this. Best of luck to you.
Your mention of Salesforce is ironic given their recent pivot towards headless SaaS. Check out Headless 360. It promises the open interface you describe in your article (for insane amounts of money).
Interesting ideas. I would love programmatic access to everything, though I think it’s a stretch to expect this within a year. Personal AI agents are still niche.
I suspect the timeline will look something like this:
1. 1-2 years, Google and Microsoft expand the capabilities of their OS-integrated apps, including support for integrating with external apps. Microsoft rolls out “Cortana Communications Protocol” (CCP), a closed-source alternative to MCP that integrates with Copilot. People hate it.
2. 3-5 years, people become more accustomed to personal AI agents.
3. 7 years, Apple rolls out “Apple Intelligence Link Protocol” (AILP) Apple’s take on CCP and MCP. It becomes the de facto standard.
4. 10 years, AILP, CCP, and MCP converge into a single standard. 80% of backend web frameworks support this standard out of the box. All phones support it. Millenials everywhere are constantly confounded and befuddled by these AI personal assistants.
———
It’s funny you mention the Salesforce CLI. I develop a Salesforce-based app for work. My agents and I likely run the `sf` command several hundred times a day.