The AI-Assisted SDLC
The AI-assisted SDLC applies language models across every phase of delivery, not just code completion: drafting and reconciling requirements, generating implementation code, writing unit and property-based tests, summarizing pull requests for reviewers, and keeping documentation synchronized with the code it describes. The mechanics differ by phase: requirements work is mostly retrieval and summarization over backlogs and transcripts, while test generation benefits from coverage-guided iteration, where the model reruns the suite and targets uncovered branches. Controlled studies show gains that are real but sharply task-dependent: on the order of 20 to 50 percent faster on greenfield, boilerplate-heavy work, near zero or negative on complex legacy code, where even experienced developers over-trust plausible suggestions. The architect's obligation is measurement: instrument DORA metrics, review rework, and defect escape rates before rollout, because an honest baseline is what separates a productivity program from a license expense. Uniform per-seat rollouts without telemetry are how enterprises buy 30 percent and receive 5.
Coding Agents: Claude Code, Cursor & the New Toolchain
Coding agents are LLM-driven loops that read a repository, plan a change, edit files, run the build and tests, and iterate on failures until the task completes or a budget runs out. Terminal-first agents like Claude Code operate through tool calls (file edits, shell execution, code search) against the real project, while IDE-native tools like Cursor blend inline completion with the same agentic loop; both depend on context engineering: repo maps, project instructions in files like CLAUDE.md, and retrieval that fits a large codebase into a finite context window. The real design decision is the supervision model. Pairing, where the developer watches every step, suits risky or unfamiliar code; delegation, where the agent works asynchronously on a branch and a human reviews the pull request, scales better but demands strong test suites and CI gates, because the reviewer becomes the only human in the loop. Choose supervision per task risk, not per team fashion.
Spec-Driven & Agentic Development Patterns
Spec-driven development inverts the usual order: a precise, versioned specification becomes the source of truth, an agent produces the implementation, and an executable test suite verifies conformance. In practice the spec is a structured artifact (acceptance criteria, interface contracts, invariants) that lives in the repository, is reviewed like code, and is fed to the agent as its primary prompt; toolkits such as GitHub's Spec Kit formalize the loop of specify, plan, implement, verify. The consequence is that prompts and specs converge into one artifact, and that is where the leverage sits: a spec good enough to make regeneration cheap turns the implementation semi-disposable, and review effort shifts upstream to a document humans can actually reason about. The failure mode is the underspecified spec, where the agent fills gaps with plausible but unwanted behavior and tests generated from the same document happily confirm the wrong thing; enterprises should review specs with the rigor they once reserved for code.
Vibe Coding vs Production Engineering
Vibe coding, Karpathy's term for accepting generated code on the evidence that it appears to work, is a legitimate mode with a narrow habitat: prototypes, spikes, internal tools, and demos where the cost of being wrong is a rewrite. Production engineering adds the layers vibe coding deliberately skips: human review, test coverage thresholds, dependency and secret scanning, threat modeling, and the maintainability question of whether the next engineer, or the next agent, can change the code safely. The distinction is not the tool but the acceptance bar; the same agent can serve both modes if the pipelines differ. The enterprise risk is boundary drift: a vibe-coded prototype demos well, acquires users, and becomes the production baseline without ever passing the rigor gate, shipping unvetted auth logic or hand-rolled SQL along the way. Make the boundary structural: separate repos or environments for exploration, and a promotion path where crossing into production triggers the full engineering bar.
AI in the Architect's Workflow
AI compresses the writing-heavy half of an architect's job: drafting ADRs, generating diagrams-as-code, structuring option analyses, and building migration plans from codebase evidence instead of tribal memory. Concretely, an agent with repository access can inventory services and dependencies, emit C4 models in Structurizr DSL or Mermaid from the actual call graph, draft an architecture decision record with options, forces, and consequences pre-populated, and score alternatives against stated quality attributes; the architect edits judgment into a document rather than assembling one from scratch. Diagrams-as-code matters twice over here, because text-based models are both generatable by AI and diff-reviewable in the same pull request as the change they describe. The caution is that models are fluent in generic trade-offs and weak on your constraints: the contract renewal date, the team's actual skills, the regulator's opinion. Use AI to widen the option set and document the decision faster, never to make it.
Governing AI-Generated Code
Governing AI-generated code means treating generation as a supply-chain event with provenance, policy, and scanning attached. Provenance first: tag commits or pull request metadata with the tool and model that produced them (commit trailers and bot co-author conventions both work) so you can answer which code an agent wrote, an increasingly common audit and incident-response question. License risk follows: models can reproduce training data near-verbatim, so enable vendor duplication filters and run snippet-matching scanners; provider IP indemnification, typically conditional on those filters being on, shifts the exposure but does not remove it. Review policy should scale with blast radius: agent-authored changes to auth, payments, or infrastructure require senior human review, while low-risk changes ride the standard pipeline, and SAST, secret scanning, and dependency checks apply uniformly because generated code keeps introducing vulnerable patterns at rates comparable to human baselines. The uncomfortable finding is that reviewers tend to approve AI code faster, so calibrate reviewer incentives, not just tooling.