Conversational AI Based Web Development
Using GitHub CoPilot and Claude Sonnet 4 Model

By James McCarthy

In a way, this kind of feels like cheating, but I wanted to see how far I could get with developing a web-app using AI tools and frameworks with only conversational AI based development. The word conversational is being defined as using a casual, know enough to break things tone of voice when composing prompts. The result is a fully functional application that showcases the power of modern web development in a rapidly evolving AI landscape using Microsoft's VS Code with GitHub Copilot and Claude Sonnet 4 model.

Technologies used included: Next.js, React, TypeScript, Material-UI, Tailwind CSS, MySQL, Tempest Weather Station API, oAuth using Google Sign-in, VS Code using GitHub Copilot with primarily Claude Sonnet 4 model and some GPT4.1 model and hosted at Vercel.

Case Study | Next Steps | Challenges | Changelog

Case Study

It all started with an idea prompt.

I intentionally created the prompt to be written in a casual tone with the minimal amount of technical jargon, but enough to be dangerous. At first this worked well, but as I iterated overinstructions I did find that more technical and specific I was the better Claude performed on the first pass. Lets get started and you will see how my prompts had to evolve over time in order to accomplish the goal.

prompt:
I have an extra domain, hikerbikerwriter, and I want you to create a website that represents those three words. They will include the following apps. 1) Markdown Editor: with PDF Export, 2) Brew Day Log: a digital logbook for tracking beer brewing sessions. For the homepage I want to include the logo I just made with chatGPT centered in the browser as well as vertically aligned middle. There should be two buttons linking to the apps.

Screenshot of the development process

I watched Claude work in the CoPilot chat panel creating and responding to its own prompts. After about 10 minutes he prompted with permission to “Start a Development Server“. I clicked the continue button and he opened the VS Code Terminal panel and the words “npm run dev“ appeared and executed. I was shocked, amazed, impressed and a little panicked. Claude interpretted this first prompt so well that it even decided on its own to use the Next App router vs Page router. It decided to use Tailwindcss for styling and had made every major architectural decision for the app and executed it until the build was without error.

The only part it had it trouble with was the UX. For example, while it created the initial scaffolding of pages, components and css Claude had difficulty creating consistent design elements like headers and footers across the first 3 components. So I found the header I liked most and cleaned up the tailwindcss then used another slightly more technical prompt to help Claude clear everything up - fingers crossed.

prompt:
the headers could use some cleanup. I like the header in the fieldnotes app, so please use that as a reference. Also, change the “Back Home“ link to use Material UIs back arrow icon. Also, add an “Apps“ menu to the right of the back home link separated with a “|“. The apps link should be a dropdown menu with the following items: 1) Markdown Editor, 2) Brew Day Log. Each menu item also wil have an icon to the left of the label. The dropdown should be styled using Material UI components. After separate with another “|“ and include the title of the page in bold.

prompt:
Great job. Can you now also do this to the other component pages so they all look the same? And, can you add a global footer to the pages that have the basic Copyright information “©/™ hikerbikerwriter“ and below that a line that reads “This project is entirely generated using Co-Pilot AI with Claude Sonnet 4 model and Tempest Weather Station API, hosted at Vercel.“

Claude did a great job with the header and footer, but I had to use some terminology that I know the non-technical-developer person I am not sure would have thought to use. These included references to tailwindcss and manual editing of their class syntax, as well as another reference to the Material UI library and the term “label“ to describe the icon location.

While looking at the homepage I felt it would be cool to show the weather conditions and temperature from my personal weather station in the backyard. After a quick gogole search I discovered the Tempest Weather Station API and was able to get an API key. I then asked Claude to integrate it into the homepage and that was that I had weather above the mountain peaks and fancy teal to white gradient background that claude himself decided would look nice.

One of the things I experimented with was taking a PDF file and asking Claude to create an app based on it. I put the PDF into an /assets folder so Claude could access it easily and simply asked him to create an app based on the PDF. I was surprised at how well it worked, but it did take a few iterations to get it right and eventually I used shorter prompts to get the desired result. I even suggested to use local storage to save the data, which Claude did. Another interpretation of the PDF file which Claude created on his own was water calculator and how the brew day data is entered and displayed. Not only did he create a dynamic form that creates individual logging fields but also added optional timer functions for each log entry - nice touch Claude - time for bed. We will continue this tomorrow.

Screenshot of the development process

The next morning while sitting at the fire-pit enjoying a cup of coffee and watching the finches play in the fountain I wrote my next prompt.

prompt:
Recipe Builder: i want a button on the homepage similar to the fieldNotes button that will link to the viewer page titled Recipes“. there will be 2 routes: 1) viewer and 2) builder. For both view and builder use the layout structure in FieldNotes page.tsx file. the viewer will have public access and the builder route will need a google auth password to use. see FieldNotes for existing google auth context. Make the Sign-in/Logout the same as FieldNotes. when logged recipes in the viewer mode will have an edit button and when clicked show the recipe in the builder mode for editing. the default view for the viewer will will include a filter bar by category and favorites as well as search. if there are no recipes than the viewer will show a “no recipes“ box with a button to add one. the recipes will be shown in a grid format with the photo thumbnail (if not available use a generic box with a material ui icon) the title below and then below the title the total time which includes the prep time + cook time. when you click the tile or thumbnail a detailed view will appear. it will show the thumbnail and then a large bold title with the prep time | cook time below it. overlayed in the top right of the thumbnail will be an icon for marking it favorite an sharing. when clicking the sharing it copy the url to the clip board. So the URL will need to be a friendly url using the title (spaces turned into dashes) Next line under the thumbnail will be the author and description. the next section will be accordions for ingredients, steps and my notes. when viewing ingredients there will be a serving size which can be adjusted and then the ingredients will scale to that size using imperial measurements. Steps will be outlined as Step1, Step2, etc. if smoker is the category there will be icons for temp, time and super smoke. There will also be a button for “Make Now“ which will change the display into a slideshow card for each step. The last step will say “Bon Apetite!“ centered with some cool icon. I don’t want to use a database so either flat files in JSON may be the best option. I would prefer storing the images as base64 in the JSON if possible if not alongside the JSON file. Store the data in a folder at /src/data/recipes

It wasn't too long and the Recipe Builder app was ready. Claude did it all from creating an index viewer and editor page to supporting PDF export and image uploads. I was amazed at how quickly it was able to put all this together so I thought about my next apps: FieldNotes and Roll And Write. I could already envision the features I wanted in these apps so having Claude build them was a no-brainer. I wrote the prompts for each app similar to the Recipe Builder and watched as Claude created the initial layouts and components.

Screenshot of the development process

A little addicted at this point and like a crazed hacker in a hackathon I knew this app was becoming something that I could legit use and share with others, so I added some authentication using Google's oAuth simply by chatting with Claude about my ideas and what I wanted. Claude took care of all the Next/react stuff but I had to create the API keys and tokens in my Google Cloud Admin console. Once that was complete it just worked. And what was more astonishing is that I (with my coding friend Claude) accomplished that task in about 30 minutes. I couldn't help but think about how much time, google searches and effort this would have taken me to do on my own.

However in order to host this on Vercel and to scale this project to a place where it can accommodate multiple users I knew it was time to ditch the JSON flat file architecture and move to a more robust database solution. This was really going to test how well Claude has context of the workspace but also the overall architecture of the app which should be high since he has so far written 100% of the code. To make it easier for Claude to understand the data model I designed a simple MySQL database schema which used the current JSON structure inside a JSON typed column and then asked Claude to help me implement it.

prompt:
so I have an issue with vercel and using flat files so I have created a database on my local mysql and want to change the API to use it. First, we will keep the current JSON structure and instead of writing it to the file system we simply insert and update the row in the new database. The schema for both tables looks like this: `CREATE TABLE `fieldnotes` ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_email` varchar(255) DEFAULT NULL, `json` json DEFAULT NULL, `created` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 CREATE TABLE `recipes` ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_email` varchar(255) DEFAULT NULL, `json` json DEFAULT NULL, `created` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4` Can you make the changes to the API so that everything is read and written to this database: hikerbikerwriter. The database credentials for local are already in the /lib/db.ts file.

Mission accomplished. In just a single prompt Claude updated the existing API using flat files and created the necessary API updates to interact with the MySQL database as well as completely tested the functionality of the app. He did all of this with minimal guidance on my part outside of the initial prompt.

Now that Claude had the app working with the database and we added Users, including a user registration and authentication system, we needed a way to management al the content from Roll And Write entries and Field Notes to Recipes. I asked Claude to create a content management system that would allow me to manage all the data in one place. This included creating a new admin page that would allow me to view, edit and delete entries from all the apps as well as approve new user requests.

Screenshot of the development process

If you can dream it, Claude can build it.

Challenges

  • Creating a consistent UI and UX experience across apps. Claude had trouble replicating the design system across different applications.
  • Had to make additional requests to Claude for mobile optimizations about 90% of the time.
  • Once I ran out of premium requests to use Claude, I switched to GPT-4.1 and found this model to be less effective at understanding the context of the app and the codebase. In some cases GPT-4.1 would change things that Claude had already done and break functionality. More often than not I had to revert the changes and ask Claude to fix it. Claude Sonnet 3.5 was generally as helpful but not quite as aware of the specific nuances of the app and often left duplicate code and files hanging around that needed manual cleanup. 3.5 also tended to hallucinate more often than Claude Sonnet 4.1.
  • For unknown reasons, Claude used both page and app router for the Next.js app so this will need to be refactored in the future to use just the app router for better performance.
  • When trying to implement similar features across apps, I had to use a one-step-at-a-time prompting because each app had its own context and requirements that Claude sometimes became confused.
  • Sometimes either Claude or GPT4.1 would summarize what they did but never made any code changes.
  • Claude sometimes forgot to remove unused code and files leaving the developer with a lot of cleanup after a conversational build of new features or editing existing. Additionlly, Claude Sonnet 3.5 would forget context to what it did sometimes as quickly as right after doing it.

Next Steps - Development

  • Code Review
  • Optimizations and code efficiency improvements for performance, security and code reusability, as well as removing lots of unneccessary code, files and documents that are no longer valid.
  • I originally planned each component to be a separate app and so the authentication and logged in/out header are independent. These will need to be combined into a single utility class.

Next Steps - Product

  • Adding more familyline management features

Changelog — view on GitHub

v1.9.1

  • Cleaned up "Signed In as ..." display for mobile and desktop.
  • Repaired the Add To Family bug that would not add the memeber to the family.

v1.9.0

  • Cleaned up mobile UI for job tracker
  • Fixed use of user.name vs .author in JSON object for more consistent displaying of name.
  • Fixed small issue with Lorem Ipsum generation.

v1.8.7

  • Added job tracker card to profile.
  • Add quick export/download to app cards on profile.

v1.8.6

  • Added list of family members to the recipe filters when sorting by family.
  • Added Google SignIn and profile image to homepage for improved navigation.
  • Improved responsiveness for mobile devices in Job Tracker.
  • Added Person page

v1.8.0

  • Added a new Job Search feature for tracking opportunities, recruiters, resources and statuses.
  • Fixed up profile page inconsistencies and improved layout on mobile.
  • Added a filter for family on recipes only accessible if there area people in the json object in the familyline.

v1.7.1

  • Added Import Recipe from URL feature when createing a new recipe.

v1.7.0

  • Completed initial family mapping in MySQL database and the ability to find family members by their email addresses or name and then add them to your familyline.

v1.6.0

  • Added new user profile page with summaries of Roll And Write, Field Notes, Recipes and Brew Day Logs, as well as family list of people you're connected with and how they relate you and shared data.
  • Added option in Recipes for "Share with Family" which allows users to share recipes with family members.

v1.5.0

  • Updated temperature thresholds for background color gradients.
  • Added content management features for user-generated recipes, roll and write, and users.

v1.4.0

  • Added new utility components for Network Tool.
  • Enhanced responsiveness for mobile devices.

v1.3.0

  • Added MySQL database support for Roll And Write.
  • Added new user registration and management page.

v1.2.0

  • Added new features for user authentication.
  • Added MySQL database support for Recipes.

v1.0.0

  • Initial release with basic features.