FAQ
Frequently asked questions
How to work with DevSense, what your project needs and which options your organization has for using the platform.
Platform and autonomy
What is DevSense, and what work does it do?
DevSense is an AI Software Factory for building and evolving software. It turns a need into a project specification, directs implementation, reviews changes, manages corrections and runs tests before preparing delivery.
Its supervision technology checks results throughout the process and retains work context. The platform brings together projects, requirements, executions, sandboxes and evidence so the organization can assess each delivery.
How is it different from working with coding agents?
Coding agents can analyze repositories, implement changes, review code and run tests. DevSense integrates these capabilities into an engineering process: it turns business intent into a specification grounded in the current codebase, then directs execution against approved scope and acceptance criteria.
Your team can delegate recurring technical coordination and evaluate the completed software with its test evidence, instead of directing each development attempt.
What does autonomy mean in DevSense?
It means delegating technical execution and its coordination once the work has been defined. DevSense assesses progress and results, determines what needs correction, and reviews and tests changes again. A developer does not have to specify the next step in every session.
Autonomy operates within agreed scope, permissions and criteria. Objectives, project authorizations and the final integration decision remain with the organization.
When does the product owner or developer participate?
The product owner or developer describes the intent and expected outcome. After analysis, they review the specification and authorize the development scope according to project policies. At the end, the team reviews code, evidence or behavior in the sandbox before approving integration.
During execution, DevSense manages technical work and corrections. Intervention is requested for infrastructure, network, billing or external system blockers. Scope and delivery approval remain with your organization.
What kinds of teams and projects is it designed for?
DevSense is designed for organizations that need to develop projects, maintain systems and supervise engineering work over time. It supports product, development and QA teams working with shared requirements, milestones and deliveries. Individual developers can also use it.
For larger teams, the savings opportunity comes from reducing coordination repeated by each developer across executions. Evaluation should consider representative projects, their dependencies and operating conditions.
How do we assess savings and the capacity recovered by the team?
Compare human intervention hours per accepted delivery, validated deliveries per team and period, and total cost per delivery. That cost includes the platform, model usage and team time spent on preparation, review and approval.
Use changes of comparable complexity and also record infrastructure or access blockers. This lets you measure how much operational coordination DevSense handles and where engineering time is recovered, rather than applying a universal savings percentage to every project.
Getting started and projects
What does my team need to prepare before delegating?
The business need and expected outcome, a connected repository and the authorized access the project needs. Describe the objective in natural language or provide documents. Also supply business constraints and decisions that are not reflected in the system.
You do not need to provide a complete technical specification, locate the files to change or write the entire test plan first. DevSense analyzes the code, identifies the gap between the request and existing behavior, proposes scope and defines verification. Your team reviews and approves that specification before development.
DevSense prepares the execution environment from the project. If test credentials, access to a private service or a decision only your organization can make are needed, your team must provide them. The platform does not replace those authorizations or invent business rules.
Can I start a project from an idea or a document?
Yes. You can start with a conversation or documents in Markdown, PDF, Word or plain text. DevSense uses that material to prepare the product definition and propose requirements, milestones and an execution plan.
The project needs a connected repository, which may be empty. The team reviews the proposal and authorizes scope before development; subsequent deliveries remain linked to the project and repository.
Can it work on a system already in production?
Yes. DevSense can work with existing GitHub or GitLab repositories, including self-hosted GitLab. It analyzes the code and project conventions to specify and implement the requested improvement within that system.
Development and testing are prepared outside production. The team receives changes and evidence to decide integration and release according to its delivery process.
Can a short description become a complete specification?
Yes. The description expresses the intent; DevSense relates it to project context and, where code exists, the repository. From that analysis it prepares scope, constraints, acceptance criteria and planned validation for the change.
The specification can be reviewed. If a business rule or expected outcome is not defined in the request or project, it needs clarification when scope is agreed. Initial review confirms that development will address the business need.
Which languages and technologies does it support?
DevSense is not tied to a predefined technology stack. It works with technologies the selected models can analyze, develop and test.
Execution and validation use the project’s dependencies and authorized access. DevSense prepares the environment; infrastructure, network, billing or external system blockers are resolved with the relevant owner.
How is a project with many requirements organized?
Work can be organized into requirements and milestones with dependencies. Each change retains its scope and acceptance criteria, while the project tracks executions, review, tests and deliveries.
This supports system evolution over time and progress review by delivery. Priorities and dependencies are agreed within the project; the platform directs technical execution within that framework.
Execution and continuity
Does my team need to repeat instructions during extended work?
No. The work can continue without your developers having to explain the project again or coordinate each retry. You can consult progress and pending decisions in the platform.
The team can consult status and evidence in the platform. This visibility supports progress review without directing every interaction with coding tools.
How are corrections and retries managed?
Review and QA are checked against the specification and acceptance criteria. When a defect is found, DevSense directs correction work and reviews and validates the change again.
Each iteration’s result remains associated with the work. A retry does not mean an approved delivery: DevSense must check the outcome before preparing the delivery for team review.
When is intervention needed during execution?
DevSense requests intervention for infrastructure, network, billing or external system blockers that require their owner. It investigates software defects and directs corrections within the approved scope without asking your team to manage each attempt.
Intent and business rules are clarified when approving scope. Changes to that scope and final delivery approval remain team decisions; they are separate from technical intervention during execution.
Can several changes be developed in parallel?
The platform supports parallel work and execution organized by milestones and dependencies. Effective capacity depends on the environment, available resources and relationships between project changes.
Changes that depend on an earlier delivery must respect that sequence. Each delivery retains its review and validation, and the organization controls integration into the target branch.
How does DevSense keep corrections aligned with the requirement?
Development, review and QA share the approved acceptance criteria and project rules. Findings are evaluated against that definition of success. A change in technical approach does not authorize lowering the required outcome.
Your team retains authority over changes to scope. Ordinary corrections do not authorize reducing the agreed acceptance criteria.
How many corrections can run, and what happens at the limit?
Correction limits are configurable per repository under the customer’s agreed policy. The applicable limits are established for the deployment.
If approved scope has not been verified when the limit is reached, execution stops and records the reason and remaining work. It is not reported as a validated delivery. Explore execution limits.
Testing, sandboxes and delivery
What is a sandbox, and what is it used for?
A sandbox is a test environment separate from production where the change runs. It supports software behavior checks and, for web applications, lets the team open a test version from the platform before approval.
Access is controlled through DevSense. Product and business stakeholders can review functional behavior while engineering and QA inspect changes and tests associated with that version.
What kinds of tests can DevSense run?
Validation can cover web interfaces in a real browser, APIs, databases and command-line tools. A project can combine several test types according to its interfaces and requirement acceptance criteria.
Checks can cover user flows, service responses, data effects and command results. QA scope is based on what the change must achieve and runs against the reviewed version.
Can it test functionality that requires authentication?
Yes. Projects can configure test identities and methods such as login forms, Bearer tokens, API keys or JWTs. Where required by the criteria, different identities are used to check permissions and access separation between users.
Required access and data must be enabled in the test environment. If an authentication prerequisite is missing, the blocker is recorded; a check that could not run is not reported as passed.
Which quality criteria must each change meet?
Each change must meet the approved requirement and the quality rules agreed for the project. Corrections do not permit lowering those requirements.
Your team receives the result and supporting evidence to assess compliance before approving integration.
What QA evidence does my team receive?
DevSense records what was checked, the observed result and change findings. Available evidence can include requests and responses, screenshots, a web session recording and a test report, depending on the validation type.
The record links the requirement, execution and delivery. The team can consult that evidence to understand how the result was assessed before deciding integration.
What happens if tests find an error?
An implementation defect returns the change to development. DevSense uses the findings to direct a correction and submits the new version for review and validation. The team does not need to manually relay every error between tools to start that cycle.
If an external condition prevents testing, it is recorded as a blocker and the corresponding intervention is requested. Distinguishing a software defect from a blocked test supports an accurate assessment of delivery status.
What happens if code changes after review or testing?
The evidence accompanying a delivery corresponds to the software your team receives. Further changes must meet the agreed acceptance criteria.
What does DevSense deliver, and who approves integration?
Delivery includes code changes prepared in a pull or merge request, together with available review and test evidence. GitHub uses pull requests and GitLab uses merge requests.
An authorized team member decides integration. In addition to reviewing code and evidence, the team can check functional behavior in the sandbox according to the project workflow. Release follows the organization’s authorizations.
Copilot and integrations
What is Copilot used for within DevSense?
Copilot is a conversational interface for consulting and operating the platform. It lets users work with project information and prepare actions without navigating every screen, within their permissions.
Development execution and supervision are DevSense platform functions. Copilot is one access channel, alongside the web interface and API.
Can Copilot change a project without my authorization?
Copilot operations that change something require explicit approval. Before execution, the proposed action, target resource and effect are presented for the user to review.
Authorization applies to that action and has a limited lifetime. This control over Copilot commands is separate from manually directing the stages of development that has already been authorized.
Can I integrate DevSense with other systems through an API?
Yes. Connect authorized systems to submit requirements, request work and retrieve progress, evidence and usage. The API reference and integration guidance are provided during customer onboarding.
Can it work with internal company services and systems?
Integration depends on the DevSense environment being able to reach the required systems with appropriate permissions. Onboarding reviews connectivity, authentication, dependencies and testing conditions.
If a feature requires an internal service, define how it will be validated in the test environment. These requirements help determine the deployment model and evaluation scope.
Security and control
How is team access organized?
DevSense organizes access by organization, users and project resources. Repositories can be shared by group, and each user operates with the permissions assigned to them.
The interface, Copilot and API respect the identity requesting an operation. Access rules and administrative responsibilities are reviewed with the organization during onboarding.
Where are code and work records kept?
Changes are prepared in the organization’s GitHub or GitLab repositories. DevSense retains requirement tracking, execution status, recorded decisions and available review and testing evidence.
DevSense uses Microsoft Azure infrastructure in Chile and Brazil. Enterprise deployments can expand to agreed regions. AI provider processing locations are reviewed separately from the platform’s deployment location. Explore data, infrastructure and code ownership.
How are keys and credentials managed?
AI provider keys are configured in the platform, validated and stored encrypted. DevSense API access keys are issued for authorized identities, have an expiry date and can be revoked.
These credentials serve different purposes: some enable model usage, while others provide access to the DevSense API. Access needed to test software is defined separately within the project.
Does Self Hosted eliminate the use of external AI providers?
Self Hosted lets the organization install DevSense on its own infrastructure. Deployment model and model provider are separate decisions: usage is configured through BYOAI or DevSense billing.
Anthropic, OpenAI and Gemini are currently supported. Organizational requirements for information location, access or handling should be reviewed alongside provider configuration and project scope before implementation.
Who owns the code and documentation? Can we export them?
All code generated for your project belongs to the customer. You can retain and take it from your repository and continue with your own team or another provider.
Approved specifications, acceptance criteria and the customer-visible decision history also belong to you and can be exported, including when you leave the service.
Ownership does not include DevSense’s platform, supervision technology or proprietary internal artifacts. Read about code ownership, data and Azure deployment.
Service models and usage
Which service models does DevSense offer?
Cloud Enterprise provides the cloud platform for teams. Self Hosted supports installation on the organization’s infrastructure with an annual platform fee. With Development Services, Intellicore operates DevSense to develop the project’s software.
In all three models, model usage is managed separately through BYOAI or usage-based billing. Platform or service terms are agreed according to organizational needs.
What does BYOAI mean, and which providers can I use?
BYOAI means Bring Your Own AI: using API keys from your own AI provider accounts. DevSense runs work with those keys, and usage is charged to your accounts. Anthropic (Claude), OpenAI and Gemini are currently supported.
API access and quotas depend on your account with each provider. Check that the credentials supplied support the usage expected for the project.
Can I register several API keys for the same provider?
Yes. You can register several keys per provider. When one runs out of balance or quota, DevSense uses the next available key from that same provider to continue the work.
The sequence is managed independently for Anthropic, OpenAI and Gemini. Exhausting one key does not automatically change provider or activate DevSense billing.
What happens if all my keys are exhausted?
You can enable a fallback in advance to move from BYOAI to DevSense billing when a provider’s keys are exhausted. That usage is recorded and billed under the agreed terms.
Fallback is opt-in: using your own keys does not enable it. Without authorization, DevSense does not activate fallback charges on its own, and usage availability must be resolved before continuing.
Can I use DevSense without providing AI keys?
Yes. You can arrange usage-based billing with DevSense under any of the three service models. In that case, you do not need to provide your own keys for the agreed usage.
Model usage is recorded by requirement, execution and milestone. The commercial proposal defines usage billing separately from platform or development service terms.
How can we evaluate DevSense before purchasing?
You can apply for a no-cost pilot, subject to team and project evaluation and approval by Intellicore. It includes platform access, a private test environment and AI usage within the agreed scope and limits.
The initial evaluation covers two weeks, one repository and up to 10 scoped requirements. Dates and terms are confirmed before work starts, with no automatic charges or obligation to purchase afterward. Review the terms and request a pilot.
Can we commission development without operating the platform?
Yes. With DevSense Development Services, Intellicore operates the platform to develop and test the project’s software. The organization agrees objectives and scope and participates in delivery review.
The proposal establishes responsibilities, project terms and how model usage is managed. This model lets the organization commission work without taking on day-to-day DevSense operation.
How do we set spending limits?
Monthly and cumulative spending thresholds are configured under the customer policy, with warnings or blocking of new operations. There is no universal amount for all customers.
These controls check admission of new operations; they are not an exact mid-execution spending cap. BYOAI quotas still apply, and fallback billing requires opt-in. Explore usage controls.
Evaluate DevSense in your organization
Review the platform with a representative project and agreed acceptance criteria.