Cubyts AI platform powers your SDLC with state of the art AI technology with clear focus on predictable and high quality of outcomes delivered by SDLC teams.
The core architecture of Cubyts AI platform is driven by four key layers, which serve as the nerve center of the entire platform:
Integration layer:
The integration layer acts as the data pipeline for the Cubyts AI platform; this layer governs the integration with the Systems of records in an enterprise landscape, extracts data from the systems of records using APIs and pushes the data to the data lake. The key characteristics of this layer are as follows:
1.1 Technology: The data extraction is done either using PAT (Personal access tokens) or oAuth integration depending on the type of the tool and the nature/intent of the integration.
1.2 Integration with project management tools: Cubyts AI supports integration with Jira (Cloud and Data centre) and ADO to extract the planning data e.g. information in the product backlog, planning boards, sprint information (present and future), etc. This provides Cubyts AI the necessary context to understand the plan behind any job.
1.3 Integration with definition tools: Cubyts AI supports integration with Figma, Google Drive, One Drive and Confluence to extract the nature of the job e.g. functional specification, technical specification, UI/UX designs etc. This provides Cubyts AI the necessary context to understand the intent behind any job.
1.4 Integration with code repositories: Cubyts AI supports integration with Github (Free/Team/Enterprise), Gitlab (Self hosted/Cloud), and Bitbucket (Cloud/Data centre) to extract the code built for the intent. This provides Cubyts AI the necessary context to understand the reasons behind the existence of a codebase.
1.5 Integration with CI/CD tools: Cubyts AI supports integration with Jenkins to extract the journey of code from developer’s machine to various environments (lower/higher) based on the configured jobs.
1.6 Integration with support tools: Cubyts AI supports integration with Jira, Freshdesk and Jira Service Management to extract customer feedback. This provides Cubyts AI the necessary context to understand the voice of the customer and trace it back to the codebase and intent.
Data lake layer:
The platform builds a massive data lake by extracting multiple raw data points from the aforementioned tools. This acts as a baseline input for the other layers of the platform.
Knowledge graph layer:
The data points in data lake are converted to a semantic knowledge consisting of inferred data points and code from the aforementioned tools. This establishes the relationship (and the relationship strength) between artefacts (e.g. Work items from Jira, Design sections from Figma, Code branch/PR from Github, CI/CD job from Jenkins, Support tickets from JSM, etc.). The knowledge graph has two distinct parts (that are connected via edges):
3.1 The data graph: The data graph connects the critical data items (and associated data points) from project management, support, CI/CD and requirement tools. This enables deeper context understanding when the graph traversal is done to unearth inferences.
3.2 The AST code graph: The code part of the graph is an Abstract Syntax Tree representation of the codebase (behaves like a compiler) optimized for .NET, JAVA, JavaScript, Golang and Ruby; this makes the RAG factories and LLMs behave and think like a compiler.
RAG Factories:
The RAG factories (based on the expected tasks) leverages the knowledge graph as the semantic context layer with state of the art prompt layer for the various solutions that are possible using the Cubyts platform. A few examples of RAG factories are outlined below:
4.1 RAG factory for specification quality: This factory focuses on ascertaining the quality of input requirements/user stories based on the specified benchmarks.
4.2 RAG factory for build quality: This factory focuses on ascertaining the quality of build plan based on the specified benchmarks.
4.3 RAG factory for specification - code drift: This factory focusses on determination of relevant specification for a code base in branch/PR and then determines the drift between the code base and the specification.
4.4 RAG factory for code dependency: This factory focuses on discovering the dependency mishaps introduced by a developer in a PR/Branch which may affect dependent codebases in other PRs.
4.5 RAG factory for code quality based on standards: This factory focuses on evaluating every commit and discovering the issues in the code based on the specified enterprise standards.
4.6 RAG factory for code explanation: This factory focuses on building the semantic meaning of a codebase based on the ASTs, the outcome of the factory is used by other factories to draw their inferences.
Adoption of this architecture - Drift Guard
The Drift guard solution uses this architecture to deliver the following assistants:
Flags is the drift assistant for the scrum team; flags discover 4 types of drifts in the system:
1.1 Process drift: Deviation from established processes causing missed deadlines, wasted effort, Reduced team efficiency, etc.
1.2 Technology drift: Technology and code quality drifts resulting in increased debugging time, delayed delivery, and higher unknown technical debt, etc.
1.3 Compliance drift: Missed adherence to info sec, regulatory standards resulting in audit risks, etc.
1.4 Feature drift: Deviation from PRDs, User stories, Feedback resulting in unplanned work, delayed launches & unrealized customer expectations.
Reports is the data assistant for Scrum teams, offers the following assistance to the scrum team:
2.1 Automatic trace of the journey of code from inception to adoption with several augmented data points for analyzing the impediments in the journey.
2.2 Automatic mashup of critical data points (and it's relationship with flags) from an artifact or team member standpoint; useful for analyzing contributions, risks, workload, productivity, efficiency of execution and members (who are executing the outcomes).
2.3 Automatic visibility into the artifacts that deviates from the established compliance standards (configured in flags).
Repository is the knowledge assistant for Scrum teams, offers the following assistance to the scrum team:
3.1 Aggregates all the documents linked in the various systems of records.
3.2 Provides context to all the documents (e.g. all the document references in a story or a task).
3.3 Discovers all the related documents in the same context.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article