After Cline - あるいは語りえぬ者について語ろうとする時代について

post-cline-world.md

After Cline - あるいは語りえぬ者について語ろうとする時代について

この資料は以下のイベントの登壇用の殴り書きです

https://hack-at-delta.connpass.com/event/350588/

今までの資料を引用して話すので、この資料はアウトラインです。

最初に: 自分の技術選定の基準

• ハイプサイクルにおけるアーリーアダプター相当で手を動かす
  • ハイプ・サイクル https://mba.globis.ac.jp/about_mba/glossary/detail-20659.html
  • https://www.thoughtworks.com/radar を読む
  • イノベーターっぽい人達をSNSで監視してる
  • 一定の熱量を感じたら自分でも動かして評価する
• 破壊的イノベーションを逃すな
  • 破壊的イノベーション - クリスチャン・クリステンセン https://www.amazon.co.jp/dp/4798100234
  • 星取表で考えない。新興技術は初期段階で星取表で負けてる
  • 先発から後発へ星取表が出てくる時、大抵は負けはじめたシグナル
    • 先発「(後発)は～がない。～もない。私達の製品は～」
    • 後発「別にそんなところで勝負してない」
  • 特にOSSの世界では先進性によってコミュニティが発生し、星取表は時間で埋まる
    • webpack => (rollup, esbuild) => vite

今までの「とにかく高速にトレンドが変化する技術」を振り返る

• 経験的に...
  • 2012: Docker
  • 2015: React
  • 2017: Block Chain
  • 2020: k8s
  • 2025: Cline等のコーディングエージェント
• コーディングエージェントはこれらに相当するものと判断
• 「動きが速すぎるから落ち着いたらやる」は、成長コンテキストを見失って逆に学習コストが上がる
  • 専門外でもちょっとずつかじって自分で判断する必要はある
• React のとき...
  • もうこれ以上 jQuery で疲弊したくない！！！！
  • 「なぜ仮想DOMという概念が俺達の魂を震えさせるのか」を書いた
    • https://qiita.com/mizchi/items/4d25bc26def1719d52e6
  • 明確な技術的な優位を提示して、現場で使わせてもらう、アーリーアダプターとして経験値を蓄積する
  • 日本の技術トレンドは海外と比較して 1.5~2年ぐらい遅い

---

Cline 以前何やってた？

• 既に GitHub Copilot は手癖になっていた
  • 元々 // 関数の実装仕様<TAB> でコードの半数を生成していたはず
• mizchi/previs (2023)
  • 自然言語からReactのコード生成エージェントを試作
  • 当時の結論: モデル性能の進化を待ったほうがいい

プログラマ vs AI 生存競争 (20240920)

https://mizchi-20240920-nextbeat-slide.pages.dev/

最終的には 試行錯誤の手数で人間のプログラマを圧倒する

予想: 人間側がボトルネックになる

実際こうなった。

モデルの性能向上とは別に、プログラミング環境へのアダプタこそが必要だったというオチ。

「私たちが知っているプログラミングの終焉」

自分はティム・オライリーが The End of Programming as We Know It を書いたことで、自分の中の踏ん切りがついた。

https://www.oreilly.com/radar/the-end-of-programming-as-we-know-it/

Google 翻訳

今まさに到来しようとしている魔法は、これまでで最も強力なものです。そしてそれは、私たちが探求と創造の深遠な時代に入り、その魔法をどのように機能させ、その力から新たな利点を引き出すかを理解しようと努めていることを意味します。この技術を採用する賢明な開発者は、付加価値を生み出すより高度な創造性に注力することで、これまで以上に多くのことを実現できるため、需要が高まるでしょう

熟練プログラマーであり、先見の明のある技術観察者であるスティーブ・イェッジ氏は、置き換えられるのはジュニアおよび中堅プログラマーではなく、新しいプログラミングツールやパラダイムを受け入れず過去に固執するプログラマーだと指摘しています

シラス氏「産業革命期における動作の自動化との類似点は顕著です。今日の自動化はまだ粗雑です。私たちは、水を汲み上げたり、ハンマーを叩いたりするのと同じような認知的作業、つまり要約、パターン認識、テキスト生成といった基本的な作業を行っています。この新しいエネルギー源のための堅牢なエンジンを構築する方法はまだ解明されていません。AIはまだ機関車の段階にも達していません。」

Google Chromeのユーザーエクスペリエンス責任者であるアディ・オスマニ氏は、これを「70%問題」と呼んでいます。「エンジニアはAIによって生産性が劇的に向上したと報告していますが、私たちが日常的に使用するソフトウェア自体は、目立った改善が見られないのです。」彼は、AIコード生成ツールを扱う非プログラマーは素晴らしいデモを作成したり、簡単な問題を解決したりすることはできるものの、複雑なプログラムの最後の30%で行き詰まってしまうと指摘しています。

これはプログラミングの終わりではありません。プログラミングの新たな改革の始まりです。

「Cline に全部賭けろ」

https://zenn.dev/mizchi/articles/all-in-on-cline

Cline は暴走列車みたいなもので、最初の指示以外は人間なんかどうでもいいと思っているフシがある。その結果、これ抜きに実現できない速さを獲得し、自分はこれ無しで我慢できなくなった。正直、かなりの中毒性がある。

自分はプログラマが不要になるとは思っていない。プログラマというのはコードを書く作業員ではなく、対象のドメインを抽象して構成要素を分解・再構築する思考訓練を受けた専門家だと思っているからだ。

自分が理解してないものを実装するには「結果から逆算されうる内部構造に対する直感」というかなり高度な思考が要求されることになる。今までプログラマではないから人がプログラマに仕事を依頼する時は、この感覚だったんだと思う。

高度なAIは自分の鏡みたいなもので、AIから引き出せる性能は、自分の能力にそのまま比例する。プログラミング作業が少し自然言語に近づいただけで、実際の動作レベルがプログラミング言語であることは変わらないし、デバッグ時に必要とされる水準は変わっていないし、なんならより難しくなっているかもしれない。

• ここでいう Cline は Cline 型のヘッドレスIDE統合環境のことで、VSCode Cline だけじゃない
  • Cursor, Windsurf, CopilotAgent, Claude Code, Codex, Aider...
• 「AIエージェントにシェル実行権限と VSCode を操作する権限を与えるとどうなるか？」というパンドラの箱を開けたことが Cline の歴史的な意義

「Cline に全部賭けろ」を書いた経緯

• 2024末から一部で話題になっていたのを認識
• 2025/2頃に、 Cline+Claude3.5 で実用に足ると判断
• 「AIの胡散臭さ」に対して、実利を提示する必要がある
  • 日本のSNSでは画像生成界隈のネガティブイメージもあり胡散臭い
  • Cline の強烈さは手元で動かさないと伝わらない
  • 暗号通貨と同じハイプ技術扱いされてしまう懸念
• 背中を押すなら、今しかねえ

「補完」の概念が拡張されていく

• LSP/インテリセンス: 静的解析でトップレベルシンボル、または . から先の補完候補を提案
• Copilot: 現在のファイルを根拠に、Tab 押したときにステートメントや関数ボディ部分まで補完を提案
• Cline: 自然言語によるコードの生成を試み、その修正ループを自動化(上手くいくとは限らない)

各種ツールの現時点の性能認識

https://zenn.dev/mizchi/articles/ai-model-current-snapshot-2025-0414

• モデル
  • ショートコンテキストの Claude 3.7
  • ロングコンテキストの Gemini 2.5
  • 安価でプロトタイピングに便利な DeepSeek v3
• コーディングエージェント
  • Cline or Roo
  • 最終的にはビルトインの GitHub Copilot Agent が勝ちそうな気がする

Aider のスコア見ると、現時点でコスパ的には Gemini 2.5 Pro 一強

https://aider.chat/docs/leaderboards/

現時点で複数モデルのワークフロー設計は逆に難しい(プロンプトキャッシングの効率性問題)

---

Post Cline の時代 (今)

• 技術検証/プロトタイピングが低コスト化
  • Well-Known で Well-Defined な技術範囲は、もはやAIの独壇場
  • ウェブ標準仕様や古典的アルゴリズムの参照が容易に
• 大規模コード理解に難があるのは変わらず
  • 品質が悪いコードでは、モジュールを組み立てられない
  • Claude は 1000 行, Gemini は 3000 行あたりで破綻する
• おそらく期待値コントロールに失敗している
  • バイブコーダーに「設計」とは難だったのかが伝わってない
  • プロトタイプとプロダクションの間の、深くて険しい壁が認識されてない
  • 「難しく考えすぎてません？シンプルに考えましょうよ」問題
    • まじめに考えてんだよ！！！！
    • 「眼前に存在しない潜在的な状態の組み合わせについて考える抽象能力」は現状プログラマにしかない
    • 認識できないものは、語り得ない...
    • https://zenn.dev/mizchi/articles/json-for-everyone

実例バイブコーディング: readability の移植

• mozilla/readablity を mizchi がバイブコーディングでDOM非依存版に移植
  • https://npmjs.com/package/@mizchi/readability
• macopy さんがバイブコーディングで Go に移植
  • https://mackee.hatenablog.com/entry/2025/04/13/174614

こうやって雑に移植がある程度機能するのはいいが、開発をやっているという感覚がないし、コードに対するオーナーシップも薄い。OSSにおいてコードのオーナーシップはメンテナンスの頻度やissue対応に影響してくる。多分こんな雑実装であるものにそんなに人は頼ってこないとは思うが。。。

また、AI雑ライブラリをうっかり使ってしまって、バグ修正や機能要望をしたものの、作者が飽きたりトークン代を払う金が無い等で対応されないケースも出てくるだろう。しかし人間がみんながみんな継続してパッションを持って手で書いてOSS等を書いているわけでは無いのである。その時はあなたがトークン代を払って問題を解決する未来が来るかもしれない。

(自分も macopy さんも経験豊富な側のプログラマで、あえてバイブコーディングしてるという文脈)

ただし、うまくいったのは、そもそも確率的な処理であること、 ARC90 のコアアルゴリズムを Claude/Gemini が学習済みだったから、という認識

実際にどこで使ってる？

• 今の自分の用途
  • ライブラリのAPIの使い方を確認
    • 認識したらコード全部捨てて自分で書き直す
  • テストコードの量産
    • とりあえずカバレッジを上げる
  • マークアップ
    • お絵かきAPIだと思って複数回 JSON 色付けさせて、いいやつを採用
  • write 権限は奪った。レビュー前提
• 大規模化
  • 大規模下で明示的にドキュメントを指示すると上手くいくが、人間のコストが重い
  • 低レベルエンジニアにコードベース荒らされてる感覚。write_file 権限は取り上げた。
  • モジュール単位で分割統治したいが、今の CLINE だと制御しきれない
• 例外設計が苦手すぎ問題
  • 全部を try catch して握りつぶしてしまう
  • Xでポストしたら賛同が集まったので、そうなんだと思う

今後の予想

• 短期的な変化
  • AI(Devin)に勝てないジュニアエンジニアの雇止め
  • 既存エンジニアはAI向けのドキュメント検索アダプタ(FunctionCall/MCP)を大量に作ることになる
  • フロントエンドは一生 ChatUI 作らされる
  • 年内にバイブコーディングへの失望期が来る
  • AIの解釈コスト観点で、仕様をプレーンテキストで記述する価値が上がる
    • Notion、エクセル、パワポで書かれたリッチテキストは解釈で不利
      • 入力コストが 100倍以上のオーダーで違う
    • MSから変換ツールが出てる https://github.com/microsoft/markitdown
• 長期的な変化
  • AIコーディングに適応できないエンジニアが駆逐される
  • セキュリティがより攻撃者有利/防衛不利に
    • 攻撃側: 攻撃コード生成が高速
    • 防衛側: バイブコーディングで中身がブラックボックス化したり、プロンプトインジェクションを受けやすくなる

プログラマ・プログラミング自体の変質

• AI は選択肢ではなく前提になる
• モデル性能理解と生成されるコードの品質予測が必須のドメイン知識になる
• 言語化・モデリング・概念の理解により比重が置かれる
  • エディタ補助が強くなってるので、逆に switch 文の文法が曖昧でもコードは書ける
• コンテキストに応じたドキュメントの参照を指示することが、専門家としての役割になる
• コーディングのためのメタドキュメント整備
  • 型と linter に思想を押し込む

今のエンジニアが今後目指すべきポジション

• エキスパートのポジションを死守
  • エキスパートとして AIに負けないドメイン知識を、最低一つ持つ
  • それ自体より、AI を疑うメンタリティを獲得するために必要
  • ドメイン知識を MCP/Function Calling として実装していく
• コードを書くことと同じぐらい、コードを生成するパイプライン設計が重要
  • 「自分を部分的に再現するプロンプト」を用意して、レビューや初期検証を高速化
  • コード評価のサンドボックス設計が重要
  • 言語化・設計・検証

「でも将来的にはAIが～」を無視する

• 手を動かして性能を微分することのみ将来の予測が可能になる。手を動かせ。
• 非連続的な進化はそもそも予測できない ので、妄想と切り捨ててよい
• 人類のリソースが注ぎ込まれてるので非連続的な進化が起こること自体は予測可能だが...
• 本当ならエンジニア全員がモデルをチューニングしてる状態が望ましいが、コストとスケール則の関係で厳しい

語り得ぬものには、沈黙しなければならない

• 最新モデルは部分的に一般的なプログラマの能力を超えつつある
  • 現時点で AI はコンテキストを認識できるレベルにない
  • 最終的には人間は手数で圧倒されるのは自明
• 自分がAIにとって語るに足る専門家である必要がある
  • ユーザーが認識できないものを指示(プロンプト)で与えても検証できない
  • そのうえで、現時点で開発を任せるのは、自分は無理

---

おまけ: 日本語圏で信頼できるソース

驚き屋ばっかりで、手を動かした肌感込みの情報が本当に少ない

• https://note.com/npaka
• https://blog.lai.so/
• https://azukiazusa.dev/blog/
• https://joisino.hatenablog.com/

あとはモデル開発側の公式情報と、手を動かした自分だけを信じましょう

🙌 [English version]

After Cline - Discussing the Era of Speaking About the Unspeakable

This document is a rough draft for a presentation at the following event:

https://hack-at-delta.connpass.com/event/350588/

Since I will be referencing previous materials, this document serves as an outline.

First: My Criteria for Technology Selection

• Act as an early adopter in the hype cycle and get hands-on
  • Hype Cycle: https://mba.globis.ac.jp/about_mba/glossary/detail-20659.html
  • Read https://www.thoughtworks.com/radar
  • Monitor innovative people on social media
  • Once I sense a certain level of excitement, I try it myself and evaluate
• Don’t miss disruptive innovations
  • Disruptive Innovation - Clayton Christensen https://www.amazon.co.jp/dp/4798100234
  • Don’t evaluate based on scoring charts; new technologies often lose in the early stages
  • When scoring charts emerge from pioneers to latecomers, it’s usually a signal of losing
    • Pioneer: “(Latecomers) lack this and that. Our product has it.”
    • Latecomer: “We’re not competing in that area.”
  • Particularly in the OSS world, communities form around advanced technology, and scoring charts fill over time
    • webpack => (rollup, esbuild) => vite

Reflecting on Past “Rapidly Changing Technology Trends”

• Based on experience...
  • 2012: Docker
  • 2015: React
  • 2017: Blockchain
  • 2020: Kubernetes
  • 2025: Coding agents like Cline
• Coding agents are judged to be equivalent to these
• “I’ll wait until things settle because they’re moving too fast” leads to losing growth context and increasing learning costs
  • Even if it’s outside your expertise, you need to nibble at it and make your own judgments
• During the React era...
  • I was tired of jQuery!!!!
  • Wrote about why the concept of the virtual DOM shook our souls
    • https://qiita.com/mizchi/items/4d25bc26def1719d52e6
  • Presented clear technical advantages, used it in the field, and accumulated experience as an early adopter
  • Japan’s tech trends are about 1.5 to 2 years behind overseas

---

What Was I Doing Before Cline?

• GitHub Copilot had already become second nature
  • Originally, I should have been generating about half of the code with // Function implementation spec <TAB>
• mizchi/previs (2023)
  • Developed a prototype of a natural language to React code generation agent
  • Conclusion at the time: Better to wait for model performance evolution

Programmer vs. AI Survival Competition (20240920)

https://mizchi-20240920-nextbeat-slide.pages.dev/

Ultimately, humans will be overwhelmed by the number of trial and error attempts

Prediction: Humans will become the bottleneck

This actually happened.

Apart from model performance improvements, adapters for programming environments were the real need.

“The End of Programming as We Know It”

I found closure when Tim O’Reilly wrote The End of Programming as We Know It.

https://www.oreilly.com/radar/the-end-of-programming-as-we-know-it/

Google Translate

The magic that is about to arrive is the most powerful ever. And it means that we are entering a profound era of exploration and creation, trying to understand how to make this magic work and derive new advantages from its power. Wise developers who adopt this technology will achieve more than ever by focusing on more advanced creativity that adds value, and demand will increase.

Steve Yegge, a skilled programmer and forward-thinking technology observer, points out that it is not junior or mid-level programmers who will be replaced, but programmers who stick to the past and refuse to embrace new programming tools or paradigms.

Silas says, “The similarities with the automation of operations during the industrial revolution are striking. Today’s automation is still crude. We are performing basic cognitive tasks, such as summarization, pattern recognition, and text generation, similar to pumping water or hammering. How to build robust engines for this new energy source has not yet been figured out. AI has not yet reached the stage of locomotives.”

Addy Osmani, Google Chrome’s user experience lead, calls this the “70% problem.” “Engineers report dramatic productivity improvements with AI, but the software we use daily has not seen significant improvements.” He notes that non-programmers using AI code generation tools can create great demos and solve simple problems but get stuck in the last 30% of complex programs.

This is not the end of programming. It is the beginning of a new reform in programming.

“Go All-In on Cline”

https://zenn.dev/mizchi/articles/all-in-on-cline

Cline is like a runaway train, unconcerned with humans beyond the initial instructions. As a result, it achieves speeds unattainable without it, and I can no longer do without it. Honestly, it’s quite addictive.

I don’t think programmers will become unnecessary. Programmers are not just code writers; they are specialists trained to abstract and deconstruct/reconstruct the components of a domain.

Implementing something I don’t understand requires a highly advanced intuition about the internal structure that can be reverse-engineered from the results. I think this was the sense people had when they asked programmers to do work when they weren’t programmers themselves.

Advanced AI is like a mirror of oneself, and the performance that can be drawn from AI is directly proportional to one’s ability. Programming tasks have become slightly closer to natural language, but the actual operation level remains programming languages, the standard required for debugging hasn’t changed, and it might even be more challenging.

• Cline here refers to a Cline-type headless IDE integration environment, not just VSCode Cline
  • Cursor, Windsurf, CopilotAgent, Claude Code, Codex, Aider...
• The historical significance of Cline is opening Pandora’s box of “What happens when you give an AI agent shell execution rights and the ability to operate VSCode?”

Background of Writing “Go All-In on Cline”

• Recognized the buzz around it from late 2024
• Around February 2025, judged Cline+Claude3.5 to be practical
• Need to present practical benefits against the “skepticism of AI”
  • Negative image of the image generation community on Japanese SNS also adds to the skepticism
  • The intensity of Cline cannot be conveyed unless you try it yourself
  • Concern about being treated as a hype technology like cryptocurrency
• If you’re going to push forward, now is the time

The Concept of “Completion” is Expanding

• LSP/IntelliSense: Proposes top-level symbols or completion candidates beyond . through static analysis
• Copilot: Based on the current file, proposes completion for statements or function bodies when Tab is pressed
• Cline: Attempts to generate code through natural language and automate the revision loop (success is not guaranteed)

Current Performance Recognition of Various Tools

https://zenn.dev/mizchi/articles/ai-model-current-snapshot-2025-0414

• Models
  • Short context: Claude 3.7
  • Long context: Gemini 2.5
  • Affordable and convenient for prototyping: DeepSeek v3
• Coding agents
  • Cline or Roo
  • Ultimately, the built-in GitHub Copilot Agent seems likely to win

Looking at Aider’s score, Gemini 2.5 Pro is the strongest in terms of cost-performance at the moment

https://aider.chat/docs/leaderboards/

Currently, designing workflows with multiple models is challenging (efficiency issues with prompt caching)

---

The Post-Cline Era (Now)

• Cost reduction in technology verification/prototyping
  • Well-Known and Well-Defined technology areas are now dominated by AI
  • Web standard specifications and classical algorithms are easily referenced
• Large-scale code understanding remains difficult
  • Poor quality code cannot assemble modules
  • Claude breaks down around 1000 lines, Gemini around 3000 lines
• Possibly failing in expectation management
  • It’s not communicated what “design” means to a vibecoder
  • The deep and steep wall between prototype and production is not recognized
  • “Aren’t you overthinking it? Let’s keep it simple” problem
    • I’m taking it seriously!!!!
    • “The abstract ability to think about combinations of potential states not present” is currently unique to programmers
    • What cannot be recognized cannot be spoken...
    • https://zenn.dev/mizchi/articles/json-for-everyone

Practical Example of Vibecoding: Porting Readability

• mizchi ported mozilla/readability to a DOM-independent version through vibecoding
  • https://npmjs.com/package/@mizchi/readability
• macopy ported it to Go through vibecoding
  • https://mackee.hatenablog.com/entry/2025/04/13/174614

It’s nice that rough porting works to some extent, but it doesn’t feel like development, and there’s weak ownership of the code. In OSS, code ownership affects maintenance frequency and issue response. I don’t think many people will rely on such rough implementations.

Also, there will be cases where people accidentally use AI rough libraries, request bug fixes or feature requests, but the author loses interest or lacks funds for tokens, resulting in no response. However, not everyone writes OSS with continuous passion. In such cases, you might have to pay for tokens to solve the problem.

(Both I and macopy are experienced programmers, vibecoding intentionally in this context)

However, the success was due to it being probabilistic processing, and the core algorithm of ARC90 was already learned by Claude/Gemini.

Where Am I Actually Using It?

• My current use cases:
  • Checking how to use library APIs
    • Once recognized, discard all code and rewrite it myself
  • Mass-producing test code
    • Raise coverage for the time being
  • Markup
    • Treat it as a drawing API, color JSON multiple times, and adopt the best one
  • Revoked write permissions. Assume review
• Large scale
  • When explicitly instructed to document, it works well, but human costs are high
  • Feels like low-level engineers are messing up the codebase. Revoked write_file permissions.
  • Want to divide and conquer by module, but current CLINE cannot control it
• Exception design is too weak
  • Catches everything in try-catch and swallows it
  • After posting on X, gathered consensus, so it seems that’s the case

Future Predictions

• Short-term changes
  • Termination of junior engineers who cannot compete with AI (Devin)
  • Existing engineers will create a lot of document search adapters for AI (FunctionCall/MCP)
  • Frontend will forever be tasked with creating ChatUI
  • Disappointment with vibecoding will come within the year
  • The value of describing specifications in plain text will rise from the perspective of AI interpretation cost
    • Rich text written in Notion, Excel, PowerPoint is at a disadvantage in interpretation
      • The input cost is an order of magnitude different
    • Conversion tools from MS are available https://github.com/microsoft/markitdown
• Long-term changes
  • Engineers who cannot adapt to AI coding will be eliminated
  • Security will become more attacker-favored/defender-disadvantaged
    • Attackers: Fast generation of attack code
    • Defenders: Vibecoding leads to black-boxing or easy prompt injection

Transformation of Programmers and Programming Itself

• AI becomes a premise, not an option
• Understanding model performance and predicting the quality of generated code becomes essential domain knowledge
• More emphasis on language, modeling, and understanding concepts
  • With strong editor assistance, you can write code even if the syntax of switch statements is vague
• Directing document references according to context becomes the role of an expert
• Preparing metadocuments for coding
  • Imposing thought into types and linters

Positions Current Engineers Should Aim for in the Future

• Defend the position of an expert
  • Have at least one domain knowledge that AI cannot surpass as an expert
  • This is necessary to develop a mentality of doubting AI
  • Implement domain knowledge as MCP/Function Calling
• Designing code generation pipelines becomes as important as writing code
  • Prepare “prompts that partially replicate yourself” to speed up reviews and initial verification
  • Sandbox design for code evaluation is important
  • Language, design, verification

Ignore “But in the future, AI will~”

• Only by getting hands-on and differentiating performance can future predictions become possible. Get hands-on.
• Discontinuous evolution cannot be predicted and can be dismissed as fantasy
• It is predictable that discontinuous evolution will occur due to the resources poured by humanity, but...
• Ideally, every engineer should be tuning models, but it’s challenging due to cost and scale principles

What Cannot Be Spoken Must Be Silent

• The latest models are partially surpassing the capabilities of general programmers
  • Currently, AI is not at a level where it can recognize context
  • Ultimately, it is clear that humans will be overwhelmed by sheer numbers
• You need to be a specialist worthy of AI’s attention
  • Users cannot verify what they cannot recognize even if given as instructions (prompts)
  • With that, I find it impossible to entrust development at this point

---

Bonus: Reliable Sources in the Japanese Language Sphere

There are too many sensationalists, and there’s very little information that includes hands-on experience.

• https://note.com/npaka
• https://blog.lai.so/
• https://azukiazusa.dev/blog/
• https://joisino.hatenablog.com/

Besides that, trust only the official information from model developers and your own hands-on experience.