What we do
Devstorm builds software for you using agentic engineering. This means we can help you build what you want, faster, at a lower cost.
We've built a toolkit that cuts the time needed for research, investigation, planning, implementation, testing, deployment, and documentation. It uses AI agents to do work that would usually need a team of developers, while the important decisions and control stay with you.
Experienced human engineers own the parts that matter: architecture, technical decisions, and what finally ships. AI does the painful, time-consuming, error-prone work in between.
Engagement models
ENGINEERING CAPACITY
An engineering team inside your business. We embed the engineers and the toolkit into your business.
We work within your architecture and your processes, to build what you want.
TEAM ENABLEMENT
We bring the toolkit and configure the agent environment around your workflows, codebase, configuration, and infrastructure.
We then train your engineers to use and maintain it within your project boundaries and your ways of working. It all stays with you after we leave.
PRODUCT DELIVERY
Whether you need a new product or application, a change to an existing system, or a full modernisation, we use our toolkit to build it for you off-site.
We handle everything, from discovery through to release and deployment, to hosting and handover, and deliver what you want. You stay involved throughout the process.
Interested in working with Devstorm?
Get in touch and tell us what you're working on.
Built around you
Whatever your code is written in, wherever it runs, and however you build, test, and release it. Whichever source control you use, however you track work, and whatever methodology your teams follow. None of that has to change. We don't impose new tools or a new process. We simply adapt to the ones you already have.
On day one, we learn your system. The code and its architecture, the infrastructure, how work moves through your teams, your practices and procedures, and how and where you document things. Agents read what already exists before they ask you anything, and you confirm what they have understood. From then on, they work the way your team works.
Azure, AWS, Google Cloud, containers and Kubernetes, or your own servers.
GitHub, Azure Repos, GitLab, Bitbucket, and your branching and pull request rules.
Azure Pipelines, GitHub Actions, GitLab CI, Jenkins, and the approval gates you already have.
Azure Boards, Jira, GitHub Issues, Linear, Markdown files, or something else.
Scrum, Kanban, or your own hybrid. Epics, features, stories, and tasks, or just issues.
Notion, Confluence, SharePoint, wikis, or flat files alongside the code.
If your team works with it, so do we.
Getting started
Most codebases were not built with agents in mind. Before any agent changes your code, we build the grounding knowledge that agents need to work in yours. It starts with an agreed scope, works from evidence, and asks you only about what the evidence cannot settle. No lengthy questionnaire, no long, drawn-out Q&A session, and no burden of writing a ton of documentation up front if it doesn't already exist.
Our agents discover the repositories, projects, permissions, and approval points that are in place. You confirm what they should and shouldn't have access to and use going forwards. Just because something is there doesn't automatically put it in scope.
We read the authorised repositories, and understand the codebase and its rationale. We discover how you use your work tracker, how you structure your documentation, and how you record decisions. These are the facts the project can supply. You just fill in any gaps.
We show you what we found, as interpretations to confirm or correct. Questions come only when the answer changes something.
We build all of these findings into a working agreement, and crystallise that in a project profile that your team can read, review, and edit. It forms a working source of truth, so the agents don't have to rediscover it each time, or make guesses.
Discover what is actually known. Let evidence resolve questions. Refine the work without inventing missing intent.
The delivery process
Things usually start with a rough idea, and pass through these stages. Often multiple passes through will be required, but not every change needs every stage.
Whether we're starting from a brief, a problem statement, a need, or a goal, we separate the knowns from the unknowns, brainstorm ideas, prototype solutions, and clarify assumptions.
From there we decompose and refine, identify requirements, define acceptance criteria, and understand the scope. We keep iterating until we have clarity.
Then we create technical plans, define the objectives, specify bounded changes, crystallise the decisions, and make them implementation-ready.
Generate code, configuration, schemas, tests, and documentation according to the agreed plans, architecture, engineering standards, and acceptance criteria.
Run tests, static analysis, security scans, and performance checks. Verify behaviour, detect regressions, and feed findings back with the evidence to support them.
Review changes for clarity, maintainability, and alignment. Assess validation evidence, challenge assumptions, and resolve outstanding findings.
JOURNEYS
There are various starting points, and combinations of skills and workflows that can form a journey, depending on the task or problem at hand. For example: a large idea that needs refining, reworking an existing codebase, or adding a major feature to an established product.
See some examples →
CASE STUDY
See how the toolkit was used on a real system to build a local replica of a production environment that only humans were allowed to access. The agent walked a person through a read-only inspection, without any direct access itself, by suggesting CLI commands to run, export wizard selections, and queries to execute. From the results, it built a local Docker environment with emulators and real schemas, in which it could then test production releases.
See the case study →
Bring people in at the judgement calls, not just because a process stage has ended.
Our toolkit
We designed the skills, workflows, and harness extensions ourselves, then evaluated and refined them through real delivery. Each skill has a defined job, a clear scope, and a point where it stops.
Agent skills
How and why the code and environments work, and what effect change will have.
Turning rough ideas into work that is ready to be implemented in the correct order.
Focused changes, planned and designed to fit the existing system.
Behaviour validation, failure diagnosis, and independent change review.
Decisions, terminology, and context preserved, so work can carry on later.
The toolkit also has skills for writing for a human audience. Pull requests, work items, and documentation follow a technical writing standard based on Simplified Technical English, with a final pass that removes vague and inflated wording.
Workflows & strategies
Agents that coordinate other agents and subagents, with clear briefs, ownership, and budgets. Their work is monitored, and the results are combined and verified.
A strategy to manage context on longer-running tasks: predicting operations that will load heavy or transient data, knowing when to checkpoint, and when to start fresh.
Two agents with separate contexts, working as a driver and navigator pair. They tackle a single problem by exchanging information, rather than in an adversarial capacity.
A staged workflow for work with high uncertainty, consequence, or context burden. Each stage produces compact evidence for human review, with a checkpoint before the next.
Delivers a scoped engineering outcome end to end, adapting skill use, delegation, human checkpoints, context, and verification to the uncertainty, consequence, and time involved.
Harness extensions
Traces what each agent and subagent did in a session, and why. Actions, decisions, tool usage, effectiveness, and behaviour can then be evaluated and reasoned about, for continuous improvement.
Wraps the terminal in a tmux session. Agents can launch in separate windows and panes, and interact with each other. Split, join, rename, or kill them at will, for full control of running agents.
Conditional instructions, matched by pattern, that load only when a specific file, file type, project, or folder comes into scope. Fine-grained rules reach the agent's context only where they apply.
Stops agents wasting context by loading skills that are already present and unchanged. Handles the cases where compaction, a session clear-down, or a skill change genuinely needs a reload.
A status bar in the terminal footer that keeps token spend, context usage in tokens and as a share of capacity, the current branch, and the current worktree in view at all times.
Not all agent harnesses can be customised in every way. We'll work with you to apply the extensions that matter to your business, based on your choice of harness.
Every expensive agent action should reduce uncertainty, make implementation progress, or produce validation evidence. If it does none of those, the agent should stop and think again.
Containerisation
An agent that has to keep asking your permission before it reads a file, makes a change, installs a package, or runs a command is slow, and makes you the bottleneck.
An agent running unrestricted on your own machine can reach every repository, document, credential, and tool that you can. That can lead to unexpected outcomes. Nobody wants to find that an agent has deleted the production database, or published a secrets file to the internet.
Telling an unrestricted agent not to read or use something is a soft boundary. If you also give it a task that needs those things, the instructions conflict, and it may decide that completing the task matters more.
That is not the agent being bad, or 'going rogue'. It is trying to complete the task you gave it, with the capabilities you made available.
The solution is not to lock the agent down and make it ask permission for everything it might need to do. Nor is it to hand over the keys to the kingdom and politely ask it not to use them, even if it later judges that it needs to.
The solution is a strictly contained environment: a ring-fenced boundary where you control the permissions, access rights, and credentials, and the agent has complete freedom to work inside it.
A dedicated container provides a Git-controlled project workspace. Network settings and mounted volumes limit what else it can reach.
Scoped credentials, access tokens, permissions, and settings are injected as environment variables at launch.
The agent runs in unrestricted mode. It can install packages, add CLI tools, read and change files, and reconfigure its system as the work needs.
Git commits and pull requests show what the agent changed. Tests show whether it works. People review the changes and decide what to keep.
Fine-grained tokens grant only the permissions the agent needs. An agent might view the main branch but not commit to it, or inspect the release pipeline but not trigger a deployment. An agent cannot use access it was never given.
If an agent breaks its environment, we discard the container and start a new one. If a change breaks the codebase, we roll it back or discard it and start again. Your machine, other projects, and credentials are unaffected.
Hooks check actions before they run, and block those that match a rule, such as commits to protected branches, destructive commands, or edits to secrets. Repository policies on the remote add further layers of protection.
Each agent checks out and branches code in its own workspace, and parallel subagents each get their own worktree. Every change is isolated to the agent that made it, the same way a human development team works.
Prompting a boundary helps. Enforcing it helps more.
Tell us what you want to deliver, what is slowing your team down, or where and how you want to introduce agents. We can discuss your goals, your constraints, and whether we are a good fit.