GenAI Usage Log & Citations

Owner: CrowdPM Team | Last updated: 2026-03-08 | Status: Production

GenAI Usage Log & Citations

Purpose

This page records how generative AI tools were used during development of the CrowdPM Platform, including the purpose of use, summarized prompts or inputs, outputs received, where the results were applied, and reflections on efficiency and verification. It is intended to satisfy course policy and provide a transparent project record.

Notes on documentation practice

• Many AI interactions were iterative rather than one-shot. In those cases, the prompt listed below is a representative summary or the most important prompt used for that task.
• Team members reviewed generated output before use. Generated code was inspected, tested, revised, or rejected as needed.
• Tools referenced below include ChatGPT, ChatGPT Codex, GPT-5 Thinking, GPT-5 Codex High, and related OpenAI models used for brainstorming, implementation support, debugging, refactoring, and test generation.

Entry template

• Owner: @name
• Purpose: What AI was used for
• Prompt/input (summary): Summary of the request or representative prompt
• Output (summary): Summary of the response or artifact generated
• Where applied: File, feature, subsystem, or workflow affected
• Verification: How the output was checked
• Reflection: What was useful, limited, or worth changing next time
• Attribution/citations: Tool used, links, or other references if available

---

Usage entries

Skylar

UI library/framework evaluation

• Owner: Skylar
• Purpose: Brainstorm which UI library/framework combination best fit the project.
• Prompt/input (summary): Compared options such as Tailwind CSS, Radix UI, Radix Themes, and ShadCN in the context of a Vite + React codebase. Representative prompt: “I'm using vite + react for my GitHub Project CrowdPMPlatform. Compare and contrast using Tailwind CSS or Radix UI or Radix themes or ShadCN.”
• Output (summary): A comparison of candidate UI approaches, including pros, cons, and tradeoffs for maintainability, styling control, accessibility, and integration complexity.
• Where applied: Frontend UI planning and component-library selection.
• Verification: Recommendations were compared against project needs and then evaluated during actual implementation.
• Reflection: This was efficient because it quickly summarized why one library/framework combination would or would not fit the team’s needs.
• Attribution/citations: ChatGPT.

Ball-clicking interaction feasibility / scoping

• Owner: Skylar
• Purpose: Scope how to implement ball clicking and determine whether the interaction was feasible with the current library stack.
• Prompt/input (summary): Asked GenAI to reason about how clickable map or visualization elements could be implemented using the project’s current frontend libraries.
• Output (summary): Suggested approaches for interaction handling, implementation direction, and likely constraints.
• Where applied: Interactive map/data visualization planning.
• Verification: Suggestions were compared against current library capabilities and existing frontend architecture.
• Reflection: Helpful for narrowing down feasible directions before implementation.
• Attribution/citations: ChatGPT.

Debugging local development and emulation

• Owner: Skylar
• Purpose: Debug run dev and local emulation after significant project changes.
• Prompt/input (summary): Representative prompt: “can you help me emulate a node so i can view the map, i’m getting ___ error”
• Output (summary): Troubleshooting steps for local development and node emulation, including likely causes of configuration/runtime errors.
• Where applied: Local development workflow, emulator setup, and map-view verification.
• Verification: Recommendations were tested locally. The team also updated documentation after resolving the issues.
• Reflection: Ideally the documentation would have already been more up to date, but the AI assistance still helped with diagnosis. Teammates were also helpful in solving the problem.
• Attribution/citations: ChatGPT.

Jack

Fix async race condition in smoke test history component

• Owner: Jack Armstrong
• Purpose: Prevent an async race condition in React from overwriting localStorage in the smoke test history component on the Admin page.
• Prompt/input (summary): Asked how to avoid async race conditions in React 19 after identifying that a useEffect was overwriting local state persisted in localStorage.
• Output (summary): Suggested a useRef-based approach and related state-management guidance to avoid the race condition.
• Where applied: Admin page smoke test history component.
• Verification: The code path was implemented, tested, and checked against the previous failure mode.
• Reflection: This was an efficient way to solve the problem. It introduced useRef as a simple mechanism to eliminate the race condition from the equation.
• Attribution/citations: ChatGPT.

Debug single-batch deletion behavior

• Owner: Jack Armstrong
• Purpose: Debug deletion behavior to ensure smoke test history was correctly deleted and reflected in localStorage.
• Prompt/input (summary): “Review and debug AdminPage.tsx to verify that smoke test history is correctly deleted and updated in localStorage.”
• Output (summary): Identified three likely bugs and proposed code changes to make deletion behavior correct.
• Where applied: AdminPage.tsx and related smoke test history state logic.
• Verification: The suggested fixes were reviewed and tested against expected deletion/update behavior.
• Reflection: Somewhat efficient. It found likely issues and generated fixes, but it tended to add code rather than refactor away unnecessary code. A narrower follow-up prompt could have improved the result.
• Attribution/citations: ChatGPT Codex.

Implement user login / sign-up workflow

• Owner: Jack Armstrong
• Purpose: Implement user dashboard and login/sign-up functionality using Firebase Authentication.
• Prompt/input (summary): “Implement user dashboard and login/sign up functionality using Firebase Auth.”
• Output (summary): Generated implementation scaffolding and code for Firebase-authenticated login/sign-up flows and dashboard support.
• Where applied: User authentication flow and user dashboard.
• Verification: Generated code was reviewed manually and integrated into the application.
• Reflection: This made implementation fast, but reviewing a large generated diff took time. A future improvement would be requesting a more step-by-step build rather than a large end-state output.
• Attribution/citations: ChatGPT Codex.

Public-facing map data for logged-out users

• Owner: Jack Armstrong
• Purpose: Attempt implementation of a public viewable map on the home screen when logged out.
• Prompt/input (summary): “On the home screen for a logged out user, add a map that includes all public toggled batches within the last 24 hours and show the corresponding balls to be clicked on that will eventually bring up a data card with the time series slider.”
• Output (summary): Generated an implementation attempt for a public map layer and related UI behavior.
• Where applied: Logged-out home screen and public map data flow.
• Verification: Tested against intended behavior.
• Reflection: Results were mixed. The agent performed many checks and tests, but the implementation still did not fully work as intended. More precise prompt control may improve future outcomes.
• Attribution/citations: ChatGPT Codex.

Implement missing route tests

• Owner: Jack Armstrong
• Purpose: Create a Vitest suite for API routes.
• Prompt/input (summary): Asked ChatGPT’s Codex agent to implement route tests covering happy path, auth, validation, missing resources, boundary conditions, and error mapping.
• Output (summary): Produced a structured route-testing approach and test implementation aligned to route behavior expectations.
• Where applied: API route test suite.
• Verification: The first route test structure was reviewed and then reused, though expanding scope too broadly caused issues in later steps.
• Reflection: Efficient for producing initial structure, but asking the agent to implement too many remaining routes at once reduced consistency. Smaller scoped tasks worked better.
• Attribution/citations: ChatGPT Codex.

Mark

API contract documentation with Swagger / OpenAPI

• Owner: Mark
• Purpose: Identify a clean way to document the API contract as code.
• Prompt/input (summary): “What’s a good solution for documenting an API”
• Output (summary): Suggested several standard approaches, including Swagger/OpenAPI, and provided a practical path for getting Swagger UI running quickly in Docker.
• Where applied: API contract documentation workflow.
• Verification: The recommendation was compared against known industry practice and used to iterate rapidly on the API contract interactively.
• Reflection: Efficient because it provided several standard options quickly, and the Swagger recommendation aligned well with existing familiarity.
• Attribution/citations: ChatGPT 5.

Telemetry multi-tenancy implementation

• Owner: Mark
• Purpose: Refactor telemetry/device ownership so that each device belongs to a user and users can only see their own devices.
• Prompt/input (summary): “we recently implemented firebase authentication and want to isolate devices on a per-user basis. Devices should be able to exist for multiple users.”
• Output (summary): Proposed code changes and design considerations to support multi-tenant device ownership and prevent improper cross-user mutation/access.
• Where applied: Device ownership model, Firebase-authenticated access control, and backend authorization logic.
• Verification: Recommendations were reviewed, refined, and adapted before integration.
• Reflection: Somewhat time consuming because review and refinement were still substantial, but valuable because the model reasoned well about security implications.
• Attribution/citations: ChatGPT Codex.

Device registration emulator / reference workflow

• Owner: Mark
• Purpose: Create a reference implementation of the registration workflow while waiting for partner hardware.
• Prompt/input (summary): Representative prompt: “Post a registration payload to the /device/start endpoint, and wait for a token response.”
• Output (summary): Generated an emulator-based reference flow to exercise the backend registration process and secure connection logic.
• Where applied: Device emulator, registration workflow testing, and backend integration.
• Verification: Used to exercise the backend registration process without requiring a completed hardware device.
• Reflection: Valuable because it allowed the team to continue backend development in parallel with hardware work. Security-related automation was especially useful here.
• Attribution/citations: ChatGPT.

Integration test for device registration

• Owner: Mark
• Purpose: Implement an automated integration test for device registration using the device emulator.
• Prompt/input (summary): “Help me use my device emulator to automatically validate device registration as part of our test suite.”
• Output (summary): Attempted to generate an automated end-to-end registration test spanning both device behavior and user approval flow.
• Where applied: Test suite for device registration.
• Verification: Attempted in project test infrastructure.
• Reflection: This was difficult. Device registration requires simulating both the device and the user approval action, and the model struggled to produce a fully working automatic test across both components.
• Attribution/citations: ChatGPT 5.2 Codex.

Jaron

Scaffold initial serverless mapping-platform codebase

• Owner: Jaron Rosenau
• Purpose: Generate the initial scaffold for a serverless architecture web application.
• Prompt/input (summary): “Build a mapping platform that ingests timestamped, geo-located pollutant measurements from distributed device nodes (provided by CrowdPM Node) and renders them as maps and time series….”
• Output (summary): Generated an initial scaffold consisting of approximately 47 files and over 11,381 lines for a serverless web application architecture.
• Where applied: Initial CrowdPM Platform application scaffold.
• Verification: Generated files were reviewed and iteratively refined after generation.
• Reflection: Efficient because it accelerated initial codebase creation dramatically. The main limitation is that prompt engineering for large scaffold tasks usually involves many iterations, making it hard to isolate a single decisive prompt.
• Attribution/citations: GPT-5 Codex High. Session link: https://chatgpt.com/s/t_6906e1ad0e1081918b4058003dc295a3

Evaluate secure node-to-platform handshake approach

• Owner: Jaron Rosenau
• Purpose: Reassess the secure handshake design for node registration after identifying problems in the original scaffold.
• Prompt/input (summary): Asked whether a crowdsourced, open-source node should use word-list/high-entropy registration or a different authentication handshake, and compared platform-generated versus node-generated codes.
• Representative prompt: “I have a platform, serverless platform, and crowdsourced distributed nodes. Which authentication handshake between the node and platform is more appropriate or secure for crowdsourcing? The node is open source. What I need to know is the handshake. Should the node have a sort of a word list that the platform also has a word list, and upon a user logging into the platform, add a device gives five words, and then on the node, you use the two buttons to register the device and type in the five words that the platform gives you? Or is it better the opposite way, where whoever creates the node, on the screen of the node, it comes up with five words, and then on the platform, when a user logs in, they have a field that they can enter in the five words.”
• Output (summary): Redirected the design away from an ad hoc high-entropy password-style pairing system and toward an OAuth 2.0 Device Code style authentication flow.
• Where applied: Device pairing and authentication architecture.
• Verification: Compared against the user story, discussed with the Node team, and used as the basis for later refactoring work.
• Reflection: Useful because it prevented deeper investment in a weaker or less maintainable custom pairing approach.
• Attribution/citations: GPT-5 Thinking.

Refactor out HMAC scaffold and replace with device code flow

• Owner: Jaron Rosenau
• Purpose: Remove the HMAC-based node connection scaffold and replace it with a more user-friendly device-code-based design.
• Prompt/input (summary): “Refactor out the existing hmac node tech and instead: Five things: an activation UI, three pairing endpoints (/device/start, /device/token, /device/register), a token issuer, and a device registry with revocation. Everything else is policy, storage, and monitoring around those.”
• Output (summary): Produced design and implementation direction for replacing the original HMAC scaffold with a more standard device-code-oriented registration flow.
• Where applied: Pairing endpoints, activation flow, token issuance, and device registry architecture.
• Verification: Reviewed against team needs and node-team coordination requirements.
• Reflection: Successful refactor direction, though it also reflected an earlier design misstep that later had to be corrected.
• Attribution/citations: GPT-5 Thinking.

Create smoke test playground

• Owner: Jaron Rosenau
• Purpose: Replace the previous editable JSON smoke test with a more usable playground supporting multiple smoke-test variants and mass edits.
• Prompt/input (summary): “In our user dashboard we have a smoke test JSON payload to tweak. I also need controls to mass edit the json for new smoke tests, … Create toggles to modify all attributes…. Make sure to use Radix-UI best practices.”
• Output (summary): Generated implementation direction and/or code for a smoke test playground that supports bulk edits and easier scenario creation.
• Where applied: User dashboard smoke test workflow.
• Verification: Reviewed and integrated as part of test tooling and dashboard improvements.
• Reflection: Useful because relying only on a real node would make testing slower and more brittle. A smoke test playground is a better development aid.
• Attribution/citations: ChatGPT / Codex workflow.

General AI-assisted issue work and timestamp normalization cleanup

• Owner: Jaron Rosenau

• Purpose: Use GenAI as a general implementation/debugging partner across issues and feature work, including a timestamp-handling cleanup.

• Prompt/input (summary): Worked iteratively with Codex, monitoring its changes in real time and stopping, redirecting, or reverting as needed. Representative prompt:

  create a new branch and complete the following:
  Timestamp handling has different patterns:
  Direct conversion in services devicePairing.ts:68-69
  Helper function usage devices.ts:54-55
  Frontend normalization MapPage.tsx:22-30
  Recommendation: Create a shared utility for timestamp
  normalization used consistently across the stack.
  First double check all timestamp are accounted for.
  

• Output (summary): Produced code changes and cleanup work around timestamp normalization and other implementation issues.

• Where applied: Shared timestamp handling and other issue-specific implementation tasks across the stack.

• Verification: Changes were monitored during agent execution, manually reviewed, and checked through application behavior and site quality improvements.

• Reflection: This workflow was productive when closely supervised. It also contributed to improvements such as raising the production site’s Lighthouse score.

• Attribution/citations: ChatGPT Codex / GenAI-assisted development workflow.

---

Summary of GenAI use across the project

GenAI was used across the project for:

• Architecture brainstorming and scaffold generation
• UI framework comparison and frontend interaction planning
• Authentication and pairing design
• Debugging React state/race-condition issues
• Firebase Auth and multi-tenant access-control implementation
• Emulator creation for device registration workflows
• API contract documentation and testing support
• Route and integration test generation
• Smoke-test tooling and developer-experience improvements

In all cases, generated output was treated as draft engineering assistance rather than an unquestioned final source of truth. Team members reviewed, tested, refined, and in some cases rejected or reworked generated outputs before adoption.