Initial Coding Projects: Building Infrastructure with AI (and Learning Along the Way)
I had my "Hello World" project created and was ready to try something more interesting - but first, I needed better infrastructure. The first thing I wanted to build was a reusable Command Line Interface (CLI) for Java projects. My goal wasn't to build a run-and-done program, but an interactive tool I could actually work with and extend. The second project focused on generating meaningful metrics - file counts by type, lines of code, and eventually test coverage.
CLI Project Prompts and Results
There is far too much ChatGPT output and discussion to include in this article, but here is the prompt that kicked off my first real Java coding project to create a reusable CLI. If you're interested in the exact prompts that I used, please let me know, or, even better, I'd encourage you to try it yourself in the AI of your choice and see how the project evolves!
If you'd like to see the final code for this project, please check out project-cli on my GitHub account.
Rob: I would like to create java source files that implement a command line interface. I would like it to be able to do the following: Once launched, it should read user input from the command line, execute the requested command, and display any return values. This should be a generic command line interface that can be reused with future projects. A feature should be tab completion. If the user hits tab, available commands should be listed. If any user input exists, that should be used to narrow the choices available. If an example program is necessary, please generate one that can be used to demonstrate the command line interface.
ChatGPT came back with around 10 source files that included example commands and build instructions. The guidance itself was also surprisingly helpful.
ChatGPT: Below is a reusable, “drop into any project” Java CLI framework with:
To get reliable tab completion on real terminals, you should use a console library. The most common choice is JLine 3.
In the space of a few commands, I asked ChatGPT to update the files to use JLine, after looking at the library and what its license was, which ChatGPT also helped me with. I wasn't too worried about the licensing for my little project, but it's a good habit to be in. From there, after ChatGPT had given me some options, we moved forward with the following:
Interestingly, we went through a number of errors before the project would compile. I started looking at each error and trying to determine what was happening and how to fix it, but then I had what felt like a simple question: why wouldn’t ChatGPT fix it? Could it?
Yes, it could and it did. I told ChatGPT:
I am getting a compile error in CliEngine.java on the following line. line = reader.readLine(ui.prompt(appName)); The error is: The method readLine(Character) in the type LineReader is not applicable for the arguments (AttributedString)
Before I knew it, ChatGPT told me that I had a JLine API mismatch, which was quite interesting. In fact, the AI generated nearly two pages of explanation that included what was happening, the correct JLine way to use a colored prompt, the proposed fix, the corrected code snippet, why this was the correct solution, what the wrong solution would have been and why, a summary, and a prompt for other suggested directions.
This was very interesting to read, and then we continued iterating:
Recommended by LinkedIn
Well, at this point, it's probably worth acknowledging a few mistakes. They weren't insurmountable, but they caused more rework than necessary, and if I had included some instructions up front, I wouldn't have to do a fairly substantial refactor at this point.
Once I had Codex working and logged into my ChatGPT account, the changes were made very quickly and I took the opportunity to save the project and later generate metrics. Here is an abridged set of metrics, which were generated using the following project. You can read more about the project and see all the metrics in the project README file. I'm guessing this project took me about 4 or 5 hours, which likely would have been much less knowing what I know now. However, creating this much code in that little time using libraries I wasn't familiar with is a big development win!
Files counted: 30
Total size: 33.9 KB
Tool files excluded: 2
Line counts (heuristic):
Total: 1217
Code: 903
Comment: 98
Blank: 216
By extension:
.java files= 21 lines= 927 code= 666 cmt= 90 blank= 171
.xml files= 4 lines= 207 code= 181 cmt= 0 blank= 26
.sh files= 4 lines= 81 code= 54 cmt= 8 blank= 19
.md files= 1 lines= 2 code= 2 cmt= 0 blank= 0
Metrics Tool
I'm going slightly out of chronological order with this tool, since I wrote it later than some of my other code projects, but metrics are an important part of how I work. I like to know how many lines of code I'm creating, how quickly I can take a project from an idea to a state where I'm happy with it, and see how well it has been tested. I also wanted these metrics in place to include in this article series.
The final code for this project is on my GitHub account under project-codemetrics.
I thought creating this tool would be a great opportunity to write some Python, which is a language I worked with extensively years ago and still enjoy, but I could definitely use a refresher on. It's an especially good opportunity as this metrics tool is standalone and file reading and parsing is a strong point of the language.
This is the prompt I used to initiate the project. While I wanted a Python tool, I left it open to a scripting or other solution as an opportunity to learn if something else was a better option:
I would like to create a tool that I can use to provide metrics on software development projects. This is what I'm thinking. The tool can be in python or a zsh shell script. (Or both!) It will recursively navigate all files and folders from the folder it is run in. The tool will count the total number of files and lines of code for the project. Build files, xml files, source files, and similar all will be included. I'd like the same script to be run against Java, Python, and JavaScript projects, and it is acceptable to have a flag to specify which type of project it is. (e.g. --Java, --Python, --JS, etc) If there are other common metrics of a similar type, please suggest or add them.
ChatGPT quickly generated the Python code as well as how to run it, and a zsh wrapper to run the tool if I wanted it. The AI also suggested a number of other potentially useful metrics, and I decided to add a test ratio to it to see what files had been tested. I also found a bug - the script was counting its own files when creating metrics for a project, which is not something I wanted. Including the tool skewed the results for every project going forward, so I asked ChatGPT to address the problem. It suggested either explicit self-exclude by filename, auto-exclude by "tool directory", or a hard-coded filename ignore. Each of these options came with a full explanation, plus a recommendation for my particular use. (Option 1 plus existing directory excludes)
While this was a smaller project, it was a very interesting one to write. It also took less than an hour to create the project to the point where I was happy with it. More information is in the project README file on GitHub.
Profile: All Files Counted: 43
Total size: 95.1 KB
Text files skipped (binary/unreadable): 0
Tool files excluded: 2
Line counts (heuristic):
Total: 2578 Code: 2204 Comment: 5 Blank: 369
By extension:
.java files= 33 lines= 2379 code= 2038 cmt= 0 blank= 341
.sh files= 5 lines= 28 code= 16 cmt= 5 blank= 7
.xml files= 4 lines= 129 code= 115 cmt= 0 blank= 14
.md files= 1 lines= 42 code= 35 cmt= 0 blank= 7
Summary
Overall, I learned a lot from both of the above projects. With these tools complete, I was ready for a more interesting set of projects, which I'll cover in my next article.
Please comment or message me with any feedback you may have. I'm interested in hearing about your experiences and learning in this area!
Yeah, this matches what we're seeing in dev workflows more broadly these days.