Blog: Thoughts on use of AI to get your project going (More Posts)
With every passing day, I rely on AI more and more for my coding. Not necessarily for every keystroke I write, but for most.
I can use it just to get my project on its way. Because finding a way to get started can be just as daunting as actually writing the code and getting through the individual tasks.
Even with AI tools available, starting development on an app with many moving parts can feel daunting. This project needed a defined markup structure, dynamic element creation, a backend database, and actions to modify stored data. Initially, I wasn’t sure how to start, but inspiration struck unexpectedly during a walk, which gave me some clarity on an approach.
I decided what I’d do was to start with a simple PHP script that would create a database, and then I’d populate it with some sample data. Data that matched the initial markup. Here’s an example.
<h3>Todo</h3>
<ul id="incomplete-tasks">
<li><input type="checkbox"><label>Pay Bills</label><input type="text"><button class="edit">Edit</button><button class="delete">Delete</button></li>
<li class="editMode"><input type="checkbox"><label>Go Shopping</label><input type="text" value="Go Shopping"><button class="edit">Edit</button><button class="delete">Delete</button></li>
</ul>
<h3>Completed</h3>
<ul id="completed-tasks">
<li><input type="checkbox" checked><label>See the Doctor</label><input type="text"><button class="edit">Edit</button><button class="delete">Delete</button></li>
</ul>
</div>I’d then have another copy of the database that I’d used to test database development on, so I’d test out each of the Database CRUD Operations. We could use 1 copy of the database to return the app to its initial state and the other to test Use Cases and continue development.
I have a copy of the original JavaScript in another version of the application, so I’ll have access to that if I need it. Originally, it felt right to remove the script that was there and start again.
The markup and CSS will remain the same, although I have converted that to SASS to update it to reflect more modern development and added some enhancements to the UI, such as colour transitions.
e.g.
p > button {
transition: color .3s ease-in-out;
&:hover {
color: $btn---col--addtask;
}
}So this is one project with moving parts that require a defined markup structure, new elements within that structure to be created, a backend database, actions that affect what is in that database, and how it changes.
I wasn’t clear what I wanted to prompt the AI with to get started. Well, later on, I took a walk and something came to my mind. I wasn’t planning on having it happen that way. But it did. It’s as if a mind sent a neuron to work on the problem, and it came back with an answer in the form of sudden thought.
To ask the model to create a schema with data that matches the unfinished ToDos and completed task data that is present in the given markup. We would then create a copy of the given .db file and leave that free so we always have a copy of the application’s initial state to go back to.
"Study the index.php file and use example tasks to create a database schema that matches the initial application state.
i.e. "Pay Bills" - incomplete - not in edit state
"Go Shopping" - incomplete task - in edit state
"See The Doctor" - completed task - not in edit state.
Tasks can be toggled into edit and non edit state by clicking the edit button for each task - regardless of whether it is a complete or incomplete task."I’m only asking the AI to replace what is there right now. But only right now. However, I wouldn’t be surprised if GTP-5 implemented “PUT” to add data via the input box.
<div class="container">
<p>
<label for="new-task">Add Item</label><input id="new-task" type="text"><button>Add</button>
</p>
...Well, this time it didn’t do that. And I’m glad of this. It allowed me to perform database generation cleanly. So that’s what I did. I created 2 copies of the database. One that matched the initial task state that I was given, so we’d always be able to go back to it, and the other (task.db), for testing and development.
I adjusted the script to load tasks from SQLite3, fixing typos in selectors, and removing the #incomplete-tasks and #complete-tasks child elements, so tasks persisted in the browser after refresh. The read-only endpoint confirmed the database was being read successfully. The next step is updating the SQL script to accept and store changes in the database.
Finally, the README could include a “Use Cases” section for testing scenarios, such as clearing all initial data from the database. This would help with development and debugging while keeping the application’s initial state intact for reference.
To recap, the project now has 2 development databases, one for the initial state and one for testing. The initial state is loaded to match the tasks supplied in the original markup. The project includes a read-only endpoint. No modifications to the front end currently affect the database.
It will be fun to see how to make changes to a database based on that kind of interaction. (PUT).