Using AI as a Pair Programmer for SharePoint Solutions

AI can produce a SharePoint script that looks convincing in seconds. The problem is that “looks convincing” is dangerous around Microsoft Graph permissions, internal field names, account identifiers, and production data. The best use of AI is not asking it to build the whole solution blindly. It is using it to expose the cases I might have missed.

The problem: happy-path code passes the demo

function isValidEmployee(array $row): bool
{
    return !empty($row['bannerId'])
        && filter_var($row['email'], FILTER_VALIDATE_EMAIL)
        && $row['active'] === true;
}

That works for the sample row. But what happens when the Banner ID contains spaces, the email address is uppercase, the account is disabled, or Graph returns null instead of false?

The quirk: AI needs the same constraints a developer needs

I give the tool the input contract and ask specifically for edge cases—not production credentials or private data.

$cases = [
    ['bannerId' => '@00123456', 'email' => 'alex@example.edu', 'active' => true],
    ['bannerId' => '  ',        'email' => 'alex@example.edu', 'active' => true],
    ['bannerId' => '@00123457', 'email' => 'not-an-email',     'active' => true],
    ['bannerId' => '@00123458', 'email' => 'LEE@EXAMPLE.EDU',  'active' => false]
];

The workaround: make AI generate the test pressure

I use AI to suggest fixtures, compare PowerShell and PHP approaches, explain unfamiliar Graph query syntax, and challenge error handling. Then I verify the real site path, list ID, permissions, internal field names, paging, and rate limits myself.

The practical skill is not “using AI.” It is knowing which assumptions to hand it, which answers to test, and which security decisions must remain human-owned.