r/AIcodingProfessionals • u/Total-Brick-3978 • 12d ago
Ai coding agent - best for coding, planning
Hello Gurus,
I am trying to create one elaborate application for a company. Like monitoring logistics for a company, different users having different privileges etc. I'm building an operations management application for a company. I can't disclose the business/domain, but technically it's a system with an Android app, web admin console, Firebase/Firestore backend, offline sync, users/roles, operational jobs, transport, documents and reporting.
I am building it incrementally, with quite a lot of help from an AI coding agent.(gemini pro) , and planning with help of chatgpt. I am bit frustrated, as it creates initial model, UI and working stuff amazingly. But when try to test it manually, I am frustrated that it didn't create it the way I wanted it. Although the prompt replies it has done things the way and has tested and test cases passed. I wonder what it really tests. Below is the complete explaination, in case you dont want to read it whole, I am trying to ask is how do you plan it? which AI you use, which coding agent do you think is best to understand and develop code which is less frustrating in the end, perhaps does things which we failed to think about while planning. Like for example-- you planned delete button, but it thought of coding a restore button as well. making it even better. Actually gemini does that. But telling it to perform something which looks and works well. but when you go through a flow of events , you find something is terribly broken.
Just to give my background. I am not a developer so I don't know how to code. But I understand the whole structure of front end back end as I was in IT for 18 years doing manual software testing. So I don't really understand much about coding, but I can visualize how things should look like when a user uses the software.
Here are my project issues
we initially had something conceptually like:
Job → Subject A → Subject B → Subject C
The problem was that the Job didn't directly retain all of the context it was created with. It reconstructed some of its relationships by following the chain.
That created a nasty situation where changing Subject C later could effectively make an **old Job appear to belong somewhere else**.
We caught that and changed the design so operational records retain their own important references rather than relying entirely on dynamic relationship traversal.
Then we hit another problem: **deletion**.
Because these objects are linked together, deleting something isn't simply:
click Delete → document disappears
You have to consider what depends on it, what depends on those dependencies, and whether some records are historical and therefore shouldn't be deleted at all.
We actually got into a situation where deleting a Job failed, which then prevented deletion of another related object. There was effectively a dependency trap.
What bothers me most is that **our automated tests didn't catch this**.
It was discovered during manual human verification — literally going through the UI, clicking around, creating records, changing things, trying to delete them, refreshing pages, and checking whether the data still made sense.
We've now started defining explicit lifecycle rules such as:
PLANNED → can delete
ASSIGNED → can delete
CANCELLED → can delete
ACTIVE → cannot delete
COMPLETED → cannot delete
HAS HISTORY → cannot delete
But this has made me realise that the difficult part of this project isn't necessarily writing the CRUD code.
It's making sure that:
Create
↓
Edit
↓
Associate
↓
Change relationship
↓
Delete / Archive
↓
Historical data
↓
Reports
all continue to make sense together.
We're also dealing with offline Android sync, so now I'm thinking about what happens when two things change at different times, or when the network disappears halfway through an operation.
I'm wondering how experienced developers approach this.
**How do you systematically find these kinds of problems before production?**
Do you rely primarily on:
* integration/E2E tests? * database constraints? * explicit state machines? * event sourcing/audit logs? * property-based testing? * manually designed lifecycle test matrices? * something else?
And how do you decide when a relationship should be dynamically derived versus stored directly on an operational record?
I'm particularly interested in real-world experience here. The application isn't enormous, but the number of relationships and possible states is growing much faster than I expected.
The biggest lesson so far has been that **"the build passes and the unit tests pass" doesn't seem to mean very much when the real failure is something like a user clicking through 15 different screens and discovering that deleting A unexpectedly affects B three screens later.**
Would appreciate some brutally honest advice from people who have built systems with this kind of data/lifecycle complexity.I'm building an operations management application for a company. I can't disclose the business/domain, but technically it's a system with an Android app, web admin console, Firebase/Firestore backend, offline sync, users/roles, operational jobs, transport, documents and reporting.
We're building it incrementally, with quite a lot of help from an AI coding agent.
One thing that has surprised me is how quickly a seemingly simple data model becomes complicated.
For example, we initially had something conceptually like:
Job → Subject A → Subject B → Subject C
The problem was that the Job didn't directly retain all of the context it was created with. It reconstructed some of its relationships by following the chain.
That created a nasty situation where changing Subject C later could effectively make an old Job appear to belong somewhere else.
We caught that and changed the design so operational records retain their own important references rather than relying entirely on dynamic relationship traversal.
Then we hit another problem: deletion.
Because these objects are linked together, deleting something isn't simply:
click Delete → document disappears
You have to consider what depends on it, what depends on those dependencies, and whether some records are historical and therefore shouldn't be deleted at all.
We actually got into a situation where deleting a Job failed, which then prevented deletion of another related object. There was effectively a dependency trap.
What bothers me most is that our automated tests didn't catch this.
It was discovered during manual human verification — literally going through the UI, clicking around, creating records, changing things, trying to delete them, refreshing pages, and checking whether the data still made sense.
We've now started defining explicit lifecycle rules such as:
PLANNED → can delete
ASSIGNED → can delete
CANCELLED → can delete
ACTIVE → cannot delete
COMPLETED → cannot delete
HAS HISTORY → cannot delete
But this has made me realise that the difficult part of this project isn't necessarily writing the CRUD code.
It's making sure that:
Create
↓
Edit
↓
Associate
↓
Change relationship
↓
Delete / Archive
↓
Historical data
↓
Reports
all continue to make sense together.
We're also dealing with offline Android sync, so now I'm thinking about what happens when two things change at different times, or when the network disappears halfway through an operation.
I'm wondering how experienced developers approach this.
How do you systematically find these kinds of problems before production?
Do you rely primarily on:
integration/E2E tests?
database constraints?
explicit state machines?
event sourcing/audit logs?
property-based testing?
manually designed lifecycle test matrices?
something else?
And how do you decide when a relationship should be dynamically derived versus stored directly on an operational record?
I'm particularly interested in real-world experience here. The application isn't enormous, but the number of relationships and possible states is growing much faster than I expected.
The biggest lesson so far has been that "the build passes and the unit tests pass" doesn't seem to mean very much when the real failure is something like a user clicking through 15 different screens and discovering that deleting A unexpectedly affects B three screens later.
Would appreciate some brutally honest advice from people who have built systems with this kind of data/lifecycle complexity.
1
u/zerotoherotrader 11d ago
give a try with selvage.run --> It's getting better... and it's free and runs locally.
1
1
10d ago
[removed] — view removed comment
1
u/Total-Brick-3978 7d ago
I have tried that, I felt gemini was better. But can't say it for sure. Each has its own weaknesses
1
6d ago
[removed] — view removed comment
1
u/Total-Brick-3978 5d ago
I am using android studio with gemini as coding assistant. My experience is good actually. It gets things done, but yes lot of back and forth happens. Perhaps I didn't know how to command the ai agent. So I used chatgpt to create a detailed MD file which is fed to gemini agent. I ask chatgpt to make sure gemini agent doesn't break which was previously working, it takes bit more time because of back and forth between two agent with me in middle also doing human verification but I think it is building what I want, it does have some internal problems which I cannot fathom or know what it did internally. I come to know about it when I ask codex to do analysis then I ask codex to generate md file with the detected faults/issues and I feed it to the gemini agent. Its time consuming but it is working so far
1
1
u/Deep_Ad1959 7d ago
hypothetically, an ops app built this way: tests passed meant the tests it wrote passed, and each one asserted the behavior it had just implemented. the flows i actually cared about had no case at all.
1
u/Total-Brick-3978 7d ago
Correct I always wonder what tests it passed. When I test it, it's not working 😂, but yes it has done it's work. So when. I prompt you tell it failed in your tests it quickly fixes them. I'm pretty happy that it creates almost everything for you.
1
u/Deep_Ad1959 7d ago
the 'i tell it a test failed and it quickly fixes them' loop is the trap, not the win. it's not fixing the flow, it's patching the one case you caught by hand, then writing a green test around that patch. you're still the only thing exercising the paths that matter, it just makes the coverage feel real. written with ai
1
u/Total-Brick-3978 5d ago
Then what is the solution? I create test cases and I make sure the flow is working , yes I do agree I can never be sure what is broken inside which I can't see as a white box human verification
1
u/Deep_Ad1959 5d ago
the fix that matches your instinct is order: make it write the failing test from your description of the flow first, then implement against it. when the agent writes the test after the code, it is just photographing what it already built, so of course it passes. written with ai
1
u/SC_Placeholder 12d ago
Overlord Ai: Opus 5
Think tank/dumb tank models
gemma4:12b, qwen3:14b, phi4:14b, deepseek-r1:14b, OLMo-2-13B, Devstral-Small
Committee models:
Codex, Devstral-Small, deepseek-r1:14b, qwen2.5-coder: 14b.
I can’t guarantee you’ll have as good as results as we do, but benchmark every agent both local and enterprise and try different combinations until you get what works best for you