NVIDIA、CLI と AI エージェントによる Holoscan アプリ開発を解説
本文の状態
日本語全文を表示中
詳細モードで約17分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
NVIDIA Developer Blog
NVIDIA は AI コーディングエージェントを活用して HoloHub の例やドキュメント、開発スキルを参照し、CLI を介した反復的なワークフローでリアルタイムエッジAIアプリケーションを開発する手法を実証した。
AI深層分析を開く2026年8月20日 07:54
AI深層分析
キーポイント
AI エージェントによる開発ワークフローの構築
エンジニアが目標と制約を定義し、コーディングエージェントが HoloHub の例やドキュメントを検索・実装し、CLI を実行する反復的なプロセスを確立した。
HoloHub と開発スキルの活用
HoloHub のリポジトリが実装パターンを提供し、NVIDIA が提供する開発スキルがエージェントに HoloHub での開発手順をガイドする役割を果たす。
CLI を通じた統一された実行インターフェース
./holohub ラッパーを介して呼び出される Holoscan CLI が共有の実行インターフェースとなり、エージェントが開発操作を発見し、エンジニアがコマンドを検証・再実行可能にする。
汎用エージェントへの適用検証
このワークフローは特定の AI エージェントに依存せず、例として Codex と GPT-5.6 sol max モードを使用して実装されたが、他のエージェントでも同様に機能する。
AI エージェントとエンジニアの協働による反復開発ループ
開発ライフサイクルのスキルやドキュメント、例を基に、AI エージェントがエンジニアと双方向で協力して開発・レビューフェーズを推進する。
重要な引用
HoloHub is its companion repository: a growing collection of reference applications and components that demonstrate what's possible.
The workflow proceeds in iterations: The engineer defines a goal and constraints, the coding agent inspects relevant examples...
The development skills guide the agent through the HoloHub development process.
The AI agent drives the ./holohub CLI for scaffolding and execution; the agent implementation produces application code and run/test evidence, which feeds back into the engineer's review
編集コメントを表示
編集コメント
NVIDIA は、開発者が直接使用するツールだけでなく、AI エージェントが自律的に開発タスクを遂行できる環境整備にも注力している。これは、エッジAI分野における開発の民主化とスピードアップに寄与する重要な一歩である。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
NVIDIA Holoscan は、医療画像処理からロボティクスまで、エッジでリアルタイム AI アプリケーションを構築するためのプラットフォームです。その companion リポジトリとして HoloHub があり、ここには実現可能な機能を示す参考アプリケーションやコンポーネントが順次追加されています。
私たちは、汎用コーディングエージェントが、実際の開発現場でエンジニアが利用するのと同じ例題、ドキュメント、開発ツールを活用できるかを探ってみました。
本稿では、AI コーディングエージェントを用いてリアルタイムの内視鏡画像セグメンテーションアプリケーションを構築する手順を追います。HoloHub の examples とドキュメントが実装パターンを提供し、開発スキル がエージェントに HoloHub での開発プロセスを案内します。
./holohub ラッパー経由で呼び出される Holoscan CLI は、共有実行インターフェースとして機能します。エージェントは CLI を通じて開発操作を発見でき、エンジニアも同じコマンドを検証・再現することが可能です。
開発ワークフローは反復的なプロセスとして進行します:
- エンジニアが目標と制約を定義する
- コーディングエージェントが関連する例題を検索し、アプリケーション固有のコードを実装した上で、必要な開発操作を実行するために CLI を使用する
エンジニアはコード、出力結果、テストを確認し、次のイテレーションの目標を設定します。
このワークフローはエージェントに依存しないものであり、本例では Codex を GPT-5.6 sol max モードで使用しました。記載のエージェント処理時間は概算値です。

図 1. AI を活用した開発およびレビューのワークフロー
セットアップと開発目標
全体の目的は、内視鏡用ツールのセグメンテーションを行うエンドツーエンドアプリケーションの開発です。リアルタイム推論を行い、セグメンテーションマスクをライブで可視化するとともに、統計分析の結果もレンダリングします。
既存の MONAI 内視鏡用ツールセグメンテーションモデル と Holoscan のサンプル動画を活用し、既存のアプリケーション [monai_endoscopic_tool_seg](https://github.com/nvidia-holoscan/holohub/tree/holoscan-sdk-4.5.0/applications/monai_endoscopic_tool_seg) がローカル環境で正常に動作することを確認しました。今回は、深層学習によるセグメンテーションパイプラインを再利用しつつ、包括的な可視化機能やランタイムのテレメトリ、再現可能なベンチマーク機能を追加する新しいアプリケーションの開発に注力します。
開発エージェントには、以下の情報も付与されています。
- Bash 実行権限を持つ Holoscan CLI
- agents.md を通じた段階的な開示パターンで提供されるドキュメントを備えた HoloHub リポジトリ
- holohub-app-lifecycle や holohub-debug-build-run などを含む、HoloHub の開発スキルセット
次の章では、エンジニアが主導するアジェンシー型開発ワークフローにおいて、これらがどのように連携して機能するかを示します。
イテレーション 0:目標の分解
一度に一つのプロンプトでアプリケーション全体を構築しようとするのではなく、不確実性や証拠に基づいて、最終的な目標をより小さく検証可能なエンジニアリングの反復ステップに分解することが重要です。このアプローチにより、設計上の選択をタイムリーに見直すことが可能になります。
したがって、包括的な目標は以下のような一連の見直せるトピックとして構造化できます:
開発環境は、類似する既存アプリケーションをローカルで実行するために正しく構成されていますか?
既存のモデルと動画は、独立したエンドツーエンドのアプリケーションとして動作しますか?
可視化は意味のある情報を提示していますか?
レイテンシは繰り返し測定できますか?
機能の退行を招くことなくレンダリングのスループットを向上させることは可能ですか?
各イテレーションでは、レビュー可能なコード、出力、テストが生成され、それらが次のイテレーションのプロンプトと設計方針に反映されます。
イテレーション 1: 最小限の動作するアプリケーションを作成する
最初のプロンプトは、モデルやデータの再利用を制限しつつ、成果物を定義しました。
開発者向けプロンプト 1:
Use $holohub-app-lifecycle to create a separate new Python HoloHub application for displaying endoscopic tool tracking as model outputs https://github.com/Project-MONAI/model-zoo/tree/dev/models/endoscopic_tool_segmentation. Reuse the MONAI endoscopic tool segmentation model, sample data, preprocessing, and inference. Show the model-derived mask, coverage and timeline, and useful uncertainty measurements in a polished HoloViz overlay. Do not train or modify the model weights. Make the sample video work end to end.これにより、モデルの再利用、視覚的な証拠の提示、重みの整合性を明確に保ちながら、実装の詳細はエージェントに委ねることができました。
エージェントは指定されたソースから情報を収集しました。具体的には、アプリライフサイクルスキル、近隣の HoloHub 例、プロジェクトメタデータ、および CLI ドキュメントです。
期待通り、さまざまな種類のアクションが実行されました:
- 関連する内視鏡、セグメンテーション、HoloViz、録画、テストのパターンを検証しました。特に monai_endoscopic_tool_seg、endoscopy_tool_tracking、surgical_scene_recon が有用な参考資料となりました
ドキュメント作成と標準的なスキャフォールドの生成・登録のために、./holohub create をドライランおよび実行しました。
既存の Holoscan オペレーターやアセットを活用し、アプリケーショングラフ、実行モード、テスト、ドキュメントの実装を行いました。
CLI で定義されたメタデータを用いて ./holohub run を実行することで、アプリケーションのビルドと動作確認を行いました。
結果として得られたアプリケーションは、ビデオ再生、前処理、TensorRT 推論、SDK のセグメンテーション後処理、テレメトリ、そして HoloViz を接続しました。推論とマスクの後処理は、再生されたすべてのフレームに対して実行されました。オーバーレイには、フレームから導き出された測定値が報告されています。

エージェントによる処理には 40 分かかりました。開発者は、エージェントと同じ CLI を使用してライブアプリを確認できます:
./holohub run endoscopy_tool_segmentation_dashboard visual --language python実装内容、視覚的な出力、テストケースを確認した結果、再利用されたモデルとサンプル動画が新しいアプリケーションで正常に動作することが確認できました。視覚レビューの結果、オーバーレイの測定値をより明確にする必要があることが判明したため、次のイテレーションの定義に進むことにします。
イテレーション 2:ベンチマークの実装による将来のレビューの再現性向上
2 つ目のプロンプトは、視覚的なデモを反復可能な開発成果物へと変換しました:
開発者用プロンプト 2:
Revise the visual output, add more meaningful statistics, tool area, mask motion, temporal intersection-over-union as a stability indicator, edge entropy, FPS, bounding box position, and remove values that remain unchanged during replay. Add a benchmark mode that records actual latency and plots the results in Python. Export the figures to the build folder and also show them interactively when the environment supports it.これを受け、エージェントは動的測定値とスクリーンショットの可読性を修正し、視覚的なレビューとベンチマークを明示的なアプリケーションモードとして実装しました。その結果、アプリには3 つの名前付きアプリケーションモードが用意されました。
| モード | 契約 |
|---|---|
visual | 対話型ウィンドウでソースの速度でサンプル全体を実行する |
smoke | 有限の結果を伴う 60 フレームのヘッドレス録画をクイック実行する |
benchmark | 300 フレームをオフスクリーンで処理し、測定値とプロットをエクスポートする |
表 1. ./holohub run を通じて利用可能な 3 つの実行モード
Holoscan CLI とアプリケーションライフサイクル管理機能により、詳細なコンテナやアプリケーションスクリプトのレシピを暗記する必要なく、各モードとテストを検索して実行できます。
/holohub で、modes endoscopy_tool_segmentation_dashboard --language python を実行します。
/holohub で、run endoscopy_tool_segmentation_dashboard benchmark --language python を実行します。
/test/holohub test endoscopy_tool_segmentation_dashboard --language python
``` (原文の技術表記: ` `、` `)
ベンチマークモードでは、ビデオ再生器から前処理、推論、テレメトリ、オフスクリーン HoloViz、レンダリングフレーム出力までの構成済みパスに対して、Holoscan Data Flow Tracking を使用しました。これにより、既存の [holoscan flow benchmarking module](https://github.com/nvidia-holoscan/holohub/tree/holoscan-sdk-4.5.0/benchmarks/holoscan_flow_benchmarking) で提示されたアイデアを効果的に再利用できました。エージェントによる処理には 20 分かかりました。

*図 3. 内視鏡アプリケーションのパフォーマンスベンチマーク。300 フレームにわたるアプリケーションパスのレイテンシを比較*
改訂されたベンチマークにより、より再現性の高い測定が可能になりました。このベースラインが整ったことで、次回の試行では視覚的な確認に頼らず、パフォーマンスの改善を検証できるようになります。
## 反復 3:レイテンシの調査と改善
アプリケーションの計測が可能になったことで、開発者は 3 つ目のプロンプトを発行しました。
**開発者プロンプト 3:**
Check whether the deep-learning model runs on every frame. Investigate ways to reduce latency, including approaches that take advantage of similar neighboring segmentations, and show the new benchmark results.
これに対し、エージェントは推論が依然として全フレームで実行されていることを確認しました。隣接するフレーム間でマスクを再利用し、一部の推論処理を省略できないか検討しましたが、そのためには「いつ古い出力を使用しても問題ないか」を判断するポリシーが必要です。
今回のエンジニアリングの反復では、あえて推論を全フレームで継続しつつ、まずはリスクの低いダッシュボード側のオーバーヘッドを削減しました。具体的には以下の対応を行いました。
- HoloViz の入力仕様と静的な座標テンソルは再利用し、テキストと動的な幾何形状のみを毎フレーム更新した。
- GPU からホストへの 10 値テレメトリデータのコピーを非同期でキューイングし、2 つのピンバッファに格納して、直前に完了した値を用いてレンダリングした。
同じテストシステム上で、最初の反復の実装と最終版を比較しました。最適化されたバージョンは、測定した 5 回の試行すべてにおいて高速でした。エージェントによる処理にかかった時間は 30 分です。
| **測定項目** | **導入前** | **導入後** | **変化** |
| --- | --- | --- | --- |
| レンダリングスループット | 204.0 FPS | 306.9 FPS | 50.5% 向上 |
| アプリケーションパスの平均レイテンシ | 4.891 ms | 3.247 ms | 33.6% 低下 |
| アプリケーションパスの P95 レイテンシ | 6.273 ms | 4.554 ms | 27.4% 低下 |
表 2 ベースラインと最適化された内視鏡ダッシュボード実装の性能比較

図 4 ベースラインと最適化された内視鏡ダッシュボードの最終的な性能比較
## 最終引き渡しプロンプトと再検証
3 つのエンジニアリング反復を経て、開発者はエージェントに対して別の手引きプロンプトを出力しました。
**開発者プロンプト 4:**
`Commit the implementation and keep the benchmark logs.`
進捗を確定させるため、アプリケーションとテストを再実行し、出力図およびヘッドレステストの結果を検証しました。実装内容とベンチマークの証拠は、コミットハッシュや依存関係バージョンとともに保持され、`./holohub env-check` および `./holohub env-info` を通じて確認可能です。
開発反復からは、このワークフローがどのような成果を生むかがわかります。CLI、スキル、ドキュメントの影響をより深く理解するため、次はこれらのリソースを異なる組み合わせで用いた場合の、同じ開発タスクの結果を比較します。
## 除去実験(アブレーションスタディ)
同じコーディングエージェントとサンドボックス環境、同一の設定条件下でリソース使用量を比較しました(なお、この調査は 8 月 1 日に最終実施されており、Codex 0.146.0 と GPT-5.6 Sol を最大推論能力で使用しています)。すべての評価は、最初のイテレーションで用いた単一のプロンプトに基づいています。 skill name が利用できない場合はその名称を除外した上で、新しいアプリケーションの作成を目的として行われました。
## CLI + skills + docs/examples (このブログ)
エージェントによる処理時間は 40 分、総トークン使用量は 11M トークンでした。
## CLI + docs/examples
エージェントには、CLI の利用ガイドやドキュメントへの参照、および HoloHub コードベースを含む `agents.md` が提供されました。ただし、HoloHub 開発用のスキルは用意されていませんでした。
エージェントによる処理時間は 65 分、総トークン使用量は 20M トークンとなりました。このワークフローにより実装目標を達成する完全なアプリケーションが作成されたものの、プロセスの効率は低かったです。エージェントは HoloHub リポジトリ内で類似したアプリを正しく特定しましたが、開発環境に対して試行錯誤的なプロービングが必要となる汎用的な Bash ツールを使用する傾向がありました。例えば、CLI ベースのリントツールを使うべきところを先に汎用的なリントツールを適用したり、ホスト上で直接 Python の依存関係をインストールして推論スクリプトを実行しようとしたりしていました(本来はコンテナ内で確実に動作させるべき箇所です)。
## docs/examples
エージェントには HoloHub コードベースが提供されましたが、agents.md はなく、CLI の利用に関する明示的なガイダンスもありませんでした。HoloHub 開発用のスキルも用意されていませんでした。
エージェントによる処理には 40 分を要し、総トークン数は 1500 万でした。
CLI のガイダンスは提供されていませんでしたが、コーディングエージェントはコードベース全体の例から CLI を理解し、主要な開発ツールとして活用しました。ただし、他の 2 つの設定と比較すると、コード品質は最適ではありませんでした。
- サードパーティ製のモデル設定とコードがアプリケーションコードに誤って埋め込まれていました
- Dockerfile の作成において、必要な依存関係がすべて含まれている既存の HoloHub ベースイメージを活用しませんでした
- TensorRT 推論やフォーマット変換器など、既に最適化された Holoscan オペレータの実装で無視されました。その結果、このバージョンは他の 2 つの設定より 2.6 倍低速となりました。
フォローアップのプロンプトでこれらの課題を解決できる可能性はありますが、CLI、スキル、ドキュメントや例を組み合わせたアプローチが、最もリソースオーバーヘッドの少ない開発者体験をもたらしました。
| エンドツーエンドのアプリケーション作成にかかるコスト | CLI + スキルセット + ドキュメント/サンプル (本ブログ) | ドキュメント/サンプル | CLI + ドキュメント/サンプル |
| --- | --- | --- | --- |
| エージェントによる処理時間 | 40 分 | 40 分 | 65 分 |
| トークン使用量 | 11M | 15M | 20M |
| 結果 | 標準的な Holoscan オペレーターを使用した別アプリケーション | アプリケーションの再作業が必要となり、Holoscan InferenceOp/TensorRT の代わりにカスタム PyTorch/MONAI 推論を使用 | レビュー可能なアプリケーション。より多くのエージェントによるホスト側検証とリトライ機能付き |
表 3. 3 つのスケルトン構成におけるエージェント処理時間とトークン使用量
## エンジニアと AI エージェントによる共開発ループ
本記事で紹介するのは、検証可能な小規模な開発ループです。このアプローチによって、既存モデルやサンプル動画、Holoscan コンポーネントを基盤としたエンジニアリングプロトタイプが構築されます。このプロトタイプはエンドツーエンドで動作し、複数のアプリケーションモードと自動テストを提供します。また、モデルの重みを保持しつつ、再現可能なベンチマーク証拠も記録可能です。
開発者と AI エージェントが共有する開発ループの要点は以下の通りです。`./holohub` が一貫した操作環境を提供し、スキル(skills)がプロジェクト固有の手順やチェックを定義します。さらに、サンプルコードとドキュメントがエンジニアリングの文脈を支えます。開発者と AI エージェントは同じ CLI コマンドを使用するため、開発者は目標の設定、制約条件の定義、トレードオフの評価、そして証拠の十分性の判断といった高次の意思決定に集中できます。
## 参考文献
- HoloHub: [https://github.com/nvidia-holoscan/holohub/tree/holoscan-sdk-4.5.0](https://github.com/nvidia-holoscan/holohub/tree/holoscan-sdk-4.5.0)
- Holoscan CLI: [https://github.com/nvidia-holoscan/holoscan-cli/tree/v4.5.0](https://github.com/nvidia-holoscan/holoscan-cli/tree/v4.5.0)
- HoloHub skills source: [https://github.com/nvidia-holoscan/holohub/tree/main/skills](https://github.com/nvidia-holoscan/holohub/tree/main/skills)
Nvidia カタログの HoloHub スキル:[https://build.nvidia.com/skills?filters=library%3Alibrary_holoscan&q=holohub](https://build.nvidia.com/skills?filters=library%3Alibrary_holoscan&q=holohub)原文を表示
NVIDIA Holoscan is a platform for building real-time AI applications at the edge, from medical imaging to robotics. HoloHub is its companion repository: a growing collection of reference applications and components that demonstrate what’s possible.
We wanted to explore how a general-purpose coding agent could use the same examples, documentation, and development tools available to an engineer in an actual development task.
In this post, we walk through building a real-time endoscopic tool segmentation application using an AI coding agent. HoloHub examples and documentation provide implementation patterns, and the development skills guide the agent through the HoloHub development process.
The Holoscan CLI, invoked via ./holohub wrapper, provides the shared execution interface. The agent can discover development operations through the CLI, while the engineer can inspect and repeat the same commands.
The development workflow proceeds in iterations:
- The engineer defines a goal and constraints
- The coding agent inspects relevant examples, implements the application-specific code, and uses CLI to run the required development operations
- The engineer reviews the code, outputs, and tests, then sets the goal for the next iteration
The workflow is agent-agnostic; in this example, we used Codex with GPT-5.6 sol max mode, and the agent processing times mentioned were approximate.

Setup and development target
The overall objective is an end-to-end endoscopic tool segmentation application: real-time inference with a live visualization of the segmentation masks, along with statistical analysis rendering.
We reused the existing MONAI endoscopic tool segmentation model and a Holoscan sample video, and confirmed that the existing application [monai_endoscopic_tool_seg](https://github.com/nvidia-holoscan/holohub/tree/holoscan-sdk-4.5.0/applications/monai_endoscopic_tool_seg) worked locally. We focused on a new application reusing the deep learning segmentation pipeline, and adding comprehensive visualization, runtime telemetry and repeatable benchmarking.
The agents were additionally provided with:
- Holoscan CLI with Bash execution permission
- HoloHub repository with documentation in a progressive disclosure pattern via the agents.md
- HoloHub development skills, including holohub-app-lifecycle and holohub-debug-build-run
The next sections show how the pieces work together in an engineer-guided, agentic development workflow.
Iteration 0: Divide the goal
Instead of trying to build the entire application with a single prompt, developers should decompose the ultimate objective into smaller, verifiable engineering iterations guided by uncertainty and evidence. This approach ensures that design choices are reviewed in a timely manner.
The comprehensive goal can thus be structured into a sequence of reviewable topics:
- Is the development environment configured correctly to run a similar existing application locally?
- Can the existing model and video run in a separate end-to-end application?
- Does the visualization present meaningful information?
- Can latency be measured repeatedly?
- Can rendering throughput be improved without feature regressions?
Each iteration produces reviewable code, outputs, and tests, which inform the prompts and design choices for the next iteration.
Iteration 1: Create a minimal working application
The first prompt defined the outcome while constraining model and data reuse.
Developer prompt 1:
Use $holohub-app-lifecycle to create a separate new Python HoloHub application for displaying endoscopic tool tracking as model outputs https://github.com/Project-MONAI/model-zoo/tree/dev/models/endoscopic_tool_segmentation. Reuse the MONAI endoscopic tool segmentation model, sample data, preprocessing, and inference. Show the model-derived mask, coverage and timeline, and useful uncertainty measurements in a polished HoloViz overlay. Do not train or modify the model weights. Make the sample video work end to end.That left implementation choices to the agent while keeping model reuse, visual evidence, and weight integrity explicit.
The agents collected information from the designated sources: read the app lifecycle skill, nearby HoloHub examples, project metadata, and CLI documentation.
Different types of actions were taken as expected:
- Inspected the relevant endoscopy, segmentation, HoloViz, recording, and testing patterns; monai_endoscopic_tool_seg, endoscopy_tool_tracking, surgical_scene_recon were particularly useful references
- Dry-ran and invoked ./holohub create to generate and register the standard scaffold
- Implemented the application graph, execution modes, tests and documentation using existing Holoscan operators and assets
- Built and ran the application via ./holohub run with the application metadata defined by the CLI
The resulting application connected video replay, preprocessing, TensorRT inference, the SDK segmentation postprocessor, telemetry, and HoloViz. Inference and mask postprocessing ran for every replayed frame. The overlay reported frame-derived measurements.

The agentic processing time was 40 minutes. The developer could review the live app through the same CLI used by the agent:
./holohub run endoscopy_tool_segmentation_dashboard visual --language python
After reviewing the implementation, the visual outputs, and the test cases, we confirmed that the reused model and sample video worked in the new application. Visual review also showed that the overlay needed clearer measurements, so we proceed to define the next iteration.
Iteration 2: Make future reviews repeatable by implementing benchmarking
The second prompt turned the visual demonstration into a repeatable development artifact:
Developer prompt 2:
Revise the visual output, add more meaningful statistics, tool area, mask motion, temporal intersection-over-union as a stability indicator, edge entropy, FPS, bounding box position, and remove values that remain unchanged during replay. Add a benchmark mode that records actual latency and plots the results in Python. Export the figures to the build folder and also show them interactively when the environment supports it.In response, the agent revised the dynamic measurements and screenshot readability, then made visual review and benchmarking explicit application modes. The app was implemented to have three named application modes:
| Mode | Contract |
|---|---|
visual | Run the full sample at source pace in an interactive window |
smoke | Quick 60-frame headless recording with a finite verdict |
benchmark | Process 300 frames offscreen and export measurements and plots |
*Table 1. The three execution modes available via ./holohub run*
With the Holoscan CLI and application lifecycle management, the modes and tests are discoverable and runnable without remembering a detailed container and application script recipe:
./holohub modes endoscopy_tool_segmentation_dashboard --language python
./holohub run endoscopy_tool_segmentation_dashboard benchmark --language python
./holohub test endoscopy_tool_segmentation_dashboard --language python
Benchmark mode used Holoscan Data Flow Tracking for the configured path from the video replayer through preprocessing, inference, telemetry, offscreen HoloViz, and the rendered-frame sink. It effectively reused the ideas presented in the existing holoscan flow benchmarking module. The agentic processing time was 20 minutes.

The revised benchmark provided more repeatable measurements. With that baseline available, the next iteration could investigate performance without relying on visual checks alone.
Iteration 3: Investigate and improve latency
Once the application was measurable, the developer issued a third prompt:
Developer prompt 3:
Check whether the deep-learning model runs on every frame. Investigate ways to reduce latency, including approaches that take advantage of similar neighboring segmentations, and show the new benchmark results.In response, the agent confirmed that inference still ran on every frame. It considered reusing masks across neighboring frames, which could avoid some inference work but would require a policy for deciding when stale output is acceptable. For this engineering iteration, it kept inference on every frame and first removed lower-risk dashboard overhead:
- Reused HoloViz input specifications and static coordinate tensors while refreshing text and dynamic geometry for every frame.
- Queued the current 10-value GPU-to-host telemetry copy asynchronously in two pinned buffers and rendered with the previous completed values.
We compared the first iteration’s implementation with the final one on the same test system. The optimized version was faster in all five measured trials. The agentic processing time was 30 minutes.
| Measurement | Before | After | Change |
|---|---|---|---|
| Rendered throughput | 204.0 FPS | 306.9 FPS | 50.5% higher |
| Mean application-path latency | 4.891 ms | 3.247 ms | 33.6% lower |
| P95 application-path latency | 6.273 ms | 4.554 ms | 27.4% lower |
*Table 2. Performance comparison between the baseline and optimized endoscopy dashboard implementations*

Final handoff prompt and revalidation
After the three engineering iterations, the developer gave the agent a separate handoff prompt.
Developer prompt 4:
Commit the implementation and keep the benchmark logs.
To finalize the progress, we reran the application and the tests, verified the output figures and headless test results. The implementation and benchmark evidence were retained along with the commit hash and dependency versions via ./holohub env-check and ./holohub env-info.
The development iterations show what the workflow produces. To better understand the impact of the CLI, skills and documentation, we next compare the same development task under different combinations of these resources.
Ablation study
We compared resource usage using the same coding agent and sandbox environment across identical settings (note that the study was last conducted on Aug. 1, using Codex 0.146.0 with GPT-5.6 Sol at max reasoning effort). All evaluations were based on the single prompt used in the first iteration (with the skill name removed if unavailable) with the goal of creating a new application.
CLI + skills + docs/examples (this blog)
The agentic processing time was 40 minutes, with a total cost of 11M tokens.
CLI + docs/examples
The agents were given agents.md including references to CLI usage guide and docs, as well as the HoloHub codebase. No HoloHub development skills were provided.
The agentic processing time was 65 minutes, with a total cost of 20M tokens. While the workflow resulted in a complete application that achieved the implementation goal, the process was less efficient. The agents correctly located similar apps within the HoloHub repository, but tended to use generic Bash tools that required more trial-and-error probing of the development environment. For instance, they often applied generic linting tools before CLI-based linting, or attempted to install Python dependencies and run inference scripts directly on the host (should have consistently worked in a container).
docs/examples
The agents were given the HoloHub codebase but without the agents.md and explicit guidance on the CLI usage. No HoloHub development skills were provided.
The agentic processing time was 40min, with a total cost of 15M tokens.
No CLI guidance was provided, the coding agents still gained understanding of the CLI (from the overall codebase examples) and used it as the main dev tooling. However the coding quality is suboptimal compared to the other two settings:
- The 3rd party model config and code were embedded in the application code incorrectly
- A Dockerfile was created without leveraging the existing HoloHub base image already has all the required dependencies
- Existing optimized Holoscan operators such as TensorRT inference and format converter were ignored in the implementation, as a result this version is 2.6x slower then the other two settings
While follow-up prompts could potentially address these issues, the combination of CLI, skills, and documentation/examples provided the best developer experience with the lowest resource overhead.
| Cost to first end-to-end app | CLI + skills + docs/examples (this blog) | docs/examples | CLI + docs/examples |
|---|---|---|---|
| Agentic processing time | 40 min | 40 min | 65 min |
| Token usage | 11M | 15M | 20M |
| Outcome | Separate application using standard Holoscan operators | Application required rework, used custom PyTorch/MONAI inference instead of Holoscan InferenceOp/TensorRT | Reviewable application, with more agentic host-side validation and retries |
*Table 3. Agentic processing time and token usage across three scaffolding configurations*
A co-development loop for engineers and agents
This post follows a small, verifiable development loop. The result is an engineering prototype built on an existing model, sample video, and Holoscan components. It runs end to end, provides several application modes and automated tests, preserves the model weights, and records reproducible benchmark evidence.
The main takeaway is the development loop shared by the developer and the agents: ./holohub supplies consistent operations, the skill encodes project-specific sequences and checks, and examples and documentation provide engineering context. The agent and the developer use the same CLI commands. The developer can focus on defining the objectives, setting the constraints, evaluating trade-offs, and deciding whether the evidence is sufficient.
References
- HoloHub: https://github.com/nvidia-holoscan/holohub/tree/holoscan-sdk-4.5.0
- Holoscan CLI: https://github.com/nvidia-holoscan/holoscan-cli/tree/v4.5.0
- HoloHub skills source: https://github.com/nvidia-holoscan/holohub/tree/main/skills
- HoloHub skills at Nvidia catalog: https://build.nvidia.com/skills?filters=library%3Alibrary_holoscan&q=holohub
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み