Concerted Engineering
frequently asked questions.

Concerted Engineering is a proposed AI-native software engineering operating model originated by Dr. Joel He at OpenKedge. It coordinates customer intent, bounded execution by engineers and coding agents, independent verification, and operational feedback through a shared versioned engineering state. Humans remain accountable for priorities, permissions, and production admission.

Faster implementation can move the bottleneck to understanding the problem, reviewing changes, reconciling requirements, and deciding what is safe to release. Concerted Engineering proposes reducing repeated translation and waiting across those boundaries. Its benefit must be tested through customer outcomes and end-to-end flow; more generated code is not sufficient evidence of better delivery.

The model is intended for product and engineering organizations introducing autonomous coding into real delivery workflows, especially where handoffs, review queues, or unclear authority slow verified changes. Product leaders, engineers, verification specialists, platform teams, and engineering leaders share responsibilities. A small team can start with one bounded service if it can preserve meaningful verification independence.

Concerted Engineering describes an operating model, not a required software product or certification. You can use existing repositories, issue trackers, CI/CD, policy systems, and observability tools to implement its contracts and controls. The illustrative YAML on this site explains the contracts; it does not enforce permissions or deploy a working control plane.

Dr. Joel He at OpenKedge originated the Concerted Engineering framework. The foundational article, Beyond Agile: The AI-Native Software Engineering Operating Model, is published on OpenKedge Insights. This companion site explains the framework, its adoption experiment, and the open questions that require evaluation.

Agile provides values and principles for adaptive, collaborative delivery. Concerted Engineering proposes a specific coordination and governance model for humans and coding agents: Intent, Execution, and Evidence Contracts linked to a shared state. Agile does not mandate handoffs or sprints, so the distinction is explicit execution authority and independent proof, not a claim that Agile cannot support continuous delivery.

Waterfall organizes work through successive project phases, commonly requirements, design, implementation, testing, and acceptance. Concerted Engineering proposes maintaining intent, execution boundaries, and verification evidence continuously against the same versioned context. Required project milestones can remain, but disciplines do not have to reconstruct context at every phase boundary.

Yes. Scrum can provide goals and an inspect-and-adapt rhythm while the three contracts govern individual changes. Kanban can visualize work, limit work in progress, and reveal evidence queues within the same model. Keep the practices that help your team. If you remove required Scrum elements, describe the resulting approach accurately rather than claiming it remains Scrum.

No. Existing CI/CD, automated testing, observability, incident response, and rollout controls provide useful implementation foundations. Concerted Engineering adds an explicit connection between customer intent, permitted execution, and independently controlled admission evidence. A successful pipeline run is one input to that decision, not a replacement for product judgment or operational ownership.

No. Specification-driven development makes intended behavior explicit to guide implementation. Concerted Engineering also separates the authority to execute, the ownership of verification evidence, and the decision to admit a change to production. A specification can contribute to an Intent Contract, but it does not automatically create permission boundaries or independent verification.

The Intent Contract states the customer problem, desired outcome, behavioral requirements, and invariants. The Execution Contract defines allowed changes, isolation, access scopes, and resource budgets. The Evidence Contract defines the independently controlled proof needed for production admission. They reference a shared versioned context so evidence can be checked against the intent and permissions that actually governed execution.

A contract here is a versioned engineering agreement with an accountable owner and explicit conditions. It is not a legal contract. A prompt or YAML file can represent part of it, but enforcement requires real controls: repository permissions, sandbox restrictions, protected verification, and an admission policy. Writing a contract without implementing its boundary does not provide governed autonomy.

Shared engineering state connects the current intent, architecture decisions, execution scope, artifact revisions, verification results, and rollout records through explicit version references. It need not be one database or vendor platform. The essential property is traceability: reviewers and admission controls can determine which intent and permissions apply to a particular artifact and whether its evidence is current.

Create a new contract version and assess which active executions, tests, and admission decisions it affects. Pause or re-scope work when assumptions or permission boundaries are no longer valid. Re-run the affected independent checks before admitting a new artifact. Evidence for an earlier intent or artifact must not silently authorize a different one.

Verification is independent when the code generator cannot unilaterally alter the acceptance requirements, weaken the protected checks, forge the resulting evidence, or approve its own release. Independence depends on ownership and access controls, not just a different prompt or agent name. Separate people or services can fulfill the responsibilities if their authority and enforcement remain distinct.

Yes. Generated unit tests and automated reviewers can help find defects. For admission evidence, however, the verifier must operate under independently owned requirements and protected controls. Two agents sharing writable tests, credentials, or release authority do not automatically provide independence. Human verification owners remain accountable for coverage, blind spots, and exceptions.

A production admission authority outside the code-generation path evaluates the required evidence under human-accountable policy. That authority may be implemented as automated policy checks, designated approvers, or both, depending on risk. The generator cannot grant itself release permission. Progressive rollout, monitored stop conditions, and rollback controls continue after admission.

Begin with one customer problem and one or two bounded services. In days 1–30, establish a baseline and write the Intent Contract. In days 31–60, implement execution isolation, scopes, and budgets. In days 61–90, enforce independently owned evidence and review customer outcomes. Treat the 90-day roadmap as an experiment with explicit stop, refine, and expand decisions, not a guaranteed transformation schedule.

Choose a service with a clear owner, observable customer friction, testable behavior, a limited blast radius, and a practical rollback path. Ensure verification owners can define independent evidence before autonomous execution begins. Avoid making the first experiment a large cross-system rewrite; it obscures whether the contracts improved coordination and makes failures harder to contain.

Product owns customer evidence and outcome intent. Engineers define architecture and execution boundaries and oversee coding agents. Verification specialists own independent requirements and proof. Technical leaders maintain invariants and durable decisions; engineering leadership designs the operating environment and admission policy. These are responsibilities, not a requirement to hire a new person for every contract.

Compare a measured baseline with customer value, intent-to-production lead time, coordination overhead, engineering health, and priority and decision stability. Track waiting and rework as well as active implementation time. Evaluate safety and total cost alongside speed. Token consumption, lines of code, pull-request counts, and perceived productivity do not establish that customers received better outcomes.

There is no universal adoption price or required product license in the model. Relevant costs include staff time to define contracts, isolation and access controls, verification infrastructure, agent compute, integration work, and operational review. Measure total cost per verified outcome in the pilot. If coordination overhead grows without a corresponding benefit, refine the approach or stop.

Postpone autonomous execution when you cannot define the customer problem, constrain permissions, independently verify outcomes, or contain a failed change. If your current workflow already provides these properties with little coordination cost, a broad reorganization may add little value. First address the actual constraint, then test the smallest useful change.

No comparative evidence presented on this site establishes that Concerted Engineering outperforms Agile, Waterfall, or another method. It is a proposed operating model with an open research agenda. DORA, METR, and other cited work motivate questions about delivery and AI adoption; they are not evaluations of this framework. Pilots should report failures and boundary conditions alongside improvements.

No. The replica-rebalancing walkthrough is a synthetic example showing how the six phases and three contracts could connect. Its 42% p99 latency reduction is illustrative, not a measured deployment result or a promised benefit. Use real service baselines, independently gathered evidence, and customer outcomes to evaluate your own pilot.

The model can organize traceability and separation of duties, but it does not establish regulatory compliance or replace required approval processes. An organization must map its actual obligations to implemented controls, evidence retention, access policies, and accountable reviewers. Keep mandatory approvals in the pilot and assess whether the contracts make those controls easier to inspect.

Risks include stale contracts, weak customer evidence, excessive permissions, shared failure modes between agents, inadequate verification, policy bypasses, and the cost of maintaining the coordination system. A contract does not eliminate uncertainty. Limit execution scope, protect admission controls, monitor production behavior, and stop expansion if safety, engineering health, or customer value deteriorates.