DEV Community: Dmitry Amelchenko

Schopenhauer in the Standup: 7 Rules to Neutralize a Toxic Boss

Dmitry Amelchenko — Thu, 24 Sep 2026 18:37:37 +0000

You try to argue logically.

You try to expose their inconsistencies.

You lose.

I have navigated environments orchestrated by toxic leadership. When you find yourself convening with key engineers before a status call just to align on a narrative and build a defensive perimeter, you are no longer doing engineering.

You are managing a hostile vector.

Every time I tried to use logic or point out the toxicity in those environments, I was outmaneuvered.

The philosopher Arthur Schopenhauer provided the answer long before modern management theory:

Will defeats reason where reason plays by the rules of the will.

Your losses are not a character flaw. They are the result of operating under the wrong rule set.

A toxic manager is rarely a mastermind executing a grand strategy. They are simply running a proven behavioral script.

They seek reactions, not logic.

To orchestrate your own environment and neutralize bad actors, you must deprecate old habits and adopt a new operational framework.

The Threat Model: Common Archetypes

Before applying the rules, recognize the vectors of attack.

Toxic leaders typically fall into one of three categories:

Archetype	Execution Vector	Objective
The Caregiver	Extracts vulnerabilities via simulated empathy — "Are you feeling overwhelmed?"	Stores your doubts to weaponize them in future performance evaluations.
The Victim	Deploys silence and suffering to engineer guilt when you set a boundary.	Forces you to offer unprompted concessions to resolve the awkwardness.
The Inquisitor	Disguises accusations as endless "detail refinement" on your backlog.	Forces you into a perpetual defensive posture.

The objective isn't to fight every attack.

It is to understand the system generating them.

Rule 1: Observe, But Remain Silent

The Scenario: Your director pitches your architectural solution in a meeting as their own.

The Flaw: You immediately object.

They smile, pivot gracefully:

"Of course, we brainstormed this together."

And you are left looking petty and defensive.

Silence is not consent; it is data collection.

Exposing a manipulator too early forces them to change tactics, closing off your visibility into their operations.

Observe the pattern.

Let them commit to the board.

Whoever reveals their cards first, loses.

Rule 2: Your Vulnerability Is Their Tooling

The Scenario: You vent to a toxic manager about project fatigue.

Two weeks later, they reassign a high-leverage epic to someone else, citing your "need for a break."

Openness is a personality trait.

Trust is an earned credential.

Do not confuse the two.

Be a lake, not a puddle.

A puddle is transparent to the bottom.

A lake obscures its depth.

When an unverified leader asks how you are managing a crisis, the optimal response is sterile and precise:

"Operating nominally."

Establish a perimeter.

Rule 3: Starve the Engine

The Scenario: A passive-aggressive comment in a code review designed to provoke you.

Toxic leaders operate via emotional feedback loops.

Without your reaction, they lose their telemetry.

They do not know if their strike landed.

When provoked, institute a hard three-second latency before responding.

Do not justify.

Do not counter-attack.

Control the pause, and you control the narrative.

Rule 4: Weaponize Time

The Scenario: You attempt to warn cross-functional teams about your manager, but you end up looking like the source of the friction.

A person driven purely by the will to dominate lacks brakes.

Eventually, they will overplay their hand, breach protocol, or alienate a critical stakeholder.

You do not need to act as the whistleblower.

Reputation is an accumulated metric.

Step aside and let time execute the exposure.

Truth requires no defense attorney.

Rule 5: Deprecate Access

The Scenario: You confront a toxic boss with a grand declaration that you will no longer tolerate their behavior.

A grand exit is still a reaction.

It is a massive data payload you just handed to the adversary.

The correct protocol is silent deprecation.

You cannot always quit immediately, but you can limit bandwidth.

Increase your response latency.
Provide concise answers.
Remain entirely polite, yet entirely unavailable.
Starve them of your reactions.

You are not escalating.

You are reducing the attack surface.

Rule 6: Audit Your Own Telemetry

We are blind to our own manipulative vectors because we classify them as self-defense or radical honesty.

Before you launch an accusation starting with:

"You always..."

in a 1-on-1, run a diagnostic.

Ask yourself:

Am I stating an objective truth, or am I engineering a specific emotional reaction?

You cannot defend against manipulation effectively if you are unknowingly utilizing the same scripts.

The system has to be audited from both sides.

Rule 7: The Master Key — Become Unreadable

The previous six rules are tactics.

Rule 7 is the baseline state.

Toxic managers navigate using a map of your triggers.

They know when you will explode.

They know when you will yield.

They know when you will over-explain.

To neutralize them permanently, you must obsolete their map.

Break your predictable rhythms.

Speak calmly where you used to shout.

Remain silent where you used to argue.

When they attempt to corner you into justifying a boundary, utilize the ultimate unassailable response:

"I have decided to take this route."

No justification.

No appeal to external logic.

Just the decision.

When you become unreadable, you become unusable.

Stop Asking Which Agentic Coding Methodology to Use

Dmitry Amelchenko — Thu, 17 Sep 2026 22:47:26 +0000

The prevailing question in AI-assisted development—"Which methodology should I use?"—is fundamentally flawed.

Superpowers, BMAD, Compound Engineering, OpenSpec, SpecKit, GSD, Ralph. The ecosystem is flooded with systems claiming to run your AI agents. The thesis here is simple: There is no universal winner. Each framework orchestrates a distinct layer of agentic development.

Stop searching for a silver bullet. Build a stack.

1. Execution vs. Intent: Superpowers vs. BMAD

The most critical comparison dictates your starting vector.

Superpowers (Pure Engineering): Operates as a demanding senior engineer. It enforces design, planning, strict test-driven development, and rigorous review. Default to this for daily coding, solo development, and pure implementation tasks.
BMAD (Product Intent): Operates as a complete product organization—analysts, PMs, architects, and readiness gates. Deploy this when product intent remains uncertain or stakeholder complexity is high.

2. Context Retention: OpenSpec vs. SpecKit

Both frameworks combat context drift by anchoring requirements in versioned files.

OpenSpec: Optimized for change and brownfield execution. It is the durable change contract for everyday work on real, existing production codebases.
SpecKit: Optimized for governance. It dictates a constitution, traceability, and audit trails. Reserve for heavily regulated environments.

3. The Autonomy Layer: GSD vs. Ralph

Tread carefully here.

GSD: Designed to safeguard structured projects across context windows via requirements, roadmaps, and verification. (Note: The original repository was archived in June 2026. Use only for long unattended runs once a stable fork emerges.)
Ralph: A continuous loop (pick an item, implement a test, repeat). Warning: Without impenetrable tests, Ralph will happily burn tokens iterating on bad decisions.

4. The Meta-Layer: Compound Engineering

Compound Engineering shifts the focus from "How do we build this correctly?" to "How does this work make the next task frictionless?" Every feature delivery concludes by recording lessons for agents to reuse. If your role leans closer to founder than individual contributor, this is your core methodology.

The Winning Synthesis

Do not install everything. Orchestrate the right sequence based on the situation:

BMAD to define requirements when product intent is ambiguous.
OpenSpec to establish a durable change contract in the codebase.
Superpowers to drive implementation and rigorous verification.
Compound Engineering to extract and record lessons post-delivery.

I personally would start with BMAD as a higher level harness, and combine it with OpenSpec to drive quality of implementation to the desired level.

Stop Optimizing for Output: Why Software Engineering is a Discovery Problem

Dmitry Amelchenko — Thu, 17 Sep 2026 14:59:34 +0000

Most engineering organizations misdiagnose software delivery as a production problem. They treat building software like operating a factory: crank the handle faster, and more features will drop off the conveyor belt.

This intuition is fundamentally flawed. In software, copying code is free. Everything you spend time building is unprecedented. Therefore, engineering is not a production process; it is an exercise in continuous discovery.

When you push a team for raw speed, you inevitably throttle their velocity. Here is the data-backed thesis for why traditional management levers fail, and how optimizing for learning naturally generates speed as a byproduct.

The Factory Fallacy

When timelines slip, leadership invariably reaches for three failed levers:

Adding Personnel: Fred Brooks established this decades ago in The Mythical Man-Month: adding manpower to a late software project makes it later.
Adding Pressure: Mandating urgency forces engineers to drop tests and bypass refactoring. You might buy a week of output today, but you finance it with months of debugging tomorrow. Software delivery is a marathon; cutting corners introduces debt that permanently impairs throughput.
Adding Process Gates: Imposing checkpoints and Change Approval Boards (CABs) creates the illusion of control. In reality, it merely introduces queues. Data from the State of DevOps Report (documented in Accelerate) is unambiguous: heavy review gates are empirically worse than having no change approval process at all. You do not gain control by slowing down.

Factory Heuristic (Output)	Discovery Heuristic (Learning)
Maximize resource utilization	Minimize feedback latency
Enforce process gates and CABs	Shift control to automated pipelines
Large, quarterly batched releases	Continuous, small-step deployments
Measure velocity and lines of code	Measure time from idea to validation

The Vector: Optimize for Learning

If your discipline is discovery, your goal is to accelerate your speed of learning. You must ascertain quickly if you are on the right track and correct course if you are not. When you optimize for learning, quality rises, unplanned rework plummets, and speed materializes naturally.

To execute this transition, implement these three operational standards:

1. Work Experimentally

Treat every meaningful change as a hypothesis. Frame the work as: "I hypothesize this code will produce X result. Let us deploy and measure it." The scientific method is the most powerful engine for navigating uncertainty. Apply it rigorously to your architecture and product decisions.

2. Compress Feedback Cycles

Your rate of learning is capped by how fast you can validate a hypothesis. If a flawed architectural design takes three months to expose itself, you only learn four times a year. If it takes twenty minutes, you can learn twenty times a day. Automated testing and continuous delivery pipelines exist for this exact purpose: rapid intelligence gathering.

3. Isolate the Variables

You can only extract signal from an experiment if you know what caused the outcome. A massive quarterly release is an experiment corrupted by a hundred uncontrolled variables. If it fails, you have bought an unplanned mystery. Deploying in small, iterative steps isolates variables, ensuring immediate clarity on what broke and why.

Realigning Metrics

The metrics you track dictate the behavior of your system.

Stop measuring utilization, sprint velocity, or lines of code. These track busyness, not progress. Instead, measure the latency of validation: How long does it take for an idea to reach the user, and how quickly can we confirm if it works?

Speed is not a command you can issue to a tired engineering squad. It is the natural byproduct of a system calibrated for rigorous, high-frequency learning.

Stop Fixing Engineers. Start Fixing the Environment.

Dmitry Amelchenko — Thu, 03 Sep 2026 18:15:33 +0000

Fear is a systemic failure masquerading as operational rigor. When you deliver unfiltered criticism, you are not engaging an engineer's logic. You are triggering a mammalian threat response.

Poorly calibrated feedback registers in the brain as a physical attack, causing the recipient to immediately shift from problem-solving to self-preservation. To orchestrate a high-functioning engineering culture, leaders must bypass the amygdala and communicate directly with the prefrontal cortex.

Here is the operational thesis on why threat-based environments collapse, how organizations institutionalize this failure, and how to calibrate your operational framework for durable execution.

The Cognitive Cost of Survival Mode

The human brain cannot optimize complex systems while defending itself.

Under the stress of looming delivery cycles and technical debt, a manager's brain defaults to threat detection. You notice only the flaws, the broken builds, and the missed estimates. When you manage exclusively through error-correction, the work environment becomes a threat vector.

The engineer's prefrontal cortex, the center for complex logic and system design, cedes control to the amygdala. Cognitive bandwidth narrows. The engineer stops optimizing the product for the end-user and starts optimizing their output for personal safety. They no longer build to solve the problem; they build to avoid blame.

The Death of the Risk Vector

Innovation requires a strict tolerance for calculated failure. Proposing an asymmetrical architecture, testing a new operational framework, or automating a legacy process all require taking a risk.

In a fear-driven culture, the risk-reward calculus is entirely broken. Engineers default to the safest, most historically mediocre solutions. Fear extracts a singular, high-speed result: compliance. The subsequent decay is catastrophic.

Execution Metric	Fear-Driven Compliance	High-Agency Execution
Optimization Vector	Evading punishment	Solving the core problem
System Architecture	Defensive, derivative, brittle	Elegant, modular, resilient
Communication	Conceals blockers and debt	Surfaces risks immediately
End State	Systemic stagnation	Continuous iteration

Orchestrating a High-Trust, Low-Fear Culture

To prevent the fight-or-flight response at the interpersonal level, you must structure your feedback to signal safety while demanding excellence.

Establish the Positive Baseline: Counteract the brain's expectation of attacks by establishing a persistent baseline of recognizing correct execution. Highlight elegant system design and proactive risk mitigation.
Decouple the Artifact from the Architect: Never attach a failure to an individual's identity. Say, "This implementation leaves edge cases exposed," rather than "You build brittle systems." The artifact can be refactored; a damaged professional relationship is much harder to repair.
Deploy the Psychological Safety Anchor: Before delivering hard truths, state: "I am sharing this observation because I hold this team to exacting standards, and I have absolute certainty you can execute at this level." This alters the cognitive processing of the recipient from threat detection to validation.
Control the Timing: Unsolicited feedback acts as a jump scare to the nervous system. Ask for permission to initiate the critique (e.g., "Are you ready to review the architecture on this initiative, or should we convene tomorrow morning?").

Institutionalizing Fear: The Performance Management Trap

Neurological threat responses do not exist solely in one-on-one meetings; modern organizations institutionalize them at scale.

To survive competitive pressure, companies deploy rigid "performance management" frameworks that mandate "developing the gaps." This structurally reinforces a culture of fear. By constantly focusing an engineer on their weaknesses, the organization perpetually triggers the exact neurological threat response that kills cognitive bandwidth.

Standardized performance management assumes uniform motivation and enforces a single, rigid baseline that everyone must meet. This approach breeds mediocrity. It forces exceptional, asymmetrical talent to optimize for arbitrary HR metrics rather than extracting their unique cognitive advantages.

True leadership rejects this standardization. It requires the harder, higher-leverage work of managing cognitive diversity. You must identify distinct motivators, extract the absolute best from varied talent profiles, and direct those vectors toward the organization's objectives.

Conclusion: The Macro Climate and The Final Delta

Understanding the neuroscience of feedback is critical because the current macroeconomic environment is actively working against you.

We are operating in an era of unprecedented ambiguity. The job market is contracting. The vector of artificial intelligence introduces a persistent, systemic anxiety; the industry anticipates paradigm shifts of biblical proportions, though the exact architecture of this future remains undefined.

Confronted with this ambient uncertainty, leadership defaults to the path of least resistance: weaponizing job insecurity. They rely on fear as a motivator because it is easy. Employees, prioritizing survival, stop speaking up, stop challenging assumptions, and mask structural risks. A vicious cycle takes root. Silence replaces candor, and compliance replaces innovation.

Neurological data establishes a clear thesis: positive motivation engineers durable, high-leverage execution, while fear extracts temporary compliance and guarantees long-term systemic decay.

The companies that break this vicious cycle will capture the market. By actively refusing to institutionalize fear—and instead orchestrating environments where cognitive diversity and intellectual rigor supersede macroeconomic panic—they will secure the high-agency talent required to win.

The Death of Story Points: Engineering Metrics in the Agentic Era

Dmitry Amelchenko — Thu, 03 Sep 2026 16:07:55 +0000

Traditional Scrum optimizes for human cognitive load. Agentic development shatters this constraint.

The two-week sprint, the Fibonacci estimation sequence, and bottom-up story pointing are artifacts of a legacy delivery model. When AI agents write the code, the correlation between task complexity and execution effort flattens. Adding a simple endpoint or executing a cross-service architectural change yield vastly different human effort profiles, but near-identical agentic execution timelines.

The thesis is absolute: engineering teams must shift from measuring human effort to managing system throughput. Here is the operational framework for managing engineering metrics in the agentic era.

The Paradigm Shift

The fundamental unit of planning is no longer the user story; it is the business objective.

Vector	Legacy Scrum	Agentic Flow
Unit of Work	User Story	Business Objective
Estimation	Story Points (Fibonacci)	Statistical Forecasting
Cadence	2-Week Sprints	Continuous Flow
Code Integration	Small, frequent commits	End-to-end functional commits
Testing Goal	Line coverage	100% Behavioral coverage
Management Focus	Velocity & Burndown	Governance & Guardrails

1. Sunsetting Story Points for Flow Metrics

Story points estimate human effort and uncertainty. When an AI agent decomposes a feature into independently deliverable tasks, debating whether a story is five or eight points adds zero value.

Velocity metrics must transition to objective completion rates and cycle time. The operational question shifts from "How many points can we burn this sprint?" to "How many independent, testable tasks can the system clear per week?" Planning becomes an exercise in flow management and empirical consistency, not subjective guessing.

2. Spec-Driven Orchestration

Autonomous execution requires an anchor. Spec-driven development frameworks (like OpenSpec) replace the traditional product backlog.

The workflow is linear:

Define the business objective.
AI generates the architectural spec.
AI decomposes the spec into small, executable tasks.
AI validates that each task is independently testable.

The spec operates as the single source of truth and a living artifact. Management orchestrates the objectives and defines the guardrails; the agents handle the tactical breakdown.

3. The Cohesive Commit

Agentic coding alters the natural unit of work. Developers are accustomed to small, iterative commits to manage risk and simplify code reviews. Agents, however, can implement an entire slice of functionality in a single pass.

Commits will increase in size. This is not messy bloat; it is the delivery of a single, coherent capability. Consequently, review practices must evolve. Instead of scanning lines of code, engineers will review AI-generated summaries tied directly back to the initial spec. Code is merged when the objective is validated by automated evidence, replacing the "commit early, commit often" heuristic with "commit verifiable value."

4. 100% Behavioral Coverage

Chasing line coverage is a vanity metric. In an autonomous delivery loop, agents write the code, generate the tests (unit, integration, end-to-end), execute them, and fix failures prior to human review.

Testing transforms from a separate, downstream phase into the core execution loop. The standard becomes 100% behavioral coverage—ensuring all critical user journeys execute successfully. Every bug naturally converts into an automated regression test, mapped back to the origin spec.

5. The End of the Two-Week Sprint

Fixed iterations exist to protect humans from scope creep and establish a predictable rhythm. Agents do not require psychological safety from scope changes; they require accurate parameters.

Because agents adapt instantly, teams can operate in a state of continuous flow rather than artificial two-week batching. Predictability and forecasting do not disappear, but they transition to statistical modeling. Instead of guessing story sizes, engineering leaders utilize historical outcome data to state: "There is an 80% probability this objective ships in four weeks."

Business reviews, retrospectives, and roadmap updates remain necessary, but they are entirely decoupled from the development lifecycle.

The Manager's Delta

The engineering manager's role is transitioning from assigning work to defining goals, maintaining system guardrails, and verifying outcomes. The agile dashboard is no longer a burndown chart; it is an operations console.

The organizations that win the next decade will be the ones that stop treating AI as a faster typist, and start architecting their operations around autonomous flow.

Scaling Code Reviews in the Age of Generative AI

Dmitry Amelchenko — Fri, 21 Aug 2026 22:28:56 +0000

The thesis is simple: Generative AI solves code generation, but it breaks code review.

As developers generate 10x more code, the bottleneck shifts downstream. Senior engineers are burning out reviewing automated output. The traditional human-in-the-loop PR process is unsustainable.

Florian Buetow, AI engineer at Xebia, recently outlined the solution: stop manually reviewing AI-generated code. Instead, orchestrate an environment where agents receive instantaneous, programmatic feedback.

Here is the operational framework to scale code validation using guardrails.

The Scaling Vectors

Organizations currently address the AI review bottleneck across two primary vectors:

Vector	Methodology	Leverage
Horizontal	Automating existing PR pipelines (e.g., AI reviewing a GitHub PR).	Marginal. Speeds up legacy processes but retains the foundational human bottleneck.
Vertical	Engineering local environments with autonomous agent feedback loops.	High. Eliminates manual review via preemptive, programmatic guardrails.

The vertical approach is the necessary evolution. You must engineer the environment in which the agent operates to eliminate the human middleman.

Architecting Guardrails

Guardrails are automated constraints that enforce technical integrity before a human ever sees the code. By bringing feedback directly to the developer's machine—rather than waiting for a pull request—you force the AI to self-correct.

Implement these three structural constraints:

Static Analysis & Semgrep: Do not rely on LLM alignment to write clean code. Enforce it. Write Semgrep rules to ban specific anti-patterns. If your standard dictates no default mutable values in Python methods, codify it. When the agent violates the rule, the script fails and feeds the natural-language error back to the agent for an immediate retry.
Architectural Unit Tests: AI tools will frequently hallucinate bizarre dependencies to force a solution to work. Implement architectural tests that analyze module dependencies (e.g., ensuring the UI layer cannot directly access the database).
Automated Stop Hooks: Utilize CLI tools and AI harnesses that support stop hooks. When the agent completes a generation cycle, the harness triggers a shell script to run your test suite and static checks. If failures occur, the harness feeds the exact errors back into the prompt, forcing a "route loop" where the AI iterates until tests pass.

The TDD Renaissance

Specification-Driven Development (SDD) and Test-Driven Development (TDD) dictate the efficacy of your AI output.

AI models struggle with ambiguity. If you draft a loose specification, the model will deviate from your intention within five minutes. The hard work of software engineering shifts entirely to the beginning of the pipeline. You must thoroughly define the architecture and write the behavioral tests upfront.

Once behavioral tests are in place, the AI can iterate rapidly. It writes the code, the tests fail, the harness provides feedback, and the model corrects itself. The code is generated precisely to specification without manual intervention.

Execution Strategy

To transition your team to a vertical AI scaling model, execute these steps:

Data-Mine Your Session Logs: Audit your .claude or local AI chat logs. Identify the repetitive corrections you make to the model's output. Translate those specific corrections into Semgrep rules or static checks.
Isolate the Harness from the Model: The harness (Claude Code, Codex, Aider) dictates your leverage more than the underlying LLM. Models are rapidly commoditizing; harnesses provide the memory layer, tool execution, and feedback loops. Do not lock your organization into a single toolset. Experiment continuously to find the optimal environment for your specific stack.
Elevate to Product Execution: Recognize that removing the code review bottleneck changes the developer's role. Engineers must now operate at the product level—focusing heavily on architecture, customer requirements, and system design—while agents execute the syntax.

The traditional code review is an artifact of the pre-AI era. Build the guardrails, orchestrate the automated feedback loop, and reclaim your engineering bandwidth.

Finding the Sweet Spot for Local LLMs: Qwen Coder & Llama.cpp

Dmitry Amelchenko — Mon, 08 Jun 2026 23:55:05 +0000

The Shift to Local Models

Running local LLMs for software development is getting increasingly popular, especially as commercial providers continue to charge by the token. It finally makes economic sense to run models locally to avoid cost overruns.

I have personally spent a lot of time trying to figure out the best configuration. After experimenting with LM Studio, Ollama, and RooCode, I finally found a setup that consistently works for my workflow: Llama.cpp running Qwen Coder via GitHub Copilot with OpenSpec SSD.

Here is a breakdown of my experience and the exact configuration I use.

The Hardware Reality

To get decent results locally, hardware is the primary constraint. I was fortunate enough to recently purchase the latest MacBook Pro M5 with 128GB of RAM.

Initially, I had some buyer's remorse spending that much on a machine, but it has proven essential. I tend to consume a lot of memory — I regularly run VS Code with multiple workspaces, React Native servers and simulators, a mail client, and around 100 Google Chrome tabs simultaneously.

Even with all of this running alongside the local LLM, my system rarely swaps more than 2GB of memory to the disk. Performance stays smooth, and I avoid the severe degradation that happens when swap usage climbs higher.

The Software Stack

While wrappers like Ollama and LM Studio are convenient, I found the best results come from running Llama.cpp directly.

Installation on macOS is straightforward:

brew install llama.cpp

For the models, Hugging Face is the best source.
To use Llama.cpp models from Hugging Face, you need files in the GGUF format. These models are optimized for local inference on both CPUs and GPUs. https://huggingface.co/docs/hub/en/gguf-llamacpp

My model of choice is Qwen3-Coder-Next-GGUF:UD-Q8_K_XL. Another good one is Qwen3.6-35B-A3B-MTP-GGUF:UD-Q8_K_XL.
Let's brake it down what the name elements stand for:

35B: The model has 35 billion total parameters (the size of its "brain").
A3B: It is a "Sparse Mixture-of-Experts" (MoE) architecture. Instead of using all 35B parameters to answer a question, it dynamically activates only 3 billion "active" parameters per token. This delivers massive speed and efficiency without sacrificing intelligence.
MTP: Multi-Token Prediction. The model is trained to predict multiple tokens (words) at once rather than one-by-one, significantly accelerating generation speeds during inference.
GGUF: Generalized GPU-CPU Fusion. A popular file format used for running AI models locally. It allows you to split the model between your graphics card (VRAM) and your computer's regular system memory (RAM).
UD: A specialized quantization method developed by the Unsloth team designed to preserve maximum intelligence at lower file sizes.
Q8_K_XL: The specific level of quantization (compression).Q8 means it is an 8-bit quantization.It aggressively reduces file size compared to the original, while still maintaining extremely high quality (nearly matching the original uncompressed model).XL indicates a specific weighting adjustment meant for Unsloth's extra-large context-size handling.

The Quantization Goldilocks Zone

Quantization makes a massive difference in performance and stability. I went through quite a bit of trial and error to find the right balance:

4-bit: I tried this first, but it lacked precision. For complex coding tasks, the model would frequently get stuck in infinite loops (pretty much always for me).
16-bit: I attempted to run the 32B parameter model at 16-bit, but it was simply too large for my hardware to handle.
8-bit: This was the sweet spot. It fits within my memory constraints while executing complex reasoning flawlessly. To download and run the server with the given model on your local environment, run:

llama-server -hf unsloth/Qwen3-Coder-Next-GGUF:UD-Q8_K_XL

When you installed llama.cpp via brew, you can run the above command, which will take a while the first time -- depending on your internet speed, up to an hour or so. Running it again will access the cached version, so it will take only a few seconds to load into the memory and start. You can check if it's running by going to http://localhost:8080/

My Copilot Configuration

If you run a model locally, GitHub Copilot does not charge you for tokens (not yet, anyways), meaning you can stay on the standard plan while running complex code analysis.

In VSCode, copilot chat window, click on the model picker and select a gear next to the "Other Models":

Then select "add models" and "custom endpoint",
type "llama.cpp" for group name, hit "enter" for the API key, and "Enter" again for the API type (the value does not really matter).

After you save the initial config, you should be able to see the llama.cpp in the list of models when you click the gear next to the "Other Models" selection again. Then, click a gear next to "llama.cpp" and open the config as JSON. To save you time -- here is the final JSON I have, you may want to copy and paste it in your config:

    {
        "name": "llama.cpp",
        "vendor": "customendpoint",
        "apiKey": "${input:chat.lm.secret.6d112807}",
        "models": [
            {
                "id": "Local Llama, qwen-Q8_0",
                "name": "qwen-Q8_0",
                "url": "http://localhost:8080",
                "toolCalling": true,
                "vision": false,
                "reasoning": true,
                "thinking": true,
                "maxInputTokens": 131072,
                "maxOutputTokens": 131072,
                "contextWindowSize": 262144,
                "parameters": {
                    "top_k": 20,
                    "top_p": 0.95,
                    "min_p": 0.0,
                    "repetition_penalty": 1.0,
                    "temperature": 0.6,
                    "max_new_tokens": 1500,
                    "num_ctx": 16384,
                    "num_gpu": -1,
                    "num_thread": 12
                }
            }
        ]
    },

Let's go over some of these parameters:

Endpoint: localhost:8080 (or your specific local port)
Tool Calling: true
Vision: false (I tried enabling this, but Qwen kept returning errors that vision is unsupported)
Reasoning & Thinking: true
Context Window: 256k total (128k max input / 128k max output)
Temperature: 0.6
GPU Offload (num_gpu): -1 (Uses all available GPUs)
Threads: 12 (Maps to the performance cores on my Mac)

A Note on Reasoning and Temperature

Some documentation suggests turning "Reasoning" and "Thinking" off for coding tasks, but my experiments proved otherwise. I use Spec-Driven Development with OpenSpec, which requires heavy analysis and planning before any code is written. Leaving reasoning set to true yielded significantly better results for this workflow.

Additionally, keep your temperature at 0.6 rather than strict 0.0. A purely deterministic 0.0 temperature can cause the model to get permanently stuck if it hits a logic loop. That bump gives it just enough variance to diverge and find a solution.

Few words on agentic coding

No matter the model you use -- Vibe coding, as we know it, is always going to suffer from the Architecture Entropy. Read more on this topic here in this post The End of Vibe Coding
This is why Spec-Driven Development (SDD) is a must.
Also, on the topic of why it's essential to keep your Architecture "as simple as possible, but not simpler", read the following post Why GenAI Billing Makes Minimalist Architecture Mandatory

The Payoff

The results I am getting from this local Qwen setup are remarkably close to top-tier remote models like Claude Opus 4.6 .

Between the high-quality output and the fact that I am saving a couple of hundred dollars a month on API costs, the heavy upfront investment in the MacBook Pro will pay for itself within a couple of years. If you have the hardware, I highly recommend giving this stack a try.

The Death of the Pull Request: Why Manual Code Reviews are Obsolete

Dmitry Amelchenko — Sat, 02 May 2026 01:01:35 +0000

Pull requests aren’t the problem. Pull request reviews are.

For years, PR reviews have been treated as a sacred checkpoint in software delivery. A necessary gate. A quality filter. A learning tool.

But in the age of GenAI, spec-driven development, and real-time collaboration, that assumption no longer holds.

Let’s be direct:

Manual PR reviews are becoming the slowest, least valuable, and most artificial step in the entire delivery pipeline.

PRs: What Problem Were They Solving?

Conceptually, pull requests were created to:

Share knowledge across the team
Enforce coding standards
Catch bugs before merge
Align contributors on architecture
Provide a safety net for junior or external contributors

All of that made sense in a world where:

Code was written entirely by humans
Context was fragmented
Validation happened late
Tooling was limited

That world has changed.

The Core Issue: Late, Low-Context Validation

PR reviews happen:

After the code is written
Without full implementation context
Detached from the original design decisions

And most importantly:

They validate the artifact (code) instead of the intent (spec)

By the time a PR is opened:

The feature is already implemented
The tests are already written
The behavior is already observable

So what’s left?

👉 A human scanning code that already works.

What Actually Replaces PR Reviews?

PR reviews don’t disappear randomly — they become unnecessary when validation shifts earlier and deeper in the process.

1. Pair / Trio Programming + GenAI

Instead of:

“I’ll code it → you review it later”

You move to:

“We design, implement, and validate together — with GenAI”

This is not new — it’s extreme programming, on steroids:

Shared context from the start
Immediate feedback while building
Continuous correction instead of delayed critique

If two engineers built the feature together:

They already challenged decisions
They already aligned on patterns
They already saw every line evolve

👉 There’s nothing meaningful left to “review” later.

2. Spec-Driven Development (SDD)

We’re no longer optimizing for code correctness.

We’re optimizing for problem definition.

With SDD:

Specs define behavior, constraints, and edge cases
GenAI generates and enforces implementation
Standards are applied automatically

This flips the model:

From “Is this code correct?”

To “Did we define the right thing correctly?”

That’s where real engineering value lives.

3. Automation as the Primary Safety Net

Manual review is a weak signal compared to:

Unit tests
Integration tests
End-to-end scenarios
Generated edge cases
Runtime observation

Instead of reading code, you:

Execute it
Observe it
Stress it
Expand coverage dynamically

You don’t need a human guessing if something might break.

👉 You watch the system prove that it doesn’t.

PR as a Transport Mechanism (Not a Gate)

Let’s separate concerns:

PR as a way to merge code ✅
PR as a mandatory human approval gate ❌

You can still:

Use feature branches
Open PRs for visibility
Track changes

But the approval step becomes either:

A formality
Or unnecessary entirely

If the people who built it understand it and stand behind it, what is approval actually adding?

Accountability > Approval

A better model replaces approvals:

Accountability over authorization

Instead of:

“Who approved this?”

You ask:

“Who built this, and do they stand behind it?”

This leads to:

Shared ownership
Clear responsibility
No rubber-stamping
No passive approvals

Call it:

Pair Programming Accountability

The Contractor Myth

A common argument:

“PR reviews help onboard new engineers.”

In practice, they don’t.

They are:

Delayed
Context-light
Passive

A better onboarding model:

Pair from day one
Focus on business domain
Ask questions continuously
Use GenAI to explore the system

Coding standards?

👉 Automatically enforced.

What matters is:

Understanding the system
Understanding the problem
Understanding the impact

Trunk-Based Development and Product Delivery Debt

In 👉 How not to fail Agile I describe product delivery debt — the hidden cost of slow feedback loops.

PR reviews are one of the biggest contributors to that debt.

They introduce:

Waiting
Context switching
Bottlenecks
Artificial delays

Now combine:

Trunk-based development
Pair programming
Spec-driven workflows
Strong automation

And you eliminate entire classes of delay.

This is how high-velocity teams ship:

Features move continuously
Feedback loops stay tight
Delivery becomes predictable

Even before GenAI, some teams achieved same-day delivery.

Now there’s even less excuse not to.

Minimalism as a Force Multiplier

Speed is not just about process — it’s also about architecture.

In 👉 Minimalistic architecture for Minimalistic product I argue that minimalistic architecture is a prerequisite for high-velocity delivery.

Why?

Because complexity amplifies everything PR reviews try (and fail) to control:

More services → more surface area to review
More abstractions → harder to reason about
More dependencies → more edge cases

Minimalism does the opposite:

Fewer moving parts
Clearer system boundaries
Easier reasoning
Faster validation

Combine minimal architecture with:

Spec-driven development
Pair programming
Strong automation

And the need for PR reviews collapses naturally.

You don’t need heavy review processes when the system itself is simple and understandable.

The Real Bottleneck: Human Latency

PR reviews struggle because:

They depend on availability
They require context reconstruction
They are rarely prioritized
They often become superficial

And most importantly:

They happen when the most valuable decisions are already behind you.

A Thought Experiment

Imagine this workflow:

Two engineers define a feature
They refine the spec
They implement it with GenAI
Tests are generated and pass
Behavior is verified
The feature is merged and deployed

Now ask:

What exactly would a PR review improve here?

The Shift That Matters

We are moving from:

Old Model	New Model
Review code	Design systems
Enforce style	Define specs
Manual validation	Automated validation
Late feedback	Continuous validation
Approval gates	Accountability ownership

Final Take

Pull requests are not dead.

But manual PR reviews are.

Not because they were wrong —

but because they no longer solve the most important problems.

If your quality depends on PR reviews, your process is already too late.

The Real Question

Not:

“Who approved this PR?”

But:

“Why are we reviewing code instead of designing better systems?”

The Token Tax: Why GenAI Billing Makes Minimalist Architecture Mandatory

Dmitry Amelchenko — Wed, 29 Apr 2026 20:38:32 +0000

The Token Tax: Why Minimalist Architecture and Language-Specific Models Win

In my previous piece, Minimalistic Architecture for Minimalistic Product, I argued that startup architecture should optimize for simplicity, scalability, and low maintenance.

Back then, the constraint was human.

Now, it’s tokens.

As we move from "Vibe Coding" to Spec-Driven Development (SDD), a new force is shaping engineering decisions:

The Token Tax.

GenAI is shifting toward token-based billing. That means every architectural decision directly affects cost—not just in runtime, but in thinking.

The Architecture–Token–Model Triangle

The old equation was:

Complexity = Cognitive Load

The new one is:

Complexity = Context = Tokens = Cost

But there’s a new multiplier:

Model Choice

Fragmented Stack = Expensive Intelligence

If your system includes:

10+ microservices
multiple languages (Java, Python, JS, Go…)
several data paradigms

You force the AI to:

load more context
switch reasoning modes
translate between abstractions

This explodes token usage before any useful work begins.

Minimal Stack + Specialized Models = Compounding Efficiency

Now consider:

Single language (e.g., JavaScript end-to-end)
Unified runtime model
Reduced architectural surface area

This unlocks something new:

You can run smaller, cheaper, language-specialized models instead of general-purpose ones.

Instead of paying for a large frontier model to reason across ecosystems, you:

use a JS-optimized model for 90% of tasks
drastically reduce context size
avoid cross-language reasoning overhead

Result: fewer tokens and cheaper tokens.

Minimalism Is What Makes Small Models Viable

Here’s the key insight:

Lightweight models only work well in predictable, constrained environments.

A chaotic architecture forces you back to large, expensive models.

A minimalist architecture lets you:

keep context windows small
standardize patterns
reduce ambiguity
enable deterministic reasoning
and the last but not least: run smaller specialized models locally for free!!!

In other words:

Architecture determines whether you can afford intelligence.

The New Role of the "Newborn Architect"

The question from SDD remains: what happens to developers?

The answer evolves.

The "Newborn Architect" is no longer just designing systems for humans.

They are designing systems for:

token efficiency
model compatibility
cost predictability

Their new responsibilities:

Define Intent (CONSTITUTION.md)
Lock in constraints that reduce ambiguity for both humans and models.
Minimize Surface Area
Every extra service, library, or language is not just complexity—
it’s a recurring token expense.
Design for Small Models
If your system requires a frontier model to understand it,
it’s already too complex.
Eliminate Translation Layers
Cross-language boundaries = hidden token multipliers.

The Real Cost of “Clever” Architecture

In the past, overengineering cost:

time
onboarding friction
maintenance

Now it costs:

tokens per prompt
tokens per iteration
tokens per bug fix
tokens per feature

And unlike technical debt, this cost is:

immediate, measurable, and unavoidable

The New Bottom Line

In 2019:

“If the product doesn’t take off, just rebuild.”

In 2026:

You might run out of budget before you learn anything.

Because every iteration is metered.

The Shift

Minimalism is no longer about elegance.

It’s about economic survival.

The winning stack is not:

the most scalable
the most flexible
the most “future-proof”

It’s the one that:

minimizes tokens
enables small, specialized models
keeps the entire system understandable in one pass

Final Thought

The best architecture today is the one that lets you downgrade your model without breaking your system.

If you can’t do that, you’re paying the Token Tax—whether you realize it or not.

What’s the most expensive piece of complexity in your stack today—not in engineering time, but in tokens?

Velocity is a Vanity Metric: Why Agentic Coding is Actually About Quality.

Dmitry Amelchenko — Thu, 23 Apr 2026 13:29:31 +0000

Beyond the Speed Trap: Why Agentic Coding is a Quality Revolution

Senior leadership often views Generative AI through a single lens: Velocity. They expect a vertical line on the burndown chart. But viewing agentic assist solely as a "speed booster" is a category error. We aren't just doing the same things faster; we are fundamentally shifting how software is delivered.

If you are an engineer using agentic tools, your priority shouldn't be speed. It should be the compounding quality of your output.

The "Apples to Oranges" Fallacy

Comparing traditional SDLC velocity to agentic-driven development is a mistake. In the traditional model, we often sacrifice long-term health for short-term "done." We ignore the small bug or the messy abstraction because fixing it requires a new ticket, a new sprint, and a new round of approvals.

Agentic coding collapses these silos.

1. In-Context Refactoring & Bug Fixing

In the past, a bug found during feature development followed a rigid path:
Backlog -> Prioritization -> Estimation -> Implementation -> Pipeline.

With agentic assist, the friction of "doing the right thing" vanishes. If you encounter a bug or a necessary refactor while working on a feature, you fix it in the context of that story. You leave the codebase better than you found it because the "cost" of doing so—in terms of time and cognitive load—has been drastically reduced.

2. From Narrow Specialists to System Architects

Traditional Scrum often forces engineers into narrow specializations to maintain speed. Spec-driven development with AI agents reverses this.

By leveraging agents to handle the boilerplate and tactical execution, engineers gain a broader understanding of the entire system architecture. The real gain isn't that the code was written in 10 minutes; it's that the engineer spent those 10 minutes ensuring the feature aligns with the broader system integrity.

3. The Death of the "Mini-Waterfall"

Even the most "Agile" Scrum teams often fall into a "mini-waterfall" trap: rigid frameworks and two-week cycles that struggle to respond to real-time discoveries.

Agentic tools enable a truly iterative approach. The feedback loop is so tight that we can respond to challenges on the spot. This shifts the fundamental question of the SDLC:

Old Question: Can we deliver this?
New Question: Should we deliver this?

Because we can prototype and iterate so quickly, we often realize a feature isn't needed before we've wasted a sprint on it.

The Obsolescence of Long-Term Planning

This shift doesn't just change how we write code; it fundamentally breaks our traditional planning horizons. The common practice of planning for three months, six months, or even a year in advance—even at the epic level—is becoming obsolete.

In an agentic environment, we explore so many new possibilities during the implementation of stories that our initial assumptions are rendered irrelevant almost immediately. Long-term planning cycles are simply too rigid for the speed of agentic discovery.

Execution and Real-Time Pivoting

Instead of focusing on long-term predictability, we must shift our focus toward high-level roadmaps and immediate execution.

Pivot on the Spot: We need to explore new possibilities as soon as they emerge rather than waiting for a Program Increment (PI) to complete.
Dynamic Roadmaps: The goal is no longer to follow a three-month plan, but to maintain a high-level vision while pivoting execution based on what we learn during the build.
Continuous Exploration: Because the cost of implementation is dropping, the value lies in the ability to test a hypothesis and pivot the strategy in real-time.

A New Approach to Estimation

If we can fix bugs, refactor code, and pivot directions in real-time, traditional upfront estimation becomes obsolete. We need to move toward post-factum velocity reflection.

Instead of guessing how long a "black box" task will take, we measure the impact and quality of the system as it evolves. Velocity improvement will come, but it must be organic.

The Bottom Line

Don't chase the "Day 1" 10x velocity jump. Instead, focus on:

Reducing "Bounce Backs": Higher quality means fewer QA rejections.
System Health: Gradual, automated improvement of the codebase.
Spec-Driven Precision: Knowing why you are building before you let the agent build it.
Radical Agility: Pivoting the moment a better path reveals itself, rather than serving an outdated roadmap.

The goal of agentic coding isn't to produce more code. It's to produce better systems.

From Vibe Coding to SDD: Why the Future of Engineering is Architecture

Dmitry Amelchenko — Mon, 30 Mar 2026 23:02:14 +0000

The Architectural Shift

The era of writing code by hand is becoming a relic of the past. As we move deeper into the age of Generative AI, the role of the software engineer is undergoing a fundamental phase shift: from the depth of manual syntax to the breadth of architectural orchestration.

The Entropy of "Vibe Coding"

"Vibe coding"—relying on AI to generate code based on loose prompts and "vibes"—is an excellent entry point, but it carries a hidden tax: architectural entropy. Without a rigorous framework, rapid AI generation leads to inconsistencies, technical drift, and a fragmented codebase that no human brain can fully map.

Enter Spec-Driven Development (SDD)

Spec-Driven Development is the "all-in" solution to AI-driven engineering. It shifts the focus from the output (the code) to the intent (the specification).

The Engineer as Architect: In SDD, writing code is the simplest and fastest part of the cycle. The real work happens in refining the "spec"—ensuring requirements are precise, edge cases are covered, and external dependencies are identified upfront.
Contextual Superiority: While a human engineer will inevitably miss details in a massive project, GenAI can hold the entire context in memory. By using SDD, the engineer acts as a high-level validator, challenging assumptions and directing the AI to maintain a consistent vision.
The End of the Jira Bug Cycle: In an SDD workflow, the feedback loop is nearly instantaneous. Instead of an architect writing a spec and waiting weeks for a developer to validate it, the "newborn architect" (formerly the developer) can validate assumptions on the spot.

The Economics of Hyper-Productivity

The transition to SDD isn't just a qualitative win; it’s a massive economic lever. In a recent month-long experiment with Spec-driven development, I burned through over 1,000% of my monthly token allowance. The cost? $135.

To put that in perspective:

Metric	Delta
Direct Cost	~$135 (Roughly one hour of a mid-level developer's time)
Output Volume	Equivalent to 3 months of full-time manual engineering
Quality Control	Precision bug identification exceeding manual capacity

The Path Forward: Breadth Over Depth

There will be resistance. Engineers who have spent years perfecting their manual craft may feel marginalized. However, the argument is not that these skills are obsolete, but that they must be elevated.

We are moving toward a world where every pull request is a spec. The goal is to turn every developer into an architect—someone who understands the entire picture, manages dependencies, and leverages AI to execute with a speed and accuracy that was previously impossible.

The conclusion is clear: Writing code by hand is becoming "lame." The future belongs to those who positions themselves to master the specification.

Entry-Level Jobs Shift to Architecture

Core Thesis

The entry-level software engineer role is structurally obsolete. The new floor for any developer entering the workforce is architectural thinking, not code execution. GenAI compresses the time required to acquire that architectural fluency, but the expectation shift is immediate and non-negotiable.

Supporting Arguments

"Everyone becomes an architect" is not aspirational framing. It is a baseline requirement. The question of what happens to junior dev jobs is already answered: those jobs, as traditionally defined, do not survive the transition.
GenAI accelerates skill acquisition toward architectural competency, but it does not lower the bar. It raises the starting line.
This aligns directly with SDD mandate: the "developer as architect/orchestrator" identity is not a senior-level privilege. It is the entry condition.

Open Questions / Blind Spots

Hiring pipeline implications. If architectural thinking is the new floor, how does a company’s current hiring rubric, leveling framework, and onboarding process need to change? The thesis demands a corresponding talent strategy, not just a cultural declaration.
The acceleration claim needs stress-testing. GenAI helps acquire skills "in no time" is an assertion, not a proof. The gap between GenAI-assisted architectural intuition and genuine systems judgment (failure modes, tradeoffs, organizational context) may be wider than the framing suggests.
Resistance vector. This argument is most threatening to mid-level engineers who built identity around depth. The framing addresses new entrants but sidesteps the harder conversation: what does this mean for the engineer who has been writing code for five years and is not yet an architect?

There is C, there is C#, and there is Java—which is effectively C♭.

Dmitry Amelchenko — Thu, 12 Mar 2026 16:12:09 +0000