Summary

SLAtech LTD is an Israeli software development company, operating since 2004. We help teams and product owners whose code was written with Claude Code: we check the architecture, security and tests, the agent's permissions and its access to secrets, take the project to production and keep developing it. The code stays in your repository. People define the architecture and make the decisions; AI only proposes.

Claude Code projects

Your Claude Code project is stuck? We will check it, fix it and take it to production

Claude Code works as an agent in the terminal: it reads the project, changes files, runs commands and tests on its own. It is a very fast way to write code. The trouble starts when there is more code than anyone can read. The agent is given broad permissions, it can see the files holding keys, and changes reach the repository without careful review. We audit Claude Code projects, continue their development, or rewrite what is not worth fixing. What we fixed, we stay accountable for.

What Claude Code does well

Works with the whole project. Reads code, runs commands and tests, and checks the result itself.

Adapts to the project. A CLAUDE.md file holds the standards, architecture decisions and review procedure.

Permissions enforced by the program. What the agent may and may not do is set by rules, and the program itself enforces them, not the model.

Hooks and subagents. Checks can be built into every agent action, and big tasks split into parts.

That is why code written with Claude Code usually does not need to be thrown away. More often what needs checking is how it got into the project and what the agent was allowed to do.

Where Claude Code projects usually get stuck

Permissions that are too broad

So the agent stops asking at every step, it is allowed everything. Then it can delete files, run a command on the production server or push changes without review.

Access to secrets

The agent reads project files, including settings with keys and connection strings, unless they are closed off. Everything it reads goes into the model's context.

An instruction is not a restriction

A line saying “do not touch production” in CLAUDE.md guides the agent but prohibits nothing. Only permission rules prohibit.

Changes without careful reading

The agent does a lot of work quickly, and it gets accepted because the tests are green. But those tests may have been written by the same agent.

An outdated CLAUDE.md

Instructions are written once, while the project changes. The agent confidently follows old rules.

Blurred architecture

Each task gets solved wherever is easiest for the agent. The same logic ends up in several places, and a fix in one never reaches the others.

What we check in a Claude Code project

1

Agent permissions: what it may do, what it may not, and where everything is allowed.

2

Secrets: which files with keys and connection strings the agent can access.

3

CLAUDE.md and instructions: whether they match how the project is built today, and which of them should become a permission rule.

4

Architecture: where each piece of logic lives and where it is repeated.

5

Application security: access rights, input validation.

6

Tests: what they actually check and which main scenarios are not covered.

7

Dependencies: unneeded, outdated and vulnerable libraries.

8

Database work: queries, indexes, migrations.

9

Deployment: whether a change can reach production without human review.

The result: a written report in plain language, a list of issues ranked by risk, and a plan of fixes.

Three ways forward

Audit

A check against the list above, a written report and a plan of fixes. A fit if you carry on yourself or with your own team.

More about the audit

Continued development

We join your team or run the product ourselves: we close the critical issues and keep developing it. What we fixed and wrote, we are accountable for.

Discuss continuing

Rewriting a part

Usually not everything needs rewriting, only the one area where the logic is most scattered: access rights, payments, data handling.

Discuss a rewrite

How we choose between these paths is described in detail on the page about helping vibe-coded projects.

How we use AI ourselves

Claude Code works as an agent: it reads the project, changes files and runs commands on its own. We work differently. On client projects, people define the architecture and make the decisions. AI proposes a solution to a task a person has set, and we bring it into the project ourselves, after review. The AI agent gets no access to the code, databases, keys or passwords, and there is not a single line in the code that a person does not know about.

Frequently asked questions

Yes, if permissions are set by rules, secrets are closed off from the agent, and a person reviews changes before merging. The audit shows where these conditions are not met.

No. An instruction guides the agent but does not prohibit the action. A restriction is set by permission rules, which the program itself enforces. We check that the important limits are written there.

No. We are not against AI tools. What matters is that tests, human review of changes and a clear system design sit alongside them. The audit shows where these are missing.

Read access to the repository. We sign an NDA if needed. Access to the database and production is discussed separately, and only when it is really needed.

It depends on two things: the size of the project and how far it has drifted, that is, how much in it needs changing and fixing. After the initial assessment we name the scope of work and the price, before any work starts.

Other AI tools

We work the same way with projects built on other tools. The general page: help for vibe-coded projects.

Tell us what you built with Claude Code

Describe the product and what is holding it back. We will take a look and suggest where to start: an audit, continued development or rewriting a part.