Sandykit

• 

  Dashboard

• 

  Select project objectives

Inspiration

SANDYKIT was born from a recurring frustration we experienced in enterprise software projects.

Organizations were investing in powerful development tools, experienced engineering teams, and AI coding assistants, but the delivery process remained fragmented. Business requirements were stored in documents, architectural decisions were discussed in meetings, tasks were managed in separate platforms, and AI instructions changed from one developer to another.

This fragmentation created several operational problems:

• inconsistent interpretation of business requirements;
• weak traceability between requirements, architecture, tasks, and code;
• duplicated engineering effort;
• inconsistent AI-generated implementations;
• technical decisions that were difficult to document or reproduce;
• slower onboarding for new developers;
• increasing technical debt despite faster code generation.

The arrival of Codex and other advanced coding agents changed what was technically possible. AI could now understand repositories, create multiple files, modify existing systems, generate tests, and participate in complex implementation workflows.

However, this raised a new enterprise challenge:

How can engineering teams use AI coding agents at scale without losing architectural consistency, quality, governance, and human control?

We realized that organizations did not only need more powerful AI models. They needed a standardized process for using those models throughout the software engineering lifecycle.

SANDYKIT was created to provide that process.

What it does

SANDYKIT is a spec-driven, AI-assisted software engineering command-line platform.

It transforms an initial idea, business requirement, or requirements document into a structured and traceable software delivery workflow:

Business requirements
        ↓
Functional specification
        ↓
Requirement clarification
        ↓
Technical architecture
        ↓
Development tasks
        ↓
Code implementation
        ↓
Automated tests
        ↓
Technical review
        ↓
Validated software project

Instead of generating an entire application from one large prompt, SANDYKIT separates software delivery into controlled engineering stages.

Each stage produces a persistent artifact that can be reviewed, modified, versioned, shared, and reused by the team.

SANDYKIT provides two operating modes.

Guided mode

Guided mode installs specialized commands into AI development environments such as Codex, Claude Code, Cursor, and GitHub Copilot.

The developer remains in control of each stage:

/sandykit.specify
/sandykit.clarify
/sandykit.plan
/sandykit.tasks
/sandykit.implement
/sandykit.review

This mode is designed for teams that require explicit human validation of requirements, architecture, implementation, and quality.

Autonomous mode

Autonomous mode reads a requirements document and orchestrates the complete delivery pipeline.

It can generate:

• functional specifications;
• technical architecture;
• development tasks;
• application source code;
• automated tests;
• project documentation;
• configuration files;
• Git commits;
• project validation reports.

Human approval remains available at critical stages. The objective is controlled automation, not uncontrolled code generation.

SANDYKIT also supports team collaboration, checkpoint recovery, cost estimation, secure API-key storage, Git integration, specification sharing, and task export to Jira or Linear.

How we built it

We built SANDYKIT as a TypeScript command-line application so that it could operate directly inside the developer’s existing environment.

The architecture was designed around clear separation of responsibilities:

Command-line interface
        ↓
Workflow orchestration
        ↓
Specification and planning engine
        ↓
AI provider abstraction
        ↓
Code and test generation
        ↓
Validation and quality controls
        ↓
Git and project-management integrations

The command-line interface manages project initialization, workflow navigation, configuration, team operations, and status monitoring.

The workflow orchestration layer controls the sequence of engineering stages. It ensures that specifications are generated before architecture, architecture before tasks, and tasks before implementation.

The AI provider abstraction supports multiple model providers, including:

• OpenAI;
• Anthropic;
• Ollama;
• custom OpenAI-compatible endpoints.

This provider-independent architecture allows organizations to select cloud-based or local models without changing the overall engineering workflow.

We also implemented persistent project artifacts for every stage:

spec.md
plan.md
tasks.md
implement.md
review.md

These files preserve the project context outside the AI conversation. They can be committed to Git, reviewed by engineers, shared with stakeholders, and used by different AI agents.

Additional components were developed for:

• reading requirements from Markdown, text, PDF, and DOCX files;
• storing API keys securely in the operating system keychain;
• estimating AI usage costs before implementation;
• saving checkpoints after each stage;
• generating and validating project files;
• creating automated Git commits;
• monitoring AI budgets;
• exporting tasks to Jira and Linear;
• sharing specifications through GitHub Gists;
• generating tests and running linting tools;
• resuming interrupted workflows.

The result is not simply an AI wrapper. It is an orchestration layer connecting business requirements, software architecture, AI agents, source-code repositories, and project-management systems.

Challenges we ran into

Balancing automation with human control

One of the main challenges was determining how much responsibility should be given to the AI.

A fully autonomous agent can generate software quickly, but an incorrect assumption during the specification or architecture stage can affect the entire project.

We therefore introduced validation points that allow users to:

• approve generated content;
• regenerate a stage with additional instructions;
• edit the generated artifact manually;
• return to a previous stage;
• stop the workflow;
• resume from a saved checkpoint.

This architecture keeps the engineer responsible for important technical decisions.

Generating complete and consistent projects

Generating a code snippet is relatively easy. Generating a complete, executable, and internally consistent project is significantly more difficult.

The system must ensure consistency between:

• file paths;
• imports;
• dependencies;
• environment variables;
• configuration files;
• API contracts;
• documentation;
• tests;
• build instructions.

We introduced structured output formats, file parsing, controlled file writing, linting, testing, and project validation to reduce incomplete or inconsistent generations.

Supporting multiple AI providers

Each AI provider has different APIs, authentication methods, models, streaming mechanisms, and pricing structures.

We created a provider abstraction so that SANDYKIT’s engineering workflow remains stable even when the underlying model changes.

Preserving context across long projects

Long AI conversations can lose important context. Sessions may also be interrupted by network failures, terminal closures, or API errors.

SANDYKIT stores specifications, plans, tasks, implementation logs, versions, and checkpoints as persistent project artifacts.

The project context therefore survives beyond a single AI session.

Maintaining architectural consistency

AI coding agents tend to optimize for immediate implementation. They may start generating code before architectural constraints have been properly defined.

SANDYKIT introduces a mandatory planning stage that defines the stack, components, folder structure, APIs, data flows, and integration boundaries before implementation begins.

Managing cost and security

Enterprise AI adoption requires visibility into cost and protection of credentials.

We implemented secure API-key storage, environment-variable support, cost estimation, usage tracking, budget limits, and local execution through Ollama.

Accomplishments that we're proud of

We are proud that SANDYKIT evolved from an internal process improvement idea into a complete software engineering workflow.

The project can now transform a requirements document into:

• a structured functional specification;
• an architecture plan;
• a granular engineering backlog;
• a complete project implementation;
• automated tests;
• technical documentation;
• a validated project structure.

We are also proud of the interoperability achieved across multiple tools and environments.

SANDYKIT can work with different AI providers and coding agents while preserving the same engineering methodology.

Another important accomplishment is the traceability created between each delivery stage.

Instead of treating AI interactions as temporary conversations, SANDYKIT converts them into version-controlled engineering assets.

The system also provides enterprise-oriented capabilities such as:

• human validation at critical stages;
• secure credential management;
• automated Git commits;
• workflow recovery;
• budget monitoring;
• Jira and Linear integration;
• team configuration;
• specification sharing;
• local AI execution.

Most importantly, SANDYKIT demonstrates that AI-assisted software development can be accelerated without abandoning software architecture, engineering discipline, or human accountability.

What we learned

The most important lesson was that enterprise AI engineering is not only a model problem.

It is primarily a process, architecture, context, and governance problem.

A more powerful model does not automatically produce a better software system. Sustainable results require:

• clear business requirements;
• testable functional specifications;
• explicit architectural decisions;
• persistent project context;
• standardized engineering workflows;
• quality controls;
• cost visibility;
• secure credential management;
• human validation.

We also learned that AI agents perform more consistently when they receive structured intermediate artifacts instead of one large prompt.

A clear specification improves the architecture.

A clear architecture improves the task breakdown.

A precise task breakdown improves implementation.

A validated implementation improves testing and maintainability.

This relationship can be represented as:

[ Q_{\text{delivery}} \propto Q_{\text{requirements}} \times Q_{\text{architecture}} \times Q_{\text{execution}} \times Q_{\text{validation}} ]

The overall quality of software delivery depends on the quality of every stage, not only on the generated code.

We also learned that standardization does not remove developer creativity. It reduces repetitive work and creates more space for engineers to focus on complex business logic, architecture, security, and user value.

What's next for Sandykit

The next phase of SANDYKIT will focus on making the platform more enterprise-ready, collaborative, and architecture-aware.

Our roadmap includes:

Enterprise architecture policies

We plan to introduce reusable architecture rules that organizations can apply across projects.

These policies could define:

• approved technology stacks;
• security standards;
• folder structures;
• API conventions;
• testing requirements;
• documentation standards;
• deployment constraints;
• data-governance rules.

Stronger repository intelligence

We want SANDYKIT to better understand existing systems before generating new features.

This includes deeper analysis of:

• existing architecture;
• dependencies;
• coding conventions;
• database schemas;
• APIs;
• shared components;
• previous technical decisions.

Architecture decision records

Future versions will automatically generate and maintain Architecture Decision Records so that important technical choices remain documented and traceable.

Pull-request automation

SANDYKIT will support more advanced branch creation, pull-request generation, automated summaries, risk analysis, and reviewer recommendations.

Continuous quality evaluation

We plan to extend project validation with:

• security scanning;
• dependency analysis;
• architecture compliance checks;
• code-quality scoring;
• test-coverage analysis;
• performance checks;
• accessibility validation.

Multi-agent engineering workflows

Future versions may coordinate specialized agents for:

• business analysis;
• software architecture;
• backend development;
• frontend development;
• testing;
• security;
• code review;
• DevOps.

Each agent would operate within the same validated specification and architecture context.

Enterprise collaboration platform

Our long-term objective is to make SANDYKIT a shared engineering layer between business teams, architects, developers, quality teams, and AI agents.

The goal is not merely to generate software faster.

The goal is to make AI-assisted software delivery more reliable, repeatable, traceable, and aligned with enterprise architecture.

AI accelerates software development. SANDYKIT provides the engineering structure required to make that acceleration sustainable.

Built With

• javascript
• typescript