Movatterモバイル変換


[0]ホーム

URL:


はてなブックマークアプリ

サクサク読めて、
アプリ限定の機能も多数!

アプリで開く

はてなブックマーク

タグ

関連タグで絞り込む (208)

タグの絞り込みを解除

プログラミングに関するigrepのブックマーク (320)

  • コードリーディングは「信じるアクセル」と「疑うブレーキ」で9割速くなる - Qiita

    この記事は カオナビ Advent Calendar 2025 5日目です。 こんにちは。 今日はコードを信じるべきか疑うべきなのかについてジュニアエンジニアなりに言語化し開発中に意識していることを記事にしました。 背景 ある日、先輩とのモブプロ中に既存コードの調査をしていると、こう言われました。 「コードは疑いながら読んだほうがいいよ」 しかしその数分後、別の箇所を読んでいると、 「そこはコードを信じて読んだほうがいいよ」 と言われました。 (……結局、疑うのか信じるのかどっちなんだ?) その時は混乱しましたが、数週間コードと向き合う中で、ある仮説に辿り着きました。 疑うか信じるかの切り替えは、「時と場合」や「勘」といった曖昧なものではなく、 「読む目的」によって明確に使い分ける必要がある説。 結論 コードを信じるか疑うかは、「知る」ことを目的とするか、「書く・検証する」ことを目的とする

    • そのAI生成コード、全部レビューしますか?全部信じますか?

      初めまして、kagayaです。AIネイティブなプロダクト開発を頑張っています。 共訳した「AIエンジニアリング(オライリー・ジャパン)」が11/28に発売です。よろしくお願いいたします。 世はAIコーディングエージェント時代。 圧倒的に手数は多くなり、自動でPRを生成する取り組みも見かけるようになりました。 かくいう私も、Claude Code Actionを夜間に動かしてGitHub Issueを自動解決する実験をし、朝に作成されているPRを眺めて、「これが不労コード生活か」と思うなどしていました。 そんな中で、新しく生まれた悩みの一つは、このコード、どこまでレビューすればいいんだ? です。 全部読んでたら、自分で書いた方が早くない?でも全部信じるのも怖い。 バイブに身を任せた結果として生まれた数千行のPRを前に、途方に暮れた経験がある人もいるのではないでしょうか。 Thoughtwo

      そのAI生成コード、全部レビューしますか?全部信じますか?
      • GitHub - openai/agents.md: AGENTS.md — a simple, open format for guiding coding agents

        # 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

        GitHub - openai/agents.md: AGENTS.md — a simple, open format for guiding coding agents
        • 私がバイブコーディングにあまり興味がない理由 - Qiita

          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 にやらせると成果物の正確性や保守性に対する信頼性が全然足りない。「適当に書き殴らせてうまくいかなかったら全部捨てればいい」「コードの良し悪しは気

          私がバイブコーディングにあまり興味がない理由 - Qiita
          igrep
          igrep2025/08/20非公開
          バイブコーディングと言わないんだろうけど、自分も高度なマクロぐらいの使い方(なるべく具体例を出して何カ所も編集してもらう)しかしないし、既存のコードを編集する場合はそれくらいが丁度いいと思ってる
          • AIでプログラミングが「楽しくなった」人たちと、少し違和感を抱く自分|magurotuna

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

            AIでプログラミングが「楽しくなった」人たちと、少し違和感を抱く自分|magurotuna
            igrep
            igrep2025/06/23非公開
            自分の場合それに加えて手を動かす作業自体を好んでいる節があるから余計質が悪いんだよなぁ。
            • プログラマの抱いている名前についての誤謬

              パトリック・ミッケンジー(Patrick McKenzie)さんのブログ・エントリ、 “Falsehoods Programmers Believe About Names” の日語訳です。翻訳の公開を快諾してくださったミッケンジーさんに感謝します。 公開: 2012-02-22 Posted on June 17, 2010 by Patrick きょう、ジョン・グレアム゠カミング(John Graham-Cumming)が、正しくない文字が含まれているといって彼のラスト・ネームを受け付けないコンピュータ・システムへの不満の記事を書いていた。もちろん彼の名前に「正しくない」ところなどない。当人の申し出たものが当人を識別するものとしては相応しいのであって、定義からして名前とはそういうものである。このことにジョンは当然ながらいらだったし、そうなるのもきわめて正当なことだ。定義からすれば事実

              igrep
              igrep2025/05/06非公開
              「日本人の名前とか」などに色々集約されちゃってる。まあ元著者が全部知っているって話ではないからね
              • OpenHands(OpenDevin)を使った感想「本家Devinは安い」

                業務でDevinを利用してすごく気に入ったので、個人用途でも使いたくなりました。 ただ個人支出で$500/月は正直無理なので、OSSのOpenHands(旧OpenDevin)に目をつけました。 しかしながらSonnet 3.7(3.5)で使った結果、逆に「実は家Devinって安いんじゃないか?」となったのでやったことと所感を書いておきます。 OpenHandsについて OpenHandsは、エンジニアリングタスクを支援するオープンソースのAIエージェントです。Devinのオープンソース実装として知られており(以前はOpenDevinという名称でした)、様々な開発作業をサポートしてくれます。 特に新規プロジェクトの立ち上げや、既存コードベースへの機能追加、リファクタリングなどできるとしており、例えば、新しいReactコンポーネントの作成や、GitHubアクションの追加、バグ修正など、幅広

                OpenHands(OpenDevin)を使った感想「本家Devinは安い」
                • 1週間、人力コーディング禁止→結果は“成果半減” それでも「やってよかった」とCTOが言い切るワケ

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

                  1週間、人力コーディング禁止→結果は“成果半減” それでも「やってよかった」とCTOが言い切るワケ
                  • 【Cursor / Cline】ほにゃららRulesの功罪:独自のカスタム設定に関する心理的バイアスについて

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

                    【Cursor / Cline】ほにゃららRulesの功罪:独自のカスタム設定に関する心理的バイアスについて
                    • The End of Programming as We Know It

                      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

                      The End of Programming as We Know It
                      • 君たちはCursorを本当に使えているか

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

                        君たちはCursorを本当に使えているか
                        • 少年院で広がるプログラミング教育 「就職に有利」を超えたねらい:朝日新聞

                          非行をした少年たちに向き合い、社会復帰に向けた教育や支援をする少年院が、近年、プログラミング教育に力を入れている。「就職に有利な専門知識やスキルを身につける」ことを超えた、そのねらいとは――。

                          少年院で広がるプログラミング教育 「就職に有利」を超えたねらい:朝日新聞
                          • その汚いコード、いつどこで整頓するの?"Tidy First?"を読んで解決した話 - Qiita

                            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

                            その汚いコード、いつどこで整頓するの?"Tidy First?"を読んで解決した話 - Qiita
                            • 関数の多重下請けをやめよう。単一責任の原則と関数の"責任"について

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

                              関数の多重下請けをやめよう。単一責任の原則と関数の"責任"について
                              igrep
                              igrep2025/01/27非公開
                              結局必要十分で簡潔な名前を付けられるかだよなあ。
                              • 人間によるコーディング禁止の CLINE 縛りでゲームを作らせてみた感想

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

                                人間によるコーディング禁止の CLINE 縛りでゲームを作らせてみた感想
                                • お試しタスクランナー (make, just, shake, ..) - toybeam

                                  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

                                  igrep
                                  igrep2025/01/18非公開
                                  justなんて何が嬉しいんだよって思ってたけど、まあやっぱ簡単でハマりにくいのがいいのか。
                                    • 月500ドルから始まる“AIチームメイト”との開発生活 〜Devinとの理想の開発プロセスを求めて〜

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

                                      月500ドルから始まる“AIチームメイト”との開発生活 〜Devinとの理想の開発プロセスを求めて〜
                                      • GitHub - Aider-AI/aider: aider is AI pair programming in your terminal

                                        You signed in with another tab or window. Reload to refresh yoursession. You signed out in another tab or window. Reload to refresh yoursession. Youswitched accounts on another tab or window. Reload to refresh yoursession. Dismiss alert

                                        GitHub - Aider-AI/aider: aider is AI pair programming in your terminal
                                        • 「リファクタリングの時間」を確保する技術

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

                                          「リファクタリングの時間」を確保する技術

                                          お知らせ

                                          公式Twitter

                                          • @HatenaBookmark

                                            リリース、障害情報などのサービスのお知らせ

                                          • @hatebu

                                            最新の人気エントリーの配信

                                          処理を実行中です

                                          キーボードショートカット一覧

                                          j次のブックマーク

                                          k前のブックマーク

                                          lあとで読む

                                          eコメント一覧を開く

                                          oページを開く

                                          はてなブックマーク

                                          公式Twitter

                                          はてなのサービス

                                          • App Storeからダウンロード
                                          • Google Playで手に入れよう
                                          Copyright © 2005-2025Hatena. All Rights Reserved.
                                          設定を変更しましたx

                                          [8]ページ先頭

                                          ©2009-2025 Movatter.jp