newnakashima
newnakashima.bsky.social
newnakashima
@newnakashima.bsky.social
27 followers 16 following 130 posts
Web系の底辺中年プログラマです。PureScriptとかが好きですが全然触れてません。生成AIで人生を一発逆転させたいです。
Posts Media Videos Starter Packs
CodexはClaudeと比べて頑張りすぎるような気がするな。デカいタスクを頑張り過ぎたり、簡単な実装で済むものを複雑に作ったりとか
ITの世界でもオフライン・対面が重要だとか言い出す経営者が増えて、オフィス回帰とか言われてるけど、これは「性能」に劣る人々が肉体と感情を使ってその性能差を埋めようとしている動きだと解釈できる。

多分地頭が良くIQの高い、「性能」の良い人々は全くオフィス回帰することなく少人数でAIを使って多くのものを生産するんだろう。

「性能」に劣る人々が大都市に集中し、「性能」の良い人はコスパが良くストレスも少ない郊外や地方都市に分散するのかもな。
「ろくに動かない」という実装はAIの性能が上がれば減るだろうが、「思ってたのと違う」実装はAIの性能がいくら上がっても減らない。プロンプトの精密さや正しさとか、仕様バグの少なさが大切になってくる。つまり人間の性能の問題になってくる。

これまで性能の低い人間であっても専門的な知識や技術を持ってれば食えていたのだとすると、知識や技術がAIによって大部分カバーされるなら、人間の性能だけが問題となる。

要するに「地頭」とか「IQ」とか呼ばれる能力だけが重要で、地頭が良いやつは何でもできる一方で地頭が悪いやつには肉体や感情を使う労働しか残されない世の中になるんだろう。
並列でコーディングAIを動かす、みたいなプラクティスが語られるけど、実際やってみたら不可能に近かった。なぜならレビューするのは人間だから。レビューせずにガシガシマージするならあり得るかもだが、デプロイしたらろくに動かないアプリとか思ってたのと違うアプリになってる可能性が高い。だから人間のレビューは必要。でも人間のレビューはシリアルにしかできない。

人間がボトルネックになっているとも言えるし、AIがまだまだポンコツだとも言える。
最近は husky でLintもFormatもTestもするので、GitHub Actions で何かがコケるということがなくなった。AI時代はエンジニア一人で開発するケースも増えるはずなので、ローカルでPassするがPRでFailする、というのがめちゃくちゃレアになるのではないだろうか。

ローカルLLMを動かすとかいう目的とは全く別に、強力なローカル環境というのがめっちゃ大事な気がする。
複数セッションにまたがる作業をAIにさせたい場合は外部のタスク管理ツールとかではなくリポジトリ内に記憶用のmdファイルを作成させるので、なんかあらゆるものがコードベース内にあってすべてがソースコード化してるなと感じてきている。

プロンプトのテンプレートなんかもソースコードとして管理したほうが良いだろうし、AIにやらせた過去の作業とかもコードベース内にあったほうがAIが読みやすい(はず)。社内wikiみたいなやつかますとやれMCPだHTTPだとなってコンテキストを消費しそう

CIのローカル化とも相まって、なんか色んなものがローカル環境に移ってきている
タスク分割の要不要は作業を行うAI自身に判断させたほうが良いかなと思っていたが、やめたほうが良いという結論に至った。「タスク分割はAIに判断させよう」と思える粒度の時点でデカいタスク。そのためプランニング&タスク分割というセッションを1回挟むのが100%正解。
AIのコードをレビューするときはDRYを徹底させたほうが良い。人間の場合は早すぎる抽象化・共通化の可能性があるため敢えて二重管理にすることも多いが、AIは二重管理のコードがあると修正時に確実に片方しか修正せずにバグを仕込んでくる。必要なコードしかコンテキストに入れずに修正するからそうなるんだろうと思う。CodeRabbitはそのへんは nitpick コメントで指摘してくれる。
複数のセッションにまたがる作業をAIに依頼する時。
最初のセッションでTODOリストを記載したマークダウンファイルを作らせる。
次回以降のセッションで、それをちょっとずつ消化させる。そのとき、次のセッションに引き継ぐべき内容があれば追記しろ、と言っておくとよい感じになる。

こういうの今どきみんなやってるんだろうけど、実際にやってみて勉強になった。今までデカいタスクを一発でやらせようとしてたから性能の劣化も激しかった。

とはいえモデルが進化すればこんな問題ほとんど気にしなくてもよくなるのかもなぁ。
Claude は本当にバカだなあ。職場にいたら耐えられないかもしれない。
Claude Code on the web は毎回環境のセットアップさせる必要があるのかな?
もしそうならだるいな
Claude Code on the web と Vibe Kanban どっちが良いんだろう。なんか、スマホからでも指示できそうな雰囲気だし自分でサーバー立てる必要ないから CC on the web のほうが一見便利そうではある。あと Vibe Kanban はフロントエンドの一部の構成に振り切ってきてる印象はある。React な環境じゃないと良さが活かせなくなってそう
Bunのserve APIとCloudflare WorkersのFetch Handlerどっちかに統一してくれたらなあ。多分Node.jsのサーバーが低レベルすぎたから分裂してるんだろうな
なるほど。今更知ったけど、WorkersはランタイムにBunをサポートしておらず、Workerdという独自ランタイムを使っているのか。Bun が使えるというのはあくまでビルド時に使えるというだけか。紛らわしいな。。
CloudFlare Workers でも BUN_VERSION を `1.3.0` にしたら Bun 1.3.0 を使えそうな雰囲気だ。
Claudeには一発では無理だろうなー、と思いながら古いNext.js製のサイトに機能追加を頼んだら一瞬で完璧に作業してくれた。Next.jsは長いこと覇権だったから学習データが大量にあるのだろう。やはりAIを真に活用するなら流行りものに乗っかることが大事だと痛感した。逆に言えば新しいソリューションが採用されづらくなるという強烈なバイアスがかかってしまう気がした。AIによって技術が停滞する未来が見える。いくらllms.txtを用意してもAIには全然重みが足りない。
Bun 1.3 今のところ使い勝手も良くて概ね満足だがやはり痒いところに手が届かない感はある。Bunが out of the box で何でもできるとは言え、Next.jsみたいなことはできない。そこら辺はフレームワークがカバーすべき点だろうと思うので、各フレームワークがBunの機能に対応していくのを待つしかないのかもしれない。
とは言えBunは言語の処理系を超えてフレームワーク的な領域にまで踏み込んでいるので既存のフレームワークと食い合わせ悪いのかも。この手広さはなんとなく .NET 思い出す。そのうちBunでスマホネイティブアプリ作れるようになったりして。
昨日からZedを使い始めてるけど今のところ良さを感じず。でかいコードベースをいじってないからか。全体的にやはりまだCursorやVSCodeに比べてこなれてない感はある。
どんなに優秀な人たちでも雇われエンジニアだとフレームワークの新バージョンで互換性が壊れて一時的に非本質的な追従作業が発生することを「ジョブセキュリティ上のメリット」とか言っちゃったりするんだな。AIにはできないからだろうけど。もうそういう世界から抜け出したいよ。ほんと無駄の極みという感じがする
ブラウザの機能でHMRできて標準でTSとTSXサポートされたらうれしいな。無理か。
Googleが買収した Stitch がよくて感動している。無料で使えるというのがすごい。これ有料化したらいくらになるのかな。。。画像も作ってくれるからすごく助かる
SolidJSをBun1.3で使うのは今のところ面倒くさそう。最近のフロントエンド界隈は、どのレイヤーも `create-**` 的なコマンドを用意しててテンプレートから設定ファイル込みのプロジェクト一式が展開されて、それ使えばスムーズにいくけど、それを独自にカスタマイズしようとするとえらく大変になる。

Bunの良いところ全部使おうと思ったらSolidJS側ではなくBunが提供しているテンプレートに乗っかるのがよくて、その場合、今のところフロントエンドの選択肢は React だけ(かバニラ)ということになりそう(`bun init --react`)

本当は React 以外が使いたい!
Good information. Thank you!
bun build --compile でAPIとフロントエンドが全部入った実行可能バイナリを作れるけど、25バイトのindex.htmlと241バイトのindex.tsをコンパイルしたら58メガバイトのバイナリになった。当然ながらランタイムとか依存パッケージが全部入ってると思われる