Ai

以前使用していた製品は、コード開発を行う際には大差なく、しかしByteのSOLOは、コード開発において大きな違いが生じた。当初は招待コードを通じてベータ版に参加したが、現在はメールアドレスを提出し審査を待つ形式となり、審査に通れば利用できる。いつ申請を行ったのか記憶が曖昧なところだが、今日Traeから審査通過の通知を受け取った。

AI を過信しすぎると、何でも AI と考えすぎてしまうことがあります。新しい動向を学ぶ場合、検索エンジンとプロジェクトの公式ドキュメントの方が信頼性が高いです。

現状では、どの大規模言語モデルも特によくとはなく、各社それぞれに得意な分野や活用シーンがあります。

技術ドキュメント

コードの提供、または IT 技術に関する質問：ChatGPT と Gemini

AIは日常の開発ワークフローに浸透しており、最近投資の方向転換があり、エクイティとETFへのシフトとなりました。

オープンソースプロジェクト

プロジェクト記録

先週、暇つぶしにGitHubバッジを取得するためにIssueモジュールを使い始めました。以前コードを書く際に、AIの変更内容を記録する場所を探していました。個別にドキュメントを作成するのは散らかってしまいがちでした。しかし、Issueモジュールを使用することで、バグ、機能、改善などのラベルで区別し、記録が明確かつ効率的にできるようになりました。将来使わない可能性もありますが、記録を残しておくことは蓄積にもなります。 Issueリストの確認

文化伝播：意識形態的な影響、潜移漫歩。 AIプログラミング：ソフトウェア設計を行わないため、手戻りが多くなる。

文化翻訳

当初のプロジェクトでは、英語、日本語、韓国語という3つの言語のみをサポートしていました。その後、「結局AI翻訳だから、色々な言語に対応した方が良いのではないか」と考え、フランス語、ロシア語、ヒンディー語を追加しました。その頃は問題に気づかず、プログラムが翻訳を実行する際に、過去のコードの問題により翻訳形式が正しくなく、保存された文章を再翻訳する必要がありました。

ブログ翻訳プロジェクトは当初、複雑に設計されていた——まずMarkdown形式を解析し、プレースホルダーでコンテンツを保護し、最後に大規模言語モデルに送信する仕組みだった。これは完全に無駄であり、大規模言語モデル自体がMarkdownの文法を認識する能力を備えており、元のコンテンツを直接処理し、翻訳時にフォーマットを維持することができたからだ。

長年にわたりバックエンド開発に注力してきましたが、最近は AI プログラミングを試したり、少しフロントエンド関連のことも取り組むようになりました。しかし、この間の苦労の中で、自分には昔からある古傷—「繁華なものに目を奪われる」—に気づきました。AI を使ってフロントエンドインターフェースを実現しようとするのですが、実際にはそのような試みが現在の仕事に大きな実用的な助けになりませんし、むしろ時間を浪費してしまいます。

本サイトはHugoで開発されていますが、筆者自身は常に中国語のタイトルを使用しており、その結果、生成される文章の超リンクが使いにくい状態でした。つまり、送信する際に、中国語の文字が超リンク内で%E4%BD%A0%E5%A5%BDのような形式にエスケープされてしまうため、見た目が良くありません。設定でslugを設定することで解決できますが、毎回手動で設定する必要があり、非常に面倒でした。 そこで、Claude4を使って翻訳アシスタントを開発し、中国語のタイトルを自動的に英語のslugに変換し、文章中に超リンクを追加することを試みました。これにより、手動での設定を回避できます。

Claude4はマジで最高！文脈理解能力が大幅に向上し、複雑なタスクの処理効率も飛躍的に向上しています。