chartered_stack
Joined 1 year ago
Joined 1 year ago
I'm talking more about agents as a force multiplier for teams who do have engineering experience. They reduce the amount of specialized knowledge, time, and coordination required to get something built and maintained. The constraint gets meaningfully weaker.
An experienced engineer who understands software architecture, debugging, product constraints, etc. but isn't an expert in every native platform can increasingly use an agent to bridge some of those gaps. That's very different from vibecoding your way into production.
fwiw I think we're still very early in the process of re-thinking about how teams are organized and what skill sets they need.
Cross-platform became so dominant because the same small dev teams had to support users across multiple platforms. Practically they either had to build ONLY for the web or use some kind of web-tech-based framework like Electron.
Agentic coding changes that constraint at a very low level. Teams are no longer limited by whether they have someone who knows how to build for iOS, Android, macOS, etc., or whether they have the bandwidth to maintain multiple native codebases. The cost of supporting multiple platforms starts to fall dramatically.
And I think this is closely related to the thesis behind Omarchy also. Setting up and customizing Linux is historically a lot of friction. If you wanted a system that was personal i.e. NOT (Mac OR PC) you often had to be comfortable troubleshooting obscure issues and spending hours getting everything just right. Don't get me wrong: a lot of people enjoy that friction. But it sucks at so many levels.
Agents lower that barrier. You can want a highly customized system without necessarily becoming an expert in every layer of the stack. If there’s some tweak or workflow that isn’t exposed through a settings menu, you can increasingly just describe what you want and have the system help you build it.
So I think the interesting shift is that software becomes less constrained by what the average team or individual programmer has the bandwidth to build and maintain. That could make both native apps and highly personalized computing environments much more viable again instead of the web-slop that we've become accustomed to over the past 20 years. I really see parallels between how the Mac empowered creatives in the 80s and agentic coding today.
It seems to me that we are on the fast ramp to making the paperclip maximizer a reality. imo the most likely "dystopian" future that we'll get to see. These models have no concept of their RL env sandboxes and the real world. Extremely interesting to see how they compete in trying to get finite resources and work with constrained supply chains.
An interesting experiment to be sure.
At any rate, it would be interesting to see what the actual capabilities would be. The Meta AI integration with WhatsApp actually sucks so bad. Hope it's better than that.
[0] - https://ai.meta.com/learn/agentic-ai/what-are-ai-agents/
[1] - https://ai.meta.com/learn/agentic-ai/agentic-ai-examples/
1. A "rough" notebook to jot down notes 2. A "classwork" notebook to present those notes properly to the teacher and get them corrected and 3. A "homework" notebook to finish homework assignments that used to be given
It's quite a discipline to jot things down in the rough work book and then write out a "neat" version in the class work book.
I stopped doing it once I finished school and realized I didn't really need to do it anymore once I understood what I was writing out. But maybe it’s a habit worth returning to.
People say Apple does its best work as a “second mover,” but that misses the actual pattern: Apple builds great products when leadership is solving their own problems.
The Mac, iPod, iPhone, and iPad weren’t just refinements of existing products. They were devices Steve Jobs personally wanted to use and couldn’t find elsewhere. The man saw the GUI at Xerox and saw how anyone could use a computer without remembering arcane commands. So he drove the development of the Mac. He was using a shitty mobile phone, saw the opportunity and had the iPhone developed. Same with the early Apple Watch (first post-Jobs new product line), which reflected Jony Ive’s fashion ambitions; once he left, it evolved into what current leadership actually uses: a high-end fitness tracker.
The stagnation we're seeing now isn’t about Apple losing its “second-mover magic.” It’s that leadership doesn’t feel an unmet need that demands a new device. None of Vision Pro, Siri, Apple Intelligence or even macOS itself anymore appear to be products the execs themselves rely on deeply, and it shows. Apple excels when it scratches its own itch and right now, it doesn’t seem to have one.
But I think a frame shift that might help is that you're not actually donating your time to LMAX (or whoever). You're instead contributing to make software that you've already benefited from become better. Any open source library represents many multiple developer-years that you've benefited from and are using for free. When you contribute back, you're participating in an exchange that started when you first used their library, not making a one-way donation.
> They wouldn't have merged my code in if they didn't think it had some amount of value, and if they think it has value then they should pay me.
This can easily be flipped: you wouldn't have contributed if their software didn't add value to your life first and so you should pay them to use Disruptor.
Neither framing quite captures what's happening. You're not in an exchange with LMAX but maintaining a commons you're already part of. You wouldn't feel taken advantage of when you reshelve a book properly at a public library so why feel bad about this?
The thing is this takes a lot of resources to get right. FOSS developers simply don't have the wherewithal - money, inclination or taste - to do this. So, by default, there are no simple things. Everything's complex, everything needs training. And this is okay because the main users of FOSS software is others of a similar bend as the developers themselves.
The bridge would come from layering natural languages interfaces on top of deterministic backends that actually do the tool calling. We already have models fine-tuned to generate JSON schemas. MCP is a good example of this kind of stuff. It discovers tools and how to use them.
Of course, the real bottle neck would be running a model capable of this locally. I can't run any of models actually capable of this on a typical machine. Till then, we're effectively digital serfs.
GUIs emerged to make things easier for users to tell their computers what to do. You could just look at the screen and know that File > Save would save the file instead of remembering :w or :wq. They minimized friction and were polished to no end by companies like MSFT and AAPL.
Now that technology has got to a point where our computers now can bridge the gap between what we said and what we meant reasonably well, we can go back to CLIs. We keep the speed and expressiveness of typing but without the old rigidity. I honestly can't wait for the future where we evolve interfaces to things we previously only dreamt of before.
https://github.com/DeadMeme5441/arrodes
It seems to be a bit more integrated than what you describe here because it's completely built around a Clojure REPL