というのを感じています。 理想としては、↓これが、 シンプルな仕事と難しい仕事の割合がこんな感じだとして…↓こうなって欲しいのだけど(シンプルなタスクが早く片付くことにより難しい仕事に取り掛かる時間が増える)、 AIによってシンプルな仕事がさっさと片付くことによりより多くの難しい仕事ができる?↓なんか実際はこうなっちゃってる。 シンプルな仕事、無限にあるなぜかAI によってシンプルなタスクをめちゃくちゃこなしやすくなっている 実際仕事は進むし、進んだ気にもなる 進んでしまうので、次のタスクも片付けられるようになる しかし、シンプルなタスクは、こなしてもこなしてもなくならない 無限にやることがあるので、無限にやることをこなしてしまう このサイクルで仕事をしていくと「アウトプットを出すための時間が非常に短い・速い」というサイクルに脳が慣れ、それが仕事だと感じるようになり、逆に時間のかかるタスク

最近久々に「スタープログラマ」という言葉を聞いた。 そういえば、私の中にもかつてそういう存在がいたなあ、と思い出した。 あえて定義することもないが、スタープログラマとは、先進的なOSSプロダクツを実装し、ブログなどでプログラミングを堂々と論じ、できれば単著の一つも書いているような人たちといったところである。 話の都合上、具体的な名前を出すが、高林哲氏、higepon氏、新山祐介氏などが、私にとってのスタープログラマであったし、少し時代を戻すとεπιστημη氏であるとか、賛否両論だとは思うが、やねうらお氏などの名前が挙げられるかもしれない。 スタープログラマというのは、駆け出しのプログラマやプログラム学習者にとっての目標であり、先輩であり、嫉妬の対象でもある。 彼らの言葉は絶対で、疑う余地もないことであり、私はそのプログラミングに対する思想を無条件に受け入れたし、彼らが使っているエディタや

インド側：調和を守り「ノー」と言わずに場を収める文化。結果的に事実とズレても“悪質なウソ”という感覚は薄い。

私の勤務先はデザイン・工学部で「デザイン思考」みたいな考え方を学びます。そして学部生が授業の一環で「あなたのニーズとか今抱えてる問題を教えてくれ」のようなメールを送ってきます。対応できる部分はしますが、正直なところ困惑もしています。下記はそのようなことに対する私の意見です。デザイン思考に対する意見ではなく、どう課題を見つけるかということに対する意見です。 私はコンサルのようなポジションの取り方には相容れないと感じるのですが、それは「自分の問題意識を持つ」という難しい部分から目をそらして、他人の問題・問題意識にフリーライドしているからです。「私はこれに興味がある」「これが問題だと思う」と宣言するのはとても難しいことです。自分の問題意識に向き合って、それを口に出すのって恥ずかしいし勇気がいることなんですよね。「そんなことに興味があるの」と他人に批評されたり、問題意識が小さい人間だと思われるのは

自分がよく言うんだけど、ちゃんと意味を説明してないとすげーパワハラワードに見えるのでちゃんと説明する。 頑張らなくていいんで結果で答えてくれる?— そーだい@初代ALF (@soudai1025) 2024年11月23日 頑張らなくてもいい 「もっと頑張ってよ」って言われて苦しくなること、経験がみんなにもあるはず。 仕事において、人それぞれ出力に差はあれど、すでに頑張っている。 それに対して「もっと頑張れ」と求めるのは「無理をしろ」という意味を表すと思っている。 瞬間的にはそれでなんとかなることもあるけれど、中長期では無理をしても継続できなくて、最終的には破綻する。 だからこそ「頑張ります！」って回答に対しては、「頑張らなくていいんで」と伝えている。 仕組みで成果を出す 仕事なので大小はあれど、成果で評価される。 前にもブログに書いたことがある。 soudai.hatenablog.com

AI Coding Agentが活況だ。巷ではClineだRoo Codeだと盛り上がり、MCPを実装したことを自慢し、驕れる平家のごとくだが(平家と違ってもう少し長生きするだろうが)、かくいう私もそうである。 とはいえ、テトリスやブロック崩しが一瞬で作れたところで我々が失職するはずもなく、最初から作るものが決まっていて定型的でいくらでもエントロピーを増やして散らかしても良い一回ポッキリのブロック崩しと、イテレーティブな開発を行うことが前提で、非定型であり、エントロピーの無秩序な拡大を抑止しながら開発しなければならない†現実†の開発とでは月とすっぽんであり、今のところAI Coding Agentは月兎にあらず、地面を頑張って跳躍しているふつうの兎だ。 ClineやRoo CodeにはOrchestration modeといって大きなタスクをサブタスクに分割してやっていくという補助機能があ

「歩くという哲学」　［著］フレデリック・グロ 歩く。移動手段としてではなく、歩くことそれ自体。歩いているとさまざまなもの・ことが流れ込み、湧き出てくる。少し私自身のことを書かせてもらおう。私は歩くことを日課にしている。道端の小さな花が、木々の芽吹きが、鳥の声が、私を浸してゆく。私はときに低い山、取り立てて面白みのない山道を歩く。それでどうやら身も心も喜んでいるらしい。 その喜びを著者はこう語っている。「自分に出会い直すとか、本当の自分だの、失われたアイデンティティだのを取り戻すだとか、そういった話ではないのだ。歩くことによって、人はむしろ、アイデンティティという概念そのものから抜け出すことができる。」 本書は、歩くことについて、そして歩くことが決定的な意味をもっていた文学者や哲学者たちについて書かれた33のエッセイからなる。「ただ身体的な努力を繰り返しているだけで、精神に『空き』ができる。

この2か月間さる事情があり──いや、本当は大した理由もなく──数学や物理のトピックをいろいろ漁って勉強していた。そして過剰に期待しては幻滅するのをくり返していた。その過程を本記事では紹介する。 アタシっていつもこれだ……。 1. 機械学習 2. 数値計算 3. 確率論 4. 数理ファイナンス 5. 非平衡統計力学 6. 量子情報 7. 型理論・ラムダ計算 8. 物性物理 1. 機械学習 思ってたのと違った度：10/10 時代の要請と思って石井／上田『わかりやすいパターン認識』（オーム社、第2版2019年）の3部作を読み始めた。そして1巻目を読了した時点で気づく。 「こいつら線形代数とか数理統計学とかを使ってアルゴリズムを組み立てるけど、それがなぜ・どのくらい上手くいくか実験以外で全く説明しねえ！　仮説もねえ！」 結果、萎え落ちした。有名なビショップ『パターン認識と機械学習 上・下』（丸善出

昔DeNAの新人が入社後半年だかの振り返りのプレゼンの中で「うまくモチベーションが上がらなくて」ということを言った時に、南場社長が「社会人がモチベーションで仕事をするな」とすごく怒ったという話*1があって、とても印象に残っている。 また、これは実体験だが、その当時所属していた会社のけっこう中心的な人物が退職する送別会で、その人が受け持っていた客の話になった時、「あれもこれも大変なお客さんですね。私たちに引き継ぎできるものですかね」と残された側が不安をこぼすと、その人は「仕事やろ」とピシャリと言った、という場面をよく覚えている。 どちらも胸に氷を刺されたような、うすら寒い気持ちになったからだった。 私は、社会人だが、どうにも好き嫌いで仕事をしている節があった。やるべきことを淡々とこなすのではなく、やらなくてはならないことの中に何とか自分の興味が持てるようなテーマを見いだして、努力の為のエネル

※自分のための覚書的に書いておく文章です。出典や論拠を少しは集めて「論」の体裁にできればよかったのですが、ひとまず個人の所感ということで文章化を試みます。 2022年末にChatGPTの登場で幕を開けた「生成AIブーム」。津々浦々にその「すごさ」が知れ渡ったことで投資先行で発展してきた基盤モデルを軸とした技術だが、2025年に入って、いよいよ「どのような経済的なインパクトを出せるのか」に焦点が当たってきた。 多くの人が思い描いているシナリオは、大まかには、単なる対話システムを超えた「AIエージェント」が人間が担ってきた労働を代替し、人間では不可能なスピードで（たとえば科学などの）進歩をもたらす近未来といったものだ。人間のホワイトカラーの仕事のほとんどを代替できるような汎用的なAI（AGI）の到来は2年先に迫っているのか、まだ20年先なのかといった議論が（その「リスク」の話とともに）、一部で

Qiita Conference 2025 https://qiita.com/official-campaigns/conference/2025#day3 Appendix - https://konifar-zatsu.hatenadiary.jp/entry/2023/11/01/193210 -

アジャイルにおいて開発の過程や成果を振り返ることは、チームの改善につながる大切な行動です。とくにスクラムにおいては、スプリントごとにレトロスペクティブ（retrospective、ふりかえり）のイベントを実施します。ふりかえりのフレームワークといえば「KPT」がまず思い浮かびますが、実際にはチームの状況やふりかえりの目的に合わせて、さまざまなレトロスペクティブの手法をチョイスするのが望ましいでしょう。 それでは具体的にKPT以外ではどんなフレームワークがあり、それぞれチームがどのような状態のときに用いると効果的なのでしょうか。ブログに「自分がレトロスペクティブで最初はKPTをやるけどそのうちやらなくなる理由」という記事を執筆したソフトウェアエンジニアの大金慧（@bayashimura、ばやし）さんと、その記事で引用された講演資料の発表者で長年エンジニアリングマネージャーを務める小田中育生（

【読売新聞】　「企業のネットが星を 被 （ おお ） い、電子や光が駆け巡っても」国家や民族が消えてなくなるほどではない近未来が舞台の『攻殻機動隊』などで、後のクリエイターに多大な影響と衝撃を与えた漫画家、士郎正宗さん（６３）。デビ

はじめに 本日(4/4) Devin 2.0 がリリースされました！ 大幅な変更があったので、本ブログではその内容をご紹介します。特に料金プランの追加により、Devinの利用がより手軽になったことをご紹介します！ リリースノート Coreプランが追加 今まで最小のTeamプランは$500からでした。企業での利用でない場合、お試しで利用し始めるには、少し手が出にくい金額でした。今回新しくCoreプランというTeamプランよりミニマムなプランができました。 以下簡単な翻訳を記載します。 AIエンジニアのコア機能（自律的なタスク完了、自然言語でのコラボレーション、時間をかけた学習）が含まれる 月額契約金額なし 最初に$20のACU購入が必要 最大10の同時Devinセッションが可能 ユーザ数制限なし プランの説明から見ると最低$20分のACUから利用可能になります！Coreプランの導入により、最

前書き 前回の記事「DevinのKnowledgeで共通ルールを整備する」では、Devinの出力をより安定させるために、共通ルールとなるDevinのKnowledgeを整備しました。 このKnowledgeによって、日本語での応答の固定化、作業ブランチの命名規則の統一、Gitリポジトリ接続時の初期確認などを自動化することができ、概ね意図通りの動作をするようになったと感じています。 今回は、さらにDevinの出力を安定させるため、プロジェクト毎のコンテキストをDevinが参照できる仕組みを作ります。 具体的には、リポジトリ内にdocsディレクトリを作成し、その中にプロジェクト単位のドキュメントをDevinに整備してもらうという試みです。 なぜプロジェクト内にdocsを置くのか 現在、私はシステム開発においてDevinとCursorを併用しています。 DevinにせよCursorにせよ、プロジ

はじめに こんにちは！LayerX AI・LLM事業部LLMグループのマネージャーを務めていますエンジニアの恩田（ さいぺ ）です。 AI・LLM事業部では「Ai Workforce」というプロダクトを開発しています。レポジトリができてから早1年半、多数の機能が実装されてきました。ところが昔から存在する一部の機能については、開発者が不在、仕様や実装を完全に把握しているメンバーが特定のエンジニアに限られているといった課題が発生しています。 また、開発スピードを優先し、コメントが残されていないコードや、設計ドキュメントがないといった課題もありました。 こうした課題に対して、Devinを活用して .cursorrules を生成し、非エンジニアメンバーの力も借りながら、ドキュメント化を進めた取り組みについて紹介したいと思います。 AIによるドキュメント作成フロー まず、Devinにレポジトリのコ

© 士郎正宗・Production I.G/講談社・攻殻機動隊2045製作委員会 © Shirow Masamune, Production I.G/KODANSHA/GITS2045

UPDATE 5/13/2021: the course has been published, check it now here: Validation and DDD. I’m working on a new Pluralsight course on the topic of validation and DDD, with the help of the FluentValidation library and .NET data annotations (attributes). So expect a couple of posts about validation in the near future. In the preparation for the course, I was re-reading some old articles about always-va