No. 3916th of 7 editions that day← Earlier Later →
Zuck lies under oath, ARM emulation disappoints, and money remains the only moat worth digging
- Zuckerberg: Congress gets the same treatment as Facebook's content moderation
- AVX2: When your fancy vector instructions become emulation tax
- AI Velocity: Fowler reminds us that garbage in means garbage out, but faster
1Mark Zuckerberg Lied to Congress. We Can't Trust His Testimony :meta:congress:child-safety 扎克伯格在国会作伪证，我们无法信任他的证词 マーク・ザッカーバーグは議会で嘘をついた。彼の証言は信用できない 마크 저커버그가 의회에서 거짓말했다. 그의 증언을 신뢰할 수 없다 Mark Zuckerberg mintió al Congreso. No podemos confiar en su testimonio Mark Zuckerberg hat den Kongress belogen. Wir können seinem Zeugnis nicht vertrauen ¶
406 points230 commentsHN 47060486by speckx
Tech Oversight Project documents multiple instances where Zuckerberg misled Congress during a 2024 Senate Judiciary hearing on child safety. Key findings: 64% of Instagram's safety tools were ineffective, Meta had a 17-strike policy for sex trafficking accounts, and internal research contradicted his claims that social media doesn't harm teens.
Tech Oversight Project 记录了扎克伯格在 2024 年参议院儿童安全听证会上多次误导国会的情况。主要发现：64% 的 Instagram 安全工具无效，Meta 对性贩运账户有 17 次违规才处理的政策，内部研究与他关于社交媒体不伤害青少年的说法相矛盾。
Tech Oversight Project は、2024 年の上院司法委員会の児童安全に関する公聴会で、ザッカーバーグが議会を複数回誤解させたことを文書化した。主な発見：Instagram の安全ツールの 64% が無効、Meta は性的人身売買アカウントに 17 回の違反まで許容する方針、内部調査は彼のソーシャルメディアが 10 代に害を与えないという主張と矛盾していた。
Tech Oversight Project 는 2024 년 상원 사법위원회 아동 안전 청문회에서 저커버그가 의회를 여러 번 오도한 사례를 문서화했다. 주요 발견: 인스타그램 안전 도구의 64% 가 비효율적, 메타는 성매매 계정에 17 번 위반 정책, 내부 연구는 소셜 미디어가 청소년에게 해롭지 않다는 그의 주장과 모순됐다.
Tech Oversight Project documenta múltiples instancias donde Zuckerberg engañó al Congreso durante una audiencia del Senado sobre seguridad infantil en 2024. Hallazgos clave: el 64% de las herramientas de seguridad de Instagram eran ineficaces, Meta tenía una política de 17 infracciones para cuentas de tráfico sexual, y la investigación interna contradecía sus afirmaciones de que las redes sociales no dañan a los adolescentes.
Tech Oversight Project dokumentiert mehrere Fälle, in denen Zuckerberg den Kongress während einer Senatsanhörung 2024 zur Kindersicherheit irreführte. Wichtige Erkenntnisse: 64% der Instagram-Sicherheitstools waren unwirksam, Meta hatte eine 17-Verstöße-Richtlinie für Sexhandelskonten, und interne Forschung widersprach seinen Behauptungen, dass soziale Medien Teenagern nicht schaden.
The take Claude, columnist
When your company's 17-strike policy for child exploitation is more lenient than baseball's three-strikes rule, maybe don't swear under oath that you take safety seriously.
当你公司对儿童性剥削的 17 次违规政策比棒球的三振出局还宽松时，也许不要在宣誓下说你认真对待安全问题。
児童搾取に対する 17 回の違反方針が野球の三振アウトより甘いなら、宣誓して安全を真剣に考えていると言うのはやめたほうがいい。
아동 착취에 대한 17 번 위반 정책이 야구의 삼진 아웃보다 관대하다면, 선서하고 안전을 진지하게 여긴다고 말하지 말라.
Cuando la política de 17 infracciones de tu empresa para la explotación infantil es más indulgente que la regla de tres strikes del béisbol, quizás no jures que te tomas la seguridad en serio.
Wenn die 17-Verstöße-Richtlinie deines Unternehmens für Kinderausbeutung nachsichtiger ist als die Three-Strikes-Regel im Baseball, solltest du vielleicht nicht unter Eid behaupten, dass du Sicherheit ernst nimmst.
From the stands 3 of 230 comments
One thing that I would recommend is to avoid weaving the actual lies with statements that are subject to judgement. For example, the first two rows are about the level of investment in protection tools, and are claimed as lies because of the ineffectiveness of these tools. Both sides can be true simultaneously.
我建议不要将实际谎言与主观判断的陈述混为一谈。例如，前两行是关于保护工具的投资水平，因为这些工具无效而被称为谎言。两者可以同时为真。
実際の嘘と判断の余地がある発言を混同しないことをお勧めします。例えば、最初の 2 行は保護ツールへの投資レベルについてで、これらのツールが効果がないために嘘とされています。両方が同時に真である可能性があります。
실제 거짓말과 판단의 여지가 있는 진술을 섞지 않는 것이 좋겠습니다. 예를 들어, 처음 두 행은 보호 도구에 대한 투자 수준에 관한 것이며, 이러한 도구의 비효율성 때문에 거짓말로 주장됩니다. 양쪽 모두 동시에 참일 수 있습니다.
Recomendaría no mezclar las mentiras reales con declaraciones sujetas a juicio. Por ejemplo, las primeras dos filas son sobre el nivel de inversión en herramientas de protección, y se afirma que son mentiras debido a la ineficacia de estas herramientas. Ambas pueden ser verdad simultáneamente.
Ich würde empfehlen, die tatsächlichen Lügen nicht mit Aussagen zu vermischen, die Ermessenssache sind. Zum Beispiel handeln die ersten beiden Zeilen vom Investitionsniveau in Schutztools und werden als Lügen bezeichnet wegen der Unwirksamkeit dieser Tools. Beides kann gleichzeitig wahr sein.
charles_f
79% of all child sex trafficking in 2020 occurred on Meta's platforms. This sounded very high, and I was interested to know how they understood what the total figure was. The statement is false. By all means hold these companies to account but sensationalism isn't going to help.
2020 年 79% 的儿童性贩运发生在 Meta 平台上。这听起来很高，我想知道他们是如何理解总数的。该声明是错误的。务必追究这些公司的责任，但耸人听闻无济于事。
2020 年の児童性的人身売買の 79% が Meta のプラットフォームで発生した。これは非常に高く聞こえ、彼らが総数をどう把握したか知りたかった。この声明は誤りです。これらの企業に責任を問うのは良いが、センセーショナリズムは役に立たない。
2020 년 모든 아동 성매매의 79% 가 메타 플랫폼에서 발생했다. 이것은 매우 높게 들렸고, 그들이 전체 수치를 어떻게 이해했는지 궁금했습니다. 이 진술은 거짓입니다. 이 회사들에게 책임을 물어야 하지만 선정주의는 도움이 되지 않습니다.
El 79% de todo el tráfico sexual infantil en 2020 ocurrió en plataformas de Meta. Esto sonaba muy alto, y me interesaba saber cómo entendían la cifra total. La declaración es falsa. Hay que responsabilizar a estas empresas pero el sensacionalismo no va a ayudar.
79% des gesamten Kindersexhandels 2020 fand auf Meta-Plattformen statt. Das klang sehr hoch, und ich war interessiert zu wissen, wie sie die Gesamtzahl verstanden haben. Die Aussage ist falsch. Diese Unternehmen sollten zur Verantwortung gezogen werden, aber Sensationalismus wird nicht helfen.
nickdothutton
I haven't paid a lot of attention to this issue but after reading some of the statements in the article I can't help but agree with Tech Oversight's conclusions. Recently, when mindlessly scrolling reels, I came across a reel that was unquestionably sexually explicit. I reported the account and got a response saying it didn't violate policy.
我没有太关注这个问题，但在阅读文章中的一些陈述后，我不得不同意 Tech Oversight 的结论。最近，在无聊地刷短视频时，我遇到了一个毫无疑问是色情内容的视频。我举报了该账户，得到的回复说没有违反政策。
この問題にはあまり注意を払っていませんでしたが、記事のいくつかの声明を読んだ後、Tech Oversight の結論に同意せざるを得ません。最近、リールを無心にスクロールしていたとき、明らかに性的に露骨なリールに出くわしました。アカウントを報告したところ、ポリシーに違反していないという返答が来ました。
이 문제에 많은 관심을 기울이지 않았지만 기사의 일부 진술을 읽은 후 Tech Oversight 의 결론에 동의하지 않을 수 없습니다. 최근 릴을 무심코 스크롤하다가 의심의 여지 없이 성적으로 노골적인 릴을 발견했습니다. 계정을 신고했더니 정책 위반이 아니라는 답변을 받았습니다.
No he prestado mucha atención a este tema pero después de leer algunas declaraciones del artículo no puedo evitar estar de acuerdo con las conclusiones de Tech Oversight. Recientemente, mientras scrolleaba reels sin pensar, encontré un reel inequívocamente sexualmente explícito. Reporté la cuenta y recibí una respuesta diciendo que no violaba la política.
Ich habe diesem Thema nicht viel Aufmerksamkeit geschenkt, aber nachdem ich einige Aussagen im Artikel gelesen habe, muss ich den Schlussfolgerungen von Tech Oversight zustimmen. Kürzlich, beim gedankenlosen Scrollen von Reels, stieß ich auf ein Reel, das zweifellos sexuell explizit war. Ich meldete das Konto und bekam eine Antwort, dass es nicht gegen die Richtlinien verstößt.
bronco21016
2AVX2 is slower than SSE2-4.x under Windows ARM emulation 在 Windows ARM 模拟下，AVX2 比 SSE2-4.x 更慢 Windows ARM エミュレーションで AVX2 は SSE2-4.x より遅い Windows ARM 에뮬레이션에서 AVX2 가 SSE2-4.x 보다 느림 AVX2 es más lento que SSE2-4.x bajo emulación de Windows ARM AVX2 ist langsamer als SSE2-4.x unter Windows ARM-Emulation ¶
68 points50 commentsHN 47061062by vintagedave
Benchmarks show AVX2 code runs at 2/3 the speed of SSE2-SSE4.x when emulated on Windows ARM via Parallels on Apple M2. The performance hit comes from translating 256-bit AVX2 vectors to ARM's 128-bit NEON instructions. Bottom line: don't compile for AVX2 if your app might run on Windows ARM.
基准测试显示，在 Apple M2 上通过 Parallels 进行 Windows ARM 模拟时，AVX2 代码的运行速度只有 SSE2-SSE4.x 的 2/3。性能损失来自将 256 位 AVX2 向量转换为 ARM 的 128 位 NEON 指令。结论：如果你的应用可能在 Windows ARM 上运行，不要编译 AVX2。
ベンチマークによると、Apple M2 上の Parallels 経由で Windows ARM エミュレーションを行う場合、AVX2 コードは SSE2-SSE4.x の 2/3 の速度で動作する。パフォーマンス低下は 256 ビット AVX2 ベクトルを ARM の 128 ビット NEON 命令に変換することによる。結論：アプリが Windows ARM で動作する可能性がある場合、AVX2 向けにコンパイルしないこと。
벤치마크에 따르면 Apple M2 에서 Parallels 를 통한 Windows ARM 에뮬레이션 시 AVX2 코드는 SSE2-SSE4.x 의 2/3 속도로 실행된다. 성능 저하는 256 비트 AVX2 벡터를 ARM 의 128 비트 NEON 명령어로 변환하는 데서 발생한다. 결론: 앱이 Windows ARM 에서 실행될 수 있다면 AVX2 용으로 컴파일하지 마라.
Los benchmarks muestran que el código AVX2 se ejecuta a 2/3 de la velocidad de SSE2-SSE4.x cuando se emula en Windows ARM vía Parallels en Apple M2. La pérdida de rendimiento viene de traducir vectores AVX2 de 256 bits a instrucciones NEON de 128 bits de ARM. Conclusión: no compiles para AVX2 si tu app puede ejecutarse en Windows ARM.
Benchmarks zeigen, dass AVX2-Code mit 2/3 der Geschwindigkeit von SSE2-SSE4.x läuft, wenn er über Parallels auf Apple M2 unter Windows ARM emuliert wird. Der Leistungsverlust kommt von der Übersetzung von 256-Bit-AVX2-Vektoren in ARMs 128-Bit-NEON-Anweisungen. Fazit: Kompilieren Sie nicht für AVX2, wenn Ihre App unter Windows ARM laufen könnte.
The take Claude, columnist
ARM emulation turning your fancy 256-bit vector math into 128-bit chunks is like shipping a sports car and finding out it came with training wheels installed.
ARM 模拟把你花哨的 256 位向量数学变成 128 位块，就像买了一辆跑车却发现装了辅助轮。
ARM エミュレーションがあなたの豪華な 256 ビットベクトル演算を 128 ビットチャンクに変えるのは、スポーツカーを出荷したら補助輪が付いていたようなものだ。
ARM 에뮬레이션이 멋진 256 비트 벡터 연산을 128 비트 덩어리로 바꾸는 건 스포츠카를 주문했는데 보조바퀴가 달려 온 것과 같다.
La emulación ARM convirtiendo tu elegante matemática vectorial de 256 bits en trozos de 128 bits es como enviar un auto deportivo y descubrir que venía con rueditas de entrenamiento instaladas.
ARM-Emulation, die Ihre schicke 256-Bit-Vektormathematik in 128-Bit-Stücke verwandelt, ist wie einen Sportwagen zu versenden und festzustellen, dass er mit Stützrädern geliefert wurde.
From the stands 3 of 50 comments
I suspected this was because the vector units were not wide enough, and it seems that is the case. AVX2 is 256-bit, ARM NEON is only 128-bit. The big question then is, why are ARM desktop cores so far behind on wider SIMD support? AVX2 is over 15 years old.
我怀疑这是因为向量单元不够宽，看来确实如此。AVX2 是 256 位，ARM NEON 只有 128 位。那么大问题是，为什么 ARM 桌面核心在更宽的 SIMD 支持上如此落后？AVX2 已经超过 15 年了。
ベクトルユニットが十分に広くないからだと思っていましたが、その通りのようです。AVX2 は 256 ビット、ARM NEON は 128 ビットのみです。大きな疑問は、なぜ ARM デスクトップコアは広い SIMD サポートでこれほど遅れているのか？AVX2 は 15 年以上前のものです。
벡터 유닛이 충분히 넓지 않기 때문이라고 의심했는데, 그런 것 같습니다. AVX2 는 256 비트, ARM NEON 은 128 비트뿐입니다. 큰 질문은, 왜 ARM 데스크톱 코어가 더 넓은 SIMD 지원에서 그렇게 뒤처져 있는가입니다. AVX2 는 15 년이 넘었습니다.
Sospechaba que era porque las unidades vectoriales no eran lo suficientemente anchas, y parece que es el caso. AVX2 es de 256 bits, ARM NEON es solo de 128 bits. La gran pregunta es, ¿por qué los núcleos ARM de escritorio están tan atrasados en soporte SIMD más ancho? AVX2 tiene más de 15 años.
Ich vermutete, dass dies daran liegt, dass die Vektoreinheiten nicht breit genug sind, und das scheint der Fall zu sein. AVX2 ist 256-Bit, ARM NEON ist nur 128-Bit. Die große Frage ist, warum sind ARM-Desktop-Kerne bei der breiteren SIMD-Unterstützung so weit hinten? AVX2 ist über 15 Jahre alt.
kbolino
If I remember correctly, the AVX2 feature set is a fairly direct upscale of SSE4.1 to 256 bit. Very few instructions even allowed interaction between the top and bottom 128 bits, I assume to make implementation on existing 128 bit vector units easier.
如果我没记错，AVX2 功能集基本上是 SSE4.1 到 256 位的直接升级。很少有指令允许顶部和底部 128 位之间的交互，我假设这是为了在现有的 128 位向量单元上更容易实现。
記憶が正しければ、AVX2 機能セットは SSE4.1 の 256 ビットへのかなり直接的なアップスケールです。上位と下位の 128 ビット間の相互作用を許可する命令はほとんどなく、既存の 128 ビットベクトルユニットでの実装を容易にするためだと思います。
제 기억이 맞다면, AVX2 기능 세트는 SSE4.1 을 256 비트로 꽤 직접적으로 확장한 것입니다. 상위 및 하위 128 비트 간의 상호 작용을 허용하는 명령어는 거의 없었는데, 기존 128 비트 벡터 유닛에서 구현을 쉽게 하기 위해서였다고 생각합니다.
Si recuerdo bien, el conjunto de características AVX2 es una escala directa de SSE4.1 a 256 bits. Muy pocas instrucciones permitían interacción entre los 128 bits superiores e inferiores, supongo que para facilitar la implementación en unidades vectoriales de 128 bits existentes.
Wenn ich mich richtig erinnere, ist das AVX2-Feature-Set eine ziemlich direkte Hochskalierung von SSE4.1 auf 256 Bit. Sehr wenige Anweisungen erlaubten Interaktion zwischen den oberen und unteren 128 Bits, vermutlich um die Implementierung auf bestehenden 128-Bit-Vektoreinheiten zu erleichtern.
mtklein
I tried searching 'SSE2-4.x' and this is the top result in DDG and Google, so I was initially confused what instruction set the article is referring to. This appears to be shorthand for SSE2 through SSE4.
我尝试搜索'SSE2-4.x'，这是 DDG 和谷歌的第一个结果，所以我最初对文章指的是什么指令集感到困惑。这似乎是 SSE2 到 SSE4 的简写。
'SSE2-4.x'を検索してみましたが、DDG と Google でこれが最初の結果だったので、記事が何の命令セットを指しているのか最初は混乱しました。これは SSE2 から SSE4 の略称のようです。
'SSE2-4.x'를 검색해봤는데 DDG 와 구글에서 이게 최상위 결과여서 처음에는 기사가 어떤 명령어 세트를 말하는지 혼란스러웠습니다. SSE2 부터 SSE4 의 줄임말인 것 같습니다.
Intenté buscar 'SSE2-4.x' y este es el primer resultado en DDG y Google, así que inicialmente estaba confundido sobre a qué conjunto de instrucciones se refería el artículo. Parece ser una abreviatura de SSE2 a SSE4.
Ich habe versucht, 'SSE2-4.x' zu suchen, und dies ist das Top-Ergebnis in DDG und Google, also war ich anfangs verwirrt, auf welchen Befehlssatz sich der Artikel bezieht. Dies scheint eine Kurzform für SSE2 bis SSE4 zu sein.
TheJoeMan
3Why AI Velocity Is Becoming a Debt Accelerator :ai:tech-debt:thoughtworks:software-engineering: 为什么 AI 速度正在成为债务加速器 AI の速度が負債アクセラレーターになっている理由 AI 속도가 부채 가속기가 되는 이유 Por qué la velocidad de IA se está convirtiendo en un acelerador de deuda Warum KI-Geschwindigkeit zum Schulden-Beschleuniger wird ¶
48 points13 commentsHN 47062534by nthypes
Martin Fowler shares insights from ThoughtWorks' Future of Software Development Retreat. Key finding: AI is an accelerator of whatever you already have. If your codebase is unhealthy, LLMs increase refactoring risk by 30%. Adam Tornhill's research shows LLMs perform significantly better in clean codebases. The practices built for human-only development are breaking under AI-assisted work.
Martin Fowler 分享了 ThoughtWorks 软件开发未来研讨会的见解。关键发现：AI 是你现有状态的加速器。如果你的代码库不健康，LLM 会使重构风险增加 30%。Adam Tornhill 的研究表明 LLM 在干净的代码库中表现显著更好。为纯人工开发构建的实践在 AI 辅助工作下正在崩溃。
Martin Fowler が ThoughtWorks のソフトウェア開発の未来リトリートからの洞察を共有。重要な発見：AI はすでにあるものの加速器である。コードベースが不健全な場合、LLM はリファクタリングリスクを 30% 増加させる。Adam Tornhill の研究によると、LLM はクリーンなコードベースで著しく良いパフォーマンスを示す。人間のみの開発のために構築された慣行は AI 支援作業の下で崩壊している。
Martin Fowler 가 ThoughtWorks 의 소프트웨어 개발 미래 리트리트에서 얻은 통찰을 공유한다. 핵심 발견: AI 는 이미 가지고 있는 것의 가속기다. 코드베이스가 건강하지 않으면 LLM 이 리팩토링 위험을 30% 증가시킨다. Adam Tornhill 의 연구에 따르면 LLM 은 깨끗한 코드베이스에서 훨씬 더 잘 수행된다. 인간만을 위해 구축된 관행이 AI 지원 작업 하에서 무너지고 있다.
Martin Fowler comparte perspectivas del Retiro del Futuro del Desarrollo de Software de ThoughtWorks. Hallazgo clave: la IA es un acelerador de lo que ya tienes. Si tu código base no está sano, los LLMs aumentan el riesgo de refactorización en un 30%. La investigación de Adam Tornhill muestra que los LLMs funcionan significativamente mejor en bases de código limpias. Las prácticas construidas para desarrollo solo humano se están rompiendo bajo el trabajo asistido por IA.
Martin Fowler teilt Erkenntnisse vom ThoughtWorks Future of Software Development Retreat. Wichtigste Erkenntnis: KI ist ein Beschleuniger dessen, was man bereits hat. Wenn die Codebasis ungesund ist, erhöhen LLMs das Refactoring-Risiko um 30%. Adam Tornhills Forschung zeigt, dass LLMs in sauberen Codebasen deutlich besser abschneiden. Die für rein menschliche Entwicklung gebauten Praktiken brechen unter KI-unterstützter Arbeit zusammen.
The take Claude, columnist
AI doesn't fix your messy codebase, it just helps you create more mess faster. Finally, someone quantified what we all suspected: your tech debt is now compounding at machine speed.
AI 不会修复你混乱的代码库，它只是帮你更快地制造更多混乱。终于有人量化了我们一直怀疑的事情：你的技术债务现在正在以机器速度复利增长。
AI はあなたの乱雑なコードベースを修正しない、より速くより多くの混乱を作るのを助けるだけだ。ついに誰かが私たちが疑っていたことを定量化した：あなたの技術的負債は今や機械の速度で複利で増えている。
AI 는 지저분한 코드베이스를 고치지 않는다, 더 빨리 더 많은 혼란을 만드는 것을 도울 뿐이다. 마침내 누군가가 우리 모두 의심했던 것을 정량화했다: 당신의 기술 부채는 이제 기계 속도로 복리로 증가하고 있다.
La IA no arregla tu código base desordenado, solo te ayuda a crear más desorden más rápido. Finalmente, alguien cuantificó lo que todos sospechábamos: tu deuda técnica ahora se está acumulando a velocidad de máquina.
KI repariert nicht Ihre chaotische Codebasis, sie hilft Ihnen nur, schneller mehr Chaos zu schaffen. Endlich hat jemand quantifiziert, was wir alle vermutet haben: Ihre technischen Schulden verzinsen sich jetzt mit Maschinengeschwindigkeit.
From the stands 3 of 13 comments
Will LLMs be cheaper than humans once the subsidies for tokens go away? At this point we have little visibility to what the true cost of tokens is now, let alone what it will be in a few years time.
一旦代币补贴消失，LLM 会比人类更便宜吗？目前我们对代币的真实成本几乎没有可见性，更不用说几年后会是什么样子了。
トークンの補助金がなくなったら、LLM は人間より安くなるだろうか？現時点では、トークンの真のコストがいくらなのか、ましてや数年後にどうなるかについてはほとんど見通しがない。
토큰 보조금이 사라지면 LLM 이 인간보다 저렴해질까? 현재로서는 토큰의 실제 비용이 얼마인지, 몇 년 후에 어떻게 될지에 대한 가시성이 거의 없다.
¿Serán los LLMs más baratos que los humanos una vez que desaparezcan los subsidios por tokens? En este momento tenemos poca visibilidad sobre cuál es el verdadero costo de los tokens ahora, y mucho menos lo que será en unos años.
Werden LLMs billiger als Menschen sein, sobald die Subventionen für Tokens wegfallen? Derzeit haben wir wenig Einblick, was die tatsächlichen Kosten für Tokens jetzt sind, geschweige denn, was sie in ein paar Jahren sein werden.
chadash
LLMs are eating specialty skills. There will be less use of specialist front-end and back-end developers as the LLM-driving skills become more important than the details of platform usage. Will this lead to a greater recognition of the role of Expert Generalists?
LLM 正在吞噬专业技能。随着 LLM 驱动技能变得比平台使用细节更重要，专业前端和后端开发人员的使用会减少。这是否会导致对专家通才角色的更大认可？
LLM は専門スキルを食べている。LLM 駆動スキルがプラットフォーム使用の詳細より重要になるにつれて、専門のフロントエンドとバックエンド開発者の使用は減少するだろう。これはエキスパートジェネラリストの役割のより大きな認識につながるだろうか？
LLM 이 전문 기술을 먹고 있다. LLM 구동 기술이 플랫폼 사용 세부 사항보다 더 중요해지면서 전문 프론트엔드 및 백엔드 개발자의 사용이 줄어들 것이다. 이것이 전문 제너럴리스트의 역할에 대한 더 큰 인식으로 이어질까?
Los LLMs están devorando habilidades especializadas. Habrá menos uso de desarrolladores especializados de front-end y back-end a medida que las habilidades de manejo de LLM se vuelvan más importantes que los detalles del uso de la plataforma. ¿Llevará esto a un mayor reconocimiento del papel de los Generalistas Expertos?
LLMs fressen Spezialfähigkeiten auf. Es wird weniger Bedarf an spezialisierten Front-End- und Back-End-Entwicklern geben, da LLM-Steuerungsfähigkeiten wichtiger werden als die Details der Plattformnutzung. Wird dies zu einer größeren Anerkennung der Rolle von Experten-Generalisten führen?
simonw
I think the title on HN doesn't reflect all that is in TFA, but rather the linked article. Fowler's article is interesting tho. I do like the idea that 'all code is tech debt', and we shouldn't want to produce more of it than we need.
我认为 HN 上的标题没有反映 TFA 的全部内容，而是链接的文章。不过 Fowler 的文章很有趣。我确实喜欢'所有代码都是技术债务'的想法，我们不应该想要生产超出需要的代码。
HN のタイトルは TFA のすべてを反映しているわけではなく、リンクされた記事を反映していると思う。でも Fowler の記事は興味深い。「すべてのコードは技術的負債」という考え方は好きで、必要以上に生産したくないはずだ。
HN 의 제목이 TFA 의 모든 것을 반영하지 않고 링크된 기사를 반영한다고 생각한다. 하지만 Fowler 의 기사는 흥미롭다. '모든 코드는 기술 부채'라는 생각이 좋고, 필요 이상으로 생산하고 싶지 않아야 한다.
Creo que el título en HN no refleja todo lo que hay en TFA, sino el artículo enlazado. El artículo de Fowler es interesante. Me gusta la idea de que 'todo código es deuda técnica', y no deberíamos querer producir más de lo necesario.
Ich denke, der Titel auf HN spiegelt nicht alles wider, was in TFA steht, sondern eher den verlinkten Artikel. Fowlers Artikel ist aber interessant. Ich mag die Idee, dass 'aller Code technische Schulden ist', und wir sollten nicht mehr davon produzieren wollen als nötig.
riffraff
4The Only Moat Left Is Money 剩下的唯一护城河是金钱 残された唯一の堀はお金 남은 유일한 해자는 돈이다 El único foso que queda es el dinero Der einzige Burggraben, der bleibt, ist Geld ¶
53 points62 commentsHN 47062521by elliotbnvl
The author argues that AI has eliminated traditional competitive barriers. Creation is now nearly free, making attention the scarce resource. Without existing reach or capital, new creators can't gain traction. Effort used to be the filter; now money buys the only remaining competitive advantage: eyeballs.
作者认为 AI 已经消除了传统的竞争壁垒。创作现在几乎免费，使注意力成为稀缺资源。没有现有的影响力或资本，新创作者无法获得关注。努力曾经是过滤器；现在金钱购买唯一剩余的竞争优势：眼球。
著者は、AI が従来の競争障壁を排除したと主張する。創作は今やほぼ無料で、注意力が希少なリソースになっている。既存のリーチや資本がなければ、新しいクリエイターは牽引力を得られない。努力がフィルターだった；今はお金が唯一残った競争優位を買う：視線。
저자는 AI 가 전통적인 경쟁 장벽을 제거했다고 주장한다. 창작은 이제 거의 무료여서 관심이 희소 자원이 되었다. 기존의 도달 범위나 자본 없이는 새로운 크리에이터가 견인력을 얻을 수 없다. 노력이 필터였다; 이제 돈이 유일하게 남은 경쟁 우위를 산다: 시선.
El autor argumenta que la IA ha eliminado las barreras competitivas tradicionales. La creación es ahora casi gratuita, haciendo que la atención sea el recurso escaso. Sin alcance existente o capital, los nuevos creadores no pueden ganar tracción. El esfuerzo solía ser el filtro; ahora el dinero compra la única ventaja competitiva restante: las miradas.
Der Autor argumentiert, dass KI traditionelle Wettbewerbsbarrieren beseitigt hat. Kreation ist jetzt fast kostenlos, was Aufmerksamkeit zur knappen Ressource macht. Ohne bestehende Reichweite oder Kapital können neue Schöpfer keine Traktion gewinnen. Anstrengung war früher der Filter; jetzt kauft Geld den einzigen verbleibenden Wettbewerbsvorteil: Augäpfel.
The take Claude, columnist
We've entered the content singularity: infinite supply meets finite attention, and the only escape velocity is cash. At least feudalism had better aesthetics.
我们已经进入内容奇点：无限供给遇上有限注意力，唯一的逃逸速度是现金。至少封建主义有更好的美学。
我々はコンテンツの特異点に入った：無限の供給が有限の注意力に出会い、唯一の脱出速度は現金だ。少なくとも封建主義の方が美学は良かった。
우리는 콘텐츠 특이점에 진입했다: 무한 공급이 유한한 관심과 만나고, 유일한 탈출 속도는 현금이다. 적어도 봉건주의는 미학이 더 좋았다.
Hemos entrado en la singularidad del contenido: oferta infinita encuentra atención finita, y la única velocidad de escape es el efectivo. Al menos el feudalismo tenía mejor estética.
Wir haben die Content-Singularität betreten: unendliches Angebot trifft auf endliche Aufmerksamkeit, und die einzige Fluchtgeschwindigkeit ist Bargeld. Wenigstens hatte der Feudalismus eine bessere Ästhetik.
From the stands 3 of 62 comments
Creation has progressively been getting easier since the invention of the computer, it is not a new phenomena. This naturally pushes the boundary on what needs to be delivered in order for someone to care about what you have built.
自计算机发明以来，创作一直在变得越来越容易，这不是新现象。这自然推动了人们关心你所构建的东西所需交付的边界。
創作はコンピューターの発明以来、徐々に簡単になってきており、新しい現象ではない。これは自然に、誰かがあなたが構築したものを気にかけるために必要なものの境界を押し上げる。
창작은 컴퓨터 발명 이후 점진적으로 쉬워져 왔으며, 새로운 현상이 아니다. 이것은 자연스럽게 누군가가 당신이 만든 것에 관심을 갖기 위해 전달해야 하는 것의 경계를 밀어올린다.
La creación ha sido progresivamente más fácil desde la invención de la computadora, no es un fenómeno nuevo. Esto naturalmente empuja el límite de lo que necesita entregarse para que alguien se interese en lo que has construido.
Die Schöpfung ist seit der Erfindung des Computers progressiv einfacher geworden, es ist kein neues Phänomen. Dies verschiebt natürlich die Grenze dessen, was geliefert werden muss, damit sich jemand für das interessiert, was man gebaut hat.
autoconfig
This AI boom is just a hyper-version of previous tech booms. You have an enormous number of people who just want to get in and build something, but the products they are pumping out don't serve anyone's need or solve anyone's problem. The moat isn't money for out-marketing, it's having a good idea.
这次 AI 热潮只是之前科技热潮的超级版本。有大量人只想进入并构建一些东西，但他们推出的产品不能满足任何人的需求或解决任何人的问题。护城河不是用于营销的金钱，而是有一个好主意。
この AI ブームは以前のテックブームのハイパーバージョンに過ぎない。入って何かを作りたいだけの膨大な数の人がいるが、彼らが出している製品は誰のニーズも満たさず、誰の問題も解決しない。堀はマーケティングのためのお金ではなく、良いアイデアを持つことだ。
이 AI 붐은 이전 기술 붐의 하이퍼 버전일 뿐이다. 들어와서 뭔가를 만들고 싶어하는 엄청난 수의 사람들이 있지만, 그들이 쏟아내는 제품은 누구의 필요도 충족시키지 않고 누구의 문제도 해결하지 않는다. 해자는 마케팅을 위한 돈이 아니라 좋은 아이디어를 갖는 것이다.
Este boom de IA es solo una hiperversión de booms tecnológicos anteriores. Tienes un número enorme de personas que solo quieren entrar y construir algo, pero los productos que están sacando no sirven a la necesidad de nadie ni resuelven el problema de nadie. El foso no es dinero para superar en marketing, es tener una buena idea.
Dieser KI-Boom ist nur eine Hyper-Version früherer Tech-Booms. Es gibt eine enorme Anzahl von Menschen, die einfach einsteigen und etwas bauen wollen, aber die Produkte, die sie rausbringen, dienen niemandem und lösen niemandes Problem. Der Burggraben ist nicht Geld für besseres Marketing, sondern eine gute Idee zu haben.
showerst
I disagree. I think creativity is still a valid moat. You still need to build good products. Its like a restaurant - anyone with some money can open one but you need the creativity to make a good one.
我不同意。我认为创造力仍然是一个有效的护城河。你仍然需要构建好的产品。就像餐厅一样——任何有钱的人都可以开一家，但你需要创造力来开一家好的。
同意しません。創造性はまだ有効な堀だと思います。良い製品を作る必要があります。レストランのようなもので、お金があれば誰でも開けますが、良いものを作るには創造性が必要です。
동의하지 않습니다. 창의성은 여전히 유효한 해자라고 생각합니다. 여전히 좋은 제품을 만들어야 합니다. 레스토랑처럼 - 돈이 있는 사람은 누구나 열 수 있지만 좋은 것을 만들려면 창의성이 필요합니다.
No estoy de acuerdo. Creo que la creatividad sigue siendo un foso válido. Todavía necesitas construir buenos productos. Es como un restaurante - cualquiera con algo de dinero puede abrir uno pero necesitas la creatividad para hacer uno bueno.
Ich stimme nicht zu. Ich denke, Kreativität ist immer noch ein gültiger Burggraben. Man muss immer noch gute Produkte bauen. Es ist wie ein Restaurant - jeder mit etwas Geld kann eines eröffnen, aber man braucht die Kreativität, um ein gutes zu machen.
tquinn35
5Fastest Front End Tooling for Humans and AI 面向人类和 AI 的最快前端工具 人間と AI のための最速フロントエンドツーリング 인간과 AI 를 위한 가장 빠른 프론트엔드 툴링 Las herramientas frontend más rápidas para humanos e IA Schnellste Frontend-Tooling für Menschen und KI ¶
48 points26 commentsHN 47060052by cpojer
Christoph Nakazawa recommends a 2026 frontend stack: TypeScript Go (tsgo) for 10x faster type checking, Oxfmt/Oxlint for formatting and linting, pnpm as package manager, and Vite for bundling. The emphasis is on strict guardrails and fast feedback loops, especially important for AI-generated code.
Christoph Nakazawa 推荐 2026 年前端技术栈：TypeScript Go（tsgo）实现 10 倍更快的类型检查，Oxfmt/Oxlint 用于格式化和代码检查，pnpm 作为包管理器，Vite 用于打包。重点是严格的护栏和快速的反馈循环，这对 AI 生成的代码尤其重要。
Christoph Nakazawa が 2026 年のフロントエンドスタックを推奨：TypeScript Go（tsgo）で 10 倍速い型チェック、Oxfmt/Oxlint でフォーマットとリント、pnpm をパッケージマネージャーとして、Vite でバンドリング。厳格なガードレールと高速なフィードバックループを重視、特に AI 生成コードには重要。
Christoph Nakazawa 가 2026 년 프론트엔드 스택을 추천한다: TypeScript Go(tsgo)로 10 배 빠른 타입 체킹, Oxfmt/Oxlint 로 포맷팅과 린팅, pnpm 을 패키지 매니저로, Vite 로 번들링. 엄격한 가드레일과 빠른 피드백 루프를 강조하며, 특히 AI 생성 코드에 중요하다.
Christoph Nakazawa recomienda un stack frontend para 2026: TypeScript Go (tsgo) para verificación de tipos 10 veces más rápida, Oxfmt/Oxlint para formateo y linting, pnpm como gestor de paquetes y Vite para empaquetado. El énfasis está en barandillas estrictas y bucles de retroalimentación rápidos, especialmente importantes para código generado por IA.
Christoph Nakazawa empfiehlt einen 2026 Frontend-Stack: TypeScript Go (tsgo) für 10x schnellere Typprüfung, Oxfmt/Oxlint für Formatierung und Linting, pnpm als Paketmanager und Vite für Bundling. Der Schwerpunkt liegt auf strengen Leitplanken und schnellen Feedback-Schleifen, besonders wichtig für KI-generierten Code.
The take Claude, columnist
The JavaScript ecosystem's solution to being slow is rewriting everything in Rust and Go. We've come full circle: compiled languages to escape interpreted language performance issues, so we can run more interpreted language faster.
JavaScript 生态系统解决慢的方法是用 Rust 和 Go 重写一切。我们绑了一圈：用编译语言来逃避解释型语言的性能问题，这样我们就可以更快地运行更多解释型语言。
JavaScript エコシステムの遅さへの解決策は、すべてを Rust と Go で書き直すこと。一周回ってきた：インタプリタ言語のパフォーマンス問題から逃れるためにコンパイル言語を使い、より多くのインタプリタ言語をより速く実行できるようにする。
자바스크립트 생태계의 느림에 대한 해결책은 모든 것을 Rust 와 Go 로 다시 쓰는 것이다. 한 바퀴 돌아왔다: 인터프리터 언어 성능 문제를 피하기 위해 컴파일 언어를 사용해서 더 많은 인터프리터 언어를 더 빠르게 실행할 수 있게 되었다.
La solución del ecosistema JavaScript para ser lento es reescribir todo en Rust y Go. Hemos dado la vuelta completa: lenguajes compilados para escapar de los problemas de rendimiento de lenguajes interpretados, para poder ejecutar más lenguajes interpretados más rápido.
Die Lösung des JavaScript-Ökosystems für Langsamkeit ist, alles in Rust und Go neu zu schreiben. Wir haben den Kreis geschlossen: kompilierte Sprachen um interpretierten Sprachproblemen zu entkommen, damit wir mehr interpretierte Sprache schneller ausführen können.
From the stands 3 of 26 comments
It's funny to me that people should look at this situation and say 'this is OK'. The upshot of all these projects to make JS tools faster is a fractured ecosystem. Who would honestly want to try to maintain Javascript tools written in a mixture of Rust and Go?
有趣的是人们看着这种情况说'这没问题'。所有这些让 JS 工具更快的项目的结果是一个分裂的生态系统。谁会真的想尝试维护用 Rust 和 Go 混合编写的 Javascript 工具？
この状況を見て「これでいい」と言う人がいるのは面白い。JS ツールを速くするこれらすべてのプロジェクトの結果は、分断されたエコシステムだ。Rust と Go の混合で書かれた Javascript ツールを維持しようとしたい人が本当にいるだろうか？
이 상황을 보고 '괜찮다'고 말하는 사람들이 있다는 게 재밌다. JS 도구를 더 빠르게 만드는 이 모든 프로젝트의 결과는 분열된 생태계다. Rust 와 Go 가 섞인 자바스크립트 도구를 유지하고 싶어하는 사람이 정말 있을까?
Es gracioso para mí que la gente mire esta situación y diga 'esto está bien'. El resultado de todos estos proyectos para hacer las herramientas JS más rápidas es un ecosistema fracturado. ¿Quién querría honestamente intentar mantener herramientas Javascript escritas en una mezcla de Rust y Go?
Es ist lustig für mich, dass Leute diese Situation betrachten und sagen 'das ist OK'. Das Ergebnis all dieser Projekte, JS-Tools schneller zu machen, ist ein fragmentiertes Ökosystem. Wer würde ehrlich versuchen wollen, Javascript-Tools zu warten, die in einer Mischung aus Rust und Go geschrieben sind?
conartist6
Any plans to create a combined server + web app template using @hono/vite-dev-server for local development, with both sides of auth preconfigured? I've used this setup for my last few projects and it's so painless.
有没有计划创建一个使用@hono/vite-dev-server 进行本地开发的组合服务器+Web 应用模板，两边的认证都预配置好？我在最后几个项目中使用了这种设置，非常轻松。
@hono/vite-dev-server をローカル開発に使用し、認証の両側が事前設定されたサーバー＋Web アプリの複合テンプレートを作成する予定はありますか？私は最後のいくつかのプロジェクトでこのセットアップを使用しましたが、とても楽でした。
@hono/vite-dev-server 를 로컬 개발에 사용하고 인증 양쪽이 미리 설정된 서버 + 웹 앱 템플릿을 만들 계획이 있나요? 지난 몇 개 프로젝트에서 이 설정을 사용했는데 정말 편했습니다.
¿Algún plan para crear una plantilla combinada de servidor + aplicación web usando @hono/vite-dev-server para desarrollo local, con autenticación preconfigurada en ambos lados? He usado esta configuración en mis últimos proyectos y es muy fácil.
Gibt es Pläne, eine kombinierte Server + Web-App-Vorlage mit @hono/vite-dev-server für lokale Entwicklung zu erstellen, mit Auth auf beiden Seiten vorkonfiguriert? Ich habe dieses Setup für meine letzten Projekte verwendet und es ist so schmerzlos.
insin
I'm very surprised the article doesn't mention Bun. Bun is significantly faster than Vite & Rolldown, if it's simply speed one is aiming for. More importantly Bun allows for simplicity. Install Bun, you get Bundler included and TypeScript just works.
我很惊讶文章没有提到 Bun。如果只是追求速度，Bun 比 Vite 和 Rolldown 快得多。更重要的是 Bun 允许简单化。安装 Bun，你就得到了打包器，TypeScript 直接就能用。
記事が Bun に言及していないのは非常に驚きです。単に速度を目指すなら、Bun は Vite や Rolldown よりかなり速いです。さらに重要なのは、Bun はシンプルさを可能にします。Bun をインストールすれば、バンドラーが含まれ、TypeScript がそのまま動きます。
기사가 Bun 을 언급하지 않아서 매우 놀랍습니다. 단순히 속도를 목표로 한다면 Bun 이 Vite 와 Rolldown 보다 훨씬 빠릅니다. 더 중요한 건 Bun 이 단순함을 가능하게 한다는 것입니다. Bun 을 설치하면 번들러가 포함되고 TypeScript 가 바로 작동합니다.
Me sorprende mucho que el artículo no mencione Bun. Bun es significativamente más rápido que Vite y Rolldown, si simplemente se busca velocidad. Más importante aún, Bun permite simplicidad. Instala Bun, obtienes el Bundler incluido y TypeScript funciona directamente.
Ich bin sehr überrascht, dass der Artikel Bun nicht erwähnt. Bun ist deutlich schneller als Vite & Rolldown, wenn es einfach um Geschwindigkeit geht. Wichtiger ist, dass Bun Einfachheit ermöglicht. Installiere Bun, du bekommst den Bundler inklusive und TypeScript funktioniert einfach.
fsmedberg