Zerg

Situations in which buyers should consider alternatives:

1. If documented compliance (SOC 2 / ISO 27001) is required before granting vendor access to source code. The vendor does not publish those certifications publicly.
2. If transparent, self-serve pricing and predictable spend are required up front. The vendor uses a demo-led engagement model and does not publish pricing.
3. If the organization cannot tolerate autonomous changes to production-adjacent code. The operational model is more autonomous than typical copilot tools and may not align with strict change governance.
4. If the primary need is simple integrations with strong governance and predictable operational controls. Established iPaaS vendors may provide faster and more controlled time-to-value.

• Deployment options: SaaS versus self-hosted options are not clearly documented.
• Data handling: It is not clear whether source code or artifacts are sent to third-party language models, retention policies, or whether vendor models are trained using customer data.
• Security controls: Details on SSO/SAML/SCIM, audit logging, and encryption practices are not publicly documented.
• Change management model: It is not clear whether automated changes are opened as pull requests only or whether the system can directly push/merge changes.
• SLAs and support model: Service levels and escalation procedures are not publicly documented.

Evidence for these gaps is the absence of public documentation on the vendor's website and public materials.

The vendor lists several short, high-level examples of outcomes without customer attribution or independently verifiable metrics, including:

1. Enterprise integration catalog maintained autonomously
2. Continuous CVE remediation without human intervention
3. Data pipeline adapting to schema changes in real time

Critical perspective: These outcomes are plausible but lack named customers, baseline comparisons, measurement methodology, and time horizons. They should be treated as vendor claims rather than independently verified evidence.

• No independent verification is available: there are no named references or published third-party case studies.
• No methodology is provided: claims do not state frequency, coverage, quantified time savings, or error rates.

Recommendation: Require the vendor to provide at least:

• a small set of reference calls with named customers
• a redacted sample of pull requests or change logs showing automated changes
• operational metrics from a controlled pilot (for example, average time to repair for broken connectors, counts and merge rates for automated PRs, rollback frequency, and escaped-defect indicators)

Zerg describes its offering as "Continuous Software": a system that connects to a customer's engineering environment (repositories, tests, APIs, dependency manifests, logs) and regenerates or rewrites code as external conditions change (for example, upstream API changes, dependency updates, evolving requirements, or newly disclosed vulnerabilities). The vendor frames the product as infrastructure-like (similar to CI/CD or Kubernetes) rather than an interactive chat-based copilot; it is designed to operate continuously and respond to drift or environment changes.

Zerg's site identifies three main product components:

• Zerg Autonomous (autonomous code generation infrastructure)
• ZDE (Zerg Development Environment for configuration and monitoring)
• ZTC (Zerg Terminal Client for command-line control)

Use cases described by the vendor include:

• Generation and ongoing maintenance of data connectors and integrations
• Large-scale code migration and refactoring
• CVE remediation (detecting, patching, and verifying vulnerabilities)
• ETL pipeline code generation and monitoring