Skip to content

Development Workflow

This document describes the end-to-end development workflow at ConnectSoft. It is written for engineers and team leads understanding how we develop and deliver software using the Factory and manual development.

At ConnectSoft, development combines AI Factory automation with human oversight. The Factory generates most code, tests, and infrastructure, while humans focus on requirements, architecture decisions, code review, and quality gates.

Note

The Factory doesn't replace human engineers—it amplifies them. Engineers focus on high-value work (architecture, domain logic, quality) while agents handle routine, template-driven work.

High-Level Flow

The development workflow follows this high-level flow:

flowchart TD
    REQ[Requirements<br/>Product Idea] --> ADR[ADR/BDR<br/>Architecture Decision]
    ADR -->|Option 1| FACTORY[Factory Run<br/>AI Agents Generate]
    ADR -->|Option 2| MANUAL[Manual Development<br/>Human Engineers]

    FACTORY -->|Generates| PR[Pull Request<br/>Generated Code]
    MANUAL -->|Creates| PR

    PR --> REVIEW[Code Review<br/>Human Review]
    REVIEW -->|Approved| CI[CI/CD Pipeline<br/>Tests & Quality Gates]
    REVIEW -->|Changes Requested| PR

    CI -->|Pass| DEPLOY[Deployment<br/>Dev/Stage/Prod]
    CI -->|Fail| PR

    DEPLOY -->|Metrics & Logs| FEEDBACK[Feedback Loop<br/>Observability]
    FEEDBACK -->|Improvements| REQ

    style FACTORY fill:#2563EB,color:#fff
    style MANUAL fill:#4F46E5,color:#fff
    style CI fill:#10B981,color:#fff
Hold "Alt" / "Option" to enable pan & zoom

Stages:

  1. Requirements - Product idea or feature request
  2. ADR/BDR - Architecture or business decision record
  3. Factory Run or Manual Dev - Generate code via Factory or develop manually
  4. Pull Request - Code changes in PR for review
  5. Code Review - Human review of changes
  6. CI/CD Pipeline - Automated tests and quality gates
  7. Deployment - Deploy to dev, staging, production
  8. Feedback Loop - Observability and improvements

Working with the Factory

Requesting New Services or Changes

Process:

  1. Create ADR/BDR - Document architecture or business decision
  2. Define Requirements - Provide structured requirements (user stories, API specs)
  3. Submit Factory Request - Request generation via Factory console or API
  4. Review Generated PR - Factory creates PR with generated code
  5. Approve or Request Changes - Review and approve, or request modifications

Example Request: 

Service: InvoiceService
Bounded Context: Invoice
Requirements:
  - Create invoice
  - Update invoice status
  - Get invoice by ID
  - Multi-tenant support
  - Event-driven (publish InvoiceCreated event)

Reviewing Generated PRs

What to Review:

  • Architecture compliance - Does it follow Clean Architecture and DDD?
  • Business logic - Is domain logic correct?
  • Security - Are security best practices followed?
  • Tests - Are tests comprehensive and correct?
  • Documentation - Is documentation complete?

What NOT to Review:

  • Boilerplate code - Template-generated code is consistent
  • Infrastructure - Pipelines and infrastructure follow standards
  • Code style - Consistent style enforced by templates

Tip

Focus code reviews on business logic, architecture decisions, and security. Don't waste time reviewing template-generated boilerplate—trust the templates and focus on what matters.

Manual Development and Extensions

When to Develop Manually

Manual development is appropriate for:

  • Custom domain logic - Complex business rules that require human judgment
  • Edge cases - Scenarios agents can't handle
  • Custom integrations - Integrations with external systems not in templates
  • Performance optimization - Critical performance paths requiring optimization
  • Legacy system integration - Integrating with existing systems

Extending Generated Code

Extension Points:

  • Domain layer - Add custom domain services and value objects
  • Application layer - Add custom use cases and workflows
  • Infrastructure layer - Add custom repositories and external service clients
  • API layer - Add custom controllers and endpoints

Best Practices:

  • Add, don't modify - Add new files rather than modifying template-generated files
  • Use extension methods - Extend template-generated classes via extension methods
  • Follow patterns - Follow the same patterns as generated code
  • Document extensions - Document why manual code was needed

Example: 

// Generated code (don't modify)
public class InvoiceService
{
    public void CreateInvoice(Invoice invoice) { ... }
}

// Manual extension (add new file)
public static class InvoiceServiceExtensions
{
    public static void CreateInvoiceWithDiscount(
        this InvoiceService service, 
        Invoice invoice, 
        decimal discount)
    {
        // Custom logic
    }
}

Code Review and Quality Gates

Code Review Process

Review Checklist:

  • Architecture compliance (Clean Architecture, DDD)
  • Business logic correctness
  • Security best practices
  • Test coverage (unit, integration, acceptance)
  • Documentation completeness
  • Performance considerations
  • Error handling

Review Guidelines:

  • Be constructive - Provide actionable feedback
  • Focus on what matters - Don't nitpick style (enforced by templates)
  • Ask questions - Understand the "why" behind decisions
  • Approve quickly - Don't block on minor issues

Quality Gates

CI/CD Quality Gates:

  • Build - Code compiles successfully
  • Unit tests - All unit tests pass
  • Integration tests - All integration tests pass
  • Code coverage - Minimum 80% code coverage
  • Static analysis - No critical security issues
  • Linting - Code style compliance

Manual Quality Gates:

  • Architecture review - Senior architect reviews architecture decisions
  • Security review - Security team reviews security-sensitive code
  • Performance review - Performance team reviews performance-critical code

Important

All PRs must pass CI/CD quality gates before merging. Manual quality gates (architecture, security, performance) are required for high-risk changes.

Typical Day-in-the-Life

Scenario: Adding a New Feature

Morning: 1. Standup - Discuss feature requirements with team 2. Create ADR - Document architecture decision for new feature 3. Submit Factory Request - Request Factory to generate feature code

Midday: 4. Factory Generates - Factory creates PR with generated code, tests, and infrastructure 5. Review PR - Review generated code, approve or request changes 6. Add Custom Logic - Manually add custom business logic not in template

Afternoon: 7. Update PR - Push manual changes to PR 8. CI/CD Runs - Pipeline runs tests and quality gates 9. Address Issues - Fix any test failures or quality issues 10. Merge PR - Merge after approval and passing gates

Evening: 11. Deploy to Dev - Automatic deployment to dev environment 12. Verify - Verify feature works in dev environment 13. Monitor - Check observability dashboards for issues

Scenario: Fixing a Bug

Process: 1. Identify Bug - Bug reported via issue tracker or monitoring 2. Investigate - Use logs, traces, and metrics to find root cause 3. Fix - Fix bug manually (or request Factory to regenerate if template issue) 4. Add Test - Add test to prevent regression 5. Create PR - Create PR with fix and test 6. Review & Merge - Review, approve, merge 7. Deploy - Deploy fix to production 8. Verify - Verify fix resolves issue