Aujourd'hui, une nouvelle fait le buzz sur Hacker News : le taux de chômage en Californie a grimpé à 5,5 %, le plus bas du pays, et le secteur technologique est en difficulté : "Le marché de l'emploi est trop cruel". > Selon les données publiées vendredi par le gouvernement de l'État, le taux de chômage en Californie a atteint 5,5 % en juillet, se classant au premier rang des États-Unis. Cela est dû à la faiblesse persistante du secteur technologique et d'autres emplois de bureau, ainsi qu'à la morosité du marché du recrutement. La nouvelle attribue cela à la faiblesse du secteur technologique, car ce secteur joue un rôle crucial dans l'économie californienne. Cette nouvelle a suscité de vives discussions dans la communauté Hacker News, où chacun a analysé les causes profondes sous-jacentes, qui sont bien plus complexes que ce que le titre de la nouvelle laisse entendre. Je pense que la discussion ci-dessus résume assez bien pourquoi le marché de l'emploi dans le secteur technologique est actuellement en déclin. 1. Tout d'abord, le point central est : dire adieu aux multiples séquelles de l'ère des "taux d'intérêt nuls" C'est le point de vue le plus courant et le plus profond dans la discussion. Beaucoup pensent que les difficultés actuelles du secteur technologique ne sont pas causées par un seul facteur, mais sont le résultat d'une réaction en chaîne provoquée par la fin de l'ère des "taux d'intérêt nuls" (ZIRP, Zero Interest Rate Policy) des dix dernières années. - Éclatement de la bulle de capital : De 2012 à 2022, des taux d'intérêt extrêmement bas ont rendu le capital exceptionnellement bon marché. De nombreux investissements en capital-risque (VC) ont afflué vers le secteur technologique, donnant naissance à d'innombrables modèles commerciaux basés sur la "brûlure d'argent", en particulier ceux des cryptomonnaies (Crypto) et des entreprises du métavers (Metaverse) qui manquaient de valeur réelle. Avec la hausse des taux d'intérêt par la Réserve fédérale, l'ère du capital bon marché s'est terminée, entraînant la rupture de la chaîne de financement de ces entreprises, ce qui a conduit à de nombreux licenciements et faillites. - Déséquilibre entre l'offre et la demande de talents : À l'ère des ZIRP, le mythe des salaires élevés dans le secteur technologique a attiré de nombreux talents. Les programmes de sciences informatiques (CS) des universités ont massivement augmenté leurs effectifs, les boot camps de programmation se sont multipliés, et avec l'immigration technique, l'offre d'ingénieurs logiciels a considérablement augmenté en dix ans. Cependant, avec le retrait du capital, la demande (en particulier des startups) a chuté de manière drastique, entraînant un excès de talents. - Effets d'entraînement sur des secteurs comme la biotechnologie : Des secteurs comme la biotechnologie (Biotech), qui dépendent également d'investissements à long terme et à haut risque, ont également été durement touchés. Ces secteurs dépendent encore plus du capital bon marché que le secteur logiciel. Après la fin des ZIRP, les fonds des VC se sont progressivement taris, et les startups, une fois leur "fonds de roulement" (runway) épuisé, n'ont pas pu obtenir de nouveaux financements, se retrouvant donc contraintes de licencier ou de fermer. > (par tqi) : "À mon avis, il est encore trop tôt pour dire que l'IA a un impact substantiel sur le recrutement des entreprises de logiciels. Une explication plus raisonnable est que, entre 2012 et 2022, l'offre de talents en ingénierie logicielle a considérablement augmenté... tandis que du côté de la demande, les fonds des VC à taux d'intérêt nuls ont principalement été investis dans des cryptomonnaies et des entreprises du métavers qui, pour la plupart, n'ont pas réussi, ce qui a conduit à un manque d'entreprises en phase de croissance ou nouvellement cotées capables d'absorber ces talents." 2. Le "double tranchant" du télétravail : la nouvelle vague de l'externalisation mondiale La pandémie de COVID-19 a popularisé le télétravail (Work From Home, WFH), ce qui a été perçu comme une bénédiction par de nombreux développeurs, mais maintenant, ses effets négatifs commencent à se manifester. - Ouvrir la voie à l'externalisation : Lorsque les développeurs se battent pour obtenir le droit de travailler entièrement à distance, ils ne réalisent peut-être pas que cela ouvre également la porte aux entreprises pour externaliser des postes vers des pays à coût inférieur. Puisque tout le monde travaille à distance, pourquoi une entreprise ne devrait-elle pas embaucher un ingénieur indien ou d'Europe de l'Est, tout aussi compétent, pour un salaire qui ne représente qu'un cinquième de celui d'un ingénieur américain ? - Les bureaux "dont on ne peut plus revenir en arrière" : Certains commentateurs estiment que la politique de "retour au bureau" (Return to Office, RTO) promue par les entreprises technologiques vise, dans une certaine mesure, à protéger les emplois locaux. Une fois qu'il est prouvé que le travail peut être effectué à 100 % à distance, il peut être réalisé de n'importe où dans le monde, et l'avantage salarial des ingénieurs américains disparaîtra. - Débat sur la qualité de l'externalisation : D'autres rétorquent que l'externalisation dure depuis des décennies, et que le développement de logiciels de haute qualité nécessite toujours des talents locaux de premier plan, car des problèmes tels que les coûts de communication, les différences de fuseau horaire et les contextes culturels sont difficiles à résoudre. Cependant, les utilisateurs soutenant l'externalisation estiment qu'avec la maturité des outils de collaboration à distance et l'amélioration des modes de gestion, ces obstacles sont progressivement surmontés. > (par aurareturn) : "Depuis 2022, j'ai dit sur HN : tous les développeurs nord-américains qui soutiennent le travail entièrement à distance, lorsque votre entreprise décidera de vous remplacer par des personnes à l'étranger, vous serez très surpris. Puisque tout le monde travaille à distance, pourquoi l'entreprise devrait-elle dépenser cinq fois plus pour vous embaucher plutôt qu'un employé à l'étranger qui travaille plus dur et se plaint moins ?... Les ordres de retour au bureau, à long terme, pourraient sauver votre carrière." 3. Le rôle de l'IA : outil de productivité, prétexte aux licenciements, ou "vampire" du capital ? La discussion sur le rôle de l'intelligence artificielle (IA) dans cette vague de licenciements présente des divergences complexes. - Effet de substitution direct limité : La plupart des gens s'accordent à dire que l'IA actuelle ne peut pas encore remplacer complètement des ingénieurs logiciels expérimentés. Mais elle a déjà commencé à remplacer certains travaux de niveau débutant et répétitifs, comme certaines petites tâches de conseil. Des consultants témoignent que des clients ne les contactent plus car ils peuvent résoudre certains petits bugs avec ChatGPT. - "Prétexte parfait" pour les licenciements : Un point de vue courant est que l'IA est devenue le "prétexte parfait" pour les entreprises pour licencier et réduire les coûts. Même si la raison fondamentale des licenciements est le ralentissement économique ou des décisions de la direction, les entreprises sont heureuses de le présenter comme un ajustement stratégique pour "embrasser l'IA et améliorer l'efficacité". - "Trou noir" du capital : L'IA joue un autre rôle clé : elle aspire les derniers investissements en capital-risque qui pourraient autrement être dirigés vers d'autres domaines technologiques. Les VC ne s'intéressent presque plus qu'aux projets d'IA, ce qui aggrave les difficultés de financement des startups dans des domaines non liés à l'IA. 4. La "rust beltisation" du secteur technologique ? Inquiétudes structurelles pour l'avenir Certains participants à la discussion expriment des inquiétudes pour l'avenir d'un point de vue plus macroéconomique, comparant le secteur technologique à l'ancienne "rust belt" de l'industrie manufacturière qui a connu un déclin après avoir été florissante. - Répétition de la perte d'emplois : Tout comme les États-Unis ont externalisé leur industrie manufacturière vers la Chine, les emplois en informatique et en développement logiciel sont maintenant en train de se déplacer massivement vers l'Inde, l'Amérique latine et l'Europe de l'Est. Cela pourrait entraîner un chômage structurel à long terme pour les ingénieurs logiciels qui gagnaient autrefois de bons salaires. - Impact politique et social : Si de nombreux emplois technologiques de la classe moyenne disparaissent, cela pourrait engendrer de nouveaux problèmes sociaux et politiques, tout comme le déclin de la "rust belt" continue d'influencer le paysage politique américain aujourd'hui. - Controverse sur l'immigration et les politiques de visa (H1B/O1) : Une partie de la discussion cible les visas de travail comme le H1B, les accusant d'être abusés, de faire baisser les salaires des ingénieurs locaux et d'aggraver la concurrence. D'autres défendent fermement l'immigration technique, affirmant que ces talents de premier plan venus du monde entier (comme les diplômés de l'Université de Waterloo) constituent la pierre angulaire de l'innovation de la Silicon Valley. 5. Gestion d'entreprise et évolution culturelle : l'"effet Musk" Un point de vue intéressant suggère que les licenciements massifs de Musk chez Twitter (maintenant X) ont eu un effet d'entraînement. - Rationalisation des licenciements : Lorsque Musk a licencié plus de 75 % des employés de Twitter, le produit a continué à fonctionner, ce qui a amené de nombreux PDG à réfléchir : "Puisqu'il peut le faire, pourquoi pas moi ?" Cela a brisé l'ancienne mentalité des entreprises technologiques selon laquelle "plus il y a de talents, mieux c'est", rendant les licenciements massifs plus acceptables psychologiquement et commercialement. 6. Facteurs politiques et politiques : controverse sur les changements fiscaux Une piste technique mais ayant des conséquences profondes concerne les changements dans la législation fiscale américaine. - Règles d'amortissement des dépenses de R&D (Section 174) : La loi de réforme fiscale (TCJA) du gouvernement Trump de 2017 contenait une disposition exigeant que les entreprises, à partir de 2022, amortissent les salaires et autres dépenses de R&D liés au développement de logiciels sur cinq ans, au lieu de pouvoir les déduire intégralement comme auparavant. Cela a considérablement augmenté la charge fiscale des entreprises technologiques (en particulier des startups), décourageant leur volonté de recruter aux États-Unis. - Rôle correctif des lois récentes : La récente adoption de la "loi Build Back Better" (BBB) a partiellement corrigé ce problème, permettant aux dépenses de R&D domestiques d'être à nouveau déduites immédiatement. Certains commentateurs estiment avoir ressenti un léger réchauffement du marché de l'emploi vers juillet, ce qui pourrait y être lié. Enfin D'après ces discussions, les raisons du déclin de l'emploi dans le secteur technologique en Californie sont assez complexes et ne peuvent pas être attribuées à un seul facteur. Il ne s'agit pas simplement de "l'IA remplaçant les humains" ou d'un "déclin cyclique de l'industrie", mais d'une combinaison de la fin de l'ère des taux d'intérêt nuls, de la restructuration du marché mondial du travail due au télétravail, de l'impact double de l'IA en tant que nouvelle technologie et aimant à capital, ainsi que de changements spécifiques dans les politiques fiscales.

Transcription : Pourquoi les grands modèles de langage ne peuvent-ils pas vraiment construire des logiciels ? Auteur : Conrad Irwin J'ai passé beaucoup de temps à interviewer des ingénieurs logiciels. C'est évidemment une tâche ardue, et je ne dirais pas que j'ai une méthode infaillible ; mais cette expérience m'a vraiment donné le temps de réfléchir à ce qu'un ingénieur logiciel efficace fait réellement. Le cycle central de l'ingénierie logicielle Lorsque vous observez un véritable expert, vous constaterez qu'il exécute toujours les étapes suivantes en boucle : * Construire un modèle mental des besoins. * Écrire (on l'espère ?!) du code capable de répondre aux besoins. * Construire un modèle mental du comportement réel du code. * Identifier les différences entre les deux, puis mettre à jour le code (ou les besoins). Il existe de nombreuses façons d'accomplir ces étapes, mais la force des ingénieurs efficaces réside dans leur capacité à construire et à maintenir des modèles mentaux clairs. Comment se comportent les grands modèles de langage ? Pour être juste, les grands modèles de langage excellent dans l'écriture de code. Lorsqu'on leur indique où se situe le problème, ils s'en sortent également assez bien pour mettre à jour le code. Ils peuvent faire tout ce qu'un ingénieur humain ferait : lire du code, écrire et exécuter des tests, ajouter des journaux, et (probablement) utiliser un débogueur. Mais ce qu'ils ne peuvent pas faire, c'est maintenir un modèle mental clair. Les grands modèles de langage tombent dans une confusion sans fin : ils supposent que le code qu'ils ont écrit fonctionne réellement ; lorsque les tests échouent, ils ne peuvent que deviner s'il faut corriger le code ou le test ; lorsqu'ils se sentent frustrés, ils suppriment tout et recommencent. Cela va à l'encontre des caractéristiques que j'attends d'un ingénieur. Les ingénieurs logiciels testent en travaillant. Lorsque les tests échouent, ils peuvent se référer à leur modèle mental pour décider s'il faut corriger le code ou le test, ou s'ils doivent d'abord recueillir plus d'informations avant de prendre une décision. Lorsqu'ils se sentent frustrés, ils peuvent chercher de l'aide en communiquant avec d'autres. Bien qu'ils puissent parfois tout supprimer et recommencer, cela se fait après avoir acquis une compréhension plus claire du problème. Mais ça ira vite, n'est-ce pas ? Avec l'augmentation des capacités des modèles, cette situation va-t-elle changer ? Peut-être ? Mais je pense que cela nécessiterait un changement fondamental dans la manière dont les modèles sont construits et optimisés. Le modèle dont l'ingénierie logicielle a besoin n'est pas simplement capable de générer du code. Lorsqu'une personne rencontre un problème, elle peut temporairement mettre de côté tout le contexte, se concentrer sur la résolution du problème immédiat, puis revenir à ses pensées précédentes et au grand problème en cours. Elle peut également passer facilement entre la vue d'ensemble et les détails, en ignorant temporairement les détails pour se concentrer sur l'ensemble, puis en approfondissant les parties lorsque cela est nécessaire. Nous ne devenons pas plus efficaces simplement parce que nous ajoutons plus de mots dans notre "fenêtre de contexte" ; cela ne ferait que nous rendre fous. Même si nous pouvons gérer une grande quantité de contexte, nous savons que ces modèles génératifs actuels présentent plusieurs problèmes graves qui affectent directement leur capacité à maintenir des modèles mentaux clairs : * Omission de contexte : les modèles ne sont pas doués pour détecter les informations contextuelles négligées. * Biais de proximité : ils sont gravement affectés par un biais de proximité lorsqu'ils traitent la fenêtre de contexte. * Hallucinations : ils ont souvent tendance à "imaginer" des détails qui ne devraient pas exister. Ces problèmes ne sont peut-être pas insurmontables, et les chercheurs s'efforcent d'ajouter de la mémoire aux modèles pour qu'ils puissent exercer des techniques de pensée similaires aux nôtres. Mais malheureusement, pour l'instant, ils ne peuvent pas réellement comprendre ce qui se passe (au-delà d'un certain niveau de complexité). Ils ne peuvent pas construire de logiciels parce qu'ils ne peuvent pas maintenir simultanément deux "modèles mentaux" similaires, identifier les différences et décider s'il faut mettre à jour le code ou les besoins. Alors, que faire maintenant ? Il est évident que les grands modèles de langage sont utiles pour les ingénieurs logiciels. Ils peuvent générer du code rapidement et excellent dans l'intégration des besoins et de la documentation. Pour certaines tâches, cela suffit : les besoins sont suffisamment clairs, le problème est suffisamment simple, et ils peuvent tout faire d'un coup. Cela dit, pour toute tâche ayant un peu de complexité, ils ne peuvent pas maintenir suffisamment de contexte de manière suffisamment précise pour produire finalement une solution viable par itération. Vous, en tant qu'ingénieur logiciel, devez toujours vous assurer que les besoins sont clairs et que le code réalise réellement ce qu'il prétend faire. Chez Zed, nous croyons que l'avenir des humains et des intelligences artificielles peut être de construire des logiciels ensemble. Cependant, nous sommes convaincus (du moins pour l'instant) que vous êtes le conducteur qui tient le volant, et que les grands modèles de langage ne sont qu'un autre outil à votre portée.

Hier, je suis allé à la conférence des chefs de produit de CSDN pour donner un discours. Il y a trois mois, quand les amis de CSDN m'ont invité à faire une présentation à la conférence des chefs de produit, j'avais en fait l'intention de refuser. La raison est que ma startup vient à peine d'être fondée depuis six mois, et je n'ai pas beaucoup de connaissances ou d'expériences à partager avec tout le monde. Cependant, les amis de CSDN ont dit que ce n'était pas grave, qu'il restait trois mois avant la conférence, et que je pouvais également partager certaines de mes expériences passées en matière de produits. Par coïncidence, la semaine dernière, après le lancement de FlowSpeech, la réputation du produit a explosé, le MRR a triplé, et l'ARR a également franchi un petit objectif, et plus important encore, nos utilisateurs ont gagné de l'argent réel en utilisant le produit, ce qui est la meilleure preuve de notre force produit. Donc, hier, pendant ma présentation, j'ai plaisanté en disant que la valeur de ce PPT avait considérablement augmenté, et j'ai demandé à tout le monde d'écouter attentivement.

« En tant qu'agriculteur, j'achète uniquement des aliments bio ; en tant que professionnel de l'IA, je ne regarde que du contenu non généré par l'IA » 😅

Vibe Coding est un terme trompeur et peu judicieux, dont la principale signification est d'utiliser l'IA pour le développement de prototypes, ce qui peut aider à déterminer rapidement les besoins du produit. Dans l'ingénierie logicielle, le code de développement de prototypes est généralement jetable ; lors du développement officiel du produit, il est nécessaire de refaire la conception système, puis de coder et de mettre en œuvre. Les résultats de Vibe Coding sont similaires : une fois les besoins déterminés, il faut encore repenser et redévelopper.

Dans l'ingénierie contextuelle, l'agent doit interagir avec des outils et un environnement pour obtenir des données afin de compléter le contexte.

Tutoriel d'auto-apprentissage en informatique TeachYourselfCS Si vous êtes un ingénieur autodidacte ou si vous avez terminé une formation en programmation, il est essentiel que vous appreniez l'informatique. Heureusement, il n'est pas nécessaire de passer des années et de débourser une somme considérable pour obtenir un diplôme : vous pouvez atteindre un niveau d'éducation de classe mondiale simplement par vous-même 💸. Sur Internet, il existe de nombreuses ressources d'apprentissage, mais il y a à la fois des perles et des déchets. Ce dont vous avez besoin, ce n'est pas d'une liste comme « 200+ cours en ligne gratuits », mais des réponses aux questions suivantes : Quels sujets devriez-vous étudier et pourquoi ? Quels sont les meilleurs livres ou cours vidéo pour ces sujets ? Dans ce guide, nous essayons de répondre de manière précise à ces questions.

Voici, les amis～ J'ai 3 millions d'utilisateurs et je ne gagne que 20 yuans : la fausse prospérité des outils d'IA - ListenHub Raconter des blagues, qui ne sait pas le faire ? Beaucoup de gens étaient intéressés par le cas que j'ai partagé sur Hardland Hacker, j'ai donc créé un podcast de blagues en utilisant @oran_ge sur ListenHub. Vous pouvez venir écouter～

De nombreux amis s'inquiètent des limites d'utilisation de la version équipe (Team) et de la version entreprise (Enterprise) de ChatGPT. L'équipe officielle a maintenant publié deux nouveaux articles de questions fréquentes (FAQ) pour expliquer cela. * Version équipe de ChatGPT - Utilisation illimitée de GPT-5 et GPT-4o, mais avec les limitations suivantes selon les différentes versions de modèle : * 200 demandes de réflexion (Thinking) GPT-5 par jour * 2800 demandes de réflexion mini (Thinking mini) GPT-5 par semaine * 15 demandes Pro GPT-5 par mois * 500 demandes GPT-4.1 toutes les 3 heures * 300 demandes o4-mini et o3 par jour * Version entreprise de ChatGPT - Utilisation illimitée de GPT-5, GPT-4o et GPT-4.1-mini, mais avec les limitations suivantes selon les différentes versions de modèle : * 200 demandes de réflexion (Thinking) GPT-5 par semaine * 15 demandes Pro GPT-5 par mois * 20 demandes GPT-4.5 par semaine * 500 demandes GPT-4.1 toutes les 3 heures * 300 demandes o4-mini par jour * 100 demandes o4-mini-high par jour * 100 demandes o3 par semaine * 15 demandes o3-pro par mois L'article FAQ mentionne également que les limitations du modèle de réflexion (Thinking) GPT-5 sont temporaires et en réalité, elles sont plus élevées que les limitations à long terme énumérées ci-dessus.

C'est vrai : il vaut mieux dire ce qu'il faut faire dans le prompt plutôt que ce qu'il ne faut pas faire. Les grands modèles se comportent un peu comme les humains, plus on leur dit de ne pas faire quelque chose, plus cela attire leur attention.