I gave Claude one app and asked it to act like four different senior developers — here’s what happened
[post_content]
Disclaimer: This article has been automatically aggregated from
All over the internet, especially on X, you’ll find prompts claiming to make chatbots more effective. When I first came across a collection of prompts from David Max, an AI educator, I was skeptical, which is exactly why I decided to give them a try.
The prompts say they could turn Claude into everything from a senior debugging engineer to a performance expert. Here’s what happened when I decided to find out.
Showing Claude my household expense tracker
I had already created a generic expense tracker that included placeholders for expenses with ChatGPT Work, so I used that and then had Claude review the app four times. Each time, I assigned it a different senior engineering role: full-stack engineer, debugging engineer, frontend engineer and performance engineer.
The result was far more revealing than simply asking Claude to “make the app better.” Each persona concentrated on a different set of problems — and occasionally found issues the previous “developer” had missed. Here’s what happened and the prompts I used.
Latest Videos FromTom’s Guide
1. The senior full-stack engineer built the app
I started by asking Claude to create an interactive household expense tracker that an everyday person could use.
The prompt: Build an interactive household expense tracker that an everyday person could use to record and understand their spending. Include the ability to add and delete expenses, assign categories, filter transactions, calculate total spending and display a visual category breakdown.
Think like a senior full-stack engineer developing a polished startup MVP. Before writing any code, briefly outline the architecture, data structure and user flow. Then build the working app as a Claude Artifact.
Make it responsive and easy to use, but do not spend additional time reviewing, debugging or optimizing the finished code. I will ask other “developers” to handle those stages.
Claude created a surprisingly polished React app. It arrived with sample transactions, spending totals, category breakdowns, search, filtering and the ability to sort transactions by date. It also saved changes so they would remain available after the app was reopened.
At first glance, it looked much closer to a finished product than a rough prototype. There were stat cards across the top, a clean expense form and colored bars showing how much had been spent in each category.
2. The senior debugging engineer found some problems
Next, I asked Claude to forget about the appearance and investigate its own work like a debugging engineer preparing an app for release.
The prompt: Now act like a senior debugging engineer who has inherited this application before it is released to the public.
Examine the app and its existing code carefully without changing its intended functionality or visual design. Test the main user flows and look for functional bugs, invalid input handling, data-loss risks, incorrect calculations, persistence problems and edge cases.
Before editing the code, give me a concise debugging report containing what you tested, every issue you found, the root cause of each issue, how serious each problem is and the fix you recommend.
Then implement the fixes and verify that the original features still work. Do not redesign the interface, perform a broader architectural refactor or make purely cosmetic changes.
The debugging pass found several genuine problems.
For example, the original inputs weren’t inside a proper form. Clicking “Save Transaction” worked, but pressing Enter might not. Claude corrected that by converting the section into a real form with a submit button.
It also discovered that users could clear the date and save a transaction with invalid date information. Claude added date validation, strengthened its checks for invalid amounts and fixed a calculation that caused “Housing” to appear as the biggest category even when the tracker was empty.
Transactions could still be permanently deleted with one click. Storage failures remained hidden in the developer console, meaning users might think their information had been saved when it hadn’t. Claude also didn’t create automated tests to confirm that its repairs worked.
3. The senior frontend engineer noticed an entirely different app
For the third pass, I asked Claude to approach the tracker as a frontend engineer specializing in responsive design and accessibility.
The prompt: Now act like a senior frontend engineer specializing in accessible, responsive consumer applications.
Review the current expense tracker from the perspective of someone using it on a phone, with a keyboard or with assistive technology. Preserve its functionality and overall visual identity, but improve its usability and accessibility.
Before changing the code, provide a concise review covering mobile and responsive behavior, keyboard navigation, form usability, screen-reader accessibility, color contrast, loading and error states, destructive actions and confusing controls.
Then implement the improvements. Make sure every input and interactive control has an accessible name, focus states are clearly visible, validation messages can be announced by a screen reader and the spending breakdown communicates information without relying on colored bars alone.
This was the most comprehensive review of the experiment.
Claude noticed that the app removed the normal outline around selected inputs without providing a replacement. Someone navigating with a keyboard would therefore have trouble seeing which field was active.
It also found that the visible labels weren’t properly connected to their corresponding inputs, the search field relied only on placeholder text and validation errors weren’t configured to be announced by screen readers.
Claude restored visible focus indicators, connected labels to form controls, added screen-reader descriptions and increased the contrast of several light-gray text elements. It also made the search bar more flexible on small screens and added more descriptive labels to icon-only buttons.
Most notably, this persona caught the deletion problem the debugging engineer had overlooked. Claude replaced the single-click delete button with a two-step confirmation asking users to either delete or keep the transaction.
Not every claim was perfect. Claude described 44 by 44 pixels as a minimum touch-target size, but enlarged the primary delete button to only 36 by 36 pixels. That satisfies the smaller WCAG 2.2 AA target, but not the 44-pixel recommendation it cited.
Even so, changing Claude’s role clearly changed what it saw. The debugging engineer examined whether the app functioned. The frontend engineer considered whether a real person could comfortably use it.
4. The performance engineer admitted the app didn’t need much help
Finally, I asked Claude to prepare the expense tracker to handle at least 10,000 transactions.
The prompt: Now act like a senior performance engineer preparing this expense tracker to handle thousands of transactions.
Analyze the current implementation for unnecessary rendering, repeated calculations, inefficient sorting or filtering, storage bottlenecks, memory growth and interactions that may become slow as the dataset increases.
Do not assume a performance problem exists. Create a realistic way to test the app with at least 10,000 transactions and establish a baseline for important operations.
Then implement only optimizations justified by the analysis. Preserve the app’s appearance, accessibility improvements and existing behavior. Do not claim a speed improvement unless you measured it or clearly label it as an expected improvement.
Claude found one especially significant bottleneck. The app created a new currency-formatting object every time it displayed an amount. With 10,000 rows, Claude measured that process at 349 milliseconds. Reusing one formatter reduced it to 5.2 milliseconds, which Claude calculated as a 67-fold improvement.
It also added table virtualization, meaning the browser would render only the transactions currently visible on screen rather than thousands of rows at once. Search and storage updates were delayed by a fraction of a second to avoid repeating expensive work after every keystroke or rapid change.
Claude even added buttons that could generate 1,000, 10,000 or 50,000 sample transactions for stress testing.
The most convincing part of the report, however, was Claude’s admission that most of this was unnecessary for the app’s intended purpose.
A household might add 30 to 50 transactions each month. Even after a decade, Claude concluded that the original app would probably have handled the resulting data without a noticeable problem. Apart from caching the currency formatter, most optimizations were useful only because I had specifically demanded support for thousands of transactions.
That restraint felt more “senior” than making changes simply because it could.
My verdict
I thought these prompts worked very well and each one highlighted what Claude does well and where it fails. Each role was a different lens for each review, which I found useful and will implement with other apps and websites.
While the debugging engineer found broken behavior, the frontend engineer found accessibility and usability problems. The performance engineer considered what would happen as the amount of data grew —and recognized when optimization was unnecessary.
The experiment also showed why one enormous “make this production-ready” prompt may not be the best approach. A single review can overlook important issues, even when the prompt sounds comprehensive. Dividing the work into focused stages gave Claude fewer priorities to juggle and made its findings easier to evaluate.
Just watch your Claude usage limits. Next time, I might try this by combining prompts to avoid hitting my limit.
Follow Tom’s Guide on Google News and add us as a preferred source to get our up-to-date news, analysis, and reviews in your feeds. Subscribe to Tom’s Guide on YouTube and follow us on TikTok.
More from Tom’s Guide
for informational purposes only. We do not claim ownership, accuracy, or liability for the content provided. All rights belong to the original publisher.