Tacticum ADP
Bring structure to AI-assisted software development
Give your team's AI-assisted workflow the context it needs: engineering knowledge, architecture decisions, design rules and quality checks. Start with one team and a clearly defined path from task to review.
- TaskRequirements and acceptance criteria
- ContextCode, architecture and team rules
- ChecksTests, design constraints and review
- ReviewResult, evidence and next decision
Illustrative workflow
A good fit for teams with an existing codebase
ADP addresses the engineering process around AI-assisted development. It is relevant when your team already uses AI tools and needs a consistent way to apply project knowledge, review changes and check the result.
- Your teams use AI tools, but their instructions and review practices differ.
- You maintain an existing codebase with architecture decisions, tests or a design system.
- You want to evaluate one repeatable workflow before introducing it more widely.
A pilot needs an engineering owner, agreed access boundaries and clear acceptance criteria. It does not promise autonomous delivery, replacement of the engineering team or a fixed productivity improvement.
Put project context into the workflow
- Engineering knowledge
- Identify the parts of the codebase, requirements and architecture decisions that matter to the task.
- Team and stack rules
- Define how the selected team works with its tools, technology stack and project conventions.
- Design constraints
- Include the relevant components, design tokens and UI requirements when the task changes the interface.
- Quality checks
- Agree which tests, reviews and security checks are required before a change can move forward.
- Traceability
- Keep a clear connection between the task, implementation decisions, checks and review outcome.
Start with one workflow
Choose the task
Choose one team, one repository, one main technology stack and a clearly defined task. Agree what a useful result looks like.
Prepare the context
Identify the relevant code, architecture rules, test expectations and access limits.
Define the checks
Decide what must be reviewed before implementation, during development and before acceptance.
Run the pilot
Follow the agreed workflow on the selected task and retain the evidence needed to review the result.
Review the outcome
Identify which rules helped, which checks need adjustment and what would be required for a wider rollout.
What we assess during a pilot
- Whether the task retains its requirements and architecture context through implementation.
- Whether the agreed tests and reviews are performed and their results are visible.
- Whether UI changes follow the relevant design constraints.
- Where human judgement, additional context or a different workflow is needed.
The proposal defines what you receive: the agreed workflow and team rules, the implementation and review findings for the selected task, and handover instructions with known limitations. Any comparison of delivery speed or quality needs an agreed baseline and comparable work.
Agree the scope and cost before starting
An initial discussion helps us understand your task and does not start paid work. If we need more information to estimate the pilot, we can propose a separate paid assessment first.
Assessment and pilot work are separately agreed paid engagements. Scope, deliverables, fees, payment terms and delivery dates are agreed before work begins.
The proposal distinguishes four cost components, making clear what is included and what is separate:
- Product or tool licensing.
- Assessment and implementation work.
- Infrastructure and model usage.
- Ongoing support.
We agree the available tools, access limits and responsibilities for your project. Production rollout, additional teams or repositories, and ongoing support are separate decisions.
Questions about an ADP pilot
Do we need to replace our development tools?
The starting point is your current workflow. We identify the tools and constraints involved, then assess how the proposed approach would fit. Compatibility is checked for the selected scope.
What should we prepare?
Choose an engineering owner and a bounded task. Gather the relevant architecture decisions, development conventions, test expectations and any design-system requirements. Access is agreed before work begins. Please do not send source code, credentials or customer data through the website contact form.
How will the pilot be evaluated?
We agree acceptance criteria before starting and review the implementation, checks and remaining limitations against them. A productivity claim requires a suitable baseline; it is not assumed from a successful demonstration.
Can we start with one team?
Yes. The proposed starting point is one team, stack and workflow. The decision to expand follows the pilot review and a separate agreement on scope.
How do we discuss the next step?
Send a short description of your engineering workflow and the problem you want to address. We can then discuss the context and a suitable first step.
Define a pilot for your engineering team
Tell us how your team uses AI today and where the workflow needs more structure. We will use that context to discuss the scope and evaluation criteria for a first pilot.
Discuss an ADP pilot