Summary

SLAtech LTD is an Israeli software development company, operating since 2004. We help teams and product owners whose code was written with OpenAI Codex: we check the architecture, security and tests, how the agent's changes are reviewed and what environment it can reach, 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.

Codex projects

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

Codex carries out tasks on its own: in the cloud, each in its own isolated environment, returning finished changes as a pull request. In the terminal it works as an agent next to the developer. The trouble starts when pull requests arrive faster than the team can read them carefully. Changes get merged with barely any review, parallel tasks contradict each other, and for convenience the agent is given full access. We audit Codex projects, continue their development, or rewrite what is not worth fixing. What we fixed, we stay accountable for.

Tell us about the project Go straight to the audit

What Codex does well

Works in parallel. Each task runs in its own isolated environment, and several tasks can run at the same time.

Returns its work for review. Changes arrive as a pull request that a person reviews before merging.

Project instructions. An AGENTS.md file holds the standards and review procedure, and the agent reads it when it starts.

Access modes. In the terminal the agent's access is configurable, from read-only to working with project files, and full access has to be switched on explicitly.

That is why code written with Codex usually does not need to be thrown away. More often what needs fixing is how it gets reviewed.

Where Codex projects usually get stuck

More pull requests than attention

The agent works faster than the team reads. Review turns into a formality, and changes get merged because they look right.

Parallel tasks against each other

Each task is solved in its own environment and knows nothing about the others. After merging, the logic drifts apart and conflicts are patched in a hurry.

Full access for convenience

A mode in which the agent may do anything is convenient, but safe only in an environment isolated in advance. On a developer machine with production access it is a risk.

Tests by the same author

If the tests are written by the same agent as the code, they check what it did, not what was intended.

An outdated AGENTS.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 Codex project

1

Review procedure: who reads the agent's changes before merging, and how.

2

Agent access: working modes, network, access to secrets and production.

3

AGENTS.md and instructions: whether they match how the project is built today.

4

Architecture: where logic is repeated or contradicts itself after parallel tasks.

5

Application security: access rights, input validation, handling of secrets.

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: branches, checks before merging, a separate environment for checking.

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

Codex carries out tasks on its own, in a separate environment, and returns finished changes. 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

Each change can be right on its own, while together they produce a system nobody designed. The audit looks at the whole.

Only in an isolated environment with no access to production or secrets. We check where the agent runs and what it can reach.

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 Codex

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.

Tell us about the project Go straight to the audit