Gojō Satoru

You might believe you should spend less time thinking about code because of AI. I strongly disagree! We’re watching this play out live where tons of AI generated code becomes a liability. At the end of the day, an engineer needs to be responsible / on call for code that gets shipped to production. If you don’t understand the system you’re trying to debug, you’re probably going to have a bad time. Yes, AI can help with all of this, if you set up the proper systems. You can have agents triage prod logs, look at errors, etc. You can speed up parts of the investigation, but an engineer needs to make the call. There might be serious customer or financial implications from that change. I expect the trend continue for trimming dependencies, vendoring code so you can modify it directly, preferring simpler systems with fewer abstractions, and spending waaaay more time thinking about system design and code maintenance. I’ve said this before, but it’s a great time to get familiar with CS fundamentals and some of the history behind what great software looks like. Many parts will be different in the coming years as AI progresses, but also a lot more than people realize will stay the same.

You might believe you should spend less time thinking about code because of AI. I strongly disagree! We’re watching this play out live where tons of AI generated code becomes a liability. At the end of the day, an engineer needs to be responsible / on call for code that gets shipped to production. If you don’t understand the system you’re trying to debug, you’re probably going to have a bad time. Yes, AI can help with all of this, if you set up the proper systems. You can have agents triage prod logs, look at errors, etc. You can speed up parts of the investigation, but an engineer needs to make the call. There might be serious customer or financial implications from that change. I expect the trend continue for trimming dependencies, vendoring code so you can modify it directly, preferring simpler systems with fewer abstractions, and spending waaaay more time thinking about system design and code maintenance. I’ve said this before, but it’s a great time to get familiar with CS fundamentals and some of the history behind what great software looks like. Many parts will be different in the coming years as AI progresses, but also a lot more than people realize will stay the same.

I’m still trying to figure things out…

J'ai envie d’interdire momentanément le multi-session ou l’ouverture de plusieurs agents simultanément à mes devs. Certains bossent sur 3 ou 4 features en même temps et n’ont même plus le temps de vérifier. Pire, ils oublient parfois même sur quoi ils étaient avec un agent… They’re just breaking things faster😭

Fork your dependencies, trim them to only your use case, never update unless it breaks for your users. I’ve been vocal about this for 10+ years. I’ve always said that updating is way riskier than latent bugs (which can be tracked and CVEs monitored). If you are updating a dependency, it’s on you to analyze every single commit in the full transitive set of dependencies. If you dont see anything compelling, dont update! I remember at HashiCorp once in awhile an engineer would try to update a dep or replace a DIY lib with an external one and id always ask “show me the commit we need.” Dont update for the sake of it. Feeling pretty swell about this mentality with all the supply chain attacks happening.

Vous n'avez pas besoin de microservices. En réalité, vous n'avez pas besoin de la plupart des tendances que vous voyez défiler sur internet. Un monolithe bien écrit bat un cluster Kubernetes mal justifié à presque tous les niveaux : lisibilité, débogage, coût opérationnel, vitesse de livraison. Par definition, un ingénieur, c'est quelqu'un qui utilise le strict minimum de technologie pour résoudre un problème donné. Pas celui qui en empile le maximum pour signaler sa sophistication. Les microservices ont leur place. Quand vous avez des équipes indépendantes qui déploient à des rythmes différents, quand la scalabilité d'un composant isolé le justifie, quand le coût de coordination est déjà absorbé par votre organisation, pas avant. Ce que vous voyez sur X ou dans les conférences, c'est l'architecture de Netflix ou Uber documentée par des ingénieurs dont le problème principal est la scale à des millions d'utilisateurs. Ce n'est pas votre problème. Entout cas pas encore et peut-être jamais. Choisir une technologie parce qu'elle est populaire, c'est laisser Twitter décider de votre architecture. Un ingénieur pose toujours la même question avant d'ajouter quoi que ce soit: quel problème précis est-ce que ça résout, et est-ce le problème que j'ai aujourd'hui ?