In this post I will cover how I my workflow looks like when coding with AI.
This is a manual version of the to illustrate the concept and anyone can apply it with their tools as is.
In a future article(s) I will post how I improved it by using GitLab tickets, but the core concepts are the same as in this post.
For the illustration purposes I will clone SpeedPy boilerplate and make a somewhat complicated feature.
I will use Claude Code and Codex, then will try to do the same with Cursor.
Using two different tools is important: no matter what, a single model can't possibly do a complete good job on anything. They all make mistakes, and notice different things. So on both stages specing and implementation you need two different models by different vendors to implement and review/verify.
So step one, I will spin up a non-dockerized version of my boilerplate https://speedpy.com/
I'll copy offered snipped, paste it in the terminal and wait for the setup to finish. If you don't have uv set up locally, you can use the Docker version. It is not that important for the purpose of the post. All we need is a real project to illustrate how to vibe code "the right way".
Next: if you use Claude Desktop/Codex Desktop or CLI doesn't matter, it will be the same, I will illustrate Desktop versions.
Open Claude desktop app, switch to Code on the top left side and open the project(point it to the directory of the project).
Click "Trust Workspace"
Now, open Codex and point it to the directory of the project:
And open the project in the code editor of your choice.
I will use Cursor.
In the project create a directory "specs" and our first spec in it "financial-planner.md"
Why do we need specs? Because the most important part when working with AI is to first settle on a well defined task before we ask it to implement anything. Most of the problems when asking AI to code anything come from incomplete specs, ambiguous statements and overlooked complexity.
Let's make a personal financial planner.
A great example of a task because it can mean something different for everyone.
I have no idea how it should look like and AI will help us understand what we need to build.
Let's start by writing a vague description of what we want to build.
At this stage it is not important to structure any of your thoughts, just list everything that feels important in no particular order.
I came up with this initial spec, which took me 10-15 minutes to write, and I think it is enough as a starting point:
We are building a family financial tracking app.
The web interface must be mobile friendly, because most of the usage will likely to happen via mobile browsers.
Must support multiple currencies.
We use terms Team and Family interchangably. In SpeedPy we have multitenancy object Team. That can be referred to as Family in this document.
All currencies of the world should be populated in the app, can be hardcoded and live in the code, not in a database.
In team settings there must be field to select favourite currencies and the default one.
Models that need to be created:
- Wallet: Represents a bank account or wallet. We choose this name to disambiguate between technical term account that can be confusing for the spec
- Fields: name, currency, description
- Notes: all wallets are visible to all members of the team/family
- Transaction (Expense/Incoming payment/Transfer between account/Currency conversion): Represents any event of funds moving/spent/added.
- Fields: amount, currency, date, comment, user who made the transation
- Types of expenses:
- Fields: name
Functionality of the app:
- Create wallets
- modify wallets(rename/delete)
- create a transaction:
- We must have buttons to create a transaction for ease of a quick input and usability: Add expense, add income, move between wallets
- Moving between wallets must ask for source and destination wallets, ask for amount of money sent and prepopulated field amount of money received, which can be modified by the user in case there are fees/expenses involved in this transaction as well as currency conversion rates. Currency conversion rates must be updated daily for the whole app globally via a scheduled task. When adding a transaction involving currency conversion user must be able to eidt the field how much money will be received on the target wallet.
- a page with list of expenses with a filter by date range and the expense type. For date range we want predefined presets (last 24h, last 7d, last 30d) and a from/to calendar selector
- a page "Wallets" with list of the wallets with current balance and currency
Make sure to save the file and go to the Codex app and write this:
Look at the spec in @specs/financial-planner.md . Help me build a proper detailed spec that an AI agent can use to implement the requested functionality. Ask me any questions, bring up concerns, suggest functionality
And execute the prompt.
For me this time Codex edited the spec file, although I don't like when it does it so I should have asked it to "write the resulting spec in a new file @specs/financial-planner.md" so that my initial file stayed as is. But.. too late for that. Moving on.
In the Codex app I can see some open questions, that's what I expected.
But if we open the spec, at the end there are 12 open questions instead of 6.
So, I suggest we grab all those 12 and answer to them in the Codex chat:
1. Should new families get default expense categories automatically? Yes: Groceries, Car fuel, Rent, Apartment bills, Medical, Gym and Health, Hobby 2. Can regular members edit/delete all transactions, or only transactions they created? Yes, everyone can edit anything 3. Should wallet deletion be impossible once transactions exist, with archive as the only option? If there is a single transaction in a wallet, only archive wallets 4. Should expenses support a merchant currency that differs from the wallet currency? Yes 5. Should transfer fees be stored on the transfer/conversion transaction, or recorded as a separate expense category? Yes, but i guess only for the same currency transactions 6. Do we need budgets in the first version, or should they wait? No budgets for this version 7. Do we need recurring transactions in the first version? Not for the first version 8. Which exchange-rate provider should production use? No idea, come up with something, must be free service and preferably without any API keys setup involved 9. Should the dashboard show converted total net worth in the family default currency, or only grouped balances by original wallet currency? Great idea, Grouped by the currency 10. Should cash wallets allow negative balances? yes 11. Do we need attachments/receipts now or later? Not in the first version 12. Should every edit/delete be audited beyond `created_at` / `updated_at`? yes
And execute the prompt.
This clears all the concerns that Codex had.
Let's review the spec with Claude Code.
Open Claude code and ask it to "review the spec for a simple family finance tracker in @specs/financial-planner.md, bring up only critical concerns and inconsistencies, bring up only critical concerns and inconsistencies, fix problems that you can if you find them, ask me questions if you can't resolve them yourself"
Notice the part "bring up only critical concerns". It is a very useful phrase that will limit the AI agent to only focus on what might be wrong and not come up with a million new ideas. You can try removing that phrase if you are okay with possible suggestions.
If you decide to ask it to also add new ideas, go back to Codex and ask to make a review on that file. At some point you NEED to tell them to bring up only critical concerns, otherwise they might never stop ideating.
Now, I have executed the query to Claude Code and it brought up a few questions in such form:
There might be a few of those, either pick an option or type your answer in "Other".
Still, I got some more open questions that Claude wants me to resolve, for example:
Critical concerns & inconsistencies
1. Permission model doesn't fit the two named mixins (fixed in spec)
The spec says to reuse TeamViewMixin and TeamAdminRequiredMixin, but I confirmed in mainapp/views/teams.py that neither expresses the "member" write tier the spec requires: TeamViewMixin lets viewers in (too loose for writes), and TeamAdminRequiredMixin rejects members (too strict for transaction CRUD). The four roles (owner/admin/member/viewer) exist in mainapp/models/teams.py, but transaction create/edit/delete needs a third gate. I added an explicit note to introduce a TeamMemberRequiredMixin (admits owner/admin/member, rejects viewer).
2. Transfer vs. conversion type was not deterministically derivable (fixed per your answer)
The type enum, the validation rules, and the "Move Between Wallets" flow disagreed about same-currency-with-fee moves — two competing fee mechanisms (fee_amount vs. edited destination_amount) meant transaction_type couldn't be computed reliably. Per your choice, I made it: transfer iff currencies match and amounts are equal; otherwise conversion with exchange_rate = destination_amount / source_amount. Updated the type definitions, validation rules, and the reporting note.
3. "All world currencies" conflicts with the rate provider's real coverage (fixed in spec)
I hit the live Frankfurter endpoint: despite the site advertising ~200 currencies, api.frankfurter.dev/v1/currencies returns only 31 (the ECB set). So wallets/transactions can use any ISO 4217 code, but auto-conversion rates exist for only those 31. I added a coverage caveat listing the 31 codes and the required behavior: when no rate exists, fall back to manual received-amount entry and never block the transaction (the move flow already supports manual entry).
4. source_currency nullability (fixed in spec)
The field list marked source_amount nullable but left source_currency unqualified, even though income has no source wallet. Marked it nullable for single-wallet income.
5. Currency fields duplicate wallet currency (fixed in spec)
source_currency/destination_currency duplicate each wallet's fixed currency and could drift. Clarified they're denormalized snapshots and must be validated equal to the wallet currency rather than chosen independently.
And these problems we do need to resolve before we ask an AI agent to implement the plan.
So, if you get such questions, try to resolve them by answering them, or if you are lazy and had enough of these chats you can ask the agent to "Resolve these questions the way you see fit to get to the MVP spec as fast as possible".
Now, this is a lazy option, but it will bring you closer to the moment when you can start implementing SOME version of the app much faster. Obviously, this approach might lead to unwanted results.
Sometimes taking such a shortcut feels like the only way, because questions and concerns can be never-ending.
As a matter of fact in my case I got pretty fine results by asking it to resolve these questions on its own.
As I said, since Claude made some changes to the spec, it is a good idea to go to Codex now and ask it to review the spec. It can be useful, especially when the task is big, and the initial MVP is a big enough task for that.
Feel free to do it if you want, I want to start the implementation phase faster.
Open a new chat in Claude in the same project, to clear the context and tell it to "begin implementation of the application based on the spec in this file @specs/financial-planner.md"
Hope you have enabled the "Auto" mode or at least "Accept edits". Claude will be working for some time now.
Some minutes later it finally worked.
Now it is time to open a new chat in Codex and tell it to "review the implementation against the spec @specs/financial-planner.md and write the review in the file reviews/financial-planner-review.md".
That's why the spec is so important because now we not only can ask Codex for general code review but the actual implementation the criteria from the spec.
After codex did that you can see the file with the review was created.
Go back to Claude, probably create a new chat to save tokens, and ask to "In the context of the task @specs/financial-planner.md act on the review @reviews/financial-planner-review.md"
And let him fix whatever is found, then repeat the Codex review/Claude fix cycle until it says that there is nothing to fix.