Recent posts
これ本当に良い。ぜひ見てください!
原文を表示 (en)
This is really good. Recommended watch!
⭐ New talk! https://andymatuschak.org/tat Coding agents might help us finally break out of two cages: the app model, which traps computing in one-size-fits-all silos; and programming as a specialization, which has crowded out cultures of imagination and domain insight.
AIがあるからコードについて考える時間を減らすべきだと思うかもしれません。 強く反対です！実際に大量のAI生成コードが負債になってるのを目の当たりにしてます。 結局のところ、エンジニアは本番環境にデプロイされたコードに対して責任を持つ必要があります。デバッグしようとしてるシステムを理解していなかったら、きっと大変なことになります。 もちろんAIはこの全てを手助けできますが、適切なシステムセットアップが必要です。本番ログをトリアージしたり、エラーを確認したり、調査の一部をスピードアップできます。でも最後の判断はエンジニアがする必要があります。その変更は深刻な顧客や財務上の影響を及ぼすかもしれません。 今後のトレンドとしては、依存関係の削減、コードのベンダリング化で直接修正できるようにする、抽象化が少ないシンプルなシステムを好む、そしてシステム設計とコードメンテナンスについてめちゃくちゃ多く考える時間に向かうと予想してます。 前にも言いましたが、CS基礎とすごいソフトウェアの歴史を勉強するのは本当にいい時期です。AIが進化する中で多くの部分は変わりますが、人々が思ってるより遥かに多くの部分は変わらないままですよ。
原文を表示 (en)
You might believe you should spend less time thinking about code because of AI. I strongly disagree! We’re watching this play out live where tons of AI generated code becomes a liability. At the end of the day, an engineer needs to be responsible / on call for code that gets shipped to production. If you don’t understand the system you’re trying to debug, you’re probably going to have a bad time. Yes, AI can help with all of this, if you set up the proper systems. You can have agents triage prod logs, look at errors, etc. You can speed up parts of the investigation, but an engineer needs to make the call. There might be serious customer or financial implications from that change. I expect the trend continue for trimming dependencies, vendoring code so you can modify it directly, preferring simpler systems with fewer abstractions, and spending waaaay more time thinking about system design and code maintenance. I’ve said this before, but it’s a great time to get familiar with CS fundamentals and some of the history behind what great software looks like. Many parts will be different in the coming years as AI progresses, but also a lot more than people realize will stay the same.
これは素晴らしい執筆であり、今日のハイレベルなリクルーティングがどのようなものかを示している。 愛するものについてのいくつかの注記...読みやすく、凝った音に見えようとしていない。基本的な単語を使う。話すように書くべき！ いくつかの数字を含めて謙虚ですが、誇大広告しようとしていない。彼自身と彼の考えに対する快適さのレベルがあり、それを感じることができる。 これにより彼と彼の背景を応援したくなる。例のいくつかに関連しているかもしれない（俺も若い頃にビデオ編集を学んだ）。人々は自分たちが好きな人と一緒に働きたいと思っている。 オーバーザトップでなく、ユーモアを使っている。これにより AI スロップではなく人間によって書かれたように感じる。 「Starbucks で働く無一文の映画学生であろうと、Papa Sam から 100 万ドル稼いでいる OpenAI リサーチャーであろうと、俺は気にしない。」 最後に、好きな部分の 1 つは、通常の履歴書/申請書を切り詰め、構築したものに直進することだけだ。 「履歴書を送らないでくれ。Clicky のデザインをしたいなら、Clicky のデザインを見せてくれ。ここで映像作家になりたい？いいね、Clicky のビデオを録画して見せてくれ。」 素晴らしい仕事 @FarzaTV！
原文を表示 (en)
This is great writing and what high-quality recruiting looks like today. Some notes on what I love... It's very easy to read and not trying to sound fancy. It uses basic words. You should write how you speak! It's humble, including some numbers, but not trying to overhype. There's a level of comfort in himself and his ideas you can feel. It makes you root for him and his background. You might even relate to some of the examples (I also learned video editing at a young age). People want to work with people they like. It uses humor without being over the top. This makes it feel written by a human and not some AI slop. "I don’t care if you are broke film student who works at Starbucks or an OpenAI researcher getting paid a milli by Papa Sam." Finally, one of my favorite parts is just cutting the normal resume / application crap and going straight to what you've built. "Do not send me your resume. If you wanna do design here, show me a design for Clicky. If you wanna be a filmmaker here, great, record a video for Clicky and show me." Nice work @FarzaTV!
I am building a team. If you're really really really good at building stuff, design, filmmaking, writing, pushing the models to their limits, or just making people care about a product at mass, certainly reach out. Let's collab + make stuff. Details: https://docs.google.com/document/d/1sfsGQurJ444vXKXcqcHg32SBRYz3LVrvOt4Hwig-ai8/edit?usp=sharing
コードは本当に正しい抽象化なんだよ。 基本的にMarkdownファイルを書いたり見直したりするだけみたいなレベルに未来が貶められてるのを見ることが多すぎる。 確かに、数千行のエージェントコードをレビューするのは難しいだろう。でも多分取り組むべきは、コードの量を減らすべきってことなのかもしれない？ 単にあきらめるのではなく（「まぁコード読まないか、損失の多いMarkdown要約読もう」みたいなやつ）、それはもっと良いシステムについて考えるシグナルであるべき。 - コードベースをもっと検証可能にするには？例えば、高速/堅牢/安定なテストとか、型付き言語に移行するとか。 - エージェントが生成したコードを解きほぐしたり、アーキテクチャ/抽象化を改善するには？例えば、すべてのコード生成ぶっこみの前にコードベースのアーキテクチャ/型にもっと時間をかけるとか。 - 時間をかけてこのコードベースをメンテナンス、進化させるには？slopsは複合する。素晴らしい解決策の一つはソフトウェアエンジニアリング過去数十年から学ぶことだ。例えば、完全に間違った抽象化があるから、コード重複が山ほどある、みたいなことかも。 Markdown派は確かにいくつかの点で正しい。毎日たくさんの異なるプロンプトとワークフローでスキル使ってるなら、それって実質「Markdownでコーディング」じゃん？みたいな。 スキルのメリットと利点についてはいっぱい議論されてきた。俺的には、スキルはエージェントに対するあなたの働き方を可視化させる。コードを置き換えるわけじゃなくて、それが本質的なポイントじゃない。 現実には、これら両方が真実である、面倒でしょっちゅう進化し続ける未来がある： 1. スキル（とMarkdown）は、エージェントへのインプットをどう与えるか、高品質なコード＆システムが作られることを保証するか、という点で重要 2. 実際のコードを見ることは、Markdown要約やコードの詳細レベルを無視する仕様書コレクションでは置き換えられない 要するに：現実にはびっくりするほどたくさんの詳細（とニュアンス）があるんだ！
原文を表示 (en)
Code is actually the right abstraction. Too often I see the future of software engineering diminished down to, effectively, writing and reviewing markdown files. Yes, it will be hard to review thousands of lines of agent code. But maybe the takeaway is that you want less code? Rather than just giving up ("well I guess we won't read the code, or we'll read this lossy markdown summary") this should be a signal forcing you to think about better systems. - How can we make our codebase more verifiable? For example, fast/robust/stable tests, or moving to a typed language. - How can we deslop or improve the architecture/abstractions of the code generated by agents? For example, spending more time up front on the codebase architecture/types before yolo generating all of the code. - How are we going to maintain and evolve this codebase over time? The slop compounds. One great solution here is... you guessed it, learning from the past decades of software engineering! For example, you might just have the wrong abstraction entirely, leading to a ton of duplicated code. I think the markdown folks *are* right in some ways. If you are using skills every day, for many different prompts and workflows, isn't that effectively "coding with markdown"? Kinda. There's been plenty of ink spilled on the merits and benefits of skills. To me, skills make your style of working legible for agents. They don't replace code and that's not really the point. In reality, there's this messy and constantly re-evolving future in which both of these things are true: 1. Skills (and markdown) are important for how you give input to the agents and ensure high-quality code & systems are created 2. Looking at the actual code will not be replaced by markdown summaries or a collection of spec documents that ignore the lower level details of the code In summary: reality has a surprising amount of detail (and nuance)!
エンジニアの応募書類を目立たせる方法（何百通ものレジュメを見てる立場から）: 1. レジュメは1ページで。どうしても必要ならウェブサイトにリンク。各職歴で10個以上の箇条書きは不要。 2. 意図的に作られたポートフォリオサイトをリンクするだけで、90%以上の応募書類を圧倒できる。 3. X（Twitter）をリンクする場合、投稿を整理した方がいい。当たり前だけど...人によってはかなりヤバい投稿してたりする。 4. GitHubはリンクすべき。ただしMySpaceみたいなバッジと画像だらけのプロフィール README は避けて。コードと君がどんな面白いアイデアを実装できるかを見たい。 5. 企業ごとに応募書類をカスタマイズすべき。スタートアップに応募するなら大学の講義履歴はそこまで重要じゃない。FAANG の ATS スクリーニングを通すなら話は別だけど。 6. AI やエージェントについて全く触れていないレジュメが意外と多い。ソフトウェア工学は変わってて、仕事で AI を使ったコーディングを学ぶ・理解することはもう必須スキル。それがレジュメとプロジェクトに反映されるべき（Cursor にいるから言ってるわけじゃなく）。 7. LinkedIn を真面目に扱って。ここ X に居着いてる開発者が多いけど、内部的には LinkedInを回すことが多い。 8. 君のユニークな強み・趣味・興味を見せる工夫をしよう。スマートで多才で思慮深い人というのは素敵だけど、その先が大事。読んで良かった本とその理由とか、書いた文章、好きな映画とか。結局のところ人は、好きで尊敬できる人と働きたい。最低限でも、いい会話のきっかけになる（「あ、この本も好きです!」）。 9. AI にカバーレターやレジュメの文章を書かせるのは止めて。特に AI 企業に応募するなら一目瞭然。アイデアや表現のブレストに使うのはいいけど、自分で書いて（AI の定番フレーズの罠に落ちない）。 10. レジュメに写真はいらない。リンク先に置いておいて。 11. 量より質。AI スロップ 27 個の壁じゃなく、本当に良くて思慮深くて詳しくて面白いプロジェクト 3 つ。 採用担当者・リクルーターは1つのポジションで何百何千もの応募をもらってる。全ての応募に20分かけるわけにはいかない。余計なものを削ぎ落として、要点を押さえる必要がある。役に立つといいな！
原文を表示 (en)
How to make your engineering job application stand out (from the perspective of someone looking at hundreds of resumes): 1. Your resume should be one page. If you really need more space, link to a website. You don't need 10+ bullets for each job. 2. You will immediately stand out >90% of applications if you link a personal website that has some intentionality behind it. 3. If you are going to link your X, you might want to clean up your posts? Seems obvious but... people post some wild stuff. 4. You should link your GitHub. Please avoid doing a profile README that looks like a MySpace profile with the badges and images. I'm trying to look at code and your ability to build interesting ideas. 5. You should try to customize your application to the company. If you're applying to a startup, the courses you took in college probably don't matter as much. Maybe more if you're trying to make it through the ATS screening for FAANG. 6. I'm seeing a surprising number of resumes which don't talk about AI or agents at all. Software engineering is changing and it's a pretty fair assumption that you will be expected to learn or understand coding with AI for your job. That should be reflected on your resume and projects (and I'm not just saying this because I'm at Cursor). 7. Take your LinkedIn seriously. Most devs are here hanging out on X but surprisingly still most people will send around your LinkedIn internally. 8. Find ways to show your unique strengths/tastes/interests. It's nice to see people are smart, well-rounded, and thoughtful. Maybe this is a collection of books you enjoyed and why. Or some writing you've done. Or films you liked. At the end of the day, people want to work with other people they like and respect. If nothing else, it will be a good conversation starter ("oh I love [book] as well!"). 9. Do not use AI to write your cover letter or resume text. It's incredibly obvious, especially if you are applying to an AI company. You can still use it to ideate on ideas or phrases, but write it by hand (don't fall victim to the overused in-the-distribution-AI-phrases). See: /humanizer skill. 10. No photos on resumes. Save those for whatever you link out to. 11. Quality over quantity. 3 really good, thoughtful, detailed, interesting projects versus a wall of 27 AI-slop ones. Remember that hiring managers / recruiters are getting hundreds or thousands of applications for a role. They're not going to spend 20 minutes on every single application. You need to cut the cruft and get to the point. I hope this helps you stand out!
最新のAIモデルとコーディングエージェントの限界をプッシュするのが好きなエンジニアなら… 俺たちと一緒に働こう！学べること、作れること、教えられることがいっぱいある。
原文を表示 (en)
If you're an engineer who loves to push the limits of the latest AI models and coding agents... You should come work with me! There's so much to learn, build, and teach.
Anthropicが@SpaceXと提携して彼らのコンピュート上でモデルを実行するとのこと、エキサイティングだ！
原文を表示 (en)
Anthropic is partnering with @SpaceX to run models on their compute, exciting!
プロダクトなし、マーケティングなし、デザインなし... ただのBuilders™
原文を表示 (en)
No product, no marketing, no design... just Builders™
1年前の自分には、優秀なコーディングエージェントが、あらゆる知的労働に向けたゼネラルエージェントへの道でもあるというのは明らかではなかった。 だが今ではすごく理に適ってる。来年のAIがどこにあるか、そして後々何が明らかに見えるのか興味深い。
原文を表示 (en)
It wasn’t obvious to me one year ago that an excellent coding agent would also be the path to a general agent for all knowledge work. But now it makes a lot of sense. I’m interested to see where AI is at next year and what seems obvious then in retrospect.
このCursorの新機能にめちゃくちゃ興奮してる。 複数のエージェントを同時に実行するのが今や*すごく*簡単に (async subagentsと改善されたworktrees付き)。 そして複数のリポにまたがってエージェントを実行できる (例: フロントエンドとバックエンド!)
原文を表示 (en)
Extremely excited about this Cursor ship. It's now *way* easier to run many agents at the same time (with async subagents and improved worktrees). And you can run agents across many repos (e.g. frontend and backend!)
Introducing /multitask in the new Cursor 3 interface. Cursor can now run async subagents to parallelize your requests instead of adding them to the queue. For already queued messages, you can ask Cursor to multitask on them instead of waiting for the current run to finish.
It’s wild how much has changed since I posted this in December 2024. Fun to look at all the demos in the thread. Curious what y’all think are the best examples now in 2026?
AI-native UX What do apps look like when you design AI first? Starting a thread to collect some examples I've found.
I really respect @antirez so I'd like to share my slightly different take on frontend development in 2026 (and especially in a coding agents world). First, on his point around libraries/frameworks and company size: > "We have things like Angular and React that are big-company-design stuff that became normal programming. It's like if every site runs on Kubernetes." It's true that frontend frameworks had to uniquely solve for the design constraints of BigCos. How do you build a system where thousands of engineers need to ship components independently without muddying the rest of the app? Composition! And if you take composition to its logical extreme and try to build a framework which works for both small *and* very large JavaScript apps, you end up with things like streaming, Suspense, and many of the other niceties of React and metaframeworks. Often, you do want many of these things to build high quality products. But sometimes you don't, and you don't have to ditch React's composition model and all the libraries, ecosystem, bundlers, et al to get there. Personally, I think Bun is one of the best realizations of this vision, where you can write React apps with a single toolchain. The layers of abstraction can fit in your head. > "There was, in big companies, an extreme desire to do two things: totally isolate frontend from backend, because the internal organization of big companies has such a split, and to make applications so standardized that hiring new people, firing old people, is something possible and easy." This might get into the HTMX holy war, but IMO this client/server debate has always been a thing. I'd also argue that, in many cases and now increasingly with AI, the client/server split is helpful for humans and agents to compartmentalize the codebase. I'm personally very supportive of open-source libraries like React and friends that get battle-tested at scale and get security patches (while painful sometimes). Models can learn this abstraction, and for many many cases, stop reinventing the wheel. Similar feelings about Tailwind. > "We later created a generation of programmers that can't even understand a single language very well in its internals, that is: Javascript, they often know the framework, not the language, nor even CSS well enough." It's true that a lot of frontend devs end up focusing on the app layer code concerns like React/Tailwind and maybe aren't as proficient at debugging heap snapshots. But I don't think the solution is to throw out the abstractions entirely, but instead to keep teaching the next generation of devs how to go up and down the stack as needed. This is now massively accelerated by AI and coding agents. Just like you can ask an agent to generate lots of frontend code for you, you can also ask it to deeply explain how every abstraction layer works. There's no forgoing competence to be a great frontend engineer. > "The irony is that front-end developers highly suffer from all that, for a number of reasons: they are forced to continue learning new ways to do the same button, form, pagination, and so forth. And, also, if they are smart they understand they don't really know what programming really is in most cases, and are not happy about it." Throughout my entire career doing frontend and product engineering, I've seen opinions like this over and over again. Back in the day, it was framing frontend as "just the HTML and CSS" / web developer, somehow less than"the great backend engineers. The reality is that there are many many incredibly talented frontend engineers who do lots of *extremely technical* work. It's time for a lot of backend engineers to give the frontend peeps their flowers, acknowledge some of this frontend stuff is Very Hard, and begrudgingly accept that React has some good ideas. And if you made it this far and still want to complain, I bet you can make an incredible frontend with Svelte/Tailwind and your coding agent of choice, taking 80-90% of the upside of the last decade of frontend dev
My POV on front-end of 2026
I actually rewrote this course three times 🙈 Coding agents and their best practices are changing quickly, making creating educational content quite difficult. This course comes after 10 different talks I've given about how Cursor uses Cursor internally, and hundreds of conversations with customers about the best ways to use agents. I tried to find the right balance between being useful today *and* foundational for your future. Let me know what you think! And now onto the next one...
Learn how to use coding agents in 30 minutes! This course teaches you how to build software with agents: plan new features, fix bugs, review and test code, and more. It's 100% free and these concepts apply to any agent!