Plans d'implémentation
How PlanToCode enables confident adoption of AI coding agents through human-in-the-loop review, granular file-by-file plans, and clear handoff workflows.
Review and approve every plan before execution. File-by-file granularity keeps scope explicit and changes aligned with your requirements.
Gouvernance avec humain dans la boucle
PlanToCode keeps planning human-in-the-loop so you can review, edit, and decide when to hand off a plan for execution.
Plans are designed for a structured review workflow before any code modifications begin:
- Réviser :Les plans s'ouvrent dans l'éditeur Monaco où les réviseurs peuvent examiner chaque modification proposée avec coloration syntaxique complète et outils d'édition professionnels.
- Modifier :You can directly modify steps, adjust approaches, add constraints, or remove risky operations using VS Code editing features.
- Demander des modifications :Generate alternative plans or merge drafts with custom instructions to converge on the approach you want.
- Approuver :When you are ready, you can hand the plan off to a coding agent or developer for execution.
- Discard:If a draft isn't useful, you can delete it from the session list.
This workflow keeps execution aligned with the plan you reviewed and helps prevent surprise changes.
Granularité fichier par fichier
Implementation plans use a highly granular structure that breaks down development tasks on a file-by-file basis, with exact file paths corresponding to the project's repository structure. This granularity makes scope explicit before any code is touched.
Chaque étape d'un plan déclare explicitement quels fichiers seront :
- Modifiés (avec plages de lignes spécifiques et modifications décrites)
- Créés (avec chemins de fichiers complets et structure de contenu initiale)
- Supprimés (avec justification et analyse des dépendances)
- Référencés (pour le contexte mais non modifiés)
Reviewers can immediately identify if critical legacy code will be modified, if breaking changes are proposed, or if the plan touches files that require additional scrutiny.
L'approche fichier par fichier permet également une transmission précise des plans approuvés aux agents de codage. Au lieu d'instructions vagues comme « mettre à jour le système d'authentification », les agents reçoivent des spécifications exactes : « modifier src/auth/session_manager.rs lignes 45-67 pour ajouter la rotation de token, créer src/auth/token_store.rs avec la structure suivante... »
Structure de données du plan
Les plans d'implémentation sont stockés comme des réponses LLM brutes avec des métadonnées associées. Le texte de la réponse est préservé exactement tel que généré, tandis que les métadonnées structurées suivent le contexte et l'utilisation du plan.
Champs de métadonnées
- planTitle - Titre généré ou fourni par l'utilisateur pour le plan
- summary - Résumé lisible par un humain du plan
- sessionName - Nom de la session qui a généré le plan
- isStructured - True for implementation_plan jobs; false for merge outputs
- isStreaming - False pour les plans terminés (true pendant la génération)
- planData - Contient agent_instructions (optionnel) et le tableau steps
Exemple de métadonnées
{
"planTitle": "Authentication System Refactor",
"summary": "Implementation plan generated",
"sessionName": "my-project",
"isStructured": true,
"isStreaming": false,
"planData": {
"agent_instructions": null,
"steps": []
}
}Structure du plan d'implémentation
Format XML pour les plans d'implémentation avec granularité fichier par fichier et métadonnées.
D'où viennent les plans
Chaque plan correspond à un job en arrière-plan dans la session actuelle. Le panneau s'abonne aux données de plan, garde une trace de quel plan est actuellement ouvert et expose la navigation entre les jobs plus anciens et plus récents. Ce comportement réside dans useImplementationPlansLogic et le composant de panneau environnant.
ImplementationPlanProcessor gère la génération de plan. Il lit les fichiers pertinents, génère optionnellement une arborescence de répertoires basée sur les répertoires racine sélectionnés et assemble un prompt unifié pour le LLM.
Plan responses are stored in the background_jobs table with metadata including planTitle, summary, sessionName, and token usage. The raw LLM response is preserved for review and debugging.
Les plans sont streamés via le LlmTaskRunner avec des événements de progression en temps réel. Des avertissements de tokens sont journalisés pour les prompts dépassant 100k tokens mais le traitement continue avec le contenu complet.
Pipeline de génération de plan
Le ImplementationPlanProcessor orchestre la génération de plan en chargeant le contenu des fichiers, construisant le contexte et streamant les résultats via le LLM task runner.
Inputs: Contexte de session, description de tâche, fichiers pertinents sélectionnés, arborescence de répertoires optionnelle (configurable via le flag include_project_structure) et flag de recherche web pour la recherche externe.
Prompt assembly: Utilise prompt_utils::build_unified_prompt pour combiner la description de tâche, le contenu complet des fichiers (sans troncature) et l'arborescence de répertoires dans un format spécifique au modèle avec des comptages de tokens estimés.
Output: Réponse LLM brute stockée comme JobResultData::Text. Les métadonnées incluent planTitle, summary, utilisation de tokens, statistiques de cache et coût réel.
Display: Les réponses sont streamées vers l'UI via des événements de progression. Les plans sont rendus dans un VirtualizedCodeViewer basé sur Monaco supportant la coloration syntaxique et les actions de copie.
Réviser les plans avec Monaco
Le contenu du plan est rendu via le VirtualizedCodeViewer partagé, qui encapsule Monaco Editor. Le visualiseur détecte automatiquement les langages courants, supporte les actions copier-vers-presse-papiers, virtualise les très grands plans et offre des métriques optionnelles comme les comptages de caractères et la coloration syntaxique.
Quand un plan est ouvert, le panneau résout le plan actif par identifiant de job, passe le contenu à Monaco et permet aux réviseurs de se déplacer entre les jobs voisins sans perdre la modale actuellement ouverte.
Contexte et métadonnées pour la gouvernance d'entreprise
Le panneau stocke quelles racines de dépôt ont été sélectionnées pendant le workflow de découverte de fichiers pour que les actions de suivi réutilisent la même portée. Il enregistre également les métadonnées spécifiques au plan, comme le répertoire du projet et tout contenu de prompt préparé, pour que les prompts en aval puissent être générés ou copiés sans recalculer le workflow.
L'estimation de tokens s'exécute avant que les prompts ne soient copiés. Le panneau appelle la commande d'estimation de tokens avec le répertoire du projet, les fichiers sélectionnés et le modèle actuellement choisi, affichant les totaux de prompt système et utilisateur pour que les équipes puissent rester sous les limites du modèle.
Plan metadata persists with each job so you can review which inputs were used (task description, selected roots/files, model settings) and compare drafts later.
Travailler avec plusieurs plans
Plans can be merged, deleted, or reopened later. The panel keeps a list of selected plan identifiers, manages a dedicated modal for terminal output tied to a plan, and exposes navigation helpers so reviewers can page through earlier plans without closing the viewer. Terminal access, prompt copy controls, and merge instructions all share the same job identifier so plan history stays consistent.
Prêt à adopter les agents de codage IA en toute sécurité ?
Les plans d'implémentation avec humain dans la boucle sont disponibles dans l'application bureau PlanToCode. Téléchargez la version pour votre plateforme pour expérimenter un développement assisté par IA sûr et gouverné.