DEV Community: Duck

After Setting Up JWT, Redis, Docker, Swagger, and CI for the 20th Time, I Built ArchGen

Duck — Wed, 03 Jun 2026 10:58:22 +0000

I Built ArchGen: A Backend Project Generator Powered by GitHub Copilot

This is a submission for the GitHub Copilot Challenge.

What I Built

As a backend developer, I kept running into the same problem.

Every new project started with hours of repetitive setup:

Configure TypeScript
Set up Fastify or FastAPI
Configure database connections
Add authentication
Configure logging
Add Docker support
Create CI pipelines
Set up validation and error handling

None of these tasks were difficult.

They were just repetitive.

After creating multiple backend services, I realized I was spending more time configuring projects than actually building features.

So I built ArchGen, a CLI tool that generates production-ready backend projects in seconds.

Instead of spending hours wiring infrastructure together, developers can run:

archgen create my-app

Answer a few prompts and get a complete backend project ready to run.

Why I Built It

I wanted a developer experience similar to:

create-next-app

but for backend applications.

Most backend generators either:

create very minimal projects
generate outdated code
focus on only one framework
don't support upgrading generated projects

I wanted something opinionated, modern, and practical.

The generated projects include real-world essentials such as:

Authentication
Validation
Logging
Error handling
Redis integration
Docker support
CI workflows
API documentation
Email services
S3-compatible storage

These are things I add to almost every backend project.

How GitHub Copilot Helped

GitHub Copilot was heavily involved throughout development.

Generating Boilerplate Faster

ArchGen itself generates boilerplate, but building the generator required writing a lot of repetitive code.

Copilot helped accelerate:

CLI command implementations
Interactive prompt flows
Template generation logic
File system operations
Validation helpers

Refactoring Large Template Systems

As the project grew, I had to reorganize templates into reusable modules.

Copilot was useful for:

Refactoring duplicated logic
Extracting reusable utilities
Updating imports across files
Generating repetitive template mappings

Building Addon Support

One of ArchGen's core features is addon injection:

archgen add docker
archgen add websocket
archgen add oauth
archgen add email
archgen add s3

Copilot helped scaffold many of the repetitive integration points required to support multiple addons consistently.

Features

Generate a Full Backend Project

archgen create my-app

Generates a production-ready backend structure.

Multiple Language Support

Node.js stack:

TypeScript
Fastify
Prisma
Redis
JWT
Zod
Pino

Python stack:

FastAPI
SQLAlchemy 2.0
PostgreSQL
Redis
APScheduler
Pydantic v2

Add Features Later

archgen add websocket
archgen add oauth
archgen add api-docs
archgen add email
archgen add s3

No need to regenerate the entire project.

Upgrade Existing Projects

archgen upgrade

ArchGen tracks project metadata and can re-apply updated templates later.

Example

Creating a complete backend project:

archgen create ecommerce-api \
  --language node \
  --docker \
  --testing \
  --ci \
  --oauth \
  --api-docs

This generates:

Fastify application
Prisma setup
Docker configuration
GitHub Actions workflow
OAuth integration
API documentation
Testing configuration

in under a second.

Demo & Screenshots

Here's a quick look at the ArchGen workflow, from project creation to the final generated codebase.

Interactive CLI Experience

ArchGen guides developers through project creation using interactive prompts. Instead of memorizing dozens of flags, you can simply answer a few questions and generate a fully configured backend project.

Supported Languages and Addons

The CLI allows developers to choose between Node.js and Python stacks, along with optional addons such as Docker, Testing, CI/CD, WebSocket support, OAuth, Email, S3 storage, and AI agent integrations.

Detailed Stack Information

Before generating a project, developers can inspect the complete technology stack. This helps teams understand exactly what will be included in the generated application.

Project Generation in Action

Creating a production-ready backend takes only a few seconds. ArchGen automatically configures the selected stack, dependencies, and project structure.

Generated Production-Ready Structure

The generated project includes a clean and opinionated architecture with modules, middleware, configuration, shared utilities, database integration, and other production essentials already wired together.

What I Learned

Building ArchGen taught me that developer productivity isn't only about writing application code.

A huge amount of engineering time is spent creating the same infrastructure repeatedly.

By automating that setup process, developers can spend more time solving actual business problems.

GitHub Copilot helped me move much faster, especially when implementing repetitive scaffolding logic and maintaining consistency across templates.

Links

GitHub Repository:

https://github.com/Kidkender/archgen

NPM Package:

https://www.npmjs.com/package/@kidkender/archgen

Thanks for reading!

I Finally Finished the Architecture Tool I Abandoned 2 Months Ago

Duck — Tue, 02 Jun 2026 04:49:42 +0000

What I Built

Two months ago, I started building an experimental tool called ArchMind.

The idea was simple:

What if software architecture could be tested the same way we test behavior?

In large Laravel applications, a single request often spans multiple layers:

Route
 → Middleware
 → Authentication
 → Controller
 → Service
 → Transaction
 → Event
 → Listener

Tests verify behavior.

Static analysis verifies code quality.

But architectural changes often slip through unnoticed.

A missing DB::transaction(), a removed middleware, or a missing authorization layer can pass tests and code review while still creating production issues.

ArchMind parses Laravel applications into execution graphs and helps developers:

Visualize execution flows
Detect architecture findings
Track architectural drift
Prevent topology regressions in CI
Provide execution-aware context for AI assistants

The project is open source and available on npm:

npm install -g @kidkender/archmind

GitHub:

https://github.com/Kidkender/archMind

npm:

https://www.npmjs.com/package/@kidkender/archmind

Demo

Trace a Route

archmind trace --project . "POST /orders"

Output:

POST /orders
└─ auth:sanctum
   └─ ResolveTenant
      └─ OrderController::store
         └─ OrderService::createOrder
            └─ DB::transaction
               ├─ Order::create
               └─ OrderCreated

Detect Architecture Regressions

archmind verify --project .

Example:

✘ TOPOLOGY REGRESSION

Route:
  POST /orders

Lost:
  transaction_boundary

This catches situations where important architectural guarantees disappear during refactoring.

CI Integration

- run: npm install -g @kidkender/archmind
- run: archmind verify --project .

If a transaction boundary, authentication layer, or tenant isolation mechanism disappears, CI fails immediately.

📸 Insert screenshot: archmind trace

📸 Insert screenshot: archmind verify

The Comeback Story

When I originally started ArchMind, it was little more than an experiment.

It could parse Laravel routes and generate a basic execution graph.

That was interesting, but not useful enough for real projects.

At that point the project was missing almost everything required to be practical.

Before

❌ No topology regression detection

❌ No architecture findings

❌ No CI integration

❌ No retrieval benchmarks

❌ No npm package

❌ No real-world validation

The project sat unfinished while I worked on other things.

A few months later I revisited the idea after encountering a production issue caused by an architectural change that passed both tests and code review.

That experience convinced me there was still something worth pursuing.

What I Added

Over the following months I completed:

Execution graph engine
Architecture findings system
Topology regression detection
CI workflows
Retrieval engine improvements
Benchmark suite
npm publishing
Documentation

Results

Retrieval recall improved from:

0.71 → 1.00

Architecture QA benchmark:

Method	Score
ArchMind	76.7%
File-based retrieval	61.7%

Token usage reduction:

Up to 15.6× smaller context

Most importantly, the project evolved from a prototype into something developers can actually install and use.

📸 Insert screenshot: benchmark table

📸 Insert screenshot: npm package page

My Experience with GitHub Copilot

GitHub Copilot played a significant role in helping me finish the project.

One of the hardest parts of reviving an older codebase is rebuilding momentum.

After several months away from ArchMind, there were many areas where I needed to quickly re-familiarize myself with the implementation.

Copilot helped by:

Accelerating Refactors

Large portions of the execution graph engine required repeated traversal and visitor patterns.

Copilot generated boilerplate structures that I could adapt rather than writing everything from scratch.

Expanding Test Coverage

Copilot helped generate test scaffolding and edge-case scenarios that I later refined and validated manually.

This made it easier to improve confidence while evolving the architecture.

Documentation and Examples

Many CLI examples, usage snippets, and documentation sections were drafted with Copilot assistance and then edited for accuracy.

Reducing Context Switching

Most importantly, Copilot reduced the friction of returning to an unfinished project.

Instead of spending hours reconstructing implementation details, I could iterate faster and focus on the architectural ideas behind the tool.

What I Learned

The biggest lesson from finishing ArchMind is that architecture itself can be treated as data.

Once architecture becomes a graph, it becomes possible to:

Version it
Query it
Compare it
Verify it

That realization transformed ArchMind from an abandoned side project into a tool that developers can use to protect architectural intent in production systems.

Tests verify behavior.

ArchMind verifies architecture.

Links

GitHub

https://github.com/Kidkender/archMind

npm

https://www.npmjs.com/package/@kidkender/archmind

Tests Verify Behavior. ArchMind Verifies Architecture.

Duck — Tue, 02 Jun 2026 03:06:09 +0000

The PR was 14 lines.

The incident cost two days.

Tests passed. Code review approved. Production corrupted customer orders anyway.

Someone refactored OrderService. One method call moved outside DB::transaction().

The email notification failed mid-request.

Half the order was written. Half wasn't.

The diff looked harmless.

The types were correct.

The logic seemed unchanged.

The architecture was not.

The problem I kept running into

Modern Laravel applications rarely execute inside a single file.

A request often flows through:

Route
 → Middleware
 → FormRequest
 → Policy
 → Controller
 → Service
 → Transaction
 → Event
 → Listener

The bigger the application becomes, the harder it is to understand this flow.

Most tooling doesn't help much.

PHPStan verifies types.

Tests verify behavior.

Code review focuses on diffs.

But none of them answer a simple question:

Did the execution architecture of this route change?

For example:

POST /orders

Before:
  auth
  tenant middleware
  DB::transaction
  Order::create
  OrderCreated event

After:
  auth
  tenant middleware
  Order::create
  OrderCreated event

The transaction disappeared.

The code still compiles.

The tests may still pass.

But the architecture has changed.

I wanted architecture to become testable

Frontend teams have snapshot testing.

If a UI unexpectedly changes, CI catches it.

I started wondering:

What if we could do the same thing for execution architecture?

That idea became ArchMind.

Instead of treating a Laravel project as a collection of files, ArchMind builds an execution graph.

Route
 → Middleware
 → Controller
 → Service
 → Transaction
 → Event

The graph becomes a baseline.

Future commits are compared against it.

If an important architectural component disappears, ArchMind reports a topology regression.

Example:

✘ TOPOLOGY REGRESSION: POST /orders

lost:
  transaction_boundary

CI fails before the change reaches production.

What ArchMind actually does

1. Trace execution flow

archmind trace --project . "POST /orders"

Output:

POST /orders
└─ auth:sanctum
   └─ ResolveTenant
      └─ OrderController::store
         └─ OrderService::createOrder
            └─ DB::transaction
               ├─ Order::create
               └─ OrderCreated

This provides a route-level view of the execution path.

No digging through controllers, services, events, and listeners manually.

2. Detect topology regressions

archmind verify --project .

Example:

✘ TOPOLOGY REGRESSION

Route:
  POST /orders

Lost:
  transaction_boundary

The goal is not to verify business logic.

The goal is to verify architecture.

3. Surface architecture findings

archmind findings --project .

Examples:

missing_authorization

Route is authenticated
but no authorization layer was detected.

Or:

transaction_escape

Event dispatched from inside
a transaction boundary.

These findings are intentionally conservative.

The idea is to surface architectural risks for review rather than claim guaranteed vulnerabilities.

An unexpected side effect: better AI context

Originally, ArchMind was not built as an AI tool.

It started as a static analysis and architecture verification tool.

But once an execution graph existed, it became useful for retrieval as well.

Most AI coding tools work roughly like this:

Question
 ↓
Find similar files
 ↓
Send files to LLM

ArchMind instead retrieves execution context:

Question:
Why does this payment endpoint sometimes double-charge customers?

Relevant context:
- transaction boundary
- payment event dispatch
- after-commit listener

In benchmark tests on real Laravel applications:

Metric	ArchMind	File Dump
Correct answers	3/3	1/3
Average score	76.7%	61.7%
Tokens per query	~700	~9000

The interesting result wasn't just higher accuracy.

It was that the execution graph compressed architecture knowledge into a much smaller context window.

How it works

At a high level:

PHP Source
    ↓
Tree-sitter parsing
    ↓
Laravel-aware analysis
    ↓
Execution Graph
    ↓
Topology Verification

No PHP runtime required.

Current support includes:

Laravel 10
Laravel 11
Laravel 12
Middleware chains
FormRequests
Policies
Transactions
Events
Route groups
apiResource routes

What ArchMind does not do

It's important to be clear about limitations.

ArchMind will not catch:

Incorrect business logic
Off-by-one errors
Wrong comparison operators
Runtime bugs caused by external services

It focuses on structural and architectural changes.

Think of it as:

Snapshot testing for execution architecture.

Not a replacement for tests.

Not a replacement for static analysis.

An additional layer that verifies architectural intent.

Example CI setup

Save a baseline:

archmind verify --project . --update

Commit it:

git add .archmind/baselines
git commit -m "chore: add topology baseline"

Then run in CI:

- run: npm install -g @kidkender/archmind
- run: archmind verify --project .

If a transaction boundary disappears, an auth middleware is removed, or a protected route loses part of its architecture, the build fails.

Final thoughts

The most interesting realization from this project wasn't about Laravel.

It was this:

Tests verify behavior.

Architecture usually lives in people's heads.

When architecture becomes a graph, it becomes something we can version, compare, and verify.

That's the idea behind ArchMind.

I'd love feedback from Laravel developers:

Have architectural regressions caused incidents in your projects?
How do you currently review execution flow changes?
Would architecture-level verification be useful in your CI pipeline?

GitHub: https://github.com/Kidkender/archMind

Write a telegram mini app

Duck — Sat, 27 Jul 2024 10:39:36 +0000

I wrote a telegram mini app that uses the user's telegram join date and gives them token rewards, features include leaderboard, or referral friends.