LLM にコードを「差分」で書き換えさせるためのアイデア
既存の LLM コード生成の問題 LLM は行カウントやワードカウントが苦手。 例えば自分は SourceMap を扱うコードのテストを書かせようとしたが、モックデータの line:column がガバガバな位置を指してまともにテストにならない。行カウント/ワードカウントができないのはつまり diff がうまく生成できない。 これらの問題があって、コードを生成するパイプラインを組む場合、 全文出力が主流になっている。 ここで何が問題になるかというと、コードが膨らんで来た時に、(書き変える対象が一部だとしても)生成が顕著に遅くなる。うまく生成できなかった時にリトライを繰り返すと、問題がさらに悪化する。 改善手法の提案: 明示的な Line Number の付与 最近の LLM は入力ウィンドウがある程度大きくても、そこそこの速度で応答する。(お金はかかるが...) 問題は生成速度にある。特に
Python + VSCode の環境構築 20240604
作業メモ。モダン Python 速習。 AI 周りのツールを動かしていたら TypeScript だけでやるには無理が出てきたので、久しぶりに Python の環境構築をする。 具体的には TestGen LLM を動かしたい。 Python はたまに触るけど、基本 2.x 時代の知識しかない。 基本的にこの記事を読みながら、細かいアレンジをしている。 追記 rye が ruff と pytest を同梱してるので rye fmt, rye check, rye test で良かった uvicorn を叩くより、 fastapi-cli を使って起動したほうが良さそうので変更 基本方針: Rye に全部任せる 良く出来てると噂に聞いたので、 rye に任せる。 自分が Python が苦手な点は pip を下手に使うと環境が汚れていく点で、基本的に rye で閉じて管理させる。システムの
プログラマ視点での生成AIとの付き合い方
プログラミングについて、最近考えてることについてのポエム。 基本的に、 GPT-4 と Claude-3-Opus を使った経験を念頭に置いて話をする。機械学習エンジニアではないので、あくまで利用者に徹した視点での話。仕事で生成AIを使ったパイプラインを作ったりはしている。 生成AIの進化速度を予測しておく 今大事なことは、今AIがどの程度の性能かという定点の話ではなく、その進化の速度を認識すること。 コード生成というタスクにおいて、生成AIモデルを人間に当てはめると、こんな感じの人物像を自分は持っている。 GPT-4: プログラミング経験2年目の大学2年生 Claude-3-Opus: プログラミング経験3年目の大学3年生 ここでいうn年目は、業務経験ではなく、プログラミングの単位がある大学での、教育課程としての経験年数。今のひたすら学習量を増やす方式だと、単に1年に1年分ぐらい賢くなっ
previs: 面倒なマークアップは AI にやらせる
自分はフロントエンドのロジックを考えるのは得意なんですが、CSS は苦手です。 なので 自分は AI にコード変更を依頼して実行結果を目視でプレビューしつつ、その生成結果を受けいれるかどうかの判断だけすればよくね？と考えて、それを CLIとして実装してみました。 ボタンの色を書き換えるという簡単な例ですが、こんな感じで動きます。 主に React Component の修正をターゲットにしていますが、class(Name) を書き換えることを優先するプロンプトを与えているので、ロジックを保ちつつ、見た目を綺麗にするためのツールになっています。 実装した背景 vscode ターミナル上で画像を表示できる OpenAI API はgpt-4-vision-preview のモデルで画像をアップロードして認識させることができる これらを使って、vscode terminal で実行することを前提
2023年のシェル環境構築
tl;dr fig starship zsh fzf sheldon なぜ vscode の .vscode/tasks.json が fishと非常に相性が悪い。とくに fish-nvm を使っていると、fish 経由のパス実行時に node と npm へパスが通らない。 そもそも fish を使っていた理由は autocomplete を快適にするためだったが、1年ぐらい Fig を使っていて、補完はこれを任せていいと気づいた。 Fig はこういうやつ そもそも fish の拡張コマンドを使わないように生活していた。方言を覚えたくない。というか bash 拡張や zsh 拡張もあんまり覚えたくない。
プログラミング学習の通過儀礼
プログラミング学習とはそもそも何なのか プログラミング初学者やITに関わる人が最初に知るべきこととして、プログラミングとは「あなたが問題を解決するのに用いたい手段を、あなたが思っているようにコンピュータに入力すること」ではない。 実際には、プログラミング学習はコンピュータに可能な(非常に限定された)処理セットを学ぶことであり、その応用の先に当初のゴールが含まれるかは、プログラミングを学んでその特性を学ばないと、判断すらできない。 例えば、手段 A によってゴール X を達成したいとしよう。非プログラマ/プログラミング初学者の発想は、よほど目の付け所がいいのではない限り、次のいずれかに分類される。 A には同じゴール X を解決する簡易な代替手段 B があり筋が悪い。 A で実現するほどの価値がない A は現状の人類の既存のソフトウェアの応用では実現できない。あるいは非常に困難。無理に実現し
イベントループと TypeScript の型から理解する非同期処理
この本は、ブルーベリー本の 8 章からインスパイアされて、 TS の型が示す情報から Promise というものを理解してみる、というアプローチで書いたJSの非同期処理の解説です。 これらの資料と合わせて読むことを推奨します。 JSのイベントループのイメージを掴む JSでは中々意識することが少ないですが、正しく理解するには OS レベルのスレッドの視点で考え始める必要があります。 ブラウザや Node.js では一つのスクリプト実行単位を1つのスレッドに割り当てます。それをメインスレッドと呼んだり、ブラウザだったら UI スレッドと呼んだりします。 例えばブラウザでは、これは秒間60回、つまり 16.6ms ごとにループを呼び出します。(node だったらこれがもっと短いです) 仮に setTimeout の実装がなかったとして、それ相当の擬似コードを書くのを試みます。 let handl
プロを目指す人のためのTypeScript 本の感想 #ブルーベリー本
自分も教える事が多いので、読み手にどういう風に学んでほしいか、自分がどういう風に伝えるべきか、という視点で読んだ。 1章・イントロダクション そもそもTypeScript とはなにかみたいな話。 コンパイルエラーが出ている状態ではプログラムが完成したとは言えません。 力強い コンパイルエラーをただ避けるのではなく、利用する気持ち で TypeScript プログラミングに臨みましょう。 初心者に型違反の向き合い方を諭す話。IDEの補助になるとか。 TS年表で取り上げてるのが特徴的。exactOptionalProperty を取り上げてたり。 TSの型はランタイムに影響しない、という話を何度も解説している。これは初心者の誤解がとても多いので、必要だと思う。何度いっても、伝わって欲しい人に伝わらないのだが… enum や namespace については意図的に解説しない。過去のTS独自路線だ
Git と GitHub の次を妄想する
GitHub みたいなサービスを今一から作るならどの言語・フレームワークを使うか GitHub の次は何かを考えてみるのは、現実に実現困難なのを忘れれば、なかなかに楽しいことではあります。ここではその妄想をやっていきましょう。 GitHub の抱える課題を分割すると、Git の問題と、 GitHub の提供する機能の問題に分けられると思います。自分は、Git をベースとして GitHub に勝つのは現代ではなかなか難しいと考えています。MS による買収と実際に注ぎ込まれてる資本を考えると、よほど斬新な切り口でないと、 同じ Git を使っても優位性は出せません。 なので、 GitHub に本質的に勝つには、その基幹となる VCS から考え直すとよいのではないか、と考えています。幸いなことに(?)、Git はその優秀さは認められていますが、学習の困難さや特定のユースケースで機能しないことが知
プログラミング初心者のための JavaScript と Node.js の歴史、それを踏まえた勉強方法
プログラミング初心者のための JavaScript と Node.js の歴史、それを踏まえた勉強方法 2020年でJavaScript学ぶならきっとブラウザ向けJSガン無視していきなり初手node.js（ただし暫く何も足さない）がいいんじゃないかというメモ - min.t (ミント) Node.js を教えることについて、自分は賛成なんですが、その学習パスが整理されてないなと思っていたのと、学習パスがなぜ整理されていないかについて書きます。 はじめに 問題意識として、今のプログラミングスクールや独学勢が Ruby on Rails に偏っていて、 Node.js の人間としては、歯がゆく感じているんですが、実際 Node.js を教えるとしても問題も多いと認識しています。 歴史の話は、当時の実情や政治を省いて結果だけを書きます。具体的には第一次ブラウザ戦争、第二次ブラウザ戦争を言及しませ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
