Seeing all the hype about agentic coding sparked my interest to give "Vibe Coding" a shot. I set a single rule for myself: don't touch the code by hand. Do it only with Claude Code straight from my terminal using the Claude Sonnet model.
The Task
Implement EDIT functionality in a very simple CRUD (single module) Android app.
- On the home screen, the app fetches all food orders the user made.
- User can see all items listed and click the edit button to enter the
CreateOrderscreen, which will be populated with existing data so it can be modified and updated. - The screen must be reused and the ViewModel should differentiate whether to POST or PUT.
The approach for this is very simple. Pass id to the details screen, fetch data by id and populate the screen. When the user edits the content, make a PUT API call instead of POST.
The Setup
I'm using the Anthropic Pro plan which gives me around 44k tokens until I hit the 5 hour limit. I added 5 agents in .claude/agents:
| Agent | Role |
|---|---|
android-architect-agent.md |
Understands the feature, makes decisions and explains trade offs to the senior android engineer agent, which takes over next. |
senior-android-engineer-agent.md |
Handles the implementation of the code while caring about clean architecture, code maintainability and unidirectional data flow. |
refactoring-agent.md |
Applies the boy scout rule after the senior agent implements the flow, caring about code readability, maintainability etc. |
test-engineer-android-agent.md |
Writes unit tests for ViewModels and domain logic. |
meta-orchestrator-agent.md |
Plays the role of Engineering Manager who orchestrates all the agents mentioned above. |
I polished the agents as much as I could with clear instructions about roles, hard rules and responsibilities. I like how Claude Code guides the creation of agents inside the terminal. It's easy to set which tools and permissions each agent can use. It really feels like assembling a whole engineering team.
The Prompt
I gave full responsibility to the agents to approach the problem however they wanted. The prompt I used was:
I want to extend CreateOrderViewModel to support editing of the order. At the moment only an order can be created, but the user can navigate to this screen by clicking the edit button on an existing order.
- User should be able to click the edit button on the order item and land in the create order screen.
- Screen must be populated with the data from the existing order.
- To get the order, use new API call (GET /api/v1/orders/{id})
- If user edits the order, then new backend call should happen. (PUT) instead of POST.
- Edge cases must be handled.
- Apply boy scout rule along the way to refactor bad code.
- ViewModel must be fully tested.
At this point, after setting all of this up, I got really hyped about what Claude Code would cook.
I prepared coffee and fired the main meta-orchestrator-agent.md with the prompt and the show was on...
The Results
After about 22 minutes of cooking, here's what Claude produced:
The Good
-
orderIdwas passed via constructor parameter in the VM - ViewModel test coverage was around 90%
- It handled the process death scenario with
SavedStateHandlein the ViewModel (this was not mentioned in the prompt) - It wired the existing Type Safe Navigation 2 by adding
orderIdas a parameter to the serialized data class destination - Connected the UI state with the UI without any issues
- Easily wired existing Koin DI
The Bad
- ViewModel exceeded 300 lines of total logic. Extra classes weren't extracted.
- Scattered
try-catchblocks everywhere, with a lot of early returns like null checks or parameter validations - Init block with heavy api operations.
The code looked a bit messy based on my preference. Error handling could be hidden somewhere else or at least use some DSL style handling. Also, the ViewModel was screaming for extraction.
I also noticed this piece of code which didn't make a lot of sense. It updates state twice in the same onSuccess block.
Example of one function in the VM which looks bloated.
The Debugging
First Run
First run crashed! Claude forgot to add the @Serializable annotation on the navigation. I prompted the error message and it started fixing.
Second Run
The Edit button wasn't doing anything. I prompted the issue again. It cooked for a bit and found out it was using tryEmit on the SharedFlow without buffer capacity, so the collector missed the emission. The fix was to add replay of 1 to the SharedFlow, which actually behaves exactly like StateFlow.
Third Run
It didn't happen. I hit the 5 hour limit with all 44k tokens used. Which means I need to manually refactor and make the app work, or wait 5 hours, or pay 100 bucks for more tokens monthly.
Conclusion
I'm still not convinced about agentic coding, especially for Android apps with complex modular architecture. For this whole task I would need 40 to 60 minutes including the test cases.
Some people are too religious about it. But maybe I haven't configured the agents correctly, or should use Opus instead of Sonnet? Or maybe it needs a smaller context first, then expand more to create a snowball effect?
I leave those questions open. There are good discussions about these topics, and I'm sure there are more experienced AI people who have different experiences than mine.
Feel free to send me a DM if you have more experience and want to discuss this.
Top comments (0)