While on holiday, sitting on the beach, I built Compliage with Gemini CLI. I wanted to see how the free tool would handle a project that involved data collection, databases, payments and the surrounding work of making an application run.
It got through those tasks. I did not write a line of code by hand. Deployment, tests and CI/CD also went through the CLI. That was the satisfying part of the experiment: the work extended beyond producing a convincing screen.
The other part was just as clear. In a couple of critical places, I had to describe what I wanted step by step. Knowing what to ask for still mattered. The keyboard work had changed, but the need to understand the system had not disappeared.
A request can hide several contracts
"Add payments" sounds like one feature. It contains a collection of promises between the application, the payment provider and the user. Which event means payment succeeded? What state should exist if the browser closes before the application receives confirmation? What happens when a notification arrives twice?
Those questions make a broad instruction more useful. They describe the behavior the integration needs, while leaving room to choose an implementation.
A generated flow may look complete because the happy path works. The difficult work is often in the cases where two systems disagree temporarily. A button says one thing, a database records another and an external service is still processing an event. Asking for a reliable outcome requires naming the relationship between those states.
Data collection has a similar shape. "Collect the data" leaves open what counts as the same record, how updates are recognized and what to do when a source changes. A script that retrieves a page successfully is only the beginning of a dependable data process.
These are the kinds of distinctions that become easier to notice when an agent removes much of the mechanical work. The application appears quickly enough that its missing assumptions become visible. That is useful, provided I treat those assumptions as my problem to clarify rather than expect the model to infer every product decision.
Tests need a reason to exist
I included testing in the work handled through Gemini CLI. That is encouraging, but the existence of tests does not make an application correct by itself. A generated test can confirm what generated code currently does while missing what the product actually needs.
The useful request describes an observable promise. If an operation is repeated, should it create a second record or return the existing one? If the network fails midway, what should remain saved? If a user returns later, what information should still be available?
Those examples give a test something independent to check. They also make review easier for me. I can read the scenario and decide whether it matches the intended behavior without first becoming familiar with every implementation detail.
The same principle applies to deployment. An automated pipeline is valuable because it can repeat a process. The process still needs a clear definition of success. A build finishing is different from an application starting correctly, and both are different from a critical user flow working after the update.
I would rather ask an agent to demonstrate those stages separately than accept a broad "done" that compresses them into one word. A useful report tells me what ran, what passed and what remains a judgment call.
The beach is not the explanation
The beach makes the story more amusing, but it is not the important technical detail. The important change is that I could move through a substantial amount of implementation by describing, inspecting and correcting the work in one tool.
Gemini CLI gave me a way to keep that loop going across application code and operational tasks. I was still responsible for the requests and for deciding when an answer was inadequate. In the critical places, the best progress came from becoming more explicit.
The experiment showed how far a builder who knows the questions can get without personally typing every implementation step. Understanding the work made it possible to guide it.
Compliage was a good test because it crossed boundaries where a visual demo is not enough. Data has to persist. Payments have consequences. Deployment has to be repeatable. The agent could help with all of that, but a few sentences of precise direction still made the difference between plausible progress and the behavior I actually wanted.