ローコードはそのうち破綻する

よりも多くの事柄を学ぶということです。

すると、どこかの時点で初期に考えたことを見直さざるを得なくなります。つまり、ダイアグラムの初期バージョンとそこから作られたスケルトン構造はかならず間違っており、理解の深まりとともに書き換えが必要になるということです。「往復」の機能、つまりコードのスケルトン構造を作り、手作業で細部を書き換えたあとで考えが変わったら、ダイアグラムを描き直してスケルトン構造を変更しつつ、細部の変更を維持する機能を実現するのは大変な難問です。今までのこの種の試みがすべて失敗してきたのは、このハードルを乗り越えられなかったからです。

設計は動的に変わるし、それを反映してかないといけない

そのためにはOOPをはじめとする種々のテクニックと、それを実際に反映できるポテンシャルが要る

コードを書かずに絵を描くのでは、既存の方法のように抽象度のレベルを上げるのが難しくなるのです。例外処理、バージョン管理、デバッグサポート、ライブラリーコード、自動テスト、デザインパターンなど、旧来のプログラミング言語を強化するために時間をかけて発展させてきたものがすべて失われてしまいます。

自然言語や絵ではリーチできない部分がある