The best context is the codebase.
The best spec is E2E tests.
The best harness is a custom linter enforcing architectural rules.
The best agentic engineering is putting LLMs to work on high-quality code.
Skills only for environment specifics. For the rest: less is more.
Santiago Fernandez retweeted
Getting more and more convinced that if you understand the "shared language" of your codebase...
(i.e. the terms used, the names for things, relationships between them)
...AND those terms are used consistently in the codebase, then you understand the codebase.
Whether you read the actual code or not.
DDD has never been more powerful.
As the mechanical cost of producing code approaches zero, the cognitive work of designing systems, writing specifications, maintaining architectural decisions, and managing business knowledge becomes the primary bottleneck and the primary source of value.
5
184
Santiago Fernandez retweeted
The 2nd edition of Designing Data-Intensive Applications, by @martinkl and me, is finished and sent to the printers! Ebooks available next week, and print books in 3–4 weeks. Sigh of relief. 😅
(BTW, this is a good opportunity to support your favourite local bookshop!)
Cohesion and coupling problems never went away — and they won’t. You still need to understand software to produce software. The real bottleneck now is the maximum cognitive load we can safely handle. You can’t be responsible for code you don’t truly know.
Software engineers: Context switching kills productivity.
Also software engineers: I'm now managing 19 AI agents and doing 1800 commits a day.
We’ve spent years complaining that managers who expect a quick 5-minute chat ruin our focus for the next hour. But a ping from an agent every few minutes, that’s ok?
We celebrated Paul Graham’s essay “Maker’s Schedule, Manager’s Schedule” in which he argued:
“When you're operating on the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in.”
Now we see software engineers claiming huge productivity gains from hordes of AI agents, celebrating thousands of commits per day from their 19 agents.
Either context switching was never really the problem, and we oversold our need for deep focus. Or we're not actually reviewing 1800 commits a day.
If we couldn't context switch before, we're not managing 19 agents. We're blindly trusting them.
That’s not engineering, it’s gambling.
127
Santiago Fernandez retweeted
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
¹ teapawt.net/mntruell/status/201282…
² teapawt.net/anthropicai/status/201…
³ wesmckinney.com/blog/agent-e…
⁴ github.com/tailwindlabs/tail…
New Engineering blog: We tasked Opus 4.6 using agent teams to build a C compiler. Then we (mostly) walked away. Two weeks later, it worked on the Linux kernel.
Here's what it taught us about the future of autonomous software development.
Read more: anthropic.com/engineering/bu…
Los desarrolladores que no se enfrentan a desafíos de escalabilidad reales, se enfocan en microadministrar la performance.
102
Santiago Fernandez retweeted
Replying to @rauchg
The most effective groups in history connected through ideas, not offices.
Remote work just strips away the theater of collaboration to focus on actual output.
Ask any open-source project that changed the world.
Santiago Fernandez retweeted
¿Aún no operás a través de matriz OMS?
Ingresá acá👉youtu.be/A6gtpiIsFBY que te mostramos cómo hacerlo desde la web y matriz app.
Somos #Primary #TecnologíaExpansiva
Santiago Fernandez retweeted
¿Conocés matriz OMS? Desde acá podés invertir en Acciones, Bonos, CEDEARs, Futuros y Opciones, además de Suscribir y/o Rescatar FCI.
+ de 35 ALyCs ya la ofrecen a sus clientes! 👏
Mirá el video y conocé cómo operar: lnkd.in/dzGebkVh
Somos Primary, #TecnologíaExpansiva
Docentes que usan ChatGPT para armar el material y las consignas de la tarea, alumnos que lo usan para hacer la tarea, docentes que lo vuelven a usar para corregirla...
Es la 2da revolución por la que pasa la educación en 3 años, y parece seguir todo igual.
1
142
“5 Things Founders, Investors and Recruiters Should Know about the CTO role” by Marc van Neerven
link.medium.com/uicj8UgOuzb
111
“Your Process Should Be Open Source” by Jade Rubick
link.medium.com/pJm4ntU3Cxb
2
172
Santiago Fernandez retweeted
At work, it's just 2: me (backend) & 1 frontend (web&mobile). We release countless features consistently, uptime ~99.999%, we solve some stupidly complex farming problems. Thanks to Elixir+PgSQL & I think a "100x developer" is not a myth (&we don't work after 16h & at weekends).
The architecture of a #web3 application
#blockchain #dapps #smartcontracts #softwarearchitecture
preethikasireddy.com/post/th…
1

















