How We Use Claude Code on Client Projects (and What Humans Still Do)

A question that comes up more and more in initial consultations: "You use AI for coding, right? So what am I paying for?" A fair question, and one worth answering in the open.

Yes, we use Claude Code and similar AI tools in almost all of our daily work. This article explains exactly what the AI does, what humans still do, how client code and data are protected, and how all of this affects estimates and pricing. If you're comparing vendors, the questions at the end can be put to anyone.

What Claude Code is, in non-technical terms

Claude Code is an AI assistant that runs in an engineer's terminal. Unlike a regular chatbot, it can read the entire project's code, change many files at once, run the tests, read error messages, and fix them itself. The engineer gives instructions in plain language, say "add a date filter to the sales report and write the tests", then reviews the result.

Think of a senior engineer who now has an assistant that types extremely fast, knows every library's documentation by heart, never gets bored writing tests, but needs direction and whose output needs checking.

What the AI speeds up

In our experience, AI is most useful in work with clear specifications that's easy to verify:

• Routine code. Forms, validation, CRUD pages, API integrations with good documentation. Work that used to take hours now takes minutes.
• Automated tests. This is the biggest change. Writing tests used to be skipped because it was tedious. Now almost every function has tests, because the cost is small.
• Reading legacy code. When a client arrives with an app inherited from a previous vendor, AI helps map its structure in hours instead of days. This speeds up migrating legacy apps.
• Documentation and translation. Technical docs, interface text in several languages, release notes.
• Debugging. Reading error logs and suggesting causes. Often right, sometimes wrong, always faster than starting from zero.
• Prototypes. A rough version of a feature to discuss with the client at the weekly demo, before building it properly.

What humans still do

This is the part that determines whether the result can be trusted.

Understanding the business problem. The AI doesn't sit in client meetings, doesn't know that "customer" means two different things in your business, and doesn't know that the requested feature actually solves the wrong problem. The discovery phase in our SDLC is entirely human.

Architecture decisions. Where data lives, what runs on the server and what on the device, which services to use, how the system will grow. These decisions determine costs for years. In Cuplikin, the local-first decision was a human decision that changed the product's entire cost structure.

Reviewing every change. No code enters a client project without an engineer reading it. Not skimming, but reading with questions: is this secure, does it handle edge cases, will it be hard to maintain. AI writes fast, and it also writes wrong things fast and confidently.

Security and data. Authentication, access permissions, payment handling, and anything touching personal data is checked manually, always. This is where AI mistakes are most expensive and least visible.

Testing by humans. Automated tests make sure the code does what was asked. Humans make sure what was asked is actually right: walking through the flow as a user, finding confusing text, noticing that an important button is hidden.

Responsibility. If something breaks in production, you call our engineer, not the AI. That responsibility is what makes us read the code.

Honest note: AI has also changed our own bad habits. When deadlines got close, tests used to be the first thing sacrificed. Now there's no excuse, because writing tests takes almost no time. On the other hand, there's a new temptation: accepting code that "looks like it works" without reading it. Our rule is simple and non-negotiable: every change is read by a human before it goes in. If the engineer can't explain why a piece of code is there, it doesn't go in.

How client code and data are protected

This is what clients with security policies ask about, and it has to be answered specifically:

• Client code stays in client-owned repositories, with access that can be revoked at any time. This is our rule regardless of AI, and we cover it in the software house checklist.
• The AI accounts we use are business accounts with terms that exclude using data for model training. Code snippets are indeed sent to the AI provider for processing; that's how these tools work, and we won't pretend otherwise.
• Production data never goes into AI tools. Customer data, credentials, API keys, and other secrets are managed separately and are not in the context the AI reads. Development uses mock data.
• Adjustable per contract. Some clients ask for additional restrictions, such as no AI tools for certain modules, or only self-hosted models. We adapt and explain the impact on the schedule.

The effect on estimates and pricing

To "so it's cheaper, right?" the answer is: it depends, and we'd rather be honest than promise a number.

What definitely changes:

• More accurate estimates. Parts that used to be hard to estimate, like third-party API integrations, are now more predictable because a prototype can be built in hours to gauge the difficulty.
• Time shifts. Less time typing, more time on review, testing, and discussion with the client. Total hours for simple projects do go down. For projects with many business rules, the saving is smaller, because the hard part was never the typing.
• Prototypes become part of discovery. Instead of debating over a document, we often show a rough version at the weekly demo.

What doesn't change: running costs after release (servers, AI services if any, maintenance) and the time needed to understand your business. Project cost ranges stay as we wrote in the cost of building an app in Indonesia 2026, with the note that simple projects now sit at the lower end of that range.

Questions for any vendor

If you're comparing software houses, ask these, including of us:

1. Do you use AI to write code? A "no" in 2026 is most likely either dishonest or inefficient.
2. Who reads the AI-written code before it enters my project?
3. Which parts are AI not allowed to do in your process?
4. Is my code sent to an AI provider, under what terms, and can it be restricted?
5. What happens if AI-generated code causes a problem in production? Who is responsible?

Good answers are specific and admit limits. An answer that's only "we use AI so it's faster and cheaper" is a sign to ask further. Other criteria for judging an AI vendor are in choosing a reliable AI development partner.

Next steps

If you want to know how this process applies to your project, or have a security policy we need to adapt to, tell us about it for a free initial consultation, or chat on WhatsApp. If you've already tried building it yourself with AI, read vibe coding for business owners first.