Commentary

A Small SQL Server Lesson in AI-Assisted Code

A generated draft still needs a contract, a review, and a test

[AI, Software Engineering, Risk]

I once asked an AI assistant for a small T-SQL utility: a procedure that waits for a specified number of hours, minutes, and seconds. The first draft looked plausible. It also calculated a total number of milliseconds that it never used.

That is a minor defect, but it is a useful one. The code was not wrong because an AI wrote it. It was incomplete because the request had not yet become a contract someone could review.

Start With the Constraints

For SQL Server 2022 and current Azure SQL offerings, WAITFOR DELAY can use a local variable, but the requested delay cannot exceed 24 hours. Microsoft also cautions that WAITFOR consumes a worker while it waits and can make a process take longer than an application expects. It is a test or scheduling utility to use deliberately—not a general-purpose production timer. Microsoft’s WAITFOR documentation describes those limits.

That gives this procedure a small contract:

  • 90 seconds is valid and becomes one minute and thirty seconds.
  • Negative values, NULL, and totals beyond 23:59:59 are rejected.
  • The caller must not rely on exact wall-clock timing.
  • The procedure should be called outside a transaction that is holding useful locks.

The Reviewed Draft

This example assumes the util schema already exists.

CREATE OR ALTER PROCEDURE util.sleep
    @hours   int = 0,
    @minutes int = 0,
    @seconds int = 0
AS
BEGIN
    SET NOCOUNT ON;

    IF @hours IS NULL OR @minutes IS NULL OR @seconds IS NULL
       OR @hours < 0 OR @minutes < 0 OR @seconds < 0
    BEGIN
        THROW 50000, 'Duration values must be non-null and non-negative.', 1;
    END;

    DECLARE @total_seconds bigint =
        CAST(@hours AS bigint) * 3600
        + CAST(@minutes AS bigint) * 60
        + @seconds;

    IF @total_seconds > 86399
    BEGIN
        THROW 50001, 'WAITFOR DELAY cannot exceed 23:59:59.', 1;
    END;

    DECLARE @delay char(8) = CONVERT(
        char(8),
        DATEADD(second, CAST(@total_seconds AS int), CAST('00:00:00' AS datetime)),
        108
    );

    WAITFOR DELAY @delay;
END;
GO

The important part is not the procedure’s cleverness. It is the reviewable behavior. The inputs are normalized through total seconds, the limit is explicit, and there is no dead calculation to imply an unimplemented feature.

Production Validation

This procedure has been used in a production environment for many months. That operating history validates the utility for its established use; it does not remove the need to review the contract again if its calling pattern, server load, or intended duration changes.

Test the Contract, Not Just the Happy Path

Run these only in a nonproduction session where a short wait is acceptable:

EXEC util.sleep @seconds = 1;
EXEC util.sleep @seconds = 90;
EXEC util.sleep @minutes = 1, @seconds = 30;

-- Expected: error because the total exceeds 23:59:59.
EXEC util.sleep @hours = 24;

An AI assistant can generate a useful first version and point out a dead variable when asked. It cannot choose the business limit, understand the load on a particular server, or prove that this procedure belongs in a production workflow. Those remain engineering decisions.

The productive version of “vibe coding” is not blind trust or reflexive rejection. It is a fast draft followed by a contract, a review, and a test.