One-Bot Team: How CreditCalculator Was Built Without Writing a Single Line of Code

Try it yourself: CreditCalculator — live app | Source code on GitHub

This project started in a way that, not that long ago, would have sounded like a bad joke. I was lying on the couch, the TV was playing in the background, and instead of opening an IDE, I typed a single sentence on Telegram:
“Hey, I want a credit installment calculator.”

There was no repo template, no Jira backlog, not even a laptop within reach. Just a phone, a chat window, and the assumption that I’d see how far this could go.

It turned out: pretty far. 😅

The core assumption of the experiment was simple. I would stay responsible for product sense, numbers, and legal correctness. The bot would take over the entire technical layer. My job was to guard business logic and validate outcomes. Its job was everything else: breaking work down, implementation, pull requests, tests, and deployment. I defined what should be built. The bot decided how to build it.

The important part was not to mix those roles. Delegation only works if responsibility is actually handed over.

The entire workflow fit into three tools. Telegram was used for conversation and decisions. GitHub was where all the work happened: issues, pull requests, and change history. GitHub Pages handled deployment. There were no boards, no dashboards, and no additional layers of “process tooling.” The fewer moving parts, the less friction.

Under the hood (what actually made this safe and possible)

One important thing I intentionally skipped so far:
this was not a random chatbot with broad access.

The agent was running on OpenClaw, and the setup was deliberately constrained.

I created a separate GitHub repository just for this experiment and generated a repo-scoped token with full access to that repo — and nothing else. No access to my main GitHub account, no org-wide permissions, no shortcuts.

The agent interacted with GitHub exclusively via github-cli. That meant every change went through commits and pull requests, all actions were auditable, and there was no hidden state or silent mutation.

Pull requests weren’t used for review — they were used as a traceable record of change. Once a task was done, the PR was merged immediately.

The agent even spawned a sub-agent dedicated to background coding, so the main agent stayed responsive for decisions and questions. That separation wasn’t something I explicitly asked for — it emerged as a practical optimization.

There was also a moment that perfectly captured how this setup behaved in practice.

At some point, the agent pinged me on Telegram with a problem:
it tried to use rsync, but the tool wasn’t available in the environment.

My response was simple and intentionally hands-off: “I don’t care. Figure it out.”

That was it. No suggestions, no alternatives, no guidance.

A few minutes later, the agent came back with a different approach that didn’t rely on rsync at all — and continued working as if nothing had happened.

That interaction mattered more than it might seem.
It showed that this wasn’t a fragile script waiting for instructions, but an autonomous executor operating within constraints.

From a security perspective, this mattered a lot.
The blast radius was intentionally small. If the agent misbehaved, the worst-case scenario was a broken demo repo — not a compromised account.

This wasn’t “trusting AI with my GitHub.”
It was about deliberately designing a constrained execution environment — and then letting the agent operate freely inside those boundaries.

With that foundation in place, the rest of the process could stay simple and predictable.

The project didn’t start with code. It started with text. First, a master document was created describing the product rules: accepted parameters, installment logic, legal constraints, and how dates and holidays should be handled.

Only after that did the bot derive issues from the document and begin implementation. This made every change traceable back to an explicit requirement instead of a vague assumption.

During the night, the project ran on its own. New pull requests appeared, CI passed, and the app went live on GitHub Pages.

In the morning, I did what I always do with financial software: I compared the numbers against reality. I took a real Information Form from Allegro, checked the installment amount and APR, and immediately felt that something was off. Not a huge error, more of a subtle mismatch, but in finance that’s usually a sign you should stop and look closer. Instead of diving into the code, I took a photo of the form, sent it via Telegram, and marked which values didn’t match. That was enough. The bot created an issue, implemented the fix, opened a pull request, merged it, and redeployed the app. No discussion, no explanations, no “works on my machine.” There was an input, a correction, and a result. 🔁

The most interesting moments came when we reached the financial definitions. First, the formula for the legal interest rate cap had to be corrected. Then it turned out that the fee was accounted for incorrectly when calculating APR. Finally, a difference of just a few cents in the installment amount led us to change the interest calculation method to ACT/365 so that the results matched the representative example. Each of these elements was “almost correct,” but in finance, “almost” is never good enough.

The division of responsibilities in this setup was very clear. I focused on meaning, numbers, and decisions. The bot planned the work, wrote the code, fixed bugs, and delivered iterations. There was no shared tinkering in the implementation. Responsibility for the technical layer was consciously delegated. This wasn’t “AI helping me write code.” I never suggested implementation details or code-level solutions — only outcomes and constraints. It was handing over an entire area of execution.

A few conclusions became obvious very quickly. Constraints simplify systems. Pull requests are an excellent carrier of history and decisions. And chat is starting to act as a control plane, replacing IDEs and ticket systems. As long as communication is concrete, it works.

One last thing is worth saying. This application was built without me writing code, without opening a laptop, and entirely from my phone while lying on the couch. That’s both fascinating and slightly unsettling. And honestly, I’m not sure which one it is more. 🤔

This is what it ended up looking like: