La programmation Pascal qui finit par un diff à relire

Ce que l'agent peut faire dans un projet

• Fichiers read_file, write_file, edit_file, grep, glob et list_dir fonctionnent dans le dossier de travail du chat. Une unité .pas, un fichier .dpr ou un formulaire texte .dfm sont à une demande de distance. Un compteur indique le nombre de fichiers créés, modifiés et lus.
• Shell exécute votre commande de build, de test ou de formateur sur Windows, dans WSL ou via SSH sur un serveur que vous possédez. La réussite est jugée par le code de sortie réel, et les commandes dangereuses sont bloquées avant exécution.
• Web web_search trouve des pages et http_get lit une page de documentation, ce qui aide lorsque vous avez besoin de la signature exacte d'une routine ou de la formulation d'un message d'erreur. L'agent lit la page ; vous décidez de ce que vous en faites.
• Captures d'écran et images ocr lit le texte d'une capture d'écran enregistrée, par exemple un message du compilateur que vous n'avez pas pu copier depuis la fenêtre, et gen_image enregistre de véritables fichiers image dans le dossier de travail.
• Orchestration task lance des sous-agents en parallèle pour des parties indépendantes d'une tâche, run_on_model envoie une étape difficile à un modèle plus puissant, et skill réutilise un jeu de règles enregistré, comme une routine de contrôle de version pour les branches et les commits.
• Modes d'approbation Auto-run agit immédiatement, Ask first met en pause avant les actions qui modifient quelque chose et affiche le diff à accepter, et Plan only rédige un plan sans rien exécuter. Les plans survivent aux redémarrages de l'application.
• Cron exécute une invite à intervalles réguliers, par exemple une demande nocturne pour lancer votre commande de test et rapporter le code de sortie. Définissez la planification une fois, et lisez les résultats dans le chat le lendemain matin.
• Modèles connectez un fournisseur d'IA cloud via un point de terminaison API, un modèle s'exécutant localement sur votre PC ou le modèle intégré. Le bouton Test affiche le temps de réponse et la fenêtre de contexte de la connexion.

Quatre tâches issues de projets réels

Lire une unité héritée

Un développeur Delphi qui hérite d'un projet ouvre souvent une unité que personne n'a touchée depuis des années. Demandez à Arraydeck de l'expliquer. L'agent appelle read_file, puis décrit la section interface, la section implémentation et la clause uses en termes clairs, et grep montre où ses procédures sont appelées depuis d'autres unités. Rien n'est écrit. Utilisez la réponse comme une carte, pas comme une preuve : comparez chaque affirmation avec la source, ouvrez l'unité dans votre propre éditeur et lancez votre commande de compilation, qui rapporte le code de sortie réel, avant de modifier une ligne du projet. Répétez la demande pour l'unité suivante lorsque la première est claire.

Faire gérer l'Unicode à une routine de chaînes

Pour convertir du code Unicode dans une chaîne, trouvez d'abord la routine qui construit ou divise le texte. L'agent exécute grep pour le nom de la fonction, lit l'unité avec read_file et propose une modification avec edit_file. Dans Ask first, le diff attend votre validation. Shell exécute ensuite votre commande de build et votre commande de test, et chaque carte affiche le code de sortie réel. Les chaînes utilisent des guillemets simples et := assigne une valeur, donc lisez le diff par rapport au fonctionnement de l'ancienne routine, testez-la avec du texte de vos propres données et rejetez la modification si un cas se comporte différemment. Conservez une copie de l'ancienne routine jusqu'à ce que les tests soient concluants.

Réduire les retours dans une fonction

Les gens débattent du nombre de retours qu'une fonction devrait avoir, et Arraydeck laisse ce choix à vos soins. Choisissez une fonction avec plusieurs sorties et demandez une version qui définit Result une seule fois. L'agent lit l'unité, modifie la fonction et affiche la modification sous forme de diff. La programmation Pascal conserve la valeur de retour dans Result, donc la modification est petite et facile à vérifier ligne par ligne. Lancez vos tests ensuite, car l'agent ne peut pas promettre que la nouvelle version se comporte comme l'ancienne, et rejetez le diff si un test échoue. Une petite modification revue vaut mieux qu'une grosse réécriture.

Vérifier comment un formulaire utilise les boîtes de dialogue

Pour voir comment utiliser correctement les dialogues FMX dans votre propre projet, demandez à l'agent de trouver tous les endroits où une boîte de dialogue est affichée. Il exécute grep sur les fichiers .pas, ouvre les correspondances avec read_file et rédige une courte liste dans le chat, nommant chaque unité et chaque gestionnaire d'événements. Les événements tels qu'un clic sur un bouton sont des procédures du formulaire, donc la liste se lit comme une table des matières. Passez à Ask first avant de demander des modifications, révisez chaque diff et testez les formulaires vous-même, car l'agent ne conçoit pas les formulaires visuellement. Répétez pour chaque formulaire.