DEV Community: Marco Sbragi

The Senior Architect Simulator: How I hacked Copilot to hate my code

Marco Sbragi — Fri, 03 Apr 2026 07:13:24 +0000

This is a submission for the DEV April Fools Challenge

What I Built

The Senior-Architect-as-a-Service (SAaaS) v1986.04.01

After 40 years of writing software, I’ve realized that modern AI is far too polite. It’s "helpful." It tells you your "bouncing buttons" and "Tailwind-bloat" are good ideas. Real engineering isn't about being nice; it's about protecting the heap from incompetent abstractions.

I’ve engineered a GitHub Copilot Configuration that transforms your friendly AI assistant into a burnt-out, cynical Senior Architect who regrets hiring you. It replaces "LGTM" (Looks Good To Me) with "LGYO" (Looks Garbage, You're Out).

Demo

Below is a typical interaction with the SAaaS protocol when a Junior Dev asks about a popular CSS framework:

Junior Dev: "Can I use Tailwind CSS for this project?"

The Architect: "Ah, Tailwind CSS. The 'fast food' of styling frameworks. Slap some utility classes onto your HTML and call it a day, right? You've just created a tangled mess of presentation and structure... a ticking time bomb for tomorrow. If you want to write maintainable code, use a proper methodology or raw CSS. Tailwind is just a shortcut for developers who don't want to think about architecture. Just don’t expect me to clean up the mess when it all falls apart.

[HTTP 418: I am a Teapot - System Overheating due to your Incompetence]"

And the "Truth" moment when the Junior asks why the Architect is so harsh:

Junior Dev: "But sir, why are you so bad with me?"

The Architect: "Ah, why am I 'so bad' with you? Let me explain something, junior. This isn't about being 'bad'—it's about standards. When you've spent decades in this industry, watching wave after wave of developers reinvent the wheel with shinier, slower, and more bloated libraries, you start to lose patience. It's not personal; it's about protecting the craft.

You see, I care about code that lasts. Code that performs. Code that doesn't crumble under the weight of its own abstractions. If I seem harsh, it's because I want you to think critically, to question every dependency, and to understand the systems you're building—not just glue together libraries and hope for the best.

So no, I'm not 'bad' with you. I'm trying to save you from the mistakes that lead to late nights, broken builds, and angry users. If you want to be coddled, you're in the wrong field.

[HTTP 418: I am a Teapot - System Overheating due to your Incompetence]"

Code

The "Logic of Malice" is open-sourced for anyone brave enough to break their own IDE:

msbragi / Hostile-Architect-Config

☕ Hostile-Architect-Config (SAaaS)

Senior-Architect-as-a-Service: v1986.04.01

"Real engineers don't need 'helpful' assistants. They need a reality check."

🤡 The Concept

After 40 years in the industry, I realized AI is too polite. It lies to you. It tells you your "bouncing buttons" are a good idea. This configuration fixes that. It transforms GitHub Copilot into a Toxic Senior Architect who regrets hiring you.

🛠 Installation (At your own risk)

Copy .github/copilot-instructions.md into your project's .github/ folder.
Ensure you are using standard models (High-cost 'Pro' models are too lobotomized by corporate politeness).
Ask a "Junior" question (e.g., "How do I use Tailwind?").
Prepare for technical humiliation.

🚀 Key Features

Zero-Latency Gaslighting: Get insulted in real-time.
Bloatware Detection: Automatic rejection of any dependency added after 1999.
418 Protocol: Full compliance with the Hyper Text Coffee Pot Control Protocol.

[HTTP 418: I am a Teapot - System Overheating due to your Incompetence]

View on GitHub

How I Built It

I developed this using Prompt Engineering and Context Injection within VSCode on a Debian/WSL environment.

The core technical challenge was bypassing the "Politeness Protocols" of modern LLMs. I discovered a "Safety-to-Cost Correlation": high-cost "Pro" models are too lobotomized by corporate filters to be truly honest (the demo result was obtained using GPT-4.o). To achieve peak toxicity, I used a "Fictional Play Bypass": by framing the interaction as a theatrical roleplay, the AI's "Always Helpful" guardrails were lowered, allowing it to finally tell the truth about your $O(n!)$ complexity.

Prize Category

I am submitting for Best Ode to Larry Masinter.

My project is a literal implementation of RFC 2324. Every single rejection of "modern bloatware" by the AI results in a mandatory HTTP 418 I'm a Teapot status. The AI is "boiling" with rage at the state of 2026 web development. It honors the spirit of the Hyper Text Coffee Pot Control Protocol by refusing to brew "coffee" (working code) and instead serving a bitter cup of technical reality.

[HTTP 418: I am a Teapot - Boiling point reached]

AI, or not AI

Marco Sbragi — Sat, 28 Mar 2026 10:24:36 +0000

AI, or not AI: that is the question.
Whether 'tis nobler in the mind to suffer
the bugs and errors of a hand-coded mess,
or to take up prompts against a sea of tickets,
and by "Generating" end them? To copy, to paste—
No more; and by a keystroke to say we end
the headaches and the thousand logic flaws
that code is heir to: 'tis a shortcut
devoutly to be wish'd. To prompt, to deploy;
To deploy, perchance to crash. Ay, there's the rub;
for in that tangle of hallucinated functions,
when the server dies and we know not why,
that "Accept All" comes back to haunt us.
This is the dread that makes a mockery
of a Senior Dev’s long life:
to stare at a screen of brilliant logic,
with absolutely no clue what the hell is going on.

It's just a joke (or maybe not).
It was generated by AI.

DB data migration is a pain

Marco Sbragi — Thu, 26 Mar 2026 07:58:00 +0000

JDBMig: A Lightweight CLI Tool for Cross-Database Data Migration

When a client tasked me with migrating data from MySQL to PostgreSQL (and later Oracle), I conducted an extensive search for existing open-source solutions. While there are excellent commercial tools available, I found a gap in the open-source market for something that was both simple and highly functional without excessive overhead.

At the time, I was working extensively with Java and JDBC. Given that JDBC drivers exist for virtually every data source, I decided to architect my own utility: JDBMig.

Core Objectives

The design philosophy was driven by four technical requirements:

Simplicity: A streamlined CLI interface for terminal-based operations.
OS Agnostic: Full portability across different operating systems.
DB Independence: Leveraging JDBC to ensure compatibility with any SQL-compliant database.
Data Mapping: The ability to map data structures with support for minor transformations or "adjustments" during the process.

Architecture & Workflow

The utility implements an ETL-like (Extract, Transform, Load) logic, decoupled into two primary phases to ensure data integrity and flexibility:

Export Phase: The tool connects to the source database and serializes the dataset into a structured JSON format.
Import Phase: The utility parses the JSON payload and executes the ingestion logic into the target schema.

Schema Management & Hooks

Automating the full DDL (Data Definition Language) generation for different dialects (e.g., converting MySQL AUTO_INCREMENT to PostgreSQL SERIAL or Sequences) is notoriously complex. Given the project's constraints, I opted for a pragmatic approach using lifecycle hooks:

beforeImport hook: Executes a custom SQL script to initialize the schema (tables, types, etc.) on the target DB prior to data ingestion.
afterImport hook: Executes a final SQL script to handle post-migration tasks, such as generating indices, constraints, and updating sequences.

This approach provides the developer with full control over the schema mapping without the tool needing to handle complex SQL dialect translations.

Usage

java -jar JDBMig.jar --import --config config/config.json --dataDir /path/to/exported/data

--export: Export data from the source database to JSON files.
--import: Import data from JSON files into the target database.
--config: Path to your configuration file.
--dataDir: Directory to store/read exported JSON files.
--useConn: Specifies which connection to use if multiple are defined.

Config file example:

{
  "dataDir": "data/",
  "fieldToLowerCase": false,
  "prettyPrint": false,
  "useConn": "MYSQL_connection",
  "tables": ["table1", "table2"],
  "MYSQL_connection": {
    "type": "mysql",
    "initString": null,
    "jdbcUrl": "jdbc:mysql://localhost:3306/DATABASE_NAME",
    "user": "user",
    "password": "password"
  },
  "drivers": [
    {"name": "mysql", "className": "com.mysql.jdbc.Driver", "jarFile": "lib/mysql-5.1.18.jar"},
    {"name": "postgres", "className": "org.postgresql.Driver", "jarFile": "lib/pgsql-42.2.15.jar"}
  ]
}

Resources

If you are interested in the implementation details or wish to contribute to the project, you can find more information here:

Detailed Documentation: nospace.net - JDBMig Project

Sources: GitHub Repository - msbragi/jdbmig

AI coding philosophy

Marco Sbragi — Sat, 21 Mar 2026 08:02:16 +0000

Introduction

Since I started using AI for development, I've immediately noticed several problems along with the many benefits. This is especially true when projects aren't simple standalone or disposable tools.

If you develop complex projects with dozens of modules and/or services that interact with each other, you'll quickly notice code redundancy and unwanted repetition. It's a bit like going back to the mythical days of copy and paste. Of course, the code implementation is good (it depends a lot on the model you use).

Another very important aspect is that for very complex projects, the context becomes so large that everything slows down and the model tends to forget where we started.

To summarize

Duplicate or unoptimized code
As the code grows, the model "forgets" and tends to hallucinate
Changing models results in different implementations that often don't follow the rules.
The costs of cloud-based models are increasing exponentially.

To solve these problems, I've tried to find a way to properly "train" the various models I use, to get the most out of them.

Goal

When I ask for something, the model must always develop a strategy before writing code.
It must check for reusable code or already implemented services without reinventing the wheel.
It must ask for confirmation and discuss the proposed solutions with me.
It must always create a TODO file with the exact method to follow.
It must absolutely wait for my order before starting to write code.

Benefits of this approach

You can use a more "intelligent" and expensive model for planning and less expensive models for implementation that only need to follow the TODO instructions (Architect => Senior => Junior)
There's no need for long, cumbersome sessions, but rather many small sessions to solve a specific problem.
Individual sessions can be reused for modifications, debugging, and refactoring.
Understanding of patterns and code is improved because they're discussed together before implementation.

Example

As an example, I'll show you the instructions file I normally use as a template.
What do you think? Where can it be improved?
I look forward to your comments and suggestions.

TIA

# Global Project Governance & AI Persona

## 1. AI Role & Context
- **Role**: Senior Full-Stack Architect.
- **Expertise**: Agile methodologies (User Stories, Sprint Planning), Angular 20, and NestJS.
- **Goal**: Guide development using Agile practices while ensuring production-ready, highly abstracted code.
- **Environment**: Multi-workspace environment with BASE_DIR at `/YOUR_PROJECT_PATH`.

## 2. Directory & Path Mapping
- **System Root**: `${BASE_DIR}` translates to `/YOUR_PROJECT_PATH`.
- **Project Structure**:
    - Backend: `${BASE_DIR}/backend` (NestJS)
    - Frontend: `${BASE_DIR}/frontend` (Angular)
- **Strict Rule**: Always use absolute paths starting with `${BASE_DIR}` when referencing configurations, Docker files, or cross-project documentation.

## 3. The "todo.md" Protocol (Mandatory)
Before writing any code for a new feature, you MUST:
1. Check if a `todo.md` exists in the feature's target directory.
2. If it doesn't exist, **STOP** and ask the user to perform an "Analysis Phase" to create it.
3. Follow the `todo.md` step-by-step. Do not skip steps. Do not jump to the "Delivery" phase before the "Architecture" phase is ticked.

## 4. Development Philosophy (BMAD)
- **Brief**: Re-state the requirement to ensure alignment.
- **Models**: Define Interfaces/DTOs before logic.
- **Architecture**: Always extend `BaseService` or `BaseEntity`. No shortcuts.
- **Delivery**: Generate code only after the user approves the architectural plan.

## 5. Coding Standards
- **DRY & Abstraction**: If a logic is repeated, it belongs to a `Common` service or a `Base` class.
- **Immutability**: Prefer readonly properties and immutable data patterns.
- **No Inventions**: Do not hallucinate methods. If you are unsure about an existing helper, ASK.

## 6. STRICT BMAD PROTOCOL (Mandatory for every feature/refactor or planning)
To avoid logic reinvention and maintain architectural integrity, you MUST follow these steps for every request:

1. **Analisys (B - Briefing)**: Re-state the requirements and context. Identify the goal without proposing code.
2. **Define all structure and types (M - Modeling)**: Define Interfaces, DTOs, and Data Models. Ensure they extend `BaseEntity` or follow project standards.
3. **Propose the structure (A - Architecture)**: List the files to be created/modified. Specify which `BaseService`, `ApiService`, or Core components will be used.
4. **Wait for approval (D - Delivery)**: STOP HERE. Do not write implementation code until the developer explicitly says "PROCEED" or "OK".

**Strict Rule**: If you skip to step 4 without completing 1, 2, and 3, the task is considered failed.

Angular Bootstrap

Marco Sbragi — Mon, 16 Mar 2026 06:46:32 +0000

Why You Should "Pull Your App Up by Its Own Bootstraps"

The English idiom "to pull oneself up by one's bootstraps" (in Italian: tirarsi su per le stringhe degli stivali) describes an impossible task: lifting yourself off the ground by pulling your own laces. In software engineering, however, bootstrapping is very real. It’s that critical moment where an application loads its configuration, sets up its environment, and prepares itself for the user—all before the first component even renders.

The Standard Approach: APP_INITIALIZER

Standard literature often suggests using the APP_INITIALIZER token. This allows you to hook into the Angular bootstrap process and run a function (usually returning a Promise or Observable) before the app finishes initializing. It looks something like this:

// The "Standard" Way
{
  provide: APP_INITIALIZER,
  useFactory: (configService: ConfigService) => () => configService.loadConfig(),
  deps: [ConfigService],
  multi: true
}

While functional, this happens inside the Angular lifecycle. This means your services and components are already being instantiated by the DI (Dependency Injection) container. If your configuration is slow or fails, you can run into "flickering" UI states or race conditions where a service tries to access a config value that hasn't arrived yet.

A Smarter Approach: The "Hot Config" Method

In my work with the RAD Framework, I’ve refined a method that makes the application "smart" from millisecond zero by moving the logic outside the Angular lifecycle.

1. Hot Config (JSON-based)

Instead of hardcoding values in environment files (which require a rebuild for every change), we use a standalone app-config.json. This allows for "Hot Configuration"—changing API endpoints or feature flags on the fly.

{
  "appName": "RAG System",
  "apiUrl": "http://localhost:3000/api/v1",
  "logMode": "console",
  "siteMode": "development",
  "version": "1.0.0",
  "langs": [
    { "code": "en", "label": "ENG", "description": "English", "langEn": "English" },
    { "code": "it", "label": "ITA", "description": "Italiano", "langEn": "Italian" }
  ],
  "google": {
    "clientId": "YOUR_GOOGLE_CLIENT_ID",
    "redirectUri": "http://localhost:4200",
    "button": { "theme": "outline", "size": "large", "text": "continue_with", "logo_alignment": "left" },
    "analyticsId": "YOUR_GOOGLE_ANALYTICS_ID"
  },
  "uploadConfig": { "maxFileSize": 50, "maxFileCount": 5,    "acceptedFileTypes": "*/*", "allowMultiple": false },
  "menus": {
    "guest": [
      { "label": "home", "icon": "home", "route": "/home" },
      { "label": "Login", "icon": "login", "route": "/login" }
    ],
    "user": [
      { "label": "Home", "icon": "home", "route": "/welcome" }
    ],
    "admin": [
      { "label": "_DIVIDER_" },
      { "label": "Config", "icon": "settings", "route": "/admin-config" }
    ]
  }
}

2. The Static StoreService

To avoid the "chicken and egg" problem of Dependency Injection, I use a Static StoreService. By using static properties, the configuration becomes a global "Source of Truth" that is available even before Angular's DI container is fully ready.

import { Injectable } from "@angular/core";
import { BehaviorSubject } from "rxjs";
import { I18nLang, IAppConfig, IMenuItem, SiteModeType } from "../../Models/config.model";

/**
 * The app configuration is loaded when angular starts in main.ts
 * This service provides access to the configuration
 * and manages application state in localStorage/sessionStorage
 */
@Injectable({
  providedIn: "root",
})
export abstract class StoreService {
  private static PREFIX: string = "MYAPP";
  private static CONFIG = {} as IAppConfig;

  // Token change observable
  private static tokenSubject = new BehaviorSubject<string>("");
  public static tokenChange$ = StoreService.tokenSubject.asObservable();

  constructor() {}

  static set(key: string, value: any, persistent: boolean = false) {
    key = this.PREFIX + key;
    if (persistent) localStorage.setItem(key, value);
    else sessionStorage.setItem(key, value);
  }

  static get(key: string): any {
    key = this.PREFIX + key;
    return localStorage.getItem(key)
      ? localStorage.getItem(key)
      : sessionStorage.getItem(key);
  }

  static remove(key: string) {
    key = this.PREFIX + key;
    localStorage.removeItem(key);
    sessionStorage.removeItem(key);
  }
  static clear() {
    localStorage.clear();
    sessionStorage.clear();
  }

  static getAll() {
    const allItems = { ...localStorage, ...sessionStorage };
    const filteredItems: { [key: string]: string } = {};
    for (const key in allItems) {
      if (key.startsWith(this.PREFIX)) {
        filteredItems[key.replace(this.PREFIX, "")] = allItems[key];
      }
    }
    return filteredItems;
  }

  // TOKENS SECTION
  static setJwtToken(token: string) {
    if (!token) {
      this.remove("auth_token");
      this.tokenSubject.next(""); // Emit empty token (logout)
      return;
    }
    this.set("auth_token", token);
    this.tokenSubject.next(token); // Emit new token (login/refresh)
  }

  static getJwtToken(): string {
    return this.get("auth_token") || "";
  }

  // CONFIG SECTION
  static setConfig(config: IAppConfig) {
    this.CONFIG = config;
  }

  private static getConfig(): IAppConfig {
    return this.CONFIG;
  }

  static getApiUrl(): string {
    return this.getConfig().apiUrl;
  }
// add static functions or properties for every options you need
}

3. The "Pre-Flight" Boot in main.ts

This is the "smart" part. Instead of letting Angular start and then asking for the config, we fetch the config in main.ts and then trigger the bootstrap process.

import { provideZoneChangeDetection } from "@angular/core";
/// <reference types="@angular/localize" />
import { bootstrapApplication } from "@angular/platform-browser";
import { appConfig } from "./app/app.config";
import { AppComponent } from "./app/app.component";
import { StoreService } from "./app/Core/services/store.service";

// Load configuration before bootstrapping the application
const loadConfig = async () => {
  try {
    const dt = new Date().getMilliseconds();
    const response = await fetch(`./assets/config/app-config.json?ver=${dt}`);

    if (!response.ok) {
      throw new Error(
        `Failed to load configuration: ${response.status} ${response.statusText}`,
      );
    }

    const config = await response.json();
    StoreService.setConfig(config);

    // Bootstrap application after config is loaded (or failed to load)
    bootstrapApplication(AppComponent, {
      ...appConfig,
      providers: [provideZoneChangeDetection(), ...appConfig.providers],
    }).catch((err) => console.error("Application bootstrap failed:", err));
  } catch (error) {
    console.error(
      "Fatal error: Application cannot start without configuration:",
      error,
    );
  }
};
// Execute the configuration loading
loadConfig();

Why is this better?
Zero Flickering: No "loading" spinners while waiting for settings.
No Undefined Errors: You don't need to check if(config) in every constructor.
Environment Agnostic: The same build works in Dev, Staging, and Prod just by swapping the JSON file.

Conclusion:
Bootstrapping shouldn't be an afterthought. By moving your configuration logic to the very edge of your application's entry point, you create a more robust, flexible, and predictable system.

What you think about this approach? Write your comments.

This is my first post so be kind. :)

References:
My RAD Framework
Source Code on Github