Secure AI-assisted development
AI can produce a large share of the code today, and for the right kind of work it speeds development up several times over. A working prototype, however, is not yet a system a business can rely on. We set up an environment where you can build fast with AI agents without an unverified change reaching production.
Three ways to work together
They differ in how much of the development you do and how much we do. You can move between them mid-project.
You bring a problem, a process or a business need. We run the analysis, design the architecture, pick the technologies, build the application, test it, deploy it and keep developing and operating it as agreed.
We own the architecture, the data and security model, the infrastructure and the critical parts of the system. Your team builds selected features, with AI agents if that suits them. Every change goes through the same tests and the same review.
You build most of it yourself. We prepare a safe application skeleton, rules for AI agents, automated tests, an isolated preview environment and a release process. On top of that we do code review, resolve conflicts or run production, to the extent you order.
Full custom development is not going anywhere. The other two modes are an addition, not a replacement.
AI speeds up development, it does not carry the responsibility
We use AI agents routinely and we say so openly. But every output is judged in the context of the specific project. AI has no view of your processes, your data history, or what happens when an integration with a neighbouring system breaks.
Analysis and technical research, implementation, writing and extending tests, code review, hunting bugs, documentation, and where it makes sense, migrations and refactoring.
Architecture, technical decisions, the security model, review and quality of the resulting code, the scope of testing, and the judgement call on whether a change is ready for production.
AI is not a cheap replacement for a junior, nor an autonomous supplier. It is a powerful tool in the hands of a senior developer. We are not claiming AI never gets it wrong. We are claiming its output does not reach production unreviewed.
What we set up for you
The scope is agreed per project and per risk level. Treat the list below as building blocks, not a mandatory bundle.
- A stable architectural skeleton for the application
- A data and security model
- Repository and branching strategy
- Instructions and guardrails for AI agents
- Development conventions and project structure
- Automated tests and quality gates
- An isolated test or preview environment
- A CI/CD pipeline
- Versioned Docker images or equivalent release artefacts
- Controlled deployment, monitoring and backups
Optionally with senior oversight, code review, our own development work and infrastructure management on top.
How a change reaches production
The exact shape differs by project. The principle does not: nothing reaches production without passing tests and being approved.
Nobody pushes straight to the main branch. Not you, not the developer, not an AI agent.
Every task or agent run gets its own branch. A smaller change is easier to review and easier to undo.
The change is opened as a pull request describing what is changing and why.
Every pull request runs the tests, static analysis and whichever checks we agreed on.
You open the change and try it on a separate version of the application, not on live data.
Once you have tested and approved it, an immutable release artefact is built, typically a versioned Docker image.
Production gets exactly the artefact that passed the tests and the approval. Nothing is repackaged along the way.
We do not push one universal branching model. A smaller project deserves a simpler flow, a system holding sensitive data a stricter one.
What happens when changes conflict
When several people and agents work on a project at once, conflicts happen. We do not promise a tool will always resolve them. We promise they will not be resolved quietly and wrongly.
Two edits to the same place in the code with no shared meaning. An AI agent may attempt this one. After the merge, all relevant tests have to run again.
The changes touch the same business logic, data model, migrations, permissions or architecture. The code merges cleanly, but the result does something other than intended. A senior developer reviews and approves this.
Conflict resolution and ongoing senior oversight can be ordered as part of a support package. The production branch cannot be bypassed by an AI agent pushing directly.
Deployment, versions and going back
Depending on the scope of the project, you can get a simple interface that lets you run deployments without knowing Git or servers:
- Open the test version of the application
- See the status of automated checks and tests
- Approve a specific release
- Deploy the approved artefact to production
- Restore the previous compatible version
On suitably designed systems the previous compatible version can be restored safely. That is exactly why an immutable artefact is deployed: we know precisely what we are going back to.
Going back depends on the compatibility of database changes, on external integrations, on irreversible operations and on the nature of the specific release. Database and irreversible changes are therefore handled by a separate migration and recovery procedure.
Security and reliability
Security is not a check bolted onto a finished application. The scope of the measures follows the risk of the project and the agreed scope of the service. An internal tool for five people warrants something different from a system holding personal data of thousands of customers.
Authentication and permission design, separation of roles and tenants, secrets handling, and a safe test environment without live data.
Dependency management, automated static analysis, known-vulnerability checks, secret scanning and container scanning.
Testing of application and API scenarios, ongoing automated security scanning and, where agreed, a penetration test.
Monitoring, logging and alerting, backup and recovery, infrastructure design, and consulting on safe use of AI during development.
We are not claiming all of these controls are automatically part of every project. What we actually put in place is always stated in the proposal.
What automated tests are actually for
Tests are not a marketing coverage number. They exist to protect the scenarios whose failure would genuinely hurt:
- Sign-in and account management
- Permissions and data visibility
- Handling of important data
- Key business rules
- Integrations with surrounding systems
- Database migrations
- Core user workflows
- Post-deployment smoke tests
The scope of testing follows the project. We do not promise a specific code coverage percentage up front. A high number on its own does not mean the application is sound.
Penetration tests
We can run penetration tests, but they are not automatically part of every project.
- They can be part of delivering a secure skeleton if explicitly included in the proposal
- They can be ordered separately at any time for an additional fee
- The scope of the test is always defined in advance
- Alongside them we offer ongoing automated security scanning
We do not call an automated vulnerability scan a penetration test. A scan looks for known vulnerabilities from a database; a penetration test is targeted human work.
Who runs the infrastructure
There are three options and none of them is mandatory. We pick based on your internal rules and on where the data has to stay.
We run the application on our own Docker infrastructure, including monitoring, backups and updates. You never deal with servers.
The system runs on your hardware or your cloud provider. We handle operations and maintenance as agreed.
We hand over documentation, the release process and the configuration. You keep operations in-house and we stay available for development and consulting.
Which AI models we use
We do not use one model for everything. Depending on the task we pick a suitable cloud or locally run model - one for long agentic tasks, another for quick implementation, code review or auxiliary data processing. Among cloud models we currently work with Claude and OpenAI GPT-5.6, for example.
For selected auxiliary, low-latency or data-sensitive tasks we can reach for locally run open-weight models, for example from the Qwen, Gemma, GPT-OSS or Llama families. Depending on the project they run on our infrastructure or on yours. We do not use them in every project, and for the most demanding work the stronger cloud models remain. Running a model locally is not a guarantee of security in itself - it still needs properly configured access, isolation, logging, updates and data handling rules.
Read the list as the current state of our tooling, not as a permanent technology commitment. Models change quickly, and the reason to work with us should be how we work, not the name of a model.
Frequently asked questions about AI-assisted development
Are you replacing developers with AI?
What happens when AI-generated changes end up in conflict?
Is a penetration test part of every project?
Can we go back to a previous version if something breaks?
Can people who are not programmers build with AI on our side?
Does this mean you no longer do full custom development?
Do you also use local AI models?
Get in touch and we will go through your intent, your processes and how much of the development you want to keep in-house. The consultation is free and non-binding. If secure AI development does not make sense for you, we will say so.