About Bill's Web Application Demo Site

We’re all aware of the hype and drama surrounding AI. There are real issues related to privacy, energy/water consumption, bias, job displacement, IP, misinformation - all of which needs to be properly addressed before some organizations can comfortably run with AI. Given the complexity and gravity of those issues, I felt it appropriate to withhold my endorsement of AI until the point at which I could actually see first hand the benefits of an AI coding “partner” in custom development. Here's hoping we resolve those issues quickly as there is much to gain. In reality, it has taken me longer to document my thoughts on this page than it took to create a distributed, fully functioning, data-driven, professionally hosted Restaurant Menu Profitability Report displaying a quadrant scatter plot a restaurant operator could use to identify a sub-par menu item. All told, Claude helped me create six sample dashboards and a demo site in less than one week. I also feel confident that as engineers, we can more effectively enforce coding, architectural, documentation and tool standards across development teams by standardizing prompting.

That said, I do not mind sharing my approach and a few observations I made along the way.

1. For each industry area, I asked Claude to act as an industry consultant/expert to generate three best-practice management report suggestions often utilized to improve quality and/or profitability by monitoring key operating metrics. I provided some domain-specific examples of metrics and reports I was familiar with as a leader but encouraged Claude to go beyond my suggestions.
2. I shared with Claude my preferred programming languages and asked Claude to suggest popular tools and frameworks often used for data-driven web-based management dashboards. My ask was for Claude to write three prompts, one for each suggested management report, and asked Claude to research anatomized, publicly-available datasets we could use for each such dashboard.
3. Of course I asked Claude to ask me clarifying questions before proceeding. I also emphasized the need for clear code comments, comprehensive testing and detailed “how to” “README” files where design decisions were captured in great detail.
4. I asked Claude to weigh in on which reports and associated metrics/variances, etc. were most feasible given likely constraints and limitations in available data. I was impressed with Claude’s feedback identifying dataset gaps and data quality issues likely to impact the accuracy of certain reports.
5. I then asked Claude to create prompts that outlined project implementation as well as describe high-level application architectural/design decisions (i.e., backend, data layer, frontend rendering, hosting, etc.). I emphasized that no code was to be written before I approved the design.
6. After reviewing Claude’s response, I finally began submitting prompts to Claude one at a time. This gave me the opportunity to make design changes and improve the prompts along the way. I will say that Claude did forget to apply some of the design ‘tweaks’ we implemented to reports implemented later in the process. I think I needed to embed those tweaks in the prompts themselves.
7. Claude defended design/architecture recommendations and even presented a case for feature change based a dataset limitation discovered after implementation had started. The project structure, code comments, function sizes, naming conventions, stylistic decisions, and design documentation all look appropriate.
8. Extensive tests were automatically run each time an application changed and before code was committed to GitHub.