Our engineering practices
Exploring code, preparing changes and verifying results: we use AI assistance within a delivery framework that keeps the software under control.
Our approach
AI assistance can help explore a repository, suggest a change or prepare tests. Its usefulness depends on the task and the context. At Etixio, we build it into our engineers’ work: architecture choices, business understanding and validation remain the team’s responsibility.
This practice is distinct from building an AI solution for your users. A coding assistant works on the project; a business agent is part of the delivered product. Both require appropriate permissions, data and verification criteria.
Our practice
AI can help locate files, explain how a component works or compare options. We check its suggestions against the code and how the product is used. The first step is to determine what needs to be understood before allowing a change, especially in inherited or poorly documented software.
We scope the change with the expected rules, the files involved and the conventions. Changes are reviewed like those of any contributor: consistency with the architecture, effects on data, errors and added dependencies. A change that is too broad is broken down so the review stays useful.
Assistance can suggest scenarios or a first draft of documentation. We check that tests examine the expected behavior and that the documentation matches the software. Failure cases, access and effects on connected systems remain subjects of explicit verification.
Explicit choices
We specify the authorized tools, the accessible repositories and the information that may be shared. Secrets and production data are not part of the default context. Repository rules can guide the assistant on commands, conventions and sensitive areas; actual permissions are managed in the environment.
The choice of tool depends on your constraints and the work to be done. Cursor can be integrated into the developer workstation; other interfaces or agents may suit other tasks. We avoid making quality practices depend on a single vendor or a model version number.
Our practice
Generation speed alone does not measure a gain. We look at the time spent preparing the task, reviewing, fixing and verifying the change. Test quality, defects found and how easily the code can be taken over are all part of the assessment.
Adoption can start with limited tasks, in a repository whose checks are well known. Feedback makes it possible to extend the uses that help the team and to drop those that mostly add verification work. The goal remains software that is understandable and maintainable.
Tell us what you want to build, the users involved and your technical environment. Together, we will define the first scope to explore.