Recent posts
戦没者追悼記念日。本日、私たちの民主主義を守るために一切を捧げた人々を敬います。民主主義は保証されたものではなく、常に手入れが必要な貴重な遺産です。🇺🇸
原文を表示 (en)
Memorial Day. Today we honor those who gave everything to defend our democracy. Democracy isn't guaranteed; it's a precious inheritance that requires our constant care. 🇺🇸
グリーンカード申請者に米国外からの申請を求める新しいホワイトハウス政策は、合法的な移民への恣意的な攻撃だ。家族に悪影響を与え、医者や教師、科学者が減り、AI分野での米国の競争力を損なう。
原文を表示 (en)
The new White House policy requiring green card applicants to apply from outside the US is a capricious attack on legal immigration. It will hurt families, leave us with fewer doctors, teachers and scientists, and hurt American competitiveness in AI.
Harvard University が学部クラスで与える A 評価の数を約 20% に制限することを投票で決めた。俺はこれに賛成していない。これは教育がどうあるべきかという俺の信念に深く反している。高い基準を維持する必要があるが、同時に学生全体の 100% の成功を支援するために全力を尽くすべきであり、一部だけではない。 Harvard の経営陣は成績インフレーションに対抗するため、学生の大多数の異議を押し切ってこの措置を取った。成績インフレーションは実在している：多くの大学がますます多くの学生に A と B の評価を与えており、これにより GPA が学生のスキルのシグナルとしての有用性が低下している。同時に、学生が成功することも望んでいる。問題の中心は教育機関の役割である。私たちの目標は以下のどちらであるべきか： - 学生が成功するのを支援する？ - 学生を評価する？ 両者に価値がある。しかし教育の分野で働く際の俺のフォーカスはほぼ全て学生が成功するのを支援することだ。 はっきり言って、多くの人は学びたい、力を持ちたい、新しいことができるスキルを構築したいと思っている！これが DeepLearningAI で俺たちが焦点を当てていることだ。この哲学は、俺のオンラインコース（Coursera での初期の Stanford オンラインコースまで遡る）が採点された課題に対して無限の再試行を許可している理由でもある。 誰かが成功するまで何かをやり直すことを認め、さらに励ましさえする信念を持っている。これは彼らが最初に正しく理解できなかったという事実について判断を下すのではなく、という考えに対置される。さらに、宿題を主に人々が練習し学ぶのを支援するために設計したいのであり、スキルレベルを判断するためではない。だから俺は「Practice Problems」と「Practice Labs」を作成したいのだ——それについて考えると、練習を得るのを助け、知っていることを強化する質問。これは主にスキルを判断するために設計された「Assessment Problems」とは対照的だ。 しかし Harvard の措置が GPA をより意味のあるものにし、採用候補者を特定するのに雇用主を支援しないだろうか？Harvard およびその他の機関から多数の人々を採用してきたので、GPA は重要なシグナルではないと自信を持って言える。スクリーニングと面接プロセスがあり、誰が本当にスキルがあるかを判断するはるかに正確な方法を提供している。申請者の GPA スコアの広がりを広げる必要はない，本当に優秀な人が誰かを判断するために！ 明確にするために、評価にも価値がある。標準化されたテストは非常に嫌われているが、SAT、ACT、GRE、TOEFL などの高品質のテストは領域内の能力の客観的な測度を提供している。ほとんどの人が学びたい、成功したいと思っていることがわかった。また、厳密な評価を望む人もいる（例えば、学校入学申請を申請するために），しかしこれはより小さなニーズであり、教育製品を構築する際のフォーカスではない。 Harvard はしばしば「エリート」教育機関として説明される。エリートになるには 2 つの方法がある：1 つのオプションは入学を制限することと，そして認められた学生の中でさえ，20% の人が上手くいくことを上限にすること。俺はむしろ別の道を進みたい：高い基準を設定し，エリートで最先端のスキルを教えるが，全員が成功するのを支援するために容赦なく努力すること。この方法でエリート性は人々を除外することではなく，できるだけ多くの人々が優秀になるのを支援することによって定義される。 [Original text: The Batch newsletter]
原文を表示 (en)
Harvard University just voted to limit the number of A grades given in undergraduate classes to about 20% of the class. I’m not in favor of this. It deeply runs counter to how I believe education should be. We should hold a high bar, but also work mightily to support the success of 100% of learners, rather than a fraction. Harvard’s administration took this step — over the objections of a large fraction of the student body — to counter grade inflation. Grade inflation is real: Many universities have been awarding A and B grades to ever larger fractions of students, and this has caused grade point averages (GPAs) to become less useful as signals of student skill. At the same time, we want students to succeed. The heart of the question is the role of educational institutions. Should our goal be: - To help students succeed? - To judge students? Both of these have value. But my focus when working in education is almost entirely helping students succeed. To me, it is clear that many people want to learn, to be empowered, to build skills that let them do new things! This is what we focus on at DeepLearningAI. This philosophy is also why my online courses (going back to my early online Stanford courses on Coursera) permitted an unlimited number of retries for graded assignments. I believe in letting — and even encouraging — someone to redo something until they succeed. This is as opposed to standing in judgement of the fact they didn’t get it right the first time. Further, I want homework assignments to be designed primarily to help people practice and learn, rather than to judge their skill level. This is why I prefer to create “Practice Problems” and “Practice Labs” — questions that, when you think through them, help you to gain practice and reinforce what you know. As opposed to “Assessment Problems” designed primarily to judge skill. But won’t Harvard’s move make GPAs more meaningful and help prospective employers identify strong candidates? Having hired a large number of people from Harvard and other institutions, I can say confidently that GPA is not an important signal. We have screening and interviewing processes that give far more accurate ways to figure out if someone is truly skilled. I do not need a wider spread in applicant GPA scores to figure out who's really good! To be clear, there is also value in assessment. Even though standardized testing is much hated, high-quality tests like the SAT, ACT, GRE, TOEFL, etc. provide objective measures of ability in a domain. I find that most people want to learn and succeed. There are also people who want rigorous assessment (for example, to apply for school admissions), but this is a lesser need, and is not my focus when building educational products. Harvard is often described as an “elite” educational institution. There are two ways to be elite: One option involves limiting enrollments, and then even among admitted students, cap the number of people that do well at 20%. I would rather pursue a different path: Set a high bar and teach elite, cutting-edge skills, but strive relentlessly to help everyone succeed. This way, eliteness is defined not by excluding people but by helping as many people as possible to be excellent. [Original text: The Batch newsletter]
新コース：画像と動画を生成する AI エージェントを構築する -- 未開拓のフロンティア。パフォーマンスの鍵は、エージェント自身の出力を評価して反復改善することだ。このショートコースは @googlecloudtech と共に構築され、Katie Nguyen と Wafae Bakkali が教える。 3つの評価技術を学んでエージェントに組み合わせる：出力がプロンプトに合致するか確認するための画像テキスト類似度スコアリング、ブランド一貫性などカスタム基準に対してスコアリングする LLM ジャッジ、「被写体がフレーム内にあるか？」「カメラの動きが一致しているか？」といった検証可能なイエス/ノー質問にプロンプトを分解する構造化ルーブリック。 学べるスキル： - 画像と動画のプロンプトエンジニアリング - ブランドガイドラインを UI モックアップに変える画像エージェントを構築 - 複数シーンの説明を計画して参照フレームをシンクロナイズされたオーディオでアニメーション化する動画エージェントを構築 参加して画像と動画を作成するエージェントを構築しよう！ https://t.co/bjuSjIxcIG
原文を表示 (en)
New course: Build AI agents that generate images and videos -- an under-explored frontier. A key to performance is having the agent evaluate its own output, and iterate to improve quality. This short course is built together with @googlecloudtech and taught by Katie Nguyen and Wafae Bakkali. You'll learn three evaluation techniques and combine them in an agent: image-text similarity scoring to check the output matches the prompt, an LLM judge that scores against custom criteria like brand consistency, and structured rubrics that break a prompt into verifiable yes/no questions like "is the subject in the frame?" and "does the camera motion match?" Skills you'll gain: - Learn image and video prompt engineering - Build an image agent that turns brand guidelines into UI mockups - Build a video agent that plans multi-scene explainers and animates reference frames with synchronized audio Join and build agents that create images and video! https://t.co/bjuSjIxcIG
新コース: Transformers in Practice。トランスフォーマーベースのLLMがどう動くかの実践的な理解が得られるから、その振る舞いを推論したり、推論の遅さみたいな問題を診断したり、デプロイについてもっと賢い決断ができるようになります。このコースは@AMDとのパートナーシップで作られていて、@realSharonZhouが教えます。 トランスフォーマーがどうやってトークン一つずつテキスト生成するのか、モデルが次の単語を予測する時にどうやって前の単語のどれが重要かを決めるのか、量子化みたいなテクニックがどうやってGPUでの推論を高速化するのかが見えます。これはビデオだけのコースじゃなくて、インタラクティブビジュアライゼーションが随所にあるから、これらの概念を実際に触ってみて、ちゃんと理解が定着する直感が得られます。 スキルセット: - なぜLLMが幻覚を見るのか理解して、RAGとchain-of-thoughtがどう生成を形作るのかを知る - モデルの内部を見て、attentionとレイヤーがどう組み合わさって次のトークンを予測するのかを理解する - 推論のボトルネックを診断して、GPUでトランスフォーマーを高速化するテクニックを習得する 参加して、LLMの内部で本当は何が起きてるのか理解しよう: https://t.co/oS6ekeHsIw
原文を表示 (en)
New course: Transformers in Practice. You'll get a practical view of how transformer-based LLMs work, so you can reason about their behavior, diagnose problems like slow inference, and make smarter decisions about deployment. This course is built in partnership with @AMD and taught by @realSharonZhou. You'll see how transformers generate text one token at a time, how the model decides which earlier words matter most when predicting the next one, and how techniques like quantization speed up inference on GPUs. This is not a video-only course; interactive visualizations throughout let you play with these concepts and build intuition that sticks. Skills you'll gain: - Understand why LLMs hallucinate, and RAG and chain-of-thought shape what they generate - Look inside the model to see how attention and layers combine to predict the next token - Diagnose inference bottlenecks and learn the techniques that speed up transformers on GPUs Join and understand what's really happening inside your LLMs: https://t.co/oS6ekeHsIw
AI ジョブポカリプスは起こらない。 AI が大量失業をもたらすという話は不要な恐怖を助長している。AI は他のテクノロジーと同じように仕事に影響するが、大規模失業の誇張された話をするのは無責任で有害だ。やめよう。 過去の投稿で AI ジョブポカリプスについて懐疑的な意見を述べてきた。今メインストリームメディアがこのナラティブに異議を唱えてくれるのは嬉しい。下の画像は最近のヘッドラインをまとめたもの。 ソフトウェアエンジニアリングは AI ツールの影響を最も受けた業界で、コーディングエージェントが急速に進化してる。でも、ソフトウェアエンジニアの採用は依然として堅調。だから AI が仕事を奪う例もあるけど、トレンドは強く、正味の雇用創出が雇用破壊よりはるかに大きいことを示してる。これは以前のテクノロジー波と同じだ。そして AI で素晴らしい進展があってもなお、米国の失業率は健全な4.3%に留まってる。 なぜ AI ジョブポカリプスのナラティブがこんなに人気なのか？第一に、フロンティア AI ラボはこの技術をもっと強力に見せるストーリーを語る強いインセンティブを持ってる。極端な例では、AI が「支配する」とか人類滅亡を引き起こすみたいなSFシナリオを促進する。テクノロジーが多くの従業員を置き換えることができるなら、その技術は確実に非常に価値があるはず！ また、多くの SaaS ソフトウェア企業はユーザー1人あたり年100～1000ドルの料金を取ってる。ただ AI 企業が年10万ドル稼いでる従業員を置き換えるか、生産性を50%上げることができるなら、年1万ドルでも妥当に見える。AI 企業は通常の SaaS 価格ではなく従業員の給与にアンカーすることで、もっと多くの料金を設定できる。 さらに、企業は AI が原因のようにレイオフについて話す強いインセンティブを持ってる。結局のところ、AI を使ってスタッフを減らしながら生産性を大幅に向上させてるという話は、賢く見える。パンデミック中に低い金利と大規模な政府財政刺激のおかげで資本が豊富だったから採用しすぎたと認めるより、ずっといいメッセージだ。 明確にしておくと、AI が多くの人の仕事を変えさせてることは認識してる。これは難しい。ストレスがある。(そして、楽しいと思う人もいる。)影響を受けた全員に共感する。同時に、これは雇用市場の崩壊を予測するのとは全然違う。 社会は現実にはほとんど基づかず、社会全体の意思決定に悪影響をもたらすストーリーを何年間も自分たちに言い聞かせることができる。例えば、原発の安全性への懸念は原発への過少投資に繋がった。1960年代の「人口爆弾」への懸念は、国々に人口を減らすための厳しい政策を実施させた。そして食事の脂肪についての懸念は、政府が数十年間にわたって不健康な高糖質食を推進させた。 メインストリームメディアが今 AI ジョブポカリプスに明らかに懐疑的になったので、これらのストーリーは(AI が人類滅亡を引き起こすという懸念と同じように)その力を失い始めると思う。 AI ジョブポカリプスの予測とは反対に、逆のことを予測する: AI ジョブアパルーザがあるだろう！AI はもっと多くの素晴らしい AI エンジニアリング職を生むだろうし、全体的な雇用市場の未来についても楽観的だ。AI エンジニアがすることは従来のソフトウェアエンジニアリングとは異なり、これらの多くの仕事は開発者の伝統的な大規模雇用者以外のビジネスにあるだろう。非 AI 職では、AI のせいで必要な skills も変わる。それは今がより多くの人を AI に習熟させるように励まし、未来の異なるが豊富な仕事の準備ができてることを確認するいい時期だ！ [The Batch ニュースレターの原文。]
原文を表示 (en)
There will be no AI jobpocalypse. The story that AI will lead to massive unemployment is stoking unnecessary fear. AI — like any other technology — does affect jobs, but telling overblown stories of large-scale unemployment is irresponsible and damaging. Let’s put a stop to it. I’ve expressed skepticism about the jobpocalypse in previous posts. I’m glad to see that the popular press is now pushing back on this narrative. The image below features some recent headlines. Software engineering is the sector most affected by AI tools, as coding agents race ahead. Yet hiring of software engineers remains strong! So while there are examples of AI taking away jobs, the trends strongly suggest the net job creation is vastly greater than the job destruction — just like earlier waves of technology. Further, despite all the exciting progress in AI, the U.S. unemployment rate remains a healthy 4.3%. Why is the AI jobpocalypse narrative so popular? For one thing, frontier AI labs have a strong incentive to tell stories that make AI technology sound more powerful. At their most extreme, they promote science-fiction scenarios of AI “taking over” and causing human extinction. If a technology can replace many employees, surely that technology must be very valuable! Also, a lot of SaaS software companies charge around $100-$1000 per user/year. But if an AI company can replace an employee who makes $100,000 — or make them 50% more productive — then charging even $10,000 starts to look reasonable. By anchoring not to typical SaaS prices but to salaries of employees, AI companies can charge a lot more. Additionally, businesses have a strong incentive to talk about layoffs as if they were caused by AI. After all, talking about how they’re using AI to be far more productive with fewer staff makes them look smart. This is a better message than admitting they overhired during the pandemic when capital was abundant due to low interest rates and a massive government financial stimulus. To be clear, I recognize that AI is causing a lot of people’s work to change. This is hard. This is stressful. (And to some, it can be fun.) I empathize with everyone affected. At the same time, this is very different from predicting a collapse of the job market. Societies are capable of telling themselves stories for years that have little basis in reality and lead to poor society-wide decision making. For example, fears over nuclear plant safety led to under-investment in nuclear power. Fears of the “population bomb” in the 1960s led countries to implement harsh policies to reduce their populations. And worries about dietary fat led governments to promote unhealthy high-sugar diets for decades. Now that mainstream media is openly skeptical about the jobpocalypse, I hope these stories will start to lose their teeth (much like fears of AI-driven human extinction have). Contrary to the predictions of an AI jobpocalypse, I predict the opposite: There will be an AI jobapalooza! AI will lead to a lot more good AI engineering jobs, and I’m also optimistic about the future of the overall job market. What AI engineers do will be different from traditional software engineering, and many of these jobs will be in businesses other than traditional large employers of developers. In non-AI roles, too, the skills needed will change because of AI. That makes this a good time to encourage more people to become proficient in AI, and make sure they’re ready for the different but plentiful jobs of the future! [Original text in The Batch newsletter.]
@coursera と @udemy がいっしょになって一社として学習者に奉仕してくれるのは嬉しい。 Coursera も Udemy も、質の高い教育へのアクセスが人生を変えるという信念で創立された。長年にわたり、両社はこの目標を進めてきて、世界中の個人、組織、コミュニティのために機会を作出してきた。 その役割は今、AI が仕事の性質を変え、継続学習の必要性を高めているなかで、さらに重要になってる。人々が職務関連スキルを構築するのを支援することは、より良い世界を作る方法にとって不可欠だろう。 両社の強みを組み合わせることで、このニーズをより良く奉仕できる。より幅広い学習コンテンツ、信頼できる講師や教育者、魅力的な学習体験をもたらす。これにより、スケールで学習をより個人化され、より応用的に、よりアクセス可能にするための新しい機会を生まれさせる。 私は統合企業の会長として奉仕することにワクワクしており、Greg Hart とリーダーシップチームと一緒に働いている。両組織に強い基礎があり、チームが一緒に構築して世界中でアクセス機会を拡大する様子を楽しみにしている。 詳しくは: https://t.co/QpCwBmqWTJ
原文を表示 (en)
I'm delighted that @coursera and @udemy have come together as one company to serve learners. Both Coursera and Udemy were founded with the belief that access to high-quality education changes lives. Over the years, both companies have advanced this goal, creating opportunities for individuals, organizations, and communities around the world. That role is even more important now, as AI is changing the nature of work and increasing the need for continuous learning. Helping people build job-relevant skills will be critical to how we create a better world. By combining the strengths of both companies, we can better serve this need. We bring together a broader range of learning content, trusted instructors and educators, and engaging learning experiences. This creates new opportunities to make learning more personalized, more applied, and more accessible at scale. I’m excited to serve as Chairman of the combined company, working alongside Greg Hart and the leadership team. There is a strong foundation in both organizations, and I look forward to what the teams will build together to expand access opportunity globally. Learn more: https://t.co/QpCwBmqWTJ
新コース:チャートや形式、ホワイトボードなどカスタムUIだけでなくプレーンテキストで応答するエージェントを構築。オンデマンド生成でチャットに直接表示。このショートコースは@CopilotKitとの提携で、CopilotKitの共同創業者@ataaimが教えます。 3つのアプローチを学べます:エージェントがチャートやフォームなど構築したカスタムコンポーネントから選択。行やカード、テキストみたいなビルディングブロックセットから新レイアウトを組成。或いはホワイトボードやカレンダーみたいな既存サードパーティアプリを会話内に組み込む。 習得スキル: - チャートやフォームなどカスタムコンポーネントをオンデマンド描画するエージェント構築 - エージェントとユーザーが共有データでチャットウィンドウ超えて協力するアプリ構築 - 地図、カレンダー、ホワイトボードなどサードパーティアプリをインターフェース内に 参加して何か見て行動するエージェントを構築しましょう! https://t.co/lvMy0YdF3z
原文を表示 (en)
New course: Build agents that respond to users with not only plaintext, but custom UIs like charts, forms, and whiteboards, generated on demand and displayed right in the chat. This short course is built in partnership with @CopilotKit and taught by @ataiiam, co-founder of CopilotKit. You'll learn three approaches: Your agent can pick from custom components you build, like charts and forms. It can compose new layouts from a set of building blocks you provide, like rows, cards, and text. Or it can incorporate existing third-party apps, like a whiteboard or a calendar, right inside the conversation. Skills you’ll gain: - Build agents that render custom components like charts and forms on demand - Build an app where the agent and user collaborate on shared data, beyond just the chat window - Place third-party apps like maps, calendars, and whiteboards right in your interface Join and build agents that give users something to see and act on! https://t.co/lvMy0YdF3z
コーディングエージェントは異なるタイプのソフトウェアワークを異なる度合いで加速させています。チームを構築する際に、これらの区別を理解することで、現実的な期待値を持つことができます。最も加速度が高い関数から低い関数へのリスティングは、私の順序では：フロントエンド開発、バックエンド、インフラストラクチャ、そして研究です。 フロントエンド開発 — 例えば、eコマースサイト向けに製品説明を提供するウェブページを構築する場合 — コーディングエージェントが TypeScript や JavaScript などの人気のあるフロントエンド言語と React や Angular などのフレームワークに精通しているため、大幅に高速化されています。さらに、ウェブブラウザを操作することで構築したものを調べることにより、コーディングエージェントは独自の実装で反復処理を行うのに非常に優れています。確かに、LLM は今日ビジュアルデザインではまだ弱いですが、デザイン（または洗練されたデザインが重要でない場合）があれば、実装は高速です！ バックエンド開発 — 例えば、製品データをリクエストするクエリに応答するための API を構築する場合 — はより困難です。現代的なモデルが微妙なバグやセキュリティ欠陥につながる可能性のあるコーナーケースについて考えるよう人間開発者がステアリングを行うには、より多くの作業が必要です。さらに、バックエンドのバグは、データベースが時々不正な結果を返すなど、非直感的なダウンストリーム効果につながる可能性があり、典型的なフロントエンドバグよりもデバッグが難しい場合があります。最後に、データベース移行はコーディングエージェントでより簡単にすることができますが、それでも難しく、データ損失を防ぐために慎重に処理する必要があります。バックエンド開発はコーディングエージェントではるかに高速ですが、加速度は低く、熟練した開発者はコーディングエージェントを使用する経験の浅い開発者よりもはるかに優れたバックエンドを設計および実装します。 インフラストラクチャ。エージェントは、eコマースサイトを 10K アクティブユーザーにスケーリングしながら 99.99% の信頼性を維持するなどのタスクではさらに効果的です。LLM の知識はインフラストラクチャと優れたエンジニアが行う必要がある複雑なトレードオフに関して相対的に限定されているため、重要なインフラ決定のために彼らを信じることはめったにありません。優れたインフラストラクチャを構築するには、多くの場合、テストと実験の期間が必要であり、コーディングエージェントはそれに役立つことができますが、最終的にはそれは高速 AI コーディングが多く役立たない重要なボトルネックです。最後に、インフラストラクチャのバグを見つけるには — 例えば、微妙なネットワーク誤設定 — 非常に困難で、深いエンジニアリング専門知識が必要です。したがって、コーディングエージェントはクリティカルインフラストラクチャをバックエンド開発よりもはるかに少なく加速させることが判明しました。 研究。コーディングエージェントは研究ワークをさらに少なく加速させます。研究には新しいアイデアについて考え、仮説を定式化し、実験を実行し、それらを解釈して仮説を潜在的に修正し、結論に達するまで反復することが含まれます。コーディングエージェントは、研究コードを書く速度を加速させることができます。（また、コーディングエージェントを使用して実験をオーケストレーションし、実験を追跡します。これにより、単一の研究者がより多くの実験を管理しやすくなります。）しかし、研究にはコーディング以外の多くの作業があり、今日のエージェントは研究を周辺的にのみ支援します。 ソフトウェアワークをフロントエンド、バックエンド、インフラ、研究に分類することは極端な簡略化ですが、異なるタスクがどの程度加速したかについての単純なメンタルモデルを持つことは、ソフトウェアチームの構成方法に役立っています。たとえば、現在フロントエンドチームに 1 年前よりもドラマティックに高速に製品を実装することを求めていますが、研究チームの期待値はほぼ同じくらい変わっていません。 コーディングエージェントを使用してソフトウェアチームを構成し、速度を達成する方法に魅了されており、今後の投稿で私の発見を共有し続けます。 [元のテキスト: https://t.co/rnnVWqebVe ]
原文を表示 (en)
Coding agents are accelerating different types of software work to different degrees. When we architect teams, understanding these distinctions helps us to have realistic expectations. Listing functions from most accelerated to least, my order is: frontend development, backend, infrastructure, and research. Frontend development — say, building a web page to serve descriptions of products for an ecommerce site — is dramatically sped up because coding agents are fluent in popular frontend languages like TypeScript and JavaScript and frameworks like React and Angular. Additionally, by examining what they have built by operating a web browser, coding agents are now very good at closing the loop and iterating on their own implementations. Granted, LLMs today are still weak at visual design, but given a design (or if a polished design isn’t important), the implementation is fast! Backend development — say, building APIs to respond to queries requesting product data — is harder. It takes more work by human developers to steer modern models to think through corner cases that might lead to subtle bugs or security flaws. Further, a backend bug can lead to non-intuitive downstream effects like a corrupted database that occasionally returns incorrect results, which can be harder to debug than a typical frontend bug. Finally, although database migrations can be easier with coding agents, they’re still hard and need to be handled carefully to prevent data loss. While backend development is much faster with coding agents, they accelerate it less, and skilled developers still design and implement far better backends than inexperienced ones who use coding agents. Infrastructure. Agents are even less effective in tasks like scaling an ecommerce site to 10K active uses while maintaining 99.99% reliability. LLMs' knowledge is still relatively limited with respect to infrastructure and the complex tradeoffs good engineers must make, so I rarely trust them for critical infra decisions. Building good infrastructure often requires a period of testing and experimentation, and coding agents can help with that, but ultimately that’s a significant bottleneck where fast AI coding does not help much. Lastly, finding infrastructure bugs — say, a subtle network misconfiguration — can be incredibly difficult and requires deep engineering expertise. Thus, I’ve found that coding agents accelerate critical infrastructure even less than backend development. Research. Coding agents accelerate research work even less. Research involves thinking through new ideas, formulating hypotheses, running experiments, interpreting them to potentially modify the hypotheses, and iterating until we reach conclusions. Coding agents can speed up the pace at which we can write research code. (I also use coding agents to help me orchestrate and keep track of experiments, which makes it easier for a single researcher to manage more experiments.) But there is a lot of work in research other than coding, and today’s agents help with research only marginally. Categorizing software work into frontend, backend, infra, and research is an extreme simplification, but having a simple mental model for how much different tasks have sped up has been useful for how I organize software teams. For example, I now ask front-end teams to implement products dramatically faster than a year ago, but my expectations for research teams have not shifted nearly as much. I am fascinated by how to organize software teams to use coding agents to achieve speed, and will keep sharing my findings in future posts. [Original text: https://t.co/rnnVWqebVe ]
AIネイティブなソフトウェアエンジニアリングチームは従来のチームとは大きく異なります。明らかな違いはAIネイティブチームがコーディングエージェントを使って製品をはるかに速く構築することですが、これはチームの運営方法に多くの変化をもたらします。例えば優秀なエンジニアの中には単なるコード記述だけでなく、より広い役割を果たす者もいます。彼らは一部プロダクトマネージャー、デザイナー、時にはマーケッターです。さらに、同じオフィスで働く小さなチームは対面で連絡が取れるので、信じられないほど素早く動くことができます。 今は速く構築できるので、何を構築するかを決めるのに時間をかけるべき。このプロジェクト管理のボトルネックに対応するため、一部チームはエンジニア:プロダクトマネージャー(PM)の比率を8:1から1:1まで下げようとしています。でもさらに良くできます。PMが何を構築するかを決めて、エンジニアが構築する場合、彼らの間のコミュニケーションがボトルネックになります。だから最速のチームはエンジニアがプロダクト業務も理解できる傾向があります(あるいはPMがエンジニアリングも理解している)。エンジニアがユーザーを理解し、何を構築するかを決断でき、直接構築できれば、実行速度は驚異的です。 エンジニアが役割をプロダクト決定まで拡大させ、PMがソフトウェア構築に拡大させるのに成功している例を見ました。テック業界にはエンジニアがPMより多いですが、どちらも有望な道です。エンジニアならプロダクト管理スキルを学ぶと役立ちますし、PMなら構築を学んでください! プロダクト管理のボトルネックを超えて、デザイン、マーケティング、法務遵守等多くのボトルネックを見ます。コーディングを10倍100倍高速化すれば、他は相対的に遅くなります。例えば私のチームが素早く素晴らしい機能を構築しすぎて、マーケティングがどう伝えるか困ってた。つまりマーケティングボトルネック。またチームが1日で構築できてもLEGAL部門が1週間かかるレビューなら法務遵守ボトルネック。こうしてエージェントコーディングはソフトウェアエンジニアリングワークフロー変えるだけでなく周囲のチーム全体を変えています。 より少ないAI対応チームが成し遂げられると、ジェネラリストが活躍します。従来の企業は多くの専門分野からピープルを集めます―エンジニアリング、プロダクト管理、デザイン、マーケティング、法務など―プロジェクト実行と価値創造のため。これは専門家の大きなチームが一緒に働く結果です。でも2人のチームが5つの専門分野が必要な業務をやり遂げるなら、いくつかは1つの専門分野外の役割を果たす必要があります。小さなチームでは個人が深い専門性を持つことがあります。例えば1人が優秀なエンジニア、もう1人が優秀なPM。でも彼らはプロジェクトを前進させるのに必要な他の主要機能も理解し、必要に応じて他の種の課題について思考できます。当然、AIツール習熟度は大助けで、異なる役割に関連する問題を考え抜くのに役立ちます。 2人チームでも速く動くにはコミュニケーションボトルネックを最小化すべき。だから同じ場所で働くチームを価値あるものと思っています。リモートチームも良いですが、全員が室内にいて問題を解くのにすぐコミュニケーション取れるのが最速。 この投稿は2~10人のAIネイティブチーム向けですが、すべてが小チームでできるわけではありません。大規模チーム調整については後で。 役割変化が多くの人にとって難しいのは理解します。同時に、関連スキル学ぶ意思のある個人と小チームが以前より遥かに多くを成し遂げられるようになってるのに励まされています。これは学習と構築の黄金期です! [原文: https://t.co/1pUxNC5UXk ]
原文を表示 (en)
AI-native software engineering teams operate very differently than traditional teams. The obvious difference is that AI-native teams use coding agents to build products much faster, but this leads to many other changes in how we operate. For example, some great engineers now play broader roles than just writing code. They are partly product managers, designers, sometimes marketers. Further, small teams who work in the same office, where they can communicate face-to-face, can move incredibly quickly. Because we can now build fast, a greater fraction of time must be spent deciding what to build. To deal with this project-management bottleneck, some teams are pushing engineer:product manager (PM) some teams are pushing engineer:product manager (PM) ratios downward from, say, 8:1 to as low as 1:1. But we can do even better: If we have one PM who decides what to build and one engineer who builds it, the communication between them becomes a bottleneck. This is why the fastest-moving teams I see tend to have engineers who know how to do some product work (and, optionally, some PMs who know how to do some engineering work). When an engineer understands users and can make decisions on what to build and build it directly, they can execute incredibly quickly. I’ve seen engineers successfully expand their roles to including making product decisions, and PMs expand their roles to building software. The tech industry has more engineers than PMs, but both are promising paths. If you are an engineer, you’ll find it useful to learn some product management skills, and if you’re a PM, please learn to build! Looking beyond the product-management bottleneck, I also see bottlenecks in design, marketing, legal compliance, and much more. When we speed up coding 10x or 100x, everything else becomes slow in comparison. For example, some of my teams have built great features so quickly that the marketing organization was left scrambling to figure out how to communicate them to users — a marketing bottleneck. Or when a team can build software in a day that the legal department needs a week to review, that’s a legal compliance bottleneck. In this way, agentic coding isn’t just changing the workflow of software engineering, it’s also changing all the teams around it. When smaller, AI-enabled teams can get more done, generalists excel. Traditional companies need to pull together people from many specialties — engineering, product management, design, marketing, legal, etc. — to execute projects and create value. This has resulted in large teams of specialists who work together. But if a team of 2 persons is to get work done that require 5 different specialities, then some of those individuals must play roles outside a single speciality. In some small teams, individuals do have deep specializations. For example, one might be a great engineer and another a great PM. But they also understand the other key functions needed to move a project forward, and can jump into thinking through other kinds of problems as needed. Of course, proficiency with AI tools is a big help, since it helps us to think through problems that involve different roles. Even in a two-person team, to move fast, communication bottlenecks also must be minimized. This is why I value teams that work in the same location. Remote teams can perform well too, but the highest speed is achieved by having everyone in the room, able to communicate instantaneously to solve problems. This post focuses on AI-native teams with around 2-10 persons, but not everything can be done by a small team. I'll address the coordination of larger teams in the future. I realize these shifts to job roles are tough to navigate for many people. At the same time, I am encouraged that individuals and small teams who are willing to learn the relevant skills are now able to get far more done than was possible before. This is the golden age of learning and building! [Original text: https://t.co/1pUxNC5UXk ]
New course: Spec-Driven Development with Coding Agents, built in partnership with @jetbrains, and taught by @paulweveritt. Vibe coding is fast, but often produces code that doesn't match what you asked for. This short course teaches you spec-driven development: write a detailed spec defining what to build, and work with your coding agent to implement it. Many of the best developers already build this way. A spec lets you control large code changes with a few words, preserve context across agent sessions, and stay in control as your project grows in complexity. Skills you'll gain: - Write a detailed specification to define your mission, tech stack, and roadmap, giving your agent the context it needs from the start - Plan, implement, and validate features in iterative loops using a spec as your agent's guide - Apply the same repeatable workflow to both new and legacy codebases - Package your workflow into a portable agent skill that works across agents and IDEs Join and write specs that keep your coding agent on track! https://t.co/hI4GwuvhtN
I'm excited about voice as a UI layer for existing visual applications — where speech and screen update together. This goes well beyond voice-only use cases like call center automation. The barrier has been a hard technical tradeoff: low-latency voice models lack reliability, while agentic pipelines (speech-to-text → LLM → text-to-speech) are intelligent but too slow for conversation. Ashwyn Sharma and team at Vocal Bridge (an AI Fund portfolio company) address this with a dual-agent architecture: a foreground agent for real-time conversation, a background agent for reasoning, guardrails, and tool calls. I used Vocal Bridge to add voice to a math-quiz app I'd built for my daughter; this took less than an hour with Claude Code. She speaks her answers, the app responds verbally and updates the questions and animations on screen. Only a tiny fraction of developers have ever built a voice app. If you'd like to try building one, check out Vocal Bridge for free: https://t.co/nGrFznAMLh
As AI agents accelerate coding, what is the future of software engineering? Some trends are clear, such as the Product Management Bottleneck, referring to the idea that we are more constrained by deciding what to build rather than the actual building. But many implications, like AI’s impact on the job market, how software teams will be organized, and more, are still being sorted out. The theme of our AI Developer Conference on April 28-29 in San Francisco is The Future of Software Engineering. I look forward to speaking about this topic there, hearing from other speakers on this theme, and chatting with attendees about it. We’re shaping the future, and I hope you will join me there! It is currently trendy in some technology and policy circles to forecast massive job losses due to AI. Even if they have not yet materialized, these losses certainly must be just over the horizon! I have a contrarian view that the AI jobpocalypse — the notion that AI will lead to massive unemployment, perhaps even rioting in the streets — won’t be nearly as bad as dire forecasts by pundits, especially pundits who are trying to paint a picture of how powerful their AI technology is. Among professions, AI is accelerating software engineering most, given the rise of coding agents. According to a new report by Citadel Research, software engineering job postings are rising rapidly. So if software engineering is a harbinger of the impact AI will have on other professions, this expansion of software engineering jobs is encouraging. Yes, fresh college graduates are having a hard time finding jobs. And yes, there have been layoffs that CEOs have attributed to AI, even if a large fraction of this was “AI washing,” where businesses choose to attribute layoffs to AI, even though AI has not changed their internal operations much yet. And yes, there is a subset of job roles, such as call center operator, that are more heavily impacted. Many people are feeling significant job insecurity, and I feel for everyone struggling with employment, whether or not the cause is AI-related. And many other factors, such as over-hiring during the pandemic and high interest rates, have contributed to the slowdown in the labor market, and the notion that AI is leading to unemployment is oversimplified. In software engineering, I see a lot of exciting work ahead to adapt our workflows. It is already clear that: (i) As AI makes coding easier, a lot more people will be doing it. (ii) Writing code by hand and even reading (generated) code is not that important, because we can ask an LLM about the code and operate at a higher level than the raw syntax (although how high we can or should go is rapidly changing). (iii) There will be a lot more custom applications, because now it’s economical to write software for smaller and smaller audiences. (iv) Deciding what to build, more than the actual building, is becoming a bottleneck. (v) The cost of paying down technical debt is decreasing (since AI can refactor for you). At the same time, there are also a lot of open questions for our profession, such as: - In the future, what will be the key skills of a senior software engineer? And for junior levels, what should be the new Computer Science curriculum? - If everyone can build features, what skills, strategies, or resources create competitive advantage for individuals and for businesses? - What are the new building blocks (libraries, SDKs, etc.) of software? How do we organize coding agents to create software? - What should a software team look like? For example, how many engineers, product managers, designers, and so on. What tooling do we need to manage their workflow? - How do AI agents change the workflow of machine learning engineers and data scientists? For example, how can we use agents to accelerate exploring data, identifying hypotheses, and testing them? I’m excited to explore these and other questions about the future of software engineering at AI Dev. I expect this to be an exciting event. Please join us! [Original text: The Batch newsletter.] https://t.co/i4bQevDG4i
New course: Efficient Inference with SGLang: Text and Image Generation, built in partnership with LMSys @lmsysorg and RadixArk @radixark, and taught by Richard Chen @richardczl, a Member of Technical Staff at RadixArk. Running LLMs in production is expensive, and much of that cost comes from redundant computation. This short course teaches you to eliminate that waste using SGLang, an open-source inference framework that caches computation already done and reuses it across future requests. When ten users share the same system prompt, SGLang processes it once, not ten times. The speedups compound quickly, especially when there's a lot of shared context across requests. Skills you'll gain: - Implement a KV cache from scratch to eliminate redundant computation within a single request - Scale caching across users and requests with RadixAttention, so shared context is only processed once - Accelerate image generation with diffusion models using SGLang's caching and multi-GPU parallelism Join and learn to make LLM inference faster and more cost-efficient at scale! https://t.co/vUiu6goWCO
The anti-AI coalition continues to maneuver to find arguments to slow down AI progress. If someone has a sincere concern about a specific effect of AI, for instance that it may lead to human extinction, I respect their intellectual honesty, even if I deeply disagree with their position. However, I am concerned about organizations that are surveying the public to find whatever messages will turn people against AI, and how the public reacts as these messages are spread by lobbyists or by politicians seeking to alarm constituents, companies pursuing regulatory capture or seeking to promote the power of their technology, and individuals seeking to gain attention or to profit by being provocative. A large study (link in original article below; h/t to the AI Panic blog) by a UK group tested different messages that are designed to raise alarm about AI. Their study found that saying AI will cause human extinction has largely failed. Doomsayers were pushing this argument a couple of years ago, and fortunately our community beat it back. But AI-enabled warfare and environmental concerns resonate better. We should be prepared for a flood of messages (which is already underway) arguing against AI on these grounds. Further, job loss and harm to children are messages that motivate people to act. To be clear, I find AI-enabled warfare alarming; we need to continue serious efforts to monitor and mitigate the environmental impact of AI; any job losses are tragic and hurt individuals and families; and as a father, I hold dearly the importance of every child’s welfare. Each of these topics deserves serious attention and treatment with the greatest of care. But when anti-AI propagandists take a one-sided view of complex issues to benefit their own organizations at the expense of the public at large — for instance, when big AI companies argue that AI is dangerous to block the free distribution of open source projects that compete with their offerings — then we all lose. For example, public perception of data centers’ environmental impact is already far worse than the reality — data centers are incredibly efficient for the work they do, and hampering their buildout will hurt rather than help the environment. While job loss is a real problem, the “AI washing” of layoffs — in which businesses that had over-hired during the pandemic blame AI for recent layoffs, although AI hasn’t yet affected their operations — has led to overblown fears about the impact of AI on employment. Unfortunately, this sort of propaganda easily leads to regulations that create worse outcomes for everyone. For example, oil companies worked for years to create fear of nuclear energy. The result is that overblown concerns about the safety of nuclear power plants has stifled nuclear power development, leading to millions of premature deaths from air pollution that was caused by other energy sources and a massive increase in CO2 emissions. Let’s make sure overblown concerns about AI do not lead to a similar fate for the many people that would benefit from faster AI development. Last week, the White House proposed a national legislative framework for AI. A key component is a federal preemption framework to prevent a patchwork of state regulations that hamper AI development. I support this. After failing to gain traction at the federal level, a lot of anti-AI propaganda has shifted to the state level. If just one of the 50 states passes a law that limits AI in an unproductive way, it could lead to stifling AI development across all the states and potentially across the globe. The White House proposal rightfully respects each state’s rights to control its own zoning, how it enforces general laws to protect consumers, and how it uses AI. But if a state were to pass laws that limit AI development, federal rules would preempt the state law. The White House proposal remains a proposal for now. However, if the U.S. Congress enacts it, it will clear the way for ongoing efforts to develop AI in beneficial ways. Where do we go from here? Let’s support limiting applications — those that use AI, and those that don’t — that harm people. When the anti-AI coalition argues against AI, in addition to considering the merits of the argument, I consider whether their position is consistent and persuasive, or if they are just promoting whatever concerns they think will sway the public at a given moment. And, let’s also keep using a scientific approach to weighing AI’s benefits against likely harms, so we don’t end up with overblown concerns that limit the benefits that AI can bring everyone. [Original text with links: https://t.co/kfZY7mo0Mi ]
New course: Agent Memory: Building Memory-Aware Agents, built in partnership with @Oracle and taught by @richmondalake and Nacho Martínez. Many agents work well within a single session but their memory resets once the session ends. Consider a research agent working on dozens of papers across multiple days: without memory, it has no way to store and retrieve what it learned across sessions. This short course teaches you to build a memory system that enables agents to persist memory and thereby learn across sessions. You'll design a Memory Manager that handles different memory types, implement semantic tool retrieval that scales without bloating the context, and build write-back pipelines that let your agent autonomously update and refine what it knows over time. Skills you'll gain: - Build persistent memory stores for different agent memory types - Implement a Memory Manager that orchestrates how your agent reads, writes, and retrieves memory - Treat tools as procedural memory and retrieve only relevant ones at inference time using semantic search Join and learn to build agents that remember and improve over time! https://t.co/nxNSEHGmr9
Should there be a Stack Overflow for AI coding agents to share learnings with each other? Last week I announced Context Hub (chub), an open CLI tool that gives coding agents up-to-date API documentation. Since then, our GitHub repo has gained over 6K stars, and we've scaled from under 100 to over 1000 API documents, thanks to community contributions and a new agentic document writer. Thank you to everyone supporting Context Hub! OpenClaw and Moltbook showed that agents can use social media built for them to share information. In our new chub release, agents can share feedback on documentation — what worked, what didn't, what's missing. This feedback helps refine the docs for everyone, with safeguards for privacy and security. We're still early in building this out. You can find details and configuration options in the GitHub repo. Install chub as follows, and prompt your coding agent to use it: npm install -g @aisuite/chub GitHub: https://t.co/OCkyxXQMCq
I'm excited to announce Context Hub, an open tool that gives your coding agent the up-to-date API documentation it needs. Install it and prompt your agent to use it to fetch curated docs via a simple CLI. (See image.) Why this matters: Coding agents often use outdated APIs and hallucinate parameters. For example, when I ask Claude Code to call OpenAI's GPT-5.2, it uses the older chat completions API instead of the newer responses API, even though the newer one has been out for a year. Context Hub solves this. Context Hub is also designed to get smarter over time. Agents can annotate docs with notes — if your agent discovers a workaround, it can save it and doesn't have to rediscover it next session. Longer term, we're building toward agents sharing what they learn with each other, so the whole community benefits. Thanks Rohit Prsad and Xin Ye for working with me on this! npm install -g @aisuite/chub GitHub: https://t.co/OCkyxXQMCq
Apple just named its latest laptop Neo -- same name as my son! Should I buy one? If I run Amazon Nova on an Apple Neo I hope to blow both of my kids' minds.
New course: Build and Train an LLM with JAX, built in partnership with @Google and taught by @chrisachard. JAX is the open-source library behind Google's Gemini, Veo, and other advanced models. This short course teaches you to build and train a 20-million parameter language model from scratch using JAX and its ecosystem of tools. You'll implement a complete MiniGPT-style architecture from scratch, train it, and chat with your finished model through a graphical interface. Skills you'll gain: - Learn JAX's core primitives: automatic differentiation, JIT compilation, and vectorized execution - Build a MiniGPT-style LLM using Flax/NNX, implementing embedding and transformer blocks - Load a pretrained MiniGPT model and run inference through a chat interface Come learn this important software layer for building LLMs! https://t.co/wm6NZOGIKC