CodeKabir
AI-generated code
Fix and stabilise an application built with AI
You built, or had built, an application with Claude Code, Cursor, Codex, Lovable, Bolt or Replit. It mostly works. Now it needs a developer who will read all of it, fix what is broken, close what is exposed and get it ready for real users, without starting over unless starting over is genuinely cheaper.
When an AI-built application needs a developer
AI tools are good at producing something that runs. These are the moments where that stops being enough.
- It works in the demo and breaks with real users. Edge cases, concurrent users, bad input or a slow network expose paths the AI never generated a check for.
- Every new prompt fixes one thing and breaks another. The codebase has grown past what a single prompt can hold in view, so changes land without regard for what depends on them.
- You are not sure who can see your data. Authentication exists, but authorisation, database access rules and exposed keys were never reviewed by a person.
- The last 20 % never gets finished. Payments, emails, file uploads, admin screens or an integration keep stalling, and the tool cannot explain why.
- You need to leave the builder platform. Hosting costs, lock-in or a client requirement mean the code has to run on infrastructure you control.
- A developer looked at it and said "rebuild". Sometimes that is right. Often it is the answer of someone who did not read the code first. You deserve a second opinion based on the actual repository.
What I can do with your AI-generated project
Eight kinds of work, from a written second opinion to taking responsibility for the application long term.
Code review and technical audit
I read the whole codebase, not a sample, and report what is sound, what is fragile and what is dangerous, ranked by severity and with the effort to fix each item.
Debugging and fixing broken functionality
Reproducing the failure, finding the cause rather than the symptom, and fixing it with a test so it stays fixed when the next change lands.
Security review and remediation
Authentication and authorisation, exposed secrets, database access rules, input validation, dependency versions and the permissions granted to third-party services.
Refactoring for maintainability
Removing duplicated and dead code, separating what the AI tangled together and adding the structure another developer can work in later.
Completing unfinished applications
Finishing the features that stalled: payments, notifications, uploads, admin tools, reporting, or the part of the workflow that was only ever mocked.
API and back-end integration
Connecting the application to payment providers, email, CRMs, inventory or your internal systems through their real APIs, with error handling and logging.
Preparing for production deployment
Environment configuration, secrets management, database migrations, backups, monitoring and a deployment that can be repeated and rolled back.
Taking over an AI-assisted project
Becoming the developer responsible for an application that was built with AI, so changes are planned and reviewed instead of prompted and hoped for.
Which projects I can take on
The tool that generated the code matters less than two things: can the code be exported, and is it a stack I work in.
- Coding agents and editors. Claude Code, OpenAI Codex, Cursor, GitHub Copilot and similar tools, where the output is an ordinary repository I can read and run.
- AI app builders. Lovable, Bolt, Replit and comparable platforms, provided the code can be exported or synced to a Git repository. Lovable, for example, documents GitHub sync on all plans and a code download on paid plans.
- Stacks I work in. PHP and Laravel, JavaScript and TypeScript with React and Next.js, Node.js back ends, WordPress and WooCommerce, PrestaShop, and the databases and hosting that go with them.
- What I will say no to. Native mobile apps, code that cannot leave a proprietary platform, and stacks I do not work in. I would rather tell you that in the first email than discover it in week three.
Security and maintainability: what the review looks for
These are the checks I run on every AI-generated codebase I review. They are also the places where generated code most often differs from code written by someone accountable for it.
- Who can do what. Login is usually present. Whether a logged-in user can read or change another user's data is the question AI-generated code most often leaves open.
- Secrets and keys. API keys in front-end code, in the repository history or in logs; service keys used where a restricted key should be.
- Database access rules. Row-level security, query filters and admin paths that assume the client is honest.
- Input and uploads. Validation that exists in the interface but not on the server; file uploads without type, size or path checks.
- Dependencies and configuration. Outdated packages with known vulnerabilities, debug settings left on, permissive CORS, missing rate limits.
- Maintainability. Duplicated components, dead code from abandoned prompts, no tests, and logic spread across files in ways that make the next change risky.
Independent studies of AI-generated code report that authentication gaps, exposed secrets and duplicated code are the recurring problems, and that a large share of the issues survive long after the code is written. That matches what the checks above are designed to catch. I quote the studies in the articles linked below rather than claiming statistics of my own.
Audit, fix, refactor or finish: choosing the scope
You do not have to decide this before we talk. The audit is designed to make the decision for you, with numbers.
- Audit only. A written review of the codebase with findings by severity and an estimate for each. Useful when you want an independent opinion before deciding anything, or before paying anyone else.
- Fix the blockers. Resolve the issues that stop you launching or that put data at risk, leave the rest documented for later. The fastest route to a safe release.
- Refactor and stabilise. Fix the blockers, then restructure the parts that make every change risky, add tests around the critical paths and set up proper deployment. For applications that will keep evolving.
- Finish the build. Everything above plus completing the features that were never finished, as a scoped project with a written specification.
How the review and remediation work
Access and inventory
You give me read access to the repository, the hosting and the services it uses. I list what is there: stack, dependencies, environments, data, integrations.
Read the whole codebase
Before changing anything I read all of it. The audit report that follows is based on the actual code, not on a quick look at the parts that happen to be broken.
Audit report
Findings ranked critical, high, medium and low, each with the risk it carries, the effort to fix it and whether it blocks launch. You can stop here and keep the report.
Scope and quote
A written proposal for the option you choose: what will be done, in what order, the timeline and the price for that specific work.
Fix on a branch, with tests
Work happens in version control, never directly on the live application. Critical paths get tests so the next change cannot silently undo the fix.
Release and hand-over
Deployment at an agreed time, with a rollback path, plus documentation of what changed and how the application now works so you are not dependent on me either.
What to expect, honestly
I am one developer, not an agency, and I work with clients in several countries from Marrakech. That means you deal with the person who reads your code, and it means I take on a limited number of projects at a time. I do not claim certifications I do not hold, I do not publish client names or numbers, and I will not tell you an application is "fully secure" because no honest developer can.
What I can promise is the process on this page: the whole codebase read before any opinion is given, findings in writing, work in version control with tests, and a hand-over that leaves you free to work with anyone afterwards. If you are weighing up what this kind of work should cost and how to choose someone, start with what actually drives the cost of fixing a vibe-coded app.
What to include when you request a quote
- Which tool or platform the application was built with, and whether the code is in a Git repository or still inside the builder
- What the application does, who uses it today and whether it is already live with real data
- What is broken, missing or worrying you, with an example of each where possible
- The stack if you know it: language, framework, database, hosting and third-party services
- Any deadline, and whether you are weighing an audit, a fix or a full hand-over
A short description and a link to the repository are enough to start. If the code is still inside a builder platform, say which one and I will explain how to get it out. If it turns out you do not need me, I will tell you that too.
Request a QuoteQuestions about fixing AI-generated applications
Common questions about taking an application built with AI tools from a working prototype to something you can run, secure and maintain.
Can you fix an app built with Lovable, Bolt or Replit?
Usually, provided the code can be taken out of the platform. Lovable documents GitHub sync on all plans and a code download on its paid plans; Bolt and Replit also let you push to GitHub or download the project. Managed databases, storage and secrets stay behind on the platform and need to be replaced, which is normal migration work. Platforms that do not let the code out are the exception, and I will say so.
Do I have to rebuild from scratch?
Not as a rule. A rebuild is the right answer when the architecture cannot carry the product, or when fixing would cost more than rewriting. Most AI-generated applications I would expect to see need targeted fixes and structure, not replacement. The audit exists to answer this question with evidence instead of instinct, and if a rebuild really is cheaper I will tell you.
Will the application be secure after your review?
It will be reviewed by a developer against the checks listed on this page, and the issues found will be fixed or documented. No one can honestly promise that software is completely secure, and I will not. What you get is a known state: what was checked, what was found, what was fixed and what was accepted as a risk.
How much does it cost?
It depends on the size of the codebase and on what the audit finds, so I do not publish prices. An audit is a fixed, written quote; fixes and refactoring are quoted per scope after the audit. The article on what drives the cost of fixing a vibe-coded app explains the factors in detail.
Do you use AI tools yourself?
Yes, as tools, with every change reviewed and tested by me before it reaches your repository. The problem with AI-generated applications is rarely the tool. It is the absence of someone responsible for reading what it produced.
Who owns the code afterwards?
You do, as you did before. Work is delivered into your repository and your hosting accounts. I do not keep a copy of your application or your data beyond the engagement, and I do not publish client projects.
Can you keep maintaining it after the fix?
Yes. Taking over an AI-assisted project long term is one of the services on this page. We agree how changes are requested, reviewed and released, and you keep the option to bring in someone else at any time because the code is documented and in version control.
Have an AI-built application that needs a developer?
Send the repository or describe the problem. I will reply with questions or a first estimate for the audit.
Request a quote
Tell me what you want to build, fix or improve. I'll read your message, ask any questions I need, and reply with next steps or a first estimate. There's no public price list: every quote is based on your actual project.
- Phone+212 671 855 177
- LocationMarrakech, Morocco