Infrastructure for the Energy Transition

Nextpower (formerly NEXTracker) makes the hardware and software that controls utility-scale solar farms: the systems that physically rotate panels to track the sun across thousands of acres. When those systems go down, energy output drops. When they go down during a storm, the damage can run into the millions.

I joined as an intern in May 2024. By February 2025 I was a full-time engineer. The work spans reliability engineering, API performance, and the kind of infrastructure decisions that matter more than they look.

As an intern, I built a CI pipeline using Azure DevOps that automated builds across multiple projects, cutting developer workload by 10 hours a week. I also led static and composition analysis across our dependencies, reducing high and medium security vulnerabilities by 92%. The interesting part wasn't the tooling. It was understanding why those vulnerabilities existed and designing checks that would catch them structurally, not just reactively.

The most consequential thing I've built here is an active–standby site controller system in Go. Solar plants can lose their primary controller during storms. The failover needs to be seamless: no manual intervention, no data loss, no gap in control. Getting that right required thinking carefully about state replication, split-brain scenarios, and what "seamless" actually means in a system where the hardware doesn't stop moving.

I also optimized API performance using OpenTelemetry and Azure Monitor Application Insights, reducing average response time from 1100ms to 385ms, a 65% improvement. The gains came from understanding where the actual latency was hiding, not from blanket caching.

A third project: enabling hardware reuse across deployments. Solar operators move equipment between sites. Previously that meant manual decommissioning workflows. I built a feature that lets users disconnect a Datahub from one site and reconnect it to another, saving thousands of dollars per reuse and a meaningful amount of operational friction.

The codebase at Nextpower spans frontend, backend, and infrastructure that have been talking to each other for years without anyone writing down how. The result is institutional knowledge that lives in the heads of people who have been here the longest. When those people are unavailable, the knowledge is unavailable.

knowledgeTree is an attempt to fix that structurally. Built on Andrej Karpathy's LLM framework with additions for our specific systems, it knows how to do a few things: capture knowledge from code, lint it for accuracy, and sync it when the code changes. The output is a wiki that describes our products end to end. How the pieces connect, not just what they each do.

The hard problem is not building it. The hard problem is keeping it useful.

**Context size.** As the tree grows, the context passed to the model during generation grows with it. Past a certain point the signal gets diluted by everything that is technically relevant but not actually useful for the current query. The resolution is hierarchical: the tree stores relationships at multiple levels of granularity, and generation only loads the subgraph relevant to the question being asked.

**Staleness.** Code moves faster than documentation. A wiki entry accurate in March can be actively wrong by May. The sync skill ties each node to the git hash of the code it was derived from. When the source changes, the node is flagged. The wiki is either current or it tells you it is not.

**Confabulated relationships.** The interesting knowledge is not what each service does in isolation. It is how they connect. LLMs, given enough latitude, will infer plausible connections that do not actually exist. The lint skill requires every relationship edge to be grounded in an observable artifact: an API call, a shared data model, a message topic. If the grounding does not exist in the code, the edge does not exist in the tree.

Working on physical infrastructure sharpens your thinking about reliability in a way that pure software problems don't. The failures here have real-world consequences measured in energy and dollars. You can't roll back a storm.

I've also learned that performance work is mostly detective work. The 65% API improvement wasn't from clever code. It came from finding the three places where we were doing work twice and stopping.