Flags in the platform roadmap

In this article, we shall cover the flags we shall be delivering to our customers and our prospective customers in the near future. 

Baseline:

The baseline for the flags mentioned below is going to be the Cubyts Code Graph (with contextual explanation of the code), the intent of the code graph is as follows:

1. The code graph will aim to represent calling relationship between functions/methods in a program (in a repo or across multiple repos).
2. In addition, the code graph will represent dependencies between various components or modules which will enable the platform to understand the flow of control within/across a program.

The code graph with the associated explanation will enable Cubyts to accomplish the following baseline tasks:

1. Accurate code analysis and review: With the availability of the structure of the codebase (with associated complexities), the platform can performance much better PR analysis or Feature branch analysis to discover potential issues and areas of improvements.
2. Refactoring of codebase: Relationships and complex dependencies can assist engineering organizations to perform error free refactoring of codebase (given an intent).
3. Debugging and support RCAs: Code graphs make it easier to trace bugs in the code based on interactions between different parts of the system.
4. Documentation: Code graphs can serve as a valuable baseline to document code structures, code flows for a specific feature or a task executed by the development team.

Future flags based on the baseline:

The baseline (outlined earlier) augmented by Gen AI frameworks in the Cubyts platform can be used to showcase the following flags to the development teams during build (for proactive resolution) and after build (for corrections in the future):

1. Flag the impact of changes in a pull request or feature branch on other features that depend on code base in the files effected by the PR/feature branch.
2. Flag the impact of changes in a pull request or feature branch on files (in the same repository or dependent repositories) not touched by the PR/feature branch.
   
3. Flag the impact of changes in a pull request or feature branch on files (in the same repository or dependent repositories) that depend on the changes in the current PR/feature branch.
4. Flag the drift between the code changes in a PR/feature branch vis-a-vis the functional specification provided as an input for the changes.
5. Flag the drift between the code changes in a PR/feature branch vis-a-vis the technical design provided as an input for the changes.
6. Flag the drift between the code changes in a PR/feature branch vis-a-vis the support documents delivered to the customer.
7. Flag the PRs that were merged with a master branch which may have resulted in a customer escalation.