Mia's AI-assisted payment fix passes its test. A customer can still be charged twice.
Mia is fictional, but you can try the checks in her story on your own work.
AI can handle more than the first draft
Mia needs to add delivery instructions to a checkout form. The project already has a similar field, so she points her coding agent toward it.
The agent reads the nearby files, changes the form and suggests a test for saving the new value.
That is a useful task to hand over. You can spend the saved effort checking whether the instructions reach the person packing the order.
Current coding agents can search a project, edit files and run checks when their tools and permissions allow it.
For example, Claude Code can trace and fix bugs. GitHub's coding agent can make requested changes and run tests on a pull request.
Check which files your agent can reach and which commands it can run before giving it access to a work project.
Keep customer records out of the chat unless your workplace permits sharing them.
You can also ask for an explanation of unfamiliar code or several ways to fix a bug, then compare the suggestions against your project.
Mia checks the packing screen and finds no delivery instructions. The field is saved, but the warehouse view never loads it.
Cheaper tasks can change hiring decisions
The delivery field is one of several similar changes waiting for the team. Mia's manager has a fixed budget for getting them done.
Suppose completing and reviewing each small change takes four hours without AI, so a forty-hour work budget can cover ten changes.
Suppose AI brings the total to two hours per change, including instructions, review and repairs. The same budget can cover twenty changes.
You should read those numbers as an example of the arithmetic, not a measured gain or a forecast about staff cuts.
The manager might use the extra capacity to finish a longer queue. If demand stays fixed, they might delay a hire instead.
Tool costs and harder tasks would change the calculation. You cannot turn cheaper code into a reliable prediction about the whole job market.
Track how much of your week goes to similar changes, then use one of them to test how much AI helps.
Judge the time saved after review and repair
The old refund module is harder. The agent produces a large rewrite, and Mia spends the afternoon checking changes she never requested.
The draft arrived quickly. Getting a patch she could safely release took much longer.
Field experiments with company developers found gains in completed tasks with AI assistance. That finding does not give you a speed estimate for your own project.
In a February 2026 research update, METR explained why its follow-up could not reliably estimate current speed gains, including problems with who joined and how time was measured.
Try the agent on a small change whose result you can check. Record the full time spent, including reading the patch and fixing mistakes.
If you keep accepting huge rewrites, you may be making review harder. Ask for a smaller patch and compare the time needed to finish it.
Learn the rules behind the feature request
A support worker asks Mia for a button that refunds cancelled orders, a request she could hand straight to the agent.
Instead, she asks what happens when the parcel has already left the warehouse.
Support needs a return process in that case. A refund button that ignores the difference could give money back while the goods are still travelling.
You get these details by talking to the people doing the work and reading the rules they already follow.
AI can help organize those rules and suggest questions. It needs access to the relevant information, and someone must settle the unanswered questions.
Before asking AI to write the button, you need to know which orders qualify for a refund and who can approve it.
You can help by finding the person who approves refunds and asking them to settle the uncertain cases.
If you rarely speak to support, ask them to walk you through a cancelled order before trying to write its refund rules.
Mia writes the agreed rule into the ticket before anyone changes the code. You can do the same even when you are new to the team.
Find the failure that the first tests missed
The payment bug appears when a customer taps Pay again after a slow response. The server treats the second request as another purchase.
Mia's original test passed because it sent the request once.
You need to ask what happens outside that happy path. Here, the missing check is whether a repeated request can charge the customer again.
The agent can help write that test once the expected behavior is clear.
You still need to verify the payment provider's rules for handling repeated requests.
Mia also checks how support will find affected orders and what to do if the fix causes a different payment problem.
If you understand the logs and the release process, you can help investigate the failure and restore an earlier version when needed.
Practice tracing the failed request through the logs.
In our date-parser test, the code failed both valid dates.
It still scored six out of eight because it rejected all the invalid ones.
Choose work where the result matters to customers
The missing delivery instructions lead Mia to the order data passed between the shop and the warehouse, an area where she knows the server code.
She learns why an order can disappear between those systems and how staff notice the problem.
She inspects the order fields in the warehouse API's response. You can use our JSON visualizer to explore those fields as a tree.
If you already work on server code, that kind of problem gives you a reason to deepen your database and failure-handling skills.
A colleague who prefers interface work could focus on checkout screens that customers can use with a keyboard, then test them with real users.
You can build on your current strengths. Choose a problem your team needs solved and learn enough to handle it.
We would keep a steady job while trying this direction. A course that promises a safe new title cannot guarantee which skills employers will want.
Keep checking real job listings for the work you want. Use them to spot gaps in your skills, without treating any single listing as a career forecast.
Keep learning the parts you need to check
Mia asks AI to explain why the repeated payment request caused trouble before closing the chat and describing the fix to a colleague.
She gets stuck on how the server remembers an earlier request.
In an Anthropic experiment with an unfamiliar Python library, developers using AI assistance scored lower on an immediate knowledge quiz.
It did not measure long-term skill loss or future employment. Participants who asked conceptual questions or sought explanations tended to do better than those who delegated.
Those observed usage patterns do not prove that a particular prompting style protects learning.
You can check your own understanding directly. Change the example, predict what will happen and run it before asking AI to explain the result.
Use your usual language to build a small practice case. Send the same request again and inspect the stored payment record.
You may need to learn a database query to read that record. Follow the request through the logs until you can explain why it produced a second charge.
And leave some work for yourself. If you cannot explain the change without the chat open, spend time on that gap before taking on a larger task.
Show that you can explain and support a change
After fixing the payment bug, Mia adds the failed case and the test that catches it to her usual description of the change.
She also explains how support can find affected orders. You could include those details in your own review so your manager can assess the work.
You can keep a short record of the problem, the change you made and how you checked the result for later review.
A colleague asks why the original test passed. Mia points to the missing repeated request and explains why the new test would fail if the bug returned.
This week, choose a bug from your own work, use AI to help you investigate it and write a test that would have caught it.