This essay is an opinionated map of where AI actually earns its keep inside a software development lifecycle, where it merely accelerates work that wasn’t the bottleneck, and where it silently accrues debt your future self will pay with interest.

The temptation to rewrite everything

The temptation is always to treat a capable new technology as a reason to remove existing structure. The first time I saw a team propose deleting their code-review process because “the LLM catches most of this now,” I had to ask what they thought the code-review process was for. Catching bugs was on the list. It wasn’t the only item.

Code review is also where taste gets transmitted, where context gets shared, where an engineer who joined three months ago learns what this codebase considers acceptable. Delete review and you don’t just lose a bug net — you lose the mechanism by which a team stays coherent. The AI is not, yet, a substitute for that. Used well, it’s an amplifier.

The SDLC is not a conveyor belt. It’s the mechanism by which a group of people stay a team. Anything that shortens a step while weakening the team has moved cost, not removed it.

Hold that sentence in mind through the rest of this piece. It’s the difference between an AI-native SDLC and an AI-accelerated one.

What the SDLC is actually for

Before deciding where AI belongs, it helps to enumerate what a good SDLC does. I’d argue five things:

• It converts intent (a product idea, a defect report, a compliance ask) into a durable change.
• It distributes risk — across reviewers, testers, staged rollouts — so no single human is the failure point.
• It preserves institutional memory — who decided what, when, and why.
• It produces a compounding improvement in the people who run it.
• It produces an auditable, reproducible trail for regulators and for your future self.

Every AI intervention should be evaluated against these five, not just the first. An AI tool that halves PR cycle time but kills the learning loop is a trade, not a win. State the trade and you can make the decision. Hide the trade and you can only discover it later.

Where AI compounds vs. where it merely accelerates

I break AI’s impact on the SDLC into three zones. This taxonomy has held up across several client engagements.

1. Compounding leverage

AI compounds leverage when the output gets better the more you use it, and when the human reviewing it becomes sharper, not lazier.

• Test generation guided by specification. A well-structured prompt over an API contract or an acceptance criterion generates test cases the human would have written — sometimes better, sometimes worse, often faster. The review of those tests teaches the engineer the shape of the spec. This compounds.
• Commit message and PR summary drafting. When the model generates a first draft from the diff, and the engineer edits it to reflect intent, the team reads clearer history. The history becomes searchable, auditable, and a better input to the next round of work.
• Knowledge retrieval over your codebase and docs. The model becomes the on-call colleague who read every runbook. Reviewed answers get cited; cited answers build the habit of writing runbooks that can be cited. This compounds too.

2. Linear acceleration

Linear acceleration means faster, but not better, and not structurally changed. Useful. Not transformative.

• Boilerplate scaffolding. CRUD, DTOs, wiring. Faster. The second-order effects are neutral.
• Refactor-in-place edits. Rename, reorganise, tidy. Saves minutes. Doesn’t change the shape of the work.
• Documentation of existing code. Helpful, but don’t confuse this with designing documentation.

Linear wins are still wins. Just don’t put them in the “transformative” column when you report to the board. They’re the easy part.

3. Silent debt

The third zone is where careers go to die. AI interventions that appear to work but introduce debt the team will only notice six months later.

• Silent generation of tests that pass but don’t test anything meaningful. Classic tell: every PR adds three tests, and production incidents stay at the same rate. The tests are asserting behaviour that can’t regress because nothing depends on it.
• Review comments that are plausible but unanchored in the codebase’s actual conventions. The model hasn’t read your style guide, but it has read the internet. Watch for drift.
• Auto-generated infrastructure that’s correct in isolation but wrong in context. Terraform, k8s manifests, policy files. “It deployed” is a low bar.

The only defence against silent debt is eval — specifically, evals that catch absence of change, not just presence of regression. We’ll come back to that.

The three evaluation shapes that matter

If you remember nothing else from this piece, remember this: you cannot roll out AI in the SDLC safely without three evaluation shapes running continuously.

Shape 1: Correctness evals

Does the output meet the spec? These are the ones everyone builds. They’re necessary, they’re not sufficient. Build them anyway.

Shape 2: Delta evals

Is the output improving or degrading over time — across model upgrades, prompt changes, context changes? A correctness eval tells you the test passed today. A delta eval tells you the test used to catch a bug and now doesn’t. This is the one most teams skip.

Shape 3: Process evals

Is the team better at their job because of the tool, or merely faster? This is harder to measure, but it’s the one that actually corresponds to compounding leverage. Proxies I’ve used: are junior engineers’ PRs improving on their own axes? Are code-review comments getting fewer and sharper, or fewer and blander? Is the team writing better issues and ADRs, or is the tool doing it for them in a way that nobody reads?

If you only have correctness evals, you’ll ship a system that passes tests and silently makes the team worse. I’ve seen it. It looks great on the quarterly review.

Rollout, reversibility, and the audit trail

Two rollout rules I stand by:

Rule one: every AI intervention in the SDLC must be reversible in a single config change. You will need to turn something off for a specific repo, a specific team, a specific customer class, under a specific auditor’s eye. If turning it off requires a migration, you’ve built a dependency, not an intervention.

Rule two: every AI-authored artefact must be traceable. Commit messages, test code, doc changes, review comments — if an AI wrote it or materially shaped it, that fact lives in the metadata. This is not for punishment. It’s for the day an auditor asks how much of this compliance document was human-authored? and you need an answer better than “we’re not sure.”

The audit trail also enables delta evals. You can only know whether AI-authored tests regressed in quality if you can distinguish them from human-authored ones.

What I’d do on day one

If I were walking into a 200-engineer org tomorrow with a mandate to embed AI in the SDLC, here’s the ninety-day shape:

1. Week 1: Name the five outcomes the SDLC is currently producing and rank them by business criticality. This is the baseline that every intervention must not regress.
2. Weeks 2–3: Pick one compounding intervention from Zone 1 above and one linear one from Zone 2. Instrument them for all three eval shapes. Pick nothing from Zone 3.
3. Weeks 4–6: Roll out to one team that has appetite and psychological safety to report honestly. Resist the urge to generalise.
4. Weeks 7–10: Read the process-eval output. Adjust. If the team is worse at their job, pause. If neutral, continue. If better, widen.
5. Weeks 11–13: Roll to a second team with different shape. Look for the interventions that portable and the ones that were actually team-specific.

Nothing in this plan is glamorous. All of it is what differentiates an AI-native SDLC from a deck that uses the words “AI-native SDLC.”

If you’re designing this for your own org and want a sounding-board, I’m always up for a conversation — drop a note via the contact form, or subscribe for more notes like this one.

This is a practical essay, not a philosophical one. I want to leave you with a small set of rules, a worked example, and enough vocabulary that the next time your security team asks “what’s the blast radius of this agent?” you have something concrete to point at.

What a tool actually is

A tool, in the agentic sense, is a named function the model can invoke. That framing is so simple it’s almost unhelpful. Let me offer a more useful one:

A tool is a commitment you make to your future self that the model can read. Everything inside the tool is under your control; everything outside is under the model’s.

The power of that framing is that it forces you to treat the tool boundary as the security perimeter, the audit perimeter, and the contract perimeter — all at once. Cross that boundary and the model is in charge. So think hard about what you let cross.

One verb, one effect

The first rule: a tool should do one thing. Not “manage orders.” One thing. The fastest way to wreck a tool layer is to bundle related effects behind a generic verb.

1
2
3
4
5
6
7
8
9
10

// Don't do this — "process" can do anything, and the model knows it.
tool({ name: "process_order_request", ... })

// Do this — bounded, named, costed.
tool({
  name: "issue_refund",
  cost: "writes:billing",
  idempotencyKey: "required",
  schema: { orderId, amountCents, reasonCode }
})

The reason isn’t aesthetic. Each verb the agent sees is a decision the model must make. Ambiguous verbs invite ambiguous plans. If process_order_request can refund or cancel or re-queue, you’ve outsourced your business logic to a probabilistic reasoner, and you will discover this the first time a support ticket comes in asking why a customer got refunded and cancelled.

One verb, one effect. If you feel tempted to reuse a tool for “similar” operations, don’t. Write a new one.

Idempotency is not optional

The second rule: every side-effecting tool must be idempotent. Not aspirationally. Not “usually.” Enforced at the schema level with a required idempotency key.

Agents retry. Orchestrators retry. Multi-agent loops retry. Your network occasionally retries for you without asking. The first time your agent fires issue_refund twice in the same second because a downstream call timed out and the retry fired before the first completed, you will care very much about whether your tool deduplicated on key.

The world is eventually consistent whether you want it to be or not. Build for it.

A useful pattern: the tool’s request schema includes a client-supplied idempotency key. Your tool stores the key with the result for some TTL. A repeated call with the same key returns the cached result. The model doesn’t need to know this — it just gets the same answer twice, which is exactly what you want.

Cost and effect in the schema

The third rule: make cost and effect visible in the tool’s name and schema. The agent’s plan is only as cautious as the inputs you give it.

A tool called send_email is less cautious than send_email_to_customer, which is less cautious than send_email_to_customer_writes_crm_log. Verbose names feel awkward until the day you read a model’s chain-of-thought and watch it reason differently because the name reminded it that a side effect was coming.

In the schema, I like to include:

• cost — a compact string describing the resource the tool consumes (writes:billing, reads:catalog, external:api, human-time)
• reversible — a boolean or enum. true, false, or compensating. The model can reason over this.
• requires_confirmation — an enum for tools that should never fire without an explicit “yes” from a planning layer or a human.
• idempotencyKey — required, recommended, ignored.

Agents given rich metadata make surprisingly careful plans. Agents given {name, args} make the plans you’d expect from something reading a flat menu.

The security team’s new front door

Every tool is a new front door for your security team. Not metaphorically — literally. Every tool that can be invoked by a model that can be influenced by untrusted input is exposed to prompt injection, which means every tool must be designed as if it will eventually be triggered by an unfriendly instruction smuggled through an email, a PDF, a customer support ticket, or a scraped webpage.

If you take one thing from this essay, take this: treat the tool layer the way you’d treat a public HTTP endpoint.

That means:

• Auth scopes per tool, not per agent. issue_refund requires billing:write; read_customer_profile requires customer:read. The agent passes scoped credentials, not a superuser token.
• Rate limits per tool, per agent, per customer. Prompt injection at scale is no different from any other API abuse.
• Structured logging with a correlation ID from invocation → tool call → downstream effect. You will need this the day an auditor asks “show me every action this agent took for this customer.”
• Deny-by-default. An agent should not have any tool the current task doesn’t explicitly require.

A small worked example

Imagine a back-office agent that resolves Tier-1 billing tickets. Here’s what the tool layer might look like, done well.

Inputs (reads)

• get_ticket(ticket_id) — the customer’s original message, metadata, category
• lookup_customer(ticket_id) — profile, account state, entitlement tier
• get_recent_charges(customer_id, window_days) — scoped to the window relevant to the ticket

Actions (writes)

• issue_refund({ charge_id, amount_cents, reason_code, idempotency_key }) — bounded verb, scoped creds, refund cap enforced server-side
• add_ticket_note({ ticket_id, note, visibility }) — internal notes default
• propose_resolution({ ticket_id, resolution_code, summary, confidence }) — does not close the ticket. Hands off to a human.

Handovers

• escalate_to_human({ ticket_id, reason, context_summary }) — structured fields, not a dump of the chat. Renders on the operator’s screen with everything they need and nothing they don’t.

What’s notable is what’s not here: no close_ticket, no send_email_to_customer, no write_to_crm generic. The human closes the ticket. The human approves the email. The CRM writes are pinned behind specific named tools with reason codes.

The agent could, in principle, do more. The architecture deliberately says: not yet. And because every tool has a name, a cost, a scope, and an idempotency contract, widening the agent’s authority later is a deliberate act, not a drift.

A five-question pre-flight

Before you let an agent touch production, walk the tool layer with this list:

1. Does every side-effecting tool have a required idempotency key?
2. Can I describe the blast radius of this agent in one sentence, using only tool names?
3. If a prompt injection fired every tool the agent has access to, what’s the worst outcome? Is that acceptable to the people who’d sign off?
4. Is there a handover tool that is always a valid choice for “I’m not sure”?
5. Can I turn off any individual tool in production without redeploying the agent?

If any answer is “no,” you don’t have a tool layer — you have a loaded gun pointed at a probabilistic aimer. Fix that first. The model you pick afterwards almost doesn’t matter.

If you’re designing a tool boundary for a real pilot and want a second opinion, the contact form is the quickest way through — happy to trade notes, and subscribing gets you the next essay directly.

1. Efficiency and Performance

Stored procedures can greatly enhance the efficiency and performance of database operations. Unlike direct SQL queries, which need to be parsed and compiled each time they are executed, stored procedures are precompiled. This means the database engine can execute them more quickly, as the compilation step is already done. For applications that require frequent database access, this performance improvement can be significant.

2. Enhanced Security

Security is a critical consideration in database management. Stored procedures can help protect against SQL injection attacks, one of the most common and dangerous vulnerabilities. By using parameterized queries, stored procedures ensure that user input is treated as data rather than executable code. This separation prevents malicious users from injecting harmful SQL into your database.

3. Easier Maintainability

Maintaining and updating SQL queries scattered throughout application code can be a daunting task. Stored procedures centralize SQL logic within the database, making it easier to manage. When changes are necessary, they can be made in one place without the need to hunt through various parts of the application. This centralization simplifies debugging and ensures that updates are applied consistently.

4. Reduced Network Traffic

Executing complex SQL operations directly on the database server can reduce the amount of data transmitted over the network. Direct SQL queries often require multiple round trips between the application and the database, especially for complex transactions. Stored procedures, however, bundle these operations, minimizing network traffic and improving overall application performance.

5. Code Reusability

Stored procedures promote code reusability by allowing the same logic to be used across different parts of an application or even in multiple applications. This not only ensures consistency but also reduces redundancy. Developers can write a procedure once and call it whenever needed, leading to cleaner and more maintainable codebases.

Conclusion

Stored procedures offer numerous advantages over direct SQL queries, including improved performance, enhanced security, easier maintainability, reduced network traffic, and greater code reusability. While direct SQL has its place, leveraging stored procedures can lead to more robust, efficient, and secure database applications. By centralizing SQL logic within the database, stored procedures streamline development and maintenance, making them an essential tool for modern developers.