この記事は カオナビ Advent Calendar 2025 5日目です。 こんにちは。 今日はコードを信じるべきか疑うべきなのかについてジュニアエンジニアなりに言語化し開発中に意識していることを記事にしました。 背景 ある日、先輩とのモブプロ中に既存コードの調査をしていると、こう言われました。 「コードは疑いながら読んだほうがいいよ」 しかしその数分後、別の箇所を読んでいると、 「そこはコードを信じて読んだほうがいいよ」 と言われました。 (……結局、疑うのか信じるのかどっちなんだ?) その時は混乱しましたが、数週間コードと向き合う中で、ある仮説に辿り着きました。 疑うか信じるかの切り替えは、「時と場合」や「勘」といった曖昧なものではなく、 「読む目的」によって明確に使い分ける必要がある説。 結論 コードを信じるか疑うかは、「知る」ことを目的とするか、「書く・検証する」ことを目的とする
初めまして、kagayaです。AIネイティブなプロダクト開発を頑張っています。 共訳した「AIエンジニアリング(オライリー・ジャパン)」が11/28に発売です。よろしくお願いいたします。 世はAIコーディングエージェント時代。 圧倒的に手数は多くなり、自動でPRを生成する取り組みも見かけるようになりました。 かくいう私も、Claude Code Actionを夜間に動かしてGitHub Issueを自動解決する実験をし、朝に作成されているPRを眺めて、「これが不労コード生活か」と思うなどしていました。 そんな中で、新しく生まれた悩みの一つは、このコード、どこまでレビューすればいいんだ? です。 全部読んでたら、自分で書いた方が早くない?でも全部信じるのも怖い。 バイブに身を任せた結果として生まれた数千行のPRを前に、途方に暮れた経験がある人もいるのではないでしょうか。 Thoughtwo

# Sample AGENTS.md file ## Dev environment tips - Use `pnpm dlx turbo run where <project_name>` to jump to a package instead of scanning with `ls`. - Run `pnpm install --filter <project_name>` to add the package to your workspace so Vite, ESLint, andTypeScript can seeit. - Use `pnpmcreate vite@latest <project_name> -- --templatereact-ts` to spin up a newReact + Vite package withTypeScript ch
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 表明しておかないと、自分が最新技術を毛嫌いしてるだけの人と思われるかもと思ったので、いったん自分の考えを吐き出しておく。 自分は、情報を評価・抽出する系の作業 (文章を要約するとか、コードをレビューするとか) をAI にやらせるのはあまり抵抗感がなくて、趣味開発でも Copilot や CodeRabbit によるコードレビューのお世話になっている。 一方で、情報を押し広げる系の作業をAI にやらせると成果物の正確性や保守性に対する信頼性が全然足りない。「適当に書き殴らせてうまくいかなかったら全部捨てればいい」「コードの良し悪しは気

最近、SNSを眺めていたり、オンライン・オフライン問わず交流をするような機会で、多くの人がAIの登場をポジティブに受け止めている声を聞く。「開発速度が格段に上がった」「今まで以上にたくさんのものが作れるようになった」「プログラミングがより楽しくなった」。確かにそれは素晴らしいことだと思う。でも、その一方で、なんとなくモヤモヤした気持ちを抱えている自分がいる。 私がソフトウェアエンジニアとして一番達成感を感じるのは、複雑な問題を解決できた時だ。OSSの難しいissueかもしれないし、本番環境で突然発生した謎のエラーかもしれないし、パフォーマンスが劣化した原因を突き止めることかもしれない。なぜこの問題が起きるのか、どこに原因があるのか、仮説を立てて検証を重ねて、ついに問題の本質を突き止めた時の興奮。そして、既存のコードと調和する美しい解決策を思いついた時の満足感。私にとって、プログラミングはパ

パトリック・ミッケンジー(Patrick McKenzie)さんのブログ・エントリ、 “Falsehoods Programmers Believe About Names” の日本語訳です。翻訳の公開を快諾してくださったミッケンジーさんに感謝します。 公開: 2012-02-22 Posted on June 17, 2010 by Patrick きょう、ジョン・グレアム゠カミング(John Graham-Cumming)が、正しくない文字が含まれているといって彼のラスト・ネームを受け付けないコンピュータ・システムへの不満の記事を書いていた。もちろん彼の名前に「正しくない」ところなどない。当人の申し出たものが当人を識別するものとしては相応しいのであって、定義からして名前とはそういうものである。このことにジョンは当然ながらいらだったし、そうなるのもきわめて正当なことだ。定義からすれば事実
業務でDevinを利用してすごく気に入ったので、個人用途でも使いたくなりました。 ただ個人支出で$500/月は正直無理なので、OSSのOpenHands(旧OpenDevin)に目をつけました。 しかしながらSonnet 3.7(3.5)で使った結果、逆に「実は本家Devinって安いんじゃないか?」となったのでやったことと所感を書いておきます。 OpenHandsについて OpenHandsは、エンジニアリングタスクを支援するオープンソースのAIエージェントです。Devinのオープンソース実装として知られており(以前はOpenDevinという名称でした)、様々な開発作業をサポートしてくれます。 特に新規プロジェクトの立ち上げや、既存コードベースへの機能追加、リファクタリングなどできるとしており、例えば、新しいReactコンポーネントの作成や、GitHubアクションの追加、バグ修正など、幅広

1週間、人力でのコーディングを禁止してみた──AIスタートアップ企業のエクスプラザ(東京都港区)は3月上旬、こんな実験を実施した。大胆な取り組みだが、その結果は「通常時の仕事の成果から半減した」と同社の松本和高CTOは話す。では実験は失敗だったかというと、そうではなく「成功だった」と答える。それはなぜか。 この実験のルールは主に2つで「期間中のコードは全部AIに書かせる」「基本的に例外なし(緊急対応時は除く)」というもの。AIが出力したコードの修正も原則禁止で、デバッグ用の簡単なコードを書くのも認めない。しかし、どうしても手入力をしたい場合は、社内Slack内に設けた「懺悔チャンネル」で何がダメだったか書き込むことで、人力での入力を“こっそり許可”するなど逃げ道も用意した。 参加者は同社所属の3人のエンジニアで、エディターは指定せず「Cursor」「Windsurf」「Visual Stu

モチベーション(100%人間) CursorやClineなどで.rulesを作成することが増えましたが 明確に何を作成すべきで何をすべきでないかはユーザー側の判断に委ねられていることが多いと感じています。 そこに対してそもそもの「作成することによる心理的バイアス」の有無や 「サービス側のPromptの考慮」の有無などについて明確に述べてみようかなと思いました。 以下AIと作った記事です。 はじめにAIサービスが普及するにつれて、Custom Instructions(カスタム指示)やRulesといった「AIの挙動をカスタマイズする機能」が多くのプラットフォームで提供されるようになりました。一見すると便利に思えるこれらの機能ですが、その実際の効果と、私たちがそれを評価する際の心理的バイアスについては、十分な議論がなされていません。本記事では、PKM(Policy-Knowledge-Me

Join the O'Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful. Learn more Betty Jean Jennings and Frances Bilas (right) program the ENIAC in 1946. Via the Computer History Museum Eventually, interpreted languages, which are much easier to debug, became the norm. BASIC, one of the first of these to hit the big time, was at first s

2025/03/27追記 Cursor側のアップデートが1ヶ月で進んでいるので、以下追記しました。本記事の内容を踏まえたあとに読むとよいかと思います! はじめに こんにちは。Builtoという会社で代表 &エンジニアをしている冨田です。タスク管理をAIがサポートする「サポットさん」など、AIプロダクトを作っています! 「サポットさん」の概要はこちらから: https://lp.sapot-san.com/ 開発にもAIをフル活用しており、そこで得られた知見を共有したいと思います。 具体的には、経験3年以上の現役ソフトウェアエンジニア(生成AIのない時代からコードを書いてきた方々)をターゲットに、本番運用レベルの大規模コードベースでもCursorを活用しコーディング時間を 1/3〜1/5 に縮めている手法をお伝えします。 仕様策定やアプリの機能にもLLMをフル活用していますが、今回は実

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Tidy First? Kent Beckさんの本「Tidy First? -個人で実践する経験主義的ソフトウェア設計」の日本語訳版が出たので読んで色々と感想を交えながら整理してみました。 翻訳版が2024/12/25に販売された いつどこでコードを改善・整頓すれば良いのかを記述した本 3部作の1作目で、本作は"個人"に焦点を当てている 内容整理目的でいくつか気になったポイントを抜粋しつつ、自分で咀嚼し言い換えたり、感想・意見を交えて整理しています。きちん正しく理解するためには本書をぜひ一読することをオススメします。 Tidy Firs

「多重下請け構造は悪い」、これは世間的にだいぶ浸透してきた考えだと思います。しかし、プログラマは 多重下請けのコードを気づかぬうちに書いてしまうことが多々あります。 なんなら皆さんもついウッカリやってしまっているでしょう。 当然ながらコードベースでも多重下請けは良くありません。今回の記事では、多重下請けコードとは何か、その問題点、回避方法を解説します。 多重下請け構造になってるコードとは? 多重下請け構造になってるコードとは、タスクをたらい回しにしているコードです。 たとえばECサイトで注文するシーンを考えてみます。サーバーの実装はこんな感じです。 def 注文API(): 注文処理(price) 集計DBにログを送る() def 注文処理(price): 決済する(price) 履歴に保存する() def 決済する(price): if キャンペーン期間中だったら: 支払う(price

現時点のAI コーディングの実力を測るために、自分はプロンプトのみ、直接コードを書くのは禁止で Roo Code による VS Code によるエディタ操作のみでコードを書かせた。その感想 (急いで書いたのでいろいろと雑です) tl;dr 良し悪しはともかく、人類は確実にAIによる自動操縦型のプログラミング体験に依存するという確信を持った。 ただ、その基盤である CLINE(系)自体のツールとしての完成度はいまいち。 CLINE以外の、各モデルのコーディング性能も、現時点では物足りない。 CLINE とは何か(知らない人向け) いろいろと機能はあるが、コア機能としてはヘッドフルなvscode runner で、AI にコードを書かせるために必要な情報を受け渡しするインターフェースを持っている。ファイルの読み書きや、コマンドを実行結果をプロンプトにしてAIに渡す。puppeteer によ

Jan 18, 2025 背景 日頃長いコマンドを打つことが多く、 fish のコマンド履歴に頼り切りになっています。何度も履歴を遡ると、それなりの手間です。 $ # テスト実行 $ cabal test --enable-options $ # 特定のテスト実行 $ cabal test --enable-options --test-options '-p /SegTree/' $ # doctest の実行 $ cabal repl --with-ghc=doctest --repl-options='-w -Wdefault' $ # などなど ここではタスクランナーを導入し、より簡単にコマンドを打てるようにします。 タスクランナー haskell-jp の皆様の動向を伺いつつ、幾つかのタスクランナーを試してみました。 bash 無意識に選択肢から外していましたが、凄腕の方も ba
Let's startprogramming fun! - たのしくプログラミングをはじめよう!

ソフトウェア開発の現場では、AIを活用した開発支援ツールへの注目が年々高まっています。 (たぶん)1年ほど前はCursorを使っているエンジニアも今ほどは少なく、OpenAI DevDayでデモを行なったOpenAIのエンジニアがCursorをエディタとして利用していたことが話題になったのを覚えています。 そして、2024年12月についにリリースされた「Devin」は、AIチームメイトの名の通り、まるでチームの一員として自律的に動く点が特徴とされています。 https://devin.ai/ 弊社も検証のためにDevinをトライアルしていますが、新人エンジニアを育成するように少しずつタスクを与え、フィードバックを繰り返していくうちに、Devinがどんどん機能してくれるようになる――そんな“育成ゲーム”のような手応えを感じています。本記事では、月500ドルという導入コストを見合う形で活用す

はじめに ソフトウェア開発において、リファクタリング、つまりコードの保守性を高める活動は、ソフトウェアの価値を高める上でとても大切ですよね。 しかし、「リファクタリングの時間が確保できない」「リファクタリング実施のための同意が得られない」という話を耳にすることがあります。 リファクタリングは「絶対やった方がいいのは感覚としてはわかっている、でもその必要性ををうまく伝えられない」となりがちな性質があるのです。 この記事では、リファクタリングの時間を確保するために、どんなことを考え、何をステークホルダーに伝え、具体的にどのようなタイミングで実施していくといいのか、について解説します。 ポイントまとめ リファクタリング時間確保のポイントを端的に説明すると、以下の通りになります。 リターンとコストを明らかにする 複数の実施パターンを選択肢として持ち、柔軟に選べるようにする。 その中でも、日頃の小さ

リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く