Considerations on Using ChatGPT Codex and Claude Code in Software Projects

On how I used two different AI Agents as collaborators during the development of a plugin for WordPress and my impressions on this new way of conducting a software development project.

Introduction

For a few weeks now, during weekends or after dinner, I’ve been working on developing a plugin called Asset Lending Manager (ALM) for the astronomy association I belong to. Since I’ve already detailed its features in a previous post [1], here I’ll just say that its purpose is to manage and facilitate the lending of devices and various objects within an organization, and then I’ll focus on the development method used.

From the early stages, I noticed I was proceeding with difficulty, without enthusiasm, and it seemed like yet another project to complete with the usual approach and typical problems; in short, the prospects weren’t great because I had taken on this work and had to handle it alone.

At a certain point, however, after reading some enthusiastic posts on social media, I decided to try something new: asking for help from collaborators, ChatGPT and Claude.

I’ve now reached the end of the first month of subscription to these two platforms and I must say I don’t regret it, both because it was a stimulating and interesting experience, and because just a few days ago, I released the first version of this product.

Development Method

I don’t know if what I did can be called “Vibe coding” or has another name, and I’m ready to accept criticisms and suggestions; in the meantime, I’ll share the way I approached this situation and how I created a “context” for the AIs that I think I will reuse, with appropriate modifications, in other projects as well.

First of all, after opening the agents’ terminals within the Visual Studio Code (VSC) prompt, I discovered that they were looking for specific files in the current directory: ChatGPT codex looks for a file called AGENTS.md, while Claude Code looks for a file called CLAUDE.md.

It’s clear that the purpose of these files is to provide directives and explanations to the agent automatically, to avoid having to rewrite them each time and to ensure they are always the same.

So I thought of creating a more detailed “context” that included various aspects of the project: description, features, development rules, etc.

I created a sort of startup procedure (bootstrap), a sequence of files with a specific purpose, to be read by the AI in a defined order starting from the one read by default by each of them.

Before describing the files, it should be noted that the project I’m talking about:

  • was in a GIT repository that I cloned locally,
  • was already configured to be properly managed with VSC,
  • was already set up to use PHPCS as a linter and xdebug for debugging,
  • I had already activated a monthly subscription to ChatGPT and Claude (currently, to try ChatGPT Codex, a free subscription is enough, while to try Claude Code, at least a Pro subscription is needed) [4].

It’s also worth mentioning that now there are integrated plugins within VSC and there’s no need to invoke the agent from the prompt, the bootstrap procedure remains the same.

That said, the files added to the project are as follows:

  1. AGENTS.md: File automatically read by ChatGPT Codex, essentially serves to redirect the agent’s attention to the AI_RULES_CHATGPT.md file.
  2. CLAUDE.md: File automatically read by Claude Code, essentially serves to redirect the agent’s attention to the AI_RULES_CLAUDE.md file.
  3. AGENTS/AI_RULES_CHATGPT.md: Entry point in the bootstrap phase for ChatGPT. This file defines the bootstrap sequence and contains work rules that apply only to ChatGPT.
  4. AGENTS/AI_RULES_CLAUDE.md: Same as the previous file but valid only for Claude.
  5. AGENTS/AGENTS_README.md: Indicates the reason for creating the AGENTS folder and briefly describes the content and purpose of each file in it.
  6. AGENTS/PROJECT.md: Description of the project, product scope, main features, and roles. It’s the functional view of the plugin: what it does, who it’s designed for, and which parts are already available. It’s useful for quickly understanding the product’s goals and boundaries.
  7. AGENTS/ARCHITECTURE.md: Description of the architecture, main modules, key directories, public hooks/endpoints, data model, technology stack, and references. It’s the technical map of the system. It helps understand where to intervene in the code and how the components connect.
  8. AGENTS/AI_BEHAVIOR.md: This file specifies how the agent should behave and operate during development, research, and issue resolution. It includes operational triggers, Definition of Done, and backlog management.
  9. AGENTS/CODING_STANDARDS.md: Coding constraints and quality standards. Ensures adherence to WordPress Coding Rules in PHP/HTML/CSS/JS and i18n, and also defines practical rules on security and style. It’s the reference to follow during development and refactoring.

The first two files are located in the project root, while the others are gathered in a directory called AGENTS, except for the PROJECT.md and ARCHITECTURE.md files, which obviously change from project to project, the others can be reused (and I have already done so) in other projects with few modifications.

Also in AGENTS, there are three other files that are read only in certain cases as specified in the previous files:

  1. AGENTS/GIT_WORKFLOW.md: Specifies how the GIT repository should be used, how to make commits, and what checks to perform before a commit.
  2. AGENTS/ISSUES_TODO.md: List of open issues and tasks to address. Allows prioritizing work by criticality and category.
  3. AGENTS/ISSUES_RESOLVED.md: Archive of resolved issues.
The bootstrap phases change depending on the agent:
  • CHATGPT CODEX -> AI_RULES_CHATGPT.md -> AGENTS_README.md -> PROJECT.md -> ARCHITECTURE.md -> AI_BEHAVIOR.md -> CODING_STANDARDS.md
  • CLAUDE CODE -> AI_RULES_CLAUDE.md -> AGENTS_README.md -> PROJECT.md -> ARCHITECTURE.md -> AI_BEHAVIOR.md -> CODING_STANDARDS.md

What happens after this setup?

At the first request or when explicitly asked, the agent reads and executes the bootstrap, creating a very valid context on which it can operate appropriately.

At this point, it’s possible to start asking the same agent about the project’s status and what to start working on, actually, I never do this because it’s specified in the AGENTS directives to give suggestions on how to proceed when starting work or completing a task, I always have indications on the next task to work on.

Trigger Commands

One very useful thing that I often use these days are trigger commands, basically, I’ve defined phrases that trigger a whole series of activities by the agent and the production of certain types of reports:

  • Do a complete review of file X: performs a complete review of the file (bugs, security, style, compliance, lint, and HTML checks where applicable) and presents a report on screen.

  • “Check URL X”: initiates a page audit for HTML/JS quality, loading efficiency, responsiveness, accessibility, and performance.

  • Check for new issues: rereads the open backlog and identifies any problems to address based on priority and impact.

  • “Give me a tabular summary of issues: produces a table by category/severity with totals and initial recommendations and suggests 4 to 5 issues to start with

They are very useful for resuming work, summarizing the project’s status, and performing complex checks and verifications.

Temporary Files

Another thing I’ve found useful, when implementing new features, refactoring, or in all those cases where various possibilities need to be considered first, is to have a document written (in a temporary file that can be deleted once the task is finished) with all the “reasonings” made with the agent.

You can also have the text written by one agent analyzed by another agent and get opinions.

If you prefer to pause the implementation and think about it, you can then resume the discussion starting from that document.

And anyway, before performing the task, you will need to tell the agent to reread that file.

If the task involves numerous steps because it’s complex, then, if they are described in a numbered list, they can be implemented one at a time to always keep the situation under control.

System Configuration

Configuring the system on Windows is very simple. Just have a recent version of Node.js on your PC and then run the following commands:

npm i -g @openai/codex
npm install -g @anthropic-ai/claude-cod

For Claude Code, actually, at this moment, installation with npm is deprecated, and two other installation methods via the native installer are recommended.

The first involves first installing Git for Windows (Git.scm) and then installing with one of these two commands depending on the shell used:

#With POWERSHELL:
irm https://claude.ai/install.ps1 | iex

#With DOS Prompt:
curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

The second involves using WSL2 (Windows Subsystem for Linux):

curl -fsSL https://claude.ai/install.sh | bash

I installed both with npm because at the time it was the only option I had, in the coming days I’ll try using WSL2.

Considerations

After a month of working with my two collaborators, I think it’s time to make some reflections.

This new programming method has made me faster and more productive, I can implement a large number of features on my own and keep bugs and reports under control more easily. It’s useless now I believe there’s no going back, the improvements and results of daily work are so superior that it’s unthinkable to go back and do less and worse.

During each session, I always try to divide the work into small tasks and implement or correct them one at a time; this way, the number of files and lines of code modified or added is always low, and before each commit, I can easily check what has been done.

The agents could also implement entire programs with a single prompt, but this would produce code completely unknown to the programmer.

Another suggestion is to always proceed by creating or having tests created: unit, integration, and functional tests to never risk publishing versions that introduce bugs or regressions.

So the concept I feel like asserting is that agents are excellent copilots, but one should never risk delegating all the work to them out of laziness or haste and not monitor the progress of a project step by step. If this were done, the results would be disastrous because you would have a product you know nothing about, don’t understand how it works, and are no longer able to manage.

 

 

Sources and References

  1. Asset Lending Manager Project (ALM) on GitHub.com.
  2. OpenAI ChatGPT Codex.
  3. Claude Code.
  4. Subscription rates: OpenAI’s ChatGPTAnthropic Claude.

*** Note: This article was translated with an automated workflow created with n8n and OpenAI.

3 months ago

Leave a Reply

Your email address will not be published. Required fields are marked *

Comment moderation is enabled. Your comment may take some time to appear.