Moving an energy software unit to an agentic SDLC.

Faster code, same manual lifecycle.

Energy software teams maintain complex integrations between renewable assets, data platforms and enterprise systems. When something breaks, engineers spend hours reading logs, fixing code, testing the change and coordinating a release.

AI coding assistants help them write code faster. The rest of the lifecycle stays largely manual: requirements, review, testing, release and the follow-up after an incident. The queue moves from writing code to everything around it.

One continuous, AI-supported workflow.

We implement an agentic SDLC that connects planning, development, testing, deployment and maintenance. AI agents investigate issues, prepare changes, write code, run tests and perform reviews. Automated controls enforce engineering standards, while people approve the critical decisions and every production release.

• Every stage commits an artifact that the next stage reads, so the commit history is also the audit trail.
• Agents work inside guardrails: protected paths, secret scanning, policy checks in the pipeline.
• People accept intent, accept the plan and approve the release. Agents never decide those.

A solar plant stops sending production data.

An API change on the plant vendor’s side breaks the integration, and production data stops flowing into the data platform. Here is how the same incident plays out in each model.

1. TraditionalAgentic
2. DetectTraditionalSomeone notices missing data, often late, from a dashboard or a downstream report.AgenticMonitoring detects the gap and opens an incident, drafted as an intent for a person to accept.
3. DiagnoseTraditionalAn engineer reads logs and compares API versions by hand to find the change.AgenticAn agent reads the logs and the vendor’s change notes, identifies the API change and attaches the evidence.
4. FixTraditionalThe engineer updates the integration from their own knowledge of the codebase.AgenticAgainst an accepted plan and the shared project context, the agent writes the change on a branch.
5. TestTraditionalManual tests, sometimes against live data.AgenticTests run as the work happens, including a replay of the failed payloads and a new contract test for the API.
6. ReleaseTraditionalA change request, a manual review and a manual deployment.AgenticAgentic review checks the diff against the plan. A person approves the release, and the pipeline enforces policy checks.
7. LearnTraditionalThe fix lives in a ticket and in someone’s memory.AgenticThe incident, the fix and the new test are committed, and the skill for this integration is updated.

Artifacts and guardrails, not just tools.

• A shared project context file per repository, and a library of reusable skills for security, architecture and testing standards.
• Hooks that block edits to protected paths, stop secrets leaving the repository and keep the plan in step with the code.
• Azure DevOps or GitHub integration for pull-request review, required approvals and pipeline policy checks.
• Monitoring wired to the loop, so an alert opens an incident that becomes the next intent.
• An evaluation suite for the agents’ own skills, plus enablement for engineers and product owners.

Four phases, starting small.

1. wk 08152330+
2. 01AssessAbout 4 weeksDelivered: an SDLC maturity assessment across the engineering teams, the tier classification and a baseline for cycle time and rework.
3. 02PilotAbout 10 weeksDelivered: two teams, one Tier A and one Tier B, working in the new loop with the guardrails live.
4. 03ExtendPer waveDelivered: the configuration, skills and pipeline policies rolled out wave by wave, informed by the pilot data.
5. 04OwnOngoingDelivered: a platform team that maintains skills and evaluations, and a quarterly review of the tier model.

Durations are indicative. Tier C code was kept out of the pilots.

Cycle, rework and risk, against the baseline.

• Elapsed time from the first intent to production, read from version-control history.
• Rework: specification changes made after the plan is committed.
• Pull-request review turnaround and the share of changes merged from the first implementation pass.
• Change failure rate and escaped defects, so speed is never bought with quality.

The measures were agreed in the Assess phase and are reported against the baseline. We do not promise performance gains up front.