Reconstruct the enterprise SDLC

Before you can sell Cursor into an enterprise, you have to draw their delivery system from memory. The real one, not the one in the wiki.

The org chart and the Confluence page describe an aspiration. The actual SDLC is a living machine made of queues, handoffs, fear and a return loop nobody documents. Day 1 is about reconstructing that machine.

Every enterprise hands you a tidy story. "We're agile, two-week sprints, we ship to prod twice a week." That's a methodology talking and it tells you nothing about how a change actually moves from someone's head into a customer's hands:

• Where it waits.
• Who signs off.
• What evidence gets generated.
• What happens when it breaks at 2am.

The gap between the stated process and the operational reality is where low-risk, high-trust Cursor wins live.

This is what separates a real field engineer from a feature-lister in an interview. A weak candidate pitches into a vacuum. A strong one says: show me your value streamThe end-to-end path a change takes from idea to running in production. and I'll show you where the AI removes toil without touching your risk posture. That line only lands if you can reconstruct the value stream faster than the customer can.

Picture the lifecycle as a circuit, not a pipeline. Work flows forward from idea to running software. A second current flows backward from production reality into the next change. Most vendors only see the forward arrow. You need both, because the return loop is where the operational pain sits and where the cheapest wins live.

The forward streamidea → production

Forward flow moves an idea through plan, design, build, test, release and into operate. Each stage has an owner, a primary system of record and an artifact it emits. Each stage is also a queue: work piles up waiting for design review, for a free QA environment, for a change-advisory-board slot. The methodology sets the cadence of the stream. It says nothing about what happens inside any stage.

The return loopincident → postmortem → corrective change

When something breaks in Operate, it generates an incident, which generates a postmortem, which generates corrective changes:

• Config hardening.
• A missing test.
• A runbook fix.
• Alert tuning.
• A dependency bump.

Those changes re-enter the forward stream at Build. This loop is a goldmine. The work is well-scoped, low-risk, usually dreaded and it produces audit-friendly evidence as a side effect. For an AI coding agent in a cautious org, it's the perfect first habitat.

Scrum, Kanban and SAFeScaled Agile Framework. A framework for coordinating many agile teams at enterprise scale, common in regulated orgs. are coordination layers.

They tell a team when to talk, how work flows and who aligns with whom. They stay deliberately silent on how you design a system, test it, release it and operate it. Confusing the two is the most common rookie mistake in enterprise discovery.

A team can be flawless at Scrum and still have a brittle, manual, fear-driven path from a merged PR to production. The methodology made the meetings efficient and never touched the machine. Cursor lives in the machine, in Design, Build, Test, Release and Operate, which is exactly the territory every methodology leaves undefined.

One mental model separates a field engineer from a demo jockey: every stage of the lifecycle emits an artifact into a system of record and every artifact is context the AI either has or doesn't. The lifecycle is a graph of artifacts strung across a fleet of disconnected enterprise systems. The AI's effectiveness is bounded by how much of that graph it can see.

The disconnect is the whole point

Each system holds a slice of the truth and none of them talk to each other natively. The Jira ticket doesn't know about the Datadog alert. The PR doesn't know about the ADRArchitecture Decision Record. A short doc capturing one architecture decision and the reasoning behind it. that justified it. A human engineer reconstructs this graph in their head every single day, which is the cognitive tax of working in a large org. An AI agent that only sees the code in the editor is flying with one slice of a six-slice context graph.

How an MCP server actually connectsthe mechanism, not the hand-wave

MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. (Model Context Protocol) is a standard for letting an agent talk to a third-party system in that system's own language. The provider exposes an MCP server; you authenticate it once; the agent can then take actions on your behalf within the scope that auth grants. It's the connective-tissue layer that keeps the engineer inside Cursor instead of swapping between Jira, GitHub and Datadog tabs all day, losing flow state and burning mental bandwidth across many sources of truth. The thing being bridged isn't more code - it's the artifact graph.

A lifecycle is run by people.

Every persona owns a stage, guards a fear and responds to a different headline. Pitch the same Cursor message to an IC dev and a release manager and you lose one of them. Memorize this map. The fear column is where deals are won or lost.

Read the room by fear, not by title

Titles vary across orgs; fears don't. The security lead might be an 'AppSec Principal' or a 'CISOChief Information Security Officer. The executive who owns security; usually the hardest and most important person to win over.'s deputy,' but the fear is always ungoverned AI touching sensitive code and data. For that persona you lead with the security spine: SOC 2 Type II, AES-256 at rest, TLS 1.2+ in transit, Privacy ModeCursor's setting that routes requests under zero-data-retention terms so providers don't store or train on your code. with zero-data-retention terms, SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. via SAMLAn enterprise standard that powers single sign-on./OIDCOpenID Connect. A modern standard that powers single sign-on, built on OAuth., SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave., RBACRole-Based Access Control. Granting permissions by role rather than configuring each person individually., model/MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs./repo allowlists, terminal sandboxing and audit logs with AI-code tracking. Open with throughput to that person and the room is already gone.

Under every persona's fear is the same unspoken one: 'is this about layoffs?'

The eng manager's date-slip fear, the IC's blame fear, the architect's drift fear - all of them sit on top of a deeper question nobody asks out loud in the room. Does adopting this make my team smaller? You answer it before it's asked, the same way Cursor frames its own adoption: this is more value with the same people, not fewer developers. It's not a headcount-reduction conversation; it's shipping more and moving faster with the team you have. That single reframe disarms the most charged objection in any rollout.

The most powerful move in a discovery call is to narrate a feature's journey through their lifecycle, name the systems and the queues, then point at exactly where Cursor removes friction.

Here's the canonical version. Adapt the system names to the account and keep the structure.

1. 1Plan. A product manager files a ticket in Jira with acceptance criteria. It sits in the backlog until a sprint pulls it. (Queue #1.)
2. 2Design. For anything non-trivial, an architect writes or updates an ADRArchitecture Decision Record. A short doc capturing one architecture decision and the reasoning behind it. in Confluence. The decision is now an artifact, a context source the agent should read via MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs..
3. 3Build. An IC dev opens the ticket in Cursor. With Jira, GitHub and Confluence bridged, the agent has the ticket, the code and the ADRArchitecture Decision Record. A short doc capturing one architecture decision and the reasoning behind it. in context. It drafts the change. The dev keeps judgment and shapes the PR.
4. 4Test / CI. The PR triggers Jenkins; tests run, artifacts land in Artifactory. BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. reviews the PR in parallel so a human reviewer starts with focused findings rather than a cold diff. (Queue #2: human review.)
5. 5Release. A change record is filed in ServiceNow; the CABChange Advisory Board. A group that reviews and signs off on higher-risk production changes before they ship. approves; the change ships through the golden path. Separation of duties holds, because the author isn't the approver.
6. 6Operate. Datadog watches it in production. If it pages, an incident opens in PagerDuty. (Forward stream ends; return loop begins.)
7. 7Return loop. The postmortem produces corrective actions: a missing test, a config hardening, a runbook fix. Those re-enter at Build as low-blast-radius work, ideal for an agent and the whole chain is linked as evidence.