Hill Climbing Apex Code

By Steve Buikhuizen
#apex#salesforce#optimisation#hill-climbing

Many organisations have Salesforce technical debt in Apex code.

Many do not have a clear sense of the location and magnitude of that debt.

Many Apex developers wonder how to let AI coding agents work more autonomously.

Today we are sharing Climber, a tool that helped us solve these problems.

A good analogy is a robotic vacuum cleaner. It maps out your environment and then cleans where you choose.

It provides tools that:

  1. survey your code, score it and render an interactive tree map
  2. group the classes in a way that makes sense for your organisation
  3. autonomously improve the scores for any group
Apex map: a tree map of Apex class groups sized by lines of code and coloured by score, with a tooltip showing per-dimension scores
Figure 1. Apex map. Each group of classes is sized by lines of code and coloured by its overall score.

The map is a good start, but the real power is in the autonomous improvement tool. It implements a process known as hill climbing. Each run of the climbing tool is called an ascent.

AI labs use hill climbing to improve large language models against evaluations. We have repurposed it to improve code using deterministic scoring. This has worked for us on our code, both Salesforce and otherwise.

Ascent report: overall score climbing from 52 to 90 over 14 iterations, with gain, climb angle, kept iterations and cost
Figure 2. Ascent report. The overall score rises from 52 to 90 over 14 iterations, of which 6 were kept. Click the image to see the full report.

You can learn about this right now by asking your agent:

Read the documentation in https://github.com/nextdoc/climber and give me a step-by-step tutorial on how it works. Cover surveying and mapping my Apex code, grouping classes, and running an ascent to improve a group's scores. Explain each step before moving to the next and check that I understand before continuing.

When you are ready, you can test-drive it in a scratch org to see it working without affecting any of your systems.

Once you have confidence, you can point it at your own development environments. Start with read-only tools and move to read-write tools when you are ready.

An ascent is run on a git branch, so your original code is unaffected. Then you pick the improvements you want from a summary produced by the retrospective tool.

We’re looking forward to feedback to decide how much to invest in these tools. Please star the repo if you find it interesting and join the Slack community if you want to discuss more.

Monitoring an ascent is fascinating. We hope you enjoy and learn from it.