DEV Community: Dmitry Amelchenko

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

The End of Vibe Coding

Dmitry Amelchenko — Sun, 08 Mar 2026 03:49:49 +0000

The "Move Fast and Break Things" era has met its match in Generative AI. We are currently witnessing a split in the engineering world. On one side, there is Vibe Coding: a frantic, prompt-heavy workflow where developers describe a goal, "re-roll" until the code looks right, and pray the edge cases don't implode in production. On the other, there is Spec-Driven Development (SDD): a disciplined, architectural approach that treats AI not as a magic wand, but as a high-velocity compiler for human intent.

If you are building mission-critical systems, the "vibe" is no longer enough. Here is why the industry is shifting toward the Power Inversion—and how you can lead the transition.

The Lethal Trifecta of Vibe Coding

Vibe coding feels like a superpower during a weekend hackathon. You aren't bogged down by syntax; you are describing a vision. However, when that prototype needs to become a foundation, three structural limits emerge:

The Assumption Problem: AI hates ambiguity. If your prompt is vague, the model will aggressively fill in the blanks with its own assumptions. This leads to code that looks perfect but is quietly, dangerously wrong.
Context Decay: AI models have the "memory of a goldfish." As a project grows, the model forgets the architectural decisions you made last week, leading to a messy patchwork of local fixes.
The Accountability Gap: In vibe coding, the code is the only source of truth. You lose the audit trail of why a decision was made, making professional governance impossible.

The Solution: The Power Inversion

To harness AI without the chaos, we must embrace the Power Inversion. In the old world, "Code was King"—if the docs and the code disagreed, the docs were wrong. In the SDD world, the Specification is the Truth. If the code deviates from the spec, the code is broken and must be fixed.

This shift transforms the developer's role from a "prompter" to an Architect of Intent.

The SDD Framework: Five Non-Negotiables

To move from "unsupervised intern" AI to a "high-leverage collaborator," your workflow must integrate these five pillars:

1. Executable Intent

Your specifications cannot be dusty PDFs. They must be living, machine-readable documents (Markdown) that live in your Git repo. A spec is "executable" when it is so unambiguous that an AI can derive a technical plan and test suite from it without guessing.

2. The Clarification Gate

AI agents are eager to please, which makes them prone to hallucinating business logic. Implement a Clarification Gate: the agent is forbidden from coding until it has surfaced all ambiguities. If a requirement touches "Money," "Security," or "Data Deletion," the threshold for ambiguity is zero.

3. The Project Constitution

Every project needs a CONSTITUTION.md (different SDD frameworks may name it differently, but the concept remains the same). This file encodes your "Architectural DNA"—naming conventions, forbidden libraries, and error-handling patterns. It ensures that code written a year from now feels like it was written by the same senior architect who started the project.

4. Atomic Decomposition (Micro-PRs)

Speed is a liability if the output is too large to review. Break features into tiny, verifiable tasks. If a human cannot verify a code change in two minutes, the task is too big. This "Small Steps Philosophy" prevents Agent Drift.

5. Verification-First Governance

Done doesn't mean "the demo works." Done means:

The intent is approved.
The tests enforcing that intent are passing.
The code is a derived artifact of the spec.

The ROI of Rigor

Critics argue that SDD slows you down. The data suggests otherwise. By shifting effort upstream—spending more time on the "What" and the "Why"—you virtually eliminate the downstream costs of debugging, rework, and technical debt.

Companies like Airbnb and Google have proven this at scale, using structured AI workflows to complete year-long migrations in a matter of weeks. They didn't just get faster; they got more deterministic.

Conclusion: Your New Superpower

In an era where AI can write code nearly for free, the bottleneck is no longer typing speed or framework knowledge. The new bottleneck is clarity of thought.

Your value as an engineer is now measured by your ability to define intent with absolute precision. Stop serving the code. Start making the code serve your intent.

Is your spec a North Star, or just a vague suggestion? The choice defines the quality of everything you build.

From 18 to 3 Hours: When Gen AI Overdelivers (or Did It?)

Dmitry Amelchenko — Thu, 14 Aug 2025 02:06:39 +0000

I wanted to implement the dark mode on my pet project mobile app for a while -- could never find enough time and motivation to do it until now. Last night I finally started chatting to Github Copilot (Claude 4 sonnet model):

18 hours? No way. It will take me at least 4 weeks working on this little project solo for 2-3 hours a day after work.

Let's see what we (Copilot and I) were able to accomplish:

There are lot more screens, I'm showing only the most significant ones here.

It took about 3 hours total, talking to Copilot, asking questions, watching youtube videos while waiting for Copilot to complete the response to a particular prompt, then iterate again, and again, and again, until it was ... done!
It touched pretty much every single file in the project.
It's done a lot of heavy lifting -- produced a lot of code, and did it very fast.

If you know what you are doing (if you know what questions to ask Copilot in the right way) -- your effectiveness as a software engineer will go through the roof. Some unintended findings -- sometimes, you ask Copilot a question, but it kind of knows where you are going with it, so it does a lot more than you ask. For instance, I asked to apply a dark mode styling for a particular card which it missed on one screen, and it figured out that the rest of the cards need to have the same approach applied -- I didn't complained and accepted the change.

At this point, I ran out of steam -- going to sleep, and will release all these changes tomorrow night after work.

P.S. After proof reading this post, I realized -- one really has to keep the architecture clean (and simple) in order for Gen AI to be able to help effectively. GenAI praised this project highly, which was very flattering — all the prior decisions on the project helped to implement non trivial tasks super easily in just one session.

Before vs. After: How AI ‘Vibe-Coded’ a Mobile App Makeover That Defies Expectations!

Dmitry Amelchenko — Sun, 15 Jun 2025 19:04:58 +0000

Claude 4.0 Did in 3 Hours What Would’ve Taken Me Months

As previously stated, UI/UX is not my forte. So, today we will try to use the power of Gen AI to apply facelift on existing react-native project.

In the previous post we've looked at different AI models available in github copilot in Agent mode https://dev.to/dmitryame/design-smarter-testing-top-llms-for-mobile-interface-optimization-k89

Based on that post, the best model which will work for us is Claude 4.0.

It took two iterations -- about 3 hours combined, 22 commits total. In the first iteration I hit the rate limit, so had no choice but to punt it to the next day. Still, the amount of work that I was able to accomplish even before I hit the limit is staggering. What I was able to complete in few hours would usually take me weeks or even months.

Unlike in the previous post, where I gave different Models a high level prompt, asking to make general UI improvements, this time I went one component at a time and was very specific. I will not be sharing the details of my interactions with the Agent (it would be overwhelming) -- I will be sharing only the end results 2 screens (before and after) with some brief notes, and it will be self explanatory.

PhotosList component (landing screen)

improvements:

top nav bar
thumbnails
- more rounder corners
- redesigned indicator for video
footer redesign
- more consistent
- modern looking buttons

animation of the top nav bar (hiding text labels on scroll)

Drawer navigation (hamburger menu)

Starred Photos (empty list)

Search Photos (empty list)

improvements:

input text box
action button

Thumbs with comments on Starred and Search Photos

Photo Details screen

improvements:

dark theme
top nav bar
more modern card view approach for components:
- comments
- AI recognized tag, text, moderation
label based design for the individual tags
better colors
bottom footer redesign

Add comments screen

Zoom View Screen

Overall Tablet improvements

photos list

detailed photo view

Works on Android too (love react-native)

Extras bonus

I noticed, as the Agent was making improvements, in one of the commits it added support for Haptic feedback -- I will take it as a free bonus. Unfortunately not able to test it until the changes rolled out to prod, but hopefully they just work.

Using the right LLM for the right purpose

After making all these cool updates, releasing the mobile app to the app store is still task on its own. Especially after all these UI changes -- need to update the app store screenshots. I don't even have the right tools for slicing and dicing the images, but I do have ChatGPT, let's give it a try.

prompt: generate iTunes store screen shot image, use first image as the the most up to date screenshot and the second image as a guidelines for design, the dimensions should be 1242 × 2688px

Chat GPT:

prompt: take the mobile phone content area only from the first image and apply it to the second image in the correct place of the phone screen

Chat GPT:

prompt: you lost the headline from the second photo, apply it to the results

Chat GPT:

Well, not exactly what I was hoping for, and kind of funny results, oh well, some day soon I'm sure it will be able to do it correctly.

Let's try the same prompt with Claude 4.0 model in copilot Agent mode.

prompt:
generate iTunes store screen shot image, the output dimensions should be 1242 × 2688px, apply the screenshot which is #iphone1_1.png to the phone screen image on the #iphone1.png maintaining the proper expected screen size, position, rotation, preserve the headline on the top of the iphone1.png, final image output file name iphone1_2.png

Claude: Sorry, your request failed. Please try again. Request id: 4bd0b681-6758-4471-9c91-9c17a0231be9

Reason: Please check your firewall rules and network connection then try again. Error Code: net::ERR_HTTP2_PROTOCOL_ERROR.

and it fails today... it probably ran out of limit for the day... will have to try again tomorrow... stay tuned for more updates.