問題
別々の機能がドリフトを生み出します。
戦略は抽象化され、設計はコードとのつながりを失い、エンジニアリングは移動する目標を調整することだけを任されます。 AI 支援ワークフローでは、一貫性を高めることなくスループットを向上させると、この問題がさらに悪化する可能性があります。
Aroidoチーム
Aroido は、Kkachi および Bigcat です。私たちがこのチームを立ち上げたのは、多くの製品品質が引き継ぎで失われてしまうためです。戦略は実装から離れ、設計はデリバリーのプレッシャーによって平坦になり、AI ツールは活用すべきところにノイズを加えることがよくあります。
私たちは、より厳密な構築方法、つまりレイヤーの数を減らし、より明確な基準を設け、出荷された後も製品そのものであると感じられる製品を望んでいます。
このチームが存在する理由
アイデアは強力に始まり、その後、役割の引き継ぎ、希薄な決定、急いで実装することに分解されます。出荷されるまでに、製品は、その製品を興味深いものにした元の規格を備えていなくなります。
問題
戦略は抽象化され、設計はコードとのつながりを失い、エンジニアリングは移動する目標を調整することだけを任されます。 AI 支援ワークフローでは、一貫性を高めることなくスループットを向上させると、この問題がさらに悪化する可能性があります。
代わりに私たちが望むもの
Aroido は、最終製品が意図的であると感じられるように、方向性、設計エンジニアリング、および配信規律を十分に近づけるために存在します。それが私たちが作るすべての基準です。
私たちが信じていること
信念01
Process は、次の決定を明確にし、出力を改善する場合にのみ役立ちます。
信念02
ビジュアル言語、インタラクションの品質、コードの品質は別個の関心事ではありません。出荷された製品のいずれかが紛失した場合、作業は不完全になります。
信念03
Prompts では十分ではありません。コンテキスト、ツール、レビュー、リリース ルールが 1 つのオペレーティング モデルとして設計されると、AIネイティブ 開発が向上します。
信念04
私たちは、速度や革新性についての曖昧な主張よりも、出荷された作品、リリースノート、進化する製品を好みます。
私たちが今構築しているもの
VibeSmith と LayoutRecall は今日の作業の公開側を示していますが、ゲームやその他の実験は適合性が明確になるまで Labs に残ります。
公共製品
これは、複数のリポジトリ、再利用可能なコンポーネント、およびコピー&ペーストの再利用では提供できないより多くの構造を必要とする AIコーディング フローをやりくりするチームやビルダー向けに構築されています。
なぜそれが重要なのか
私たちは、品質の基準を下げることなく、ずれを減らし、コンテキストを保持し、次のプロジェクトを開始しやすくするソフトウェアを重視しています。
その背後にいる人々
製品思考、設計エンジニアリング、リリースプレッシャーが同じ意思決定ループの近くにあるため、この作業は最も強力です。
ビルダー01
プロダクトの方向性、システム思考、リリース規律。
Bigcat は、製品を実際の決定に向けた状態に保ち、曖昧さを迅速に軽減し、分散したバックログではなく 1 つの意味のある結果に向けて各サイクルを推進します。
ビルダー02
デザインエンジニアリング、インターフェースクラフト、フロントエンド実行。
Kkachi は、標準を目に見えて使用できるものに変えます。つまり、明確なビジュアル言語、強力なインタラクションの詳細、およびパフォーマンス、応答性、実稼働現実を尊重した実装です。
私たちの働き方
VibeSmith や LayoutRecall などの公開製品は、現在のリリースバーの位置を示しますが、Labs は、同じ表面に値するまで新しいアイデアを正直に保ちます。