Working with Claude.ai

Over the past few days, I updated our main first party application (CLIQ) from Angular 17 to Angular 21. Unfortunately, a direct upgrade to the existing project became untenable as I was spending more time debugging than I felt was necessary. After some back and forth with claude.ai, I decided to start with a clean project and transition each component from the old project to the new project.

I leveraged claude quite a bit to help with making the necessary updates to each component, troubleshooting issues, and act as a guide through Angular configuration. Since I gave claude my modules file, it knew each component that was in the application. It proceeded to prompt for the code, and then would return the updated component. My coding tends to be very simple and straightforward, so this process went quickly and well.

At the end of the process, I asked claude the following: Based on what you saw with the CLIQ-DENALI code, what do you think it does?

It's response was impressive:

Based on everything I saw, CLIQ appears to be a configuration-driven enterprise portal for Dickinson College that serves as a middleware layer between end users and your backend ColdFusion/Oracle systems.

Core capabilities:
Data Management (CRUD subsystem) — the heart of the application. Rather than building individual screens for each dataset, CLIQ uses JSON templates to dynamically generate AG Grid-powered data views with add, read, update, and delete capabilities. This means new data management screens can be created without writing new code — just a new JSON definition.

Document System — renders dynamic documents from templates, likely used for institutional forms, reports, and records. The document editor allows administrators to build these templates visually.

Form Center / Workflow (Tasks) — a workflow engine that routes tasks to users, collects form-based responses, and drives approval or process flows. The saveReaction pattern suggests users are presented with workflow decisions and their responses trigger downstream processes.

Form Editor — a visual builder for form definitions used throughout the workflow system.

Proxy System — suggests administrative users can proxy as other users, which is common in institutional systems for support and troubleshooting.

Overall architecture philosophy — CLIQ appears to be a meta-application — instead of hardcoding institutional processes, it interprets configuration files at runtime. That's a sophisticated and pragmatic approach for a one or two person shop managing a complex institution. It's clearly the product of deep institutional knowledge built up over 20 years.

These are all genuine key elements of the system and claude absolutely nailed them.

The one line that I found really impressive was: The saveReaction pattern suggests users are presented with workflow decisions and their responses trigger downstream processes.

There was no specificity in talking about how the workflow is actually implemented yet it was able to deduce a key process based on code. I find that deduction very valuable. I think my next experience will claude regarding my work code is share the configuration files and see what it makes of them. My hope is that it would be able to generate high to mid-level documentation by crossing the roles and function data with the configuration data. That should be one heck of a document.