Latest / M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語） / つぎはぎデバッグから脱却：.NETとAzureで使うGitHub Copilotエージェントモード（AI吹き替え）

Transcript

つぎはぎデバッグから脱却：.NETとAzureで使うGitHub Copilotエージェントモード（AI吹き替え） · M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語）

0:00
マイクロソフト365コパイロット ai アジュールそして働き方の未来を築く人々が集う10日間準備はいいですかこの1月 m 365コンが帰ってきます
0:10
さらに規模を拡大してお届けしますライブセッションや実践的なデモ世界中の mvp や業界エキスパートによる知見をぜひ体験してください
0:18
ありきたりなスライドは一切ありません無意味な専門用語の羅列もありませんコパイロットスタジオ ai エージェント
0:24
ファブリックセキュリティガバナンス自動化といった現実の課題に取り組みます it プロフェッショナル開発者ビジネスリーダーの皆様それぞれのニーズに合わせたセッションを用意しています
0:35
充実した10日間で多様な技術を探求し世界中のコミュニティとつながりましょうライブ配信を見て組織ですぐに役立つ実践的な知見を持ち帰ってください
0:44
2027年1月10日間一つのマイクロソフトコミュニティ登録受付を開始しましたメートル365コンドットネットにアクセスして今すぐ参加枠を確保しましょう
0:56
サイトはメートル365コンドットネットですメートル365コンドットネットから今すぐ登録を1月のライブでお会いしましょう
1:04
ソリューションを開いた瞬間複雑に絡み合うファイルや参照そして待ち受けるバグの山に圧倒された経験はありませんか
1:10
それはあなただけではありません多くの開発者はあちらをパッチしこちらをデバッグするという受け身の作業に追われています
1:15
GitHubコパイロットのエージェントモードはより広い文脈を理解しファイル間をまたぐ変更を調整することを目指しています
1:20
この動画では実際のドットネットおよびアジュールプロジェクトでそのワークフローがどう機能するかを実演します
1:25
ライブ環境のソリューションを通じエージェント利用前後の変化をお見せします最小限の手間で複数ファイルのコードを生成しファイル間のエラーを迅速に解消する様子や
1:33
自然言語の使用から機能をスケルトン生成する方法をご覧いただきますその前に私たちが日常的に陥っているデバッグループに隠されたコストについて考えてみましょう
1:41
パッチワーク的なデバッグに隠されたコスト一見シンプルに見えるエラーを修正しようと取り組み始めます
1:46
アプリケーションはビルドできずコンソールはメインプロジェクトファイルの行を指摘しますメソッドを微調整して再コンパイルし解決したと思った矢先
1:53
わずかに形を変えた同じメッセージが再表示されますさらに30分が経過しようやく真の問題に気づきます
2:03
を修正して再デプロイする頃には午後の大半がパッチワーク作業で消えてしまいます予定していた機能開発は明日に持ち越しですこのパターンは非常によくあるため
2:11
もはや当たり前のように感じられますバグを一つ潰すたびに達成感があるため表面上は前進しているように見えます
2:15
しかし実際には同じ場所をぐるぐると回っているだけですコードを書くコンパイルするエラーが出る修正する繰り返すこのループです
2:21
因果関係を追いかけるだけで何時間も失われその結果得られるのは有意義な進歩ではなくバータリ的な対応にすぎません
2:26
このループにはまって午後を丸ごと無駄にしてしまった経験がある方はどれくらいいらっしゃいますか一言コメントをどうぞ
2:31
上位の変身には目を通しますこのサイクルが疲弊を招くのは周囲のツールは進化し続けているのにパターンが変わらないからです
2:37
エディタは新機能を追加しフレームワークは進化し統合は深まっていますがデバッグは依然として受動的なアプローチを強いています
2:43
それは燃え広がる火をバケツ一杯の水で食い止めようとするようなものです発生した火種はその場しのぎで対応されますがそれを引き起こした根本的な条件は残ったままであり
2:51
次の火災をほぼ確実に招きますそしてタブを切り替えるたびに隠れたコストが積み上がっていきますサービスクラスから設定ファイルへそして依存関係グラフへと飛び回ります
2:59
切り替えるたびに思考の糸は途切れその都度メンタルをリセットしなければなりません単にウィンドウの切り替えに数秒かかるだけでなく何度もコンテキストを再構築する精神的負担がのしかかるのです
3:09
1日を通すとそうした小さなリセットが積み重なって大きな負担となりますここの開発者にとってその疲労はフラストレーションと時間の浪費として現れます
3:16
エンタープライズプロジェクトに取り組むチームにとってはその影響はさらに増幅されますデバッグのループはスプリントの目標を起動から外し機能のリリースを遅らせ解消よりも蓄積が早いバックログを生み出します
3:26
技術的負債の増大も火消しに費やされる時間の副作用にすぎません多くのチームが開発時間の大部分を受動的なデバッグに吸い取られていると報告しています
3:35
これはエンジニアリングの醍醐味ではありません同じ依存関係の不一致を5度も追うような計画を立てる人はいません
3:41
それにも関わらず週ごとにリソースの多くがそこに割かれていますエラー修正が進捗と定義されてしまうと新機能の開発は二の次となり裏側でアーキテクチャは静かに
3:50
疲弊していきます受け入れがたい真実ですが継ぎはぎだらけのデバッグは単に作業を遅らせるだけではありません
3:55
設計ではなく反応の文化を助長してしまうのですあなたはシステムを構築しているのではなくただ火を消すことに時間を費やしています
4:02
それは短期的には製品を維持できるかもしれませんがチームのスケールと確信を持ったリリース能力を制限してしまいます
4:07
では火消しというイメージで一度立ち止まってみましょう火元へ駆けつけ水をかけ次へ進む問題は開発者がそれが下手なことではありません
4:14
彼らは十分に優秀です問題は炎がいつまでも消えないことです炎は場所を変え新しいファイルやプロジェクト設定で燃え上がり全員を創造モードではなく対応モードに
4:24
縛り付けますそこで疑問が生じますこのサイクルをあなた一人で背負う必要がなかったとしたらどうでしょうか
4:29
もし追跡切り替え修正といった繰り返しの作業を別の方法で管理しあなたは構築だけに集中できるとしたら火消しの負担は明らかですがまだ触れていない別の圧力の点が存在するからです
4:41
プロジェクトが単一のファイルやモジュールではないとき本当の重圧がかかります修正すべき箇所が複数のレイヤーにまたがるときこそそれが起こります
4:48
ロジックが異なるプロジェクトサービスライブラリ全体に散らばっているソリューションを開くところを想像してみてください必要なパーツが同時に3箇所に存在し
4:57
それを頭の中で整理するだけでも一苦労ですマルチファイルの混沌と ai によるコンテキスト制御
5:03
プロジェクトが複数のレイヤーにまたがる場合真の課題はコードを書くことではありません
5:08
すべての稼働パーツを統合し続けることですここにマルチファイルの混沌と ai 主導のコンテキスト制御との間の緊張関係が最も明確に現れます
5:15
10以上のプロジェクトを含む大規模な.netソリューションを例に挙げましょう新しい機能は通常複数のレイヤーに同時に影響を与えます
5:22
コントローラーが1箇所サービスが別の場所そして設定ファイル群がまた別の場所に存在します
5:27
コードを一興書く前に参照をたどり依存関係を確認することに時間を費やします小さな変更が連鎖的に予期せぬ破壊を引き起こさないことを願いながら
5:35
そのワークフローは例外ではありませんエンタープライズアプリケーションでは普通のことです
5:39
特にアジュールサービスや統合が関わってくると顕著になりますこうしたシステムの構造はフラットではありません
5:45
インターフェース依存関係の注入マッピングプロジェクト間の参照がすべて役割を果たしています
5:50
アジュールが混ざると関数アプリサービスバスのバインディングリソース設定ストレージ接続などソリューションホルダーの外側にある依存関係も現れます
5:58
IDE内のコードディスク上の設定ファイルそしてクラウドで定義されたサービスの間で調整を行う必要があります
6:03
それらはどれもあなたがクリック数を減らしたいことなど考慮してくれませんコンテキストを切り替えるたびに全体像を再構築するためにエネルギーを消費します
6:10
私たちのほとんどはそのコンテキストをワーキングメモリの中でやりくりしようとします最初はうまくいきますがプロジェクトが成長するにつれてミスが入り込みます
6:16
サービスに新しいメソッドを追加してもDI登録を忘れてしまうのです
6:19
アジュール関数をコーディングしたもののホスト jsonやデプロイテンプレートへのバインディング追加を忘れていたことに後で気づくといった具合です
6:25
実行時まで何も通知されずビルドではなくデバッグに追われることになりますコード自体は難しい部分ではありません難しいのはファイル間での調整ですコントローラーからサービス
6:34
モデル設定ファイルへとタブを行き来し結局なぜそのファイルを開いたのか忘れてしまうあの感覚は誰もが知っているはずです
6:41
それは1日に何度も繰り返される小さな中断ですそれらのやりとりが積み重なり実際の進捗を遅らせる摩擦を生み出します
6:48
結果として配信が遅れますそれは書くのが遅いからではなくすべてを同期させることが集中力を奪うからです
6:54
このオーバーヘッドはクラウドファーストのプロジェクトでより増大しますアジュールは重要な設定をローカル構成ファイル環境変数
7:01
アームバイセップテンプレート ci cd パイプラインなど複数の場所に分散させます一見単純な機能リクエストに見えるものでも多くの場合4つの抽象化レイヤーにまたがっています
7:11
この複雑さは避けられませんエコシステムの仕組みそのものに組み込まれているからですそこで大きな転換点となり得るのがエージェントモードです
7:18
すべてを自分で調整するのではなく複数のファイルにまたがる広範なコンテキストを保持できるように設計されていますつまりあるレイヤーに変更を求めても他のレイヤーがおざなりになることはありません
7:27
でもでは新しいアジュールファンクションを作成しエージェントがどのようにメソッド本体の生成バインディング構成の作成ホストの更新を支援するかをお見せします
7:34
ジェイソンの更新や適切なDI登録の提案まで行います通常これは複数のファイルにまたがる複雑なプロセスです
7:41
エージェントならそれを一つのフローに効率化できますこれは皆さんの判断に変わるものではなく繰り返しの事務作業を取り除き設計の本質的な選択に集中できるようにするためのものです
7:50
人間は頭の中やホワイトボードに大まかな概要を書くことができます AIはファイル単位で詳細を追跡し筋道を見失うことがありません
7:58
私たちにとって大きな認知的負荷となる作業もエージェントにとっては基本的なコンテキストにすぎません実際の違いはタブを行き来する断片的な作業から同期を持った計画的な変更へと移行できる点にあります
8:07
デモ中にエージェントが作成したプルリクエストや差分を表示しどのような編集が行われたかを正確にご確認いただきますその可視性が重要なのです
8:14
皆さんはレビューと承認の全権を維持したまま複数のファイルを更新する面倒な作業を代行させることができますつまり午後の時間を断片的なコードの継ぎ剥ぎに費やす代わりに一度変更を指示し
8:23
生成された更新を確認してより高次元な設計へと移行できるのですその恩恵はクリック数やキー入力の削減だけでなく多数のファイルの関連性をたどるのではなく
8:31
本質的な問題解決に集中できる点にありますこの利点が最も明確になるのはシステムが壊れた時です
8:37
コンテキスト処理が強力であってもシステム障害や設定のズレ参照の不一致は再び発生し得るからですそこで次のテストが始まります
8:43
エラーが表面化した際にそれをどのように追跡し解決するかという点ですエラー探しから自律的な修正へ単一のファイルを指し示すエラーメッセージにどれほど頻繁に遭
8:52
するか考えてみてくださいスタックトレースに従って指定されたメソッドを修正しリビルドを実行します
8:58
それが明白な解決策に思えますがすぐに少し形を変えた同じエラーが再発しますそこで初めてスタックトレースが示していたのは症状に過ぎなかったと気づくのです
9:06
真の問題は全く別の場所にありサポートクラスの中や1週間開いてもいなかった設定ファイルに隠れているかもしれません
9:11
すべての開発者がこのようなミスリードを経験したことがあるはずです問題だと思える場所が必ずしも修正すべき箇所とは限りません
9:16
これは時間を大きく浪費します一つ調整してリビルドし待機するすると新たなエラーが発生し別のファイル別の修正またリビルドへと続きます
9:25
動いてタイピングして再コンパイルしているため生産的に見えますが実際には本質的な解決ではなく試行錯誤を繰り返しているだけです
9:32
そのサイクルは時間を奪うだけで表面的な修正はできても本来の機能開発は一向に進みませんここで失われているのは本来得られたはずの成果です
9:41
リビルドと再試行に追われている間ビジネス上の課題解決もユーザーが待望する機能の提供も止まったままになります
9:47
前進する力は設計ではなく当て水量へと消えていきますその瞬間は活動しているように感じますが結局のところシステムを壊さないための対応に追われているにすぎません
9:56
チーム全体で見ればこうした表面的な作業がすべてを停滞させ機能のバックログが溜まり続けてしまいますここでエージェントワークフローという考え方が重要になります
10:05
スタックトレースが示すたった一向で止まるのではなくその先を見据えるのです
10:08
システム全体の文脈を理解しそのファイルが何をすべきかだけでなく一貫性を保つためにどの連鎖的な修正が必要かを判断します
10:17
実際には複数のファイルにまたがる編集案が提示されることもあるでしょう例えばメソッドに変更が必要な場合関連する設定ファイルやデプロイテンプレートの修正も合わせて提案してくれます
10:28
自分で探し回る必要はありませんこれこそが単なるオートコンプリートから一歩踏み出した進化です
10:33
オートコンプリート破業を保管しますがエージェントはファイル間を調整しますエラーが複数の箇所に散らばっているときにこそこの調整能力がいきます
10:40
azureの一般的なシナリオを例に挙げましょう新しい関数アプリを作成しデプロイしたところ
10:44
バインディングとメソッドのシグネチャが一致せず旧のトリガーが失敗するというケースです
10:48
通常ならログを掘り下げどのバインディングが間違っているかを特定し手動で関数ジェイソンを調整し
10:54
インフラテンプレートの不一致まで修正しなければなりません全てのステップが個別の追跡作業となり修正の度にテストを繰り返すことになります
11:01
エージェントモードを使えばワークフローは一変しますコード修正の提案に加え適切な関数ジェイソンバインディングを生成し
11:07
デプロイスクリプトの不一致があればそれも修正してくれますあとは確認して承認するだけ各層をつなぎ合わせるために何時間も
11:13
費やす必要はありませんここで重要なのは信頼です自分の知らないところで勝手にコードが書き換わるような不安を感じさせてはいけません
11:18
だからこそレビュープロセスが不可欠なのです今回のデモではその流れを一緒に見ていきましょう
11:22
エージェントが最適化された一連の変更を提案します差分を開いて生成されたコードを精査しユニットテストを実行しローカルでビルドを検証した上で
11:30
編集内容を適用するかどうかを判断しますその検証ループにより単純作業を排除しながらも完全にコントロールを維持できます
11:37
強調しておきたいのはエージェントは開発を加速させますが優れたエンジニアリングの習慣にとって変わるものではないということです
11:42
コードレビューやciは依然として不可欠な関門として扱うべきです ai に調査時間を短縮させる一方で自動チェックと人間によるレビューをセーフティネットとして
11:50
維持してくださいそのバランスこそが信頼の問題を解決しスピード向上が安定性を損なわないようにします
11:55
そのスピードの差は理論上の話ではありませんエラーの追跡と手作業での修正に半日かかるような作業も統合された提案があれば数分に短縮できます
12:03
そして取り戻した時間は本来注力したい作業に当てることができますユーザーが実感する機能の開発やコードベースを改善するアーキテクチャの設計などです
12:11
実行時のトラブル対応に追われるのではなく自信を持って前もって設計できるようになりますつまりデバッグのループに1日を支配される必要はなくなるのです
12:18
エージェントがファイル間を横断する更新を提案することで手探りの検索からレビューと承認を行うリズムへとシフトしますエラーを堂々巡りするのではなくデバッグをワークフローにおける構造化されたほぼ自動化されたステップとして扱うようになります
12:30
そのシフトにより知的リソースと時間を確保し単なる欠陥修正ではなく機能構築に集中できるようになりますまたエラー修正が単なる症状の追跡ではなくなればより大きな可能性への扉が開かれます
12:39
機能全体を同じ構造化された方法で開始する方法についてです統合された修正を提案するのと同じワークフローが平易な言葉による使用書を受け取りそれを機に機能する構造を構築できるとしたらどうでしょうか
12:50
そこから開発の次のステージが始まりますオーバーヘッドのない使用駆動型開発です
12:55
最も興味深い変化の一つはファイルやメソッドのことばかりを考えるのをやめ平易な言葉で作業を組み立てるようになることです
13:02
そこで登場するのがオーバーヘッドのない使用駆動型開発です簡単な機能リクエストを書くところを想像してみてください
13:08
月次サマリーを生成し保存し管理ページから利用できるようにするレポート作成ワークフローを追加するといった内容です
13:14
単に断片的な行動を受け取るのではなくアプリ全体にマップされた動作する構造が返ってきますコントローラーのスタブが作成されモデルが生成されサービスが登録され設定が
13:24
紐づけられます糸を記述してからプロジェクト内に具体的な骨組みが出現するまでの流れこそがこのアプローチを理論だけでなく実践的なものにしています
13:31
従来の設定において使用先行型の開発は重苦しいという評価があります大企業では通常長大な要件定義書や何ページにも渡る設計書硬直的な図表を意味し全体のペースを遅らせて
13:41
しまいます規制の厳しい業界や世界中に分散したチームでは意味がありますが日々のコーディングにおいて多くの開発者はそれらを省略しています
13:47
詳細な使用書の作成と維持にはコストがかかりそれに耐えられる忍耐も時間も誰にもありません機能のリリースに加えて余分な作業が発生し締め切りが迫ると通常そうした予備的な作業は削られて
13:57
しまいます皮肉なことに開発者は本来もっと対極的に考えることを好むものです
14:01
あらかじめ構造を把握しておくことは安心感につながります問題なのは意図ではなく維持管理のコストです一度使用書が現実と食い違い始めるとそのメンテナンスは主にとなります
14:10
そのため厳密な計画を掲げている現場でさえ現実の仕事の多くは完全な設計よりもその場しのぎに流れてしまうのですエージェントワークフローはその代替案となります
14:20
完璧な設計ドキュメントを求める代わりに平易な言葉で書かれた仕様を改良可能なスケルトンに変換する手助けをしてくれます
14:26
umlsや手書きのインターフェースマップは不要です新しい api エンドポイントを持つレポートモジュールを作成し
14:32
ストレージにリンクしてロールベースアクセスで保護すると伝えるだけでシステムが.net ソリューション全体のベースラインを生成します
14:40
デモでは平易な言葉で書かれた仕様を読み上げエージェントが作成したコントローラーモデルサービス登録のファイルを示し
14:47
手動での調整が必要だった箇所を指摘しますそうすればあなた自身で品質を判断できるはずです
14:53
これは2つの開発スタイルの中間点を作り出すものです一方にはバイブコーディング感覚的なコーディングがあります
14:58
高速で自由ですが長期的なシステムには脆いものですもう一方には使用駆動型設計があります
15:03
信頼性は高いですが非常に時間がかかりますエージェントのサポートがあれば自然言語でアイデアを解説するだけでスケルトンが現れ
15:09
構造化された利点を保ちつつバイブコーディングとほぼ同じ速さで反復開発が可能です先ほどのレポート作成のワークフローを例に挙げましょう
15:16
通常ならモデルを作成しデータサービスを構築しコントローラーを配線しセキュリティを設定し起動時にすべてを接続しなければなりません
15:23
つまり複数のファイルを行き来しながら一貫性が保たれていることを願うことになりますこのアプローチならスケルトンが一気に配置されます
15:29
真の効率化はタイピングの量を減らすことよりも新しいサービスを構築したのに登録を忘れるといったファイル間でのミスを防ぐことにあります
15:36
もちろんスタイルの問題は常にあります ai は提携行動を押し付けたり監修を上書きしたりしないでしょうか
15:42
実際にはエージェントは既存のプロジェクトのパターンを反映して提案することが多いのです
15:46
デモではその両面をご覧に入れます開発チームのコントローラー構造と完全に一致した箇所と ai の推測が少しずれてしまった箇所があります
15:53
その混在が重要なのですどこを信頼しどこを調整すべきかがわかるようになります
15:58
最終結果は型通りのコードではありません手作業のスケルトン作成が減るだけで完成したコードは依然としてあなたのプロジェクトそのものです
16:04
スピードを維持しながら将来の拡張に向けて洗練可能な基盤に依存し続けることができます
16:09
使用策定作業は図表作成に根気のあるアーキテクトだけのものではなくなり秩序を犠牲にすることなく素早く試行錯誤したい全ての開発者にとってのツールとなります
16:17
これが日常のフローの一部になると使用策定は堅苦しい企業向けのプロセスではなくより軽量なショートハンドのように感じられるようになります
16:24
意図を記述すればシステムが基盤を構築し自分は細部の調整に専念できるようになります
16:29
より大きなインパクトは生成されるコードそのものだけでなく毎週積み重なる時間短縮から生まれます
16:35
機能開発に割く時間が増えセットアップの苦労が減りますそこですべての開発者が最も気にかける疑問に直面します
16:41
これらの変化が生産性の面で具体的にどれほどの成果につながるのかという点です生産性という対価重要なのはここぞという時に数分節約できるかどうかではなく
16:50
そうした小さな変化が週単位でどれほど意味のある時間に積み重なるかということですこれこそが生産性という対価です
16:56
コンテキストスイッチ繰り返されるビルドサイクル手作業での修正など普段は気づかないうちに失われている時間を取り戻すのです
17:02
多くの開発者はそうした小さな損失を仕事の一部として受け入れています設定値の確認に10分参照ミスによる再実行25分あるいは接続確認のためにファイル感を行き来するなどです
17:11
ここで見れば些細なことに思えますしかしスプリント全体で合算すれば実際にどれだけの価値を提供できるかを左右します
17:18
日常のルーチンに見えるものが実は脳機を遅らせる大きな足枷となっているのです隠れた主にはコンパイル時間やタイピング速度ではありません
17:25
集中力を削ぐ止めては動かすというリズムにありますファイルから別のファイルへ移るたびに脳はリセットされますそのリセットには代償が伴います
17:32
反復的な修正をエージェントに任せることでその負担は軽減されますコンテキストを絶えず再構築する代わりにより重要な設計上の問題解決に集中力を使えるようになります
17:41
多くのチームはこれらの微細なコストを追跡していませんジラチケットやギット履歴には現れないからです
17:46
成果につながらない作業は記録されませんがそれでも確実にエネルギーを消耗しますコードベースが拡大するにつれこの摩擦は単なる線形以上の増加を見せます
17:53
レイヤーが増えれば記憶しておくべき依存関係も増え先に進む前に構造を整えるだけで時間を浪費する機会も増えます
17:59
エージェントワークフローはこうした時間浪費の要因に直接働きかけることで計算式を書き換えます単にメソッドのスタブを早く埋めるだけではありません
18:05
午後を食いつぶすような検索修正再実行のループを減らしてくれるのですエージェントワークフローを利用しているチームからは多くの場合問題解決までの時間が短縮されたと報告されています
18:14
この動画ではインパクトを判断いただけるようビフォーアフターのタスクを一つ実演します同じアジュール機能を実装するのにかかる時間を手作業の場合とエージェントを使う場合で記録し
18:23
生産性の向上を具体的に見ていただけるようにしますビジネスの観点から見るとその価値はプロジェクトのスピードに現れます
18:29
サイクルの短縮は単に開発者の満足度だけの問題ではありません今回のリリースで機能を実装するか数四半期先送りするかの分かれ道となります
18:35
ハックやリグレッションがバックログに残りにくくなるため技術的不採にも影響しますフローが円滑になれば前のスプリントの修正作業に戻ることなくチームは着実に前進できます
18:44
その一貫性が積み重なることでトラブル対応が減り長期的にはより強固なデリバリーが可能になりますそこには人間的な要素も存在します
18:50
エラーの追跡に1日を費やせばどんなエンジニアでも疲れ果ててしまいます疲労が溜まると洗練された設計は難しくなり細部を見落としミスが入り込みます
18:57
機械的な修正をエージェントに任せることで開発者はより長く集中力を維持できますその余裕が生産性と品質の両方を向上させます
19:05
繰り返される摩擦にすり減らされることがなければ広い視野で考えより効果的に計画を立てられます実際の違いはこのように現れます複数のバインディングやサービス統合を含む
19:15
新しいアジュール関数は自力では丸2日かかるかもしれません設定やテスト不整合な参照の修正など作業は長引く一方です
19:23
エージェントの助けを借りれば同じ関数を半日で作成できます手抜きをするからではなくファイル間の設定や調整が初回で正確に決まるからです
19:32
やり直しや無駄な労力が省かれスケジュールが短縮されます一部の開発者は最もな懸念を口にします
19:38
ai に保守を頼ることで自分自身のスキルが鈍るのではないかとその視点は何が実際に変化しているのかを見落としています
19:44
反復的な設定を肩代わりさせることは専門性を弱めるのではなく判断力が生きる設計やアーキテクチャのために温存させるのです
19:50
実際には軌道修正にエネルギーを浪費する代わりにより高度な問題解決に取り組む余地が生まれます試してみた方はスプリントで何時間取り戻せたかコメントで教えてください
19:58
興味深い回答は今後の動画で取り上げさせていただきます他チームの体験を聞くことでデモや例を超えた真の価値を誰もが理解できるようになります
20:06
ただし注意点として自動化は役立ちますが安全性は依然として重要ですエージェントが作成した変更は必ずテストを実行しコードレビューを行ってください
20:14
煩雑な作業が減ることは信頼しつつもこれまで通りのガードレールは維持しましょうスピードの差が利益を生むのは品質が一定に保たれている場合だけです
20:21
強力なテストと賢明な pr レビューが壊れやすい自動化からリリースパイプラインを守ります真の成果はコードを早く書くことではなくより優れたソリューションを生み出すためのスペースを確保することに
20:31
あります疲労を減らしより少ない