Enrique Soria

Hola github.com/rsinger86/djan…

AI has made it easier to write optimized code on day 0, but it is creating a new problem... Ask an LLM to write some code, and it will often reach for the most "correct" version - caching, batching, async, configurable strategies. Code that looks staff-level from the first commit. If you keep probing it to optimize further, it will come up with such absurd optimizations that you may not have even heard of. Most of these optimizations solve a problem you do not have yet. A function handling 50 records a day does not need a connection pool, a retry queue, and a pluggable backend. It needs to work and be readable. To be honest, we engineers have always over-engineered, but AI has lowered the cost of writing the complex version to nearly zero, so the lazy default (write the simple thing first) no longer feels lazy. It feels like leaving performance on the table. The result is codebases full of abstractions nobody asked for. Interfaces with a single implementation. Generic configs for cases that will never change. Vector operations and macros no one asked for. The skill that matters now is not writing optimized code. It is knowing when to stop optimizing. Premature optimization used to be expensive enough that most people avoided it by default. Now it is one prompt away. Good engineering judgement is about knowing which optimizations the problem in front of you actually needs. Hope this helps.

A short story about deferring tech choices to thought leaders: Early days at Disqus (~2010-2012), we made several frontend choices based largely on what thought leaders were promoting at the time. One example: there was a big movement toward "micro-frameworks." Instead of larger, well-tested libraries like jQuery, you'd stitch together tiny interoperable micro libraries (Ender.js was one). Disqus was an embeddable JavaScript app, so file size mattered. It fit our use case, so we went with it. Then it went live, and we were serving millions of users. The reality of those choices became clear. Micro libraries meant that instead of one good semi-bloated library, you ran 6-7 smaller, less-tested, crappier ones. We burned a ton of cycles fixing bugs and covering corner cases when we could've been shipping product. We made a few choices like this. At conferences, I'd track down those same thought leaders and ask for advice. "I'm hitting problem X, Y, Z. How did you solve this?" That's when I learned my lesson: they rarely had answers, because they'd never reached our scale. Their energy went into promoting new stuff, not running it. You should know this has never stopped. It's happening right now with AI. It'll happen again with whatever comes next. Do your own homework. Test a lot. Don't just go with what somebody tells you.

A mí personalmente lo que me llamó de la programación en su época fue el desafío intelectual que me suponía darle la mejor solución posible a un problema dado. Últimamente ando un poco poff con esto porque la IA te quita bastante de este trabajo técnico, aunque queda todavía bastante donde trabajar. Pero la cosa es que con el código ya no disfruto tanto como antes y tengo que buscar esa satisfacción en otros aspectos. PD: también es problema de los proyectos que me llegan últimamente, no todo es culpa de la IA 😂

Hablando con amigos de distintas empresas sobre AI, todos parecen estar de acuerdo en una cosa. El tokenmaxxing y la AI en general beneficia a los vagos y hace más difícil identificarlos. Antes de los LLM era muy fácil distinguir a un profesional de un vago underperformer. Ahora, el vago puede tirar un par de prompts y llenar el repo de PRs llenas de slop que otros tienen que revisar. A primera vista, parece que su rendimiento es idílico. Los managers no lo pueden ver fácil a no ser que se pongan a revisar PRs o reciban feedback directo. Los profesionales se interesan por sacar código de calidad y bien probado. Pero ahora tienen que revisar toneladas de slop en documentos, tickets y PRs. Revisar slop cansa y quema mucho. Y cada vez hay más.

Or maybe reduce that percentage

This is the point. Same will happen in all countries that will make social media age restrictions. “Won’t someone think of the children” is usually not about the children

I'm an old programmer (by programmer standards). I use agents daily, extensively. Here's a view from the other side of "wooooow look how many lines it wrote!", taken from my work today.

@DjangoTricks Thanks! I've had a lot of misassumptions about this, especially with threading.local, lru_caches and things computed at import time. Do you have more resources on this topic?

In my latest blog post, I explore the memory usage of Gunicorn workers. djangotricks.com/blog/2026/06/u…

About Getting or Setting a Cache Value djangotricks.com/tricks/58SWpmG…

In my experience, you can find enormous (and often obvious) performance wins in most systems because no one else has bothered to look

My current experience with coding models.

software engineering in 2026: - your package manager is compromised - your cloud provider blocks your account - github itself is hacked software is solved

There will be a regression to the mean. For now, every developer is under pressure to do more with AI, even at the price of losing observability and understanding of their code base. Eventually, we'll regress to a point where we get the productivity boost from LLMs while still staying in control of what the code does and taking ownership. It will probably take a few large-scale disasters for that to happen. But it eventually will. There is no free lunch in AI.

We are investigating unauthorized access to GitHub’s internal repositories. While we currently have no evidence of impact to customer information stored outside of GitHub’s internal repositories (such as our customers’ enterprises, organizations, and repositories), we are closely monitoring our infrastructure for follow-on activity.

didYouAskClaude

nothingUnexpectedCanEverHappenInASprint

Si todo es urgente, nada lo es.

I strongly believe there are entire companies right now under heavy AI psychosis and its impossible to have rational conversations about it with them. I can't name any specific people because they include personal friends I deeply respect, but I worry about how this plays out. I lived through the great MTBF vs MTTR (mean-time-between-failure vs. mean-time-to-recovery) reckoning of infrastructure during the transition to cloud and cloud automation. All those arguments are rearing their ugly heads again but now its... the whole software development industry (maybe the whole world, really). It's frightening, because the psychosis folks operate under an almost absolute "MTTR is all you need" mentality: "its fine to ship bugs because the agents will fix them so quickly and at a scale humans can't do!" We learned in infrastructure that MTTR is great but you can't yeet resilient systems entirely. The main issue is I don't even know how to bring this up to people I know personally, because bringing this topic up leads to immediately dismissals like "no no, it has full test coverage" or "bug reports are going down" or something, which just don't paint the whole picture. We already learned this lesson once in infrastructure: you can automate yourself into a very resilient catastrophe machine. Systems can appear healthy by local metrics while globally becoming incomprehensible. Bug reports can go down while latent risk explodes. Test coverage can rise while semantic understanding falls. Changes happens so fast that nobody notices the underlying architecture decaying. I worry.