The problem it solves
Most teams do not lack ideas. They lack the hours to turn every request into a specified, reviewed, shipped change. Requests arrive in calls and chat threads, get written down somewhere, and quietly age.
CodeLynq picks the work up at that point and carries it as far as your rules allow, stopping wherever a person needs to decide something. You approve the technical spec. You merge the pull request. Everything in between — implementation, your test suite, a review of the diff, a security scan, the docs — the platform does and shows its work.
Where the work comes from
Meeting notes and transcripts are one way in, not the definition of the product. A two-line written request works. So does a production alert from your monitoring, a failing CI run on an open pull request, an item picked up during AI backlog grooming, a greenfield project interview, or another AI assistant calling CodeLynq over MCP. They all land in the same reviewed pipeline.
What runs before a human looks at it
A development run does not stop at "wrote some code". It executes your project’s verify command and feeds failures back to itself, reviews its own diff as a critic, scans the change for secrets and vulnerabilities with the tools your repository already has, and updates the docs. Each of those can send it back to fix its own work. Anything it could not resolve is written into the pull request body rather than hidden.
After the pull request opens, a red CI run or a changes-requested review can send it back to the same branch, up to a limit you set. What your reviewers say is distilled into durable project memory, so later runs start already knowing it.
What you get
Many ways in, one pipeline
Meeting notes and transcripts, a two-line written request, a production alert, a groomed backlog item, or another AI tool calling in over MCP. However work arrives, it lands in the same reviewed pipeline.
Scope settled before code
The validation chat questions every task before anyone builds it. Unknowns, edge cases and missing requirements surface while they are still cheap to fix.
Specs grounded in your codebase
Technical Solution Documents drafted against your actual repository, with full revision history. Engineers review the plan, not a surprise diff.
Runs that check their own work
Before a pull request opens, the run executes your verify command, reviews its own diff, scans it for security issues and updates the docs — and fixes what it finds.
It keeps going after the PR
Failing CI or a changes-requested review sends the run back to the same branch until it is green or hits your cap. A merge can trigger your deploy pipeline and record the release.
Learns your codebase as it goes
Every run and every review adds durable facts about how your project actually works — conventions, layout, pitfalls — and later runs start from that instead of from nothing.
Governance your security team asks about
SAML 2.0 and OIDC single sign-on, SCIM user provisioning, enforced MFA, IP allowlists, admin/member roles, configurable retention, and an audit log you can export or stream to an HTTPS endpoint of your own.
Your code can stay on your machines
A self-hosted runner clones your repositories locally and they never reach our servers. Bring your own model key and the spend and retention terms are yours too.
Where the human stays in charge
There are three checkpoints, and none of them can be skipped. A task is validated in chat before anything is specified. The technical spec needs your explicit approval before a line is written. The result arrives as a pull request that goes through your normal review.
CodeLynq never merges and never pushes to a protected branch. If you merge nothing, nothing ships. Anything that can act on its own — iterating on CI feedback, opening a fix from an alert, triggering a deploy after a merge — is off by default and enabled per project, within limits you set.
What your security team will ask about
Single sign-on over SAML 2.0 or OIDC against your own identity provider, with password login blocked for your domain once you enforce it. SCIM 2.0 provisioning and deprovisioning, organisation-wide enforced MFA, CIDR IP allowlists, and admin/member roles.
Every privileged action is written to an audit log you can filter, export to CSV, or stream as JSON to an HTTPS endpoint you control. You set how long audit and run logs are kept. Repository tokens, model keys and SSO secrets are encrypted at rest, and a run only ever receives the credentials it needs — never the platform’s own.
If your source cannot leave your infrastructure, a self-hosted runner executes runs on your machines: repositories are cloned locally and never reach our servers, while specs, approvals and the audit trail stay in CodeLynq. Bring your own model key and the spend and the provider’s retention terms sit under your contract rather than ours.