At Whyphy Technologies, we help Independent Sales Organizations (ISOs) build their own POS software. In the span of 10 years, we have built multiple full-service POS software solutions.
We use AI heavily, but we deliberately don't let it make the important engineering decisions for us.
We don't believe in vibe coding; instead, we believe in Agentic Engineering. At least that's what Peter Steinberger, the creator of OpenClaw, calls it. For us, Agentic Engineering means engineers remain responsible for requirements, architecture, planning, and final review, while specialized agents help with analysis, implementation, testing, and repetitive review work.
With this post, I'll try to explain how AI helps us accelerate our development process while implementing new changes. We are using this workflow for multiple production Point of Sale software projects, and we'll keep improving it.
1. What if it blasts?
We mostly use Codex for our development workflow. While iterating on the project, we don't let LLMs do the planning.
Imagine we're changing how discounts are calculated. It sounds like a small change, but it could affect order totals, taxes, refunds, receipts, reporting, and payment reconciliation. The developer working on this will first collect the requirements in as much detail as possible. They go through them and report to the product team if there are any possible gaps or technical limitations.
Once the ticket is in shape, the dev then decides the blast radius. We like to measure firsthand how it will affect the other modules and, if something goes wrong, how much damage it can cause and in what areas.
To decide this blast radius, we let our custom Codex agent do its job, usually with the 5.6 Sol model with extra-high reasoning. The agent then prepares a document that we can review to understand the possible regressions.
After multiple rounds of back and forth, we decide the final technical requirements with minimum blast radius, minimum code, and fewer loopholes.
This process is a must for us while working on any mission-critical software like Point of Sale. One mistake here and there, and we might break a restaurant's complete workflow.
2. We don't ask LLMs to create a plan
We simply don't ask an LLM to write the implementation plan for us. The developers write it point by point in an empty Markdown document.
Once the handwritten plan covers everything, we then ask our planner agent to review it and suggest any missing points. Up until this point, we are basically brainstorming with Codex without writing a single line of code.
Once the agent and developer are both on the same page, we move forward to the next process.
3. From human plan to agent execution outline
Once the plan is finalized, we prepare the design outline next. We ask Codex to create the execution outline in phases, detailing how it'll implement the plan given by the user.
We then review the document thoroughly with all the devs in a meeting. Sometimes, working synchronously is more productive than working asynchronously.
We found that if developers collaborate on these documents asynchronously, it ends up taking more time and discussion anyway. Lucky for us, we all like to work together in the office.
Once all the dev members are on the same page, we move to the next step, which is development.
4. The development
After completing the design outline, we simply ask Codex to implement the plan with our implementation agent.
Our implementation agent is maintained by all team members. If the agent makes the same mistake twice, we add it to its system prompt to avoid it next time.
We follow a practice where we keep a separate implementation agent for each project. These implementation agents are fine-tuned to be project-specific.
5. Testing
After development is finished, we write E2E tests to verify the work. In most of our Android POS projects, we use clean architecture, which gives us an unfair advantage when writing unit tests at the ViewModel level. ViewModels are basically a state for the UI, i.e., Activity or Fragment.
This means an E2E test on the Maestro platform, which may take 1 hour to run, takes less than 1 minute to run while validating the business logic. We still run E2E tests to catch other UI wiring, navigation, device behavior, integration issues, etc.
For writing unit tests, we don't let Codex write them autonomously; instead, we make inline changes. We use the Codex plugin inside JetBrains-based IDEs, and with Cmd+K, we use quick inline prompting to make deterministic changes while writing the tests.
This is because, in our internal evals and practice, we found that models are still very bad at writing and maintaining unit tests.
6. Code review and maintenance
We still follow a traditional code review mechanism because when you care about quality, you don't want to make a single line of unreadable code live in production. As Mario Zechner, creator of the PI coding agent, says, "Read the F***ing code."
But with an increase in development thanks to Codex, we usually face a bottleneck during the code review process.
So we made an agent that auto-reviews the code. These agents are project-specific; one project's agent is obsolete in another project. These are optimized by engineers on our team with their in-person experience of actual code reviews of the projects they are contributing to.
This Codex-powered auto-review agent goes through the PR and leaves possible comments. It keeps doing this until the said confidence rate is achieved. We give it certain parameters in the system prompt to calculate the confidence score.
After that, a PR can be submitted for a manual review by an engineer. This process has helped us solve the bottleneck issue to some extent.
7. Overall results
Based on our internal experience, this process has helped us improve our productivity by 2x to 3x, which is perfect for us while developing mission-critical software. We don't aim for 10x or 100x boosts, which in return may generate a slop pile, making the software completely unmaintainable in the long run. The goal is to ship reliable software faster without increasing the maintenance burden.
This is the specific process we are following for new feature and change implementation. In upcoming posts, I'll share what agentic workflows we use for bug fixing and code refactoring. Stay tuned.