DEV Community: Dmitry Amelchenko

GenAI Changed the Cost of Coding. Why Are We Still Organizing Work the Same Way?

Dmitry Amelchenko — Thu, 22 Oct 2026 19:01:06 +0000

GenAI Changed the Cost of Coding. Why Are We Still Organizing Work the Same Way?

Everyone is talking about BMAD. Agents. Specifications. How much code they can generate.

Okay. Cool.

But what does that actually change?

If we use these tools to produce more code while keeping the same organizational structure, the same handoffs, and the same feedback cycles, we are missing the more interesting opportunity.

GenAI changes the economics of implementation. Our way of working should change with it.

Here is where I think this is going. Some of it is practical today. Some of it is a prediction. And some of it probably deserves an argument.

The bottleneck is moving

The traditional squad structure made sense under a particular constraint.

One Product Owner. Five to ten developers.

The PO figured out what needed to happen. Developers spent the next sprint or several sprints implementing it. Development was expensive, so we invested heavily in planning before committing to execution.

Now implementation is becoming cheaper.

Not free. Not automatically correct. Certainly not free of integration, security, or operational problems.

But cheap enough that we need to reconsider the balance.

The question is shifting from:

Can we build this?

To:

Should we build this?

And the best way to answer the second question is often to build a small version, put it in front of users, and see what happens.

This is hardly a new idea. It is a core Agile principle.

What is new is how quickly we can act on it.

The constraint increasingly becomes our ability to make good decisions and validate them, rather than our ability to turn a decision into code.

So why would the ratio between business and engineering remain unchanged?

One PO. One engineer. Working on the same problem.

Here is the model I would like to see more teams try:

One Product Owner working directly with one engineer.

Not a PO writing stories for ten developers. Not an engineer receiving requirements over the wall.

Two people working on the same concept, with agents supporting the implementation.

The PO brings business context, customer understanding, and product judgment. The engineer brings architecture, technical constraints, and an understanding of what can be simplified.

Neither person has to pretend to be the other.

I do not think the typical future is one person doing the entire job. Some people can move comfortably across business and engineering. Most have deeper expertise on one side.

That is fine. The point is to connect those strengths, not eliminate them.

The conversation changes from:

Write the requirements. We will show you the result at the end of the sprint.

To:

Is this what you meant? What if we do it this way? Does that change the business outcome? Let's try it.

That is a fundamentally different feedback loop.

An engineer can challenge an unnecessary requirement while it is still an idea. A PO can correct a misunderstanding before it becomes a completed feature.

You do not need to wait for the sprint review to discover that you built the wrong thing.

BMAD is interesting because it connects the workflow

BMAD is interesting to me because its ambition goes beyond code generation.

It connects product exploration, requirements, architecture, epics, stories, implementation, and review.

That matters because the business question and the engineering question should not live in separate universes.

A tool that helps execute a specification is useful.

A workflow that helps us question the specification, identify contradictions, and carry decisions through implementation is more consequential.

It gives the PO and engineer a shared structure to work within.

It does not make their judgment unnecessary. It makes their collaboration more valuable.

Automating the handoff is useful. Removing an unnecessary handoff is better.

A prototype that would previously have been hard to justify

One experiment on my team illustrates why this matters.

We have a complex workflow embedded in a mobile application through a WebView. From the mobile side, it behaves like a black box. The workflow reaches into multiple subsystems, while the application mostly hosts the experience.

Replacing it with a native experience used to look like a substantial coordination problem.

You would need to understand the existing implementation, trace dependencies across repositories, identify the available interfaces, and preserve the business behavior.

Before writing much native code, you already had a discovery project.

One engineer on the team is now exploring that replacement by bringing the relevant repositories into a shared workspace and using BMAD to help reason across them.

This is a prototype, not a claim that the entire migration is finished.

But the change in feasibility is already interesting.

Something we previously struggled to justify as a larger engineering effort is now being explored by one person.

And this particular experiment has a useful constraint: the business behavior should stay the same.

We are changing the implementation, not inventing new business rules.

That does not remove the need for validation. It gives us a clearer target.

What if we stopped assuming every feature must live forever?

There is another consequence of cheaper implementation that I find even more interesting.

We might finally reconsider our habit of continuously adding to existing software.

I remember a presentation from roughly 15 years ago, possibly at a Ruby on Rails conference. The speaker suggested something that sounded impractical:

When you begin the next iteration, reconsider and rewrite what you built in the previous one instead of automatically building on top of it.

You implemented login and registration. Now you understand the problem better. Before adding account settings, implement that foundation again using what you learned.

People were skeptical. Understandably.

Rewriting working software is expensive. Existing behavior is easy to miss. At some point, the product becomes too large for the idea to make sense.

Those objections have not disappeared.

But the economics are changing.

What used to be obviously impractical may now deserve another look, at least within a well-defined boundary.

Not the whole enterprise stack. Not every service before every release.

A workflow. A module. A bounded part of the product.

Instead of asking:

How do we attach another feature to this?

We could ask:

Knowing what we know now, what should this part of the product look like?

Those are very different questions.

Rewrite the implementation. Preserve the knowledge.

There is an important distinction here.

I am not suggesting that we throw away everything we learned and ask an agent to recreate production from a vague prompt.

That would be a great way to rediscover old bugs.

The valuable assets include:

Business rules.
Explicit requirements.
Architectural constraints.
Tests that capture expected behavior.
Knowledge of failures and edge cases.

The implementation is one expression of that knowledge.

It does not have to be the permanent expression.

If we can preserve the constraints and validate the behavior, we have more freedom to replace an implementation that no longer fits.

We also have more freedom to remove things.

Cheaper code generation can make feature bloat much worse. It becomes easy to add something and surprisingly difficult to explain why it should remain.

The ability to build more should increase our discipline about what we keep.

Otherwise, we just generate a larger maintenance problem faster.

Community matters more than another internal framework

Another part of this shift is where the workflows themselves come from.

I would rather start with an active, community-driven framework than assume every organization needs to invent its own agent orchestration system.

Internal experiments are useful. Specialized constraints are real.

But maintaining a development framework is a separate product responsibility. Someone has to improve it, test it, adapt it to changing models, and learn from its failures.

A community can create a useful feedback loop:

People try the workflow.
They expose weaknesses.
Improvements become available to other users.
Those users test it against different problems.

The interesting opportunity is to contribute to that loop, then customize where the actual business constraints require it.

We should spend less time proving that we can invent another framework and more time learning how to use these workflows effectively.

This is an experiment, not a new organizational religion

Large organizations will not suddenly become collections of independent PO-engineer pairs.

Shared platforms, backend dependencies, compliance, and coordinated releases still exist. Faster code generation does not make them disappear.

But those constraints should tell us where to test the model, rather than become a reason never to test it.

Pick a bounded workflow.

Pair a PO with an engineer.

Give them a structured agentic workflow and a short path to feedback.

Then measure how long it takes to answer a useful question:

Did we build something worth keeping?

We can implement more quickly. We can reconsider implementations that once felt too expensive to replace. We can bring business and engineering into the same working conversation.

But only if we change how we work.

Otherwise, we have taken a fundamentally different capability and used it to make the old conveyor belt run faster.

Inside My llama.cpp Setup: Tuning Qwen 3.8 27B for 512K Context

Dmitry Amelchenko — Sat, 03 Oct 2026 01:28:14 +0000

Understanding My llama.cpp Qwen 3.8 Configuration

I've been tuning llama.cpp for local AI development, and the command line can quickly become a collection of cryptic flags.

Here's what my current configuration does, parameter by parameter.
I'm specifically focusing on maxing out the utilization of my system (which is MBP M5 with 128 GB Unified RAM), for multi-agent coding which requires parallel agents execution.

llama serve \
  -hf unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_XL \
  --spec-type draft-mtp \
  --spec-default \
  --spec-draft-n-max 8 \
  -ngl 99 \
  -c 524288 \
  --override-kv qwen2.context_length=int:524288 \
  --rope-scaling yarn \
  --yarn-orig-ctx 262144 \
  -b 16384 -ub 4096 \
  -t 16 \
  -tb 16 \
  -np 2 \
  -fa on \
  --cache-type-k f16 \
  --cache-type-v f16 \
  --kv-offload \
  --load-mode none \
  --host 127.0.0.1 \
  --port 8080

The easiest way to understand it is to divide the configuration into several areas:

Model
Speculative decoding
Context
GPU
Batching
CPU
KV cache
Server configuration

1. Model

-hf unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_XL

This tells llama.cpp to download and load the model from Hugging Face.

Breaking it down:

unsloth/ — Hugging Face repository owner
Qwen3.8-27B — approximately 27 billion parameters
GGUF — the model format used by llama.cpp
UD-Q4_K_XL — the quantization

Q4 means the model weights are approximately 4-bit quantized.

The trade-off is straightforward: lower precision produces a much smaller model and significantly reduces memory requirements, at some cost to numerical precision.

2. Speculative decoding / MTP

--spec-type draft-mtp

This enables speculative decoding using MTP (Multi-Token Prediction).

Instead of having the main model generate:

token → token → token → token

the system uses a draft mechanism to propose multiple future tokens, which the main model then verifies.

Conceptually:

                 Draft model
                      │
                      ▼
              token token token
                      │
                      ▼
                Main model
                  verifies
                      │
                      ▼
             accept several tokens

When several proposed tokens are accepted, generation can become substantially faster.

For this model, speculative decoding is one of the most important performance-related settings.

3. `--spec-default`

--spec-default

This enables the default speculative-decoding configuration associated with the selected speculation type.

In this case:

draft-mtp

It's generally not something I'd change unless I was experimenting with the underlying speculative-decoding implementation.

4. Maximum speculative tokens

--spec-draft-n-max 8

This controls the maximum number of speculative tokens proposed ahead.

With:

the draft mechanism can attempt to predict up to eight tokens ahead.

Conceptually:

Main model:
A

Draft:
A → B → C → D → E → F → G → H

Main model verifies:
A B C D ✓ ✓ ✓ ✗

The more tokens you speculate, the greater the potential speedup—but only if the draft predictions are good enough.

This is one of the parameters worth benchmarking:

2
4
8

Eight is an aggressive but reasonable value to test.

5. GPU layers

-ngl 99

This is short for:

--n-gpu-layers

It specifies how many model layers should be offloaded to the GPU.

99 effectively means:

Put as many layers as possible on the GPU.

It does not mean "use 99 GPU cores."

Think of it as:

CPU
 │
 ├── some model layers
 │
GPU
 │
 └── most/all model layers

If the model fits comfortably on the GPU, -ngl 99 is generally what you want for performance.

6. Context size

-c 524288

This specifies the maximum context window.

The value is:

524,288 tokens = 512K tokens.

That is an enormous context window.

For comparison:

32K   = 32,768
128K  = 131,072
256K  = 262,144
512K  = 524,288

The important trade-off is that larger context requires more memory, particularly because of the KV cache.

For agentic coding workloads, however, having hundreds of thousands of tokens available can be extremely useful.

7. Context-length override

--override-kv qwen2.context_length=int:524288

This is different from -c.

You're overriding a value stored in the model's GGUF metadata:

qwen2.context_length

and setting it to:

In other words, you're telling llama.cpp to treat the model as having a 512K context length.

This does not magically train the model for 512K context.

That's why the configuration also uses YaRN.

8. RoPE scaling

--rope-scaling yarn

This enables YaRN — Yet another RoPE extension.

RoPE stands for Rotary Position Embedding.

RoPE is part of how the transformer represents token positions:

token 1
token 2
token 3
...
token 262144

When extending the context beyond the model's original trained range, positional scaling is required.

YaRN provides a mechanism for extending that range.

In this configuration:

Original context:
262K

Target context:
524K

So the positional range is being extended by roughly 2×.

9. Original YaRN context

--yarn-orig-ctx 262144

This tells YaRN:

The model's original context length is 262,144 tokens.

So the relevant configuration is:

Original:
262,144

Target:
524,288

Extension:
2×

These two parameters work together:

--rope-scaling yarn
--yarn-orig-ctx 262144

10. Logical batch size

-b 16384

This specifies the maximum number of tokens processed in a logical batch.

The value is:

16,384 tokens

This primarily affects prompt processing / prefill.

For example, if you send a large prompt containing thousands of tokens, a larger batch can allow the GPU to process more tokens efficiently.

Larger batches can increase prompt-processing throughput, but they also consume more memory.

Importantly:

context = 524K
batch   = 16K

is perfectly valid.

The batch size does not limit the context window.

11. Physical / micro batch

-ub 4096

This is the physical or micro-batch size.

It controls how many tokens are actually processed at one time.

The configuration therefore has:

Logical batch:
16,384

Physical batch:
4,096

Conceptually:

16,384 tokens

┌──────────────────┐
│ 4,096 tokens     │
├──────────────────┤
│ 4,096 tokens     │
├──────────────────┤
│ 4,096 tokens     │
├──────────────────┤
│ 4,096 tokens     │
└──────────────────┘

This allows a large logical batch without requiring all 16K tokens to be processed simultaneously.

-ub is therefore particularly important for VRAM usage and prompt-processing performance.

12. CPU threads

-t 16

This specifies the number of CPU threads used for computation.

Here:

16 CPU threads

This does not mean 16 GPU cores.

How useful additional CPU threads are depends heavily on your CPU and on how much of the workload remains on the CPU.

13. Batch-processing CPU threads

-tb 16

This specifies the number of CPU threads used specifically for batch processing.

So the configuration is:

Normal computation: 16 threads
Batch computation:  16 threads

Whether 16 is optimal depends on your CPU.

If you're running on a high-core-count CPU, this is worth benchmarking.

More threads don't automatically mean higher performance.

14. Parallel sequences

-np 2

This enables two parallel sequences/requests.

Conceptually:

                 Model
                   │
          ┌────────┴────────┐
          ▼                 ▼
      Context #1         Context #2
      512K max           512K max

This is useful if you're running two concurrent requests or agents.

There is, however, a memory cost.

With:

512K context
×
2 parallel sequences

the potential KV-cache requirement becomes very large.

If you only ever run one request at a time, -np 1 may provide a better memory/performance balance.

15. Flash Attention

-fa on

This enables Flash Attention.

Flash Attention is an optimized implementation of the attention mechanism designed to reduce memory traffic and improve performance.

It becomes particularly important at long context lengths.

For a 512K configuration, I'd keep:

-fa on

16. K cache

--cache-type-k f16

This specifies the datatype used for the Key portion of the KV cache.

You're using:

F16

or 16-bit floating point.

17. V cache

--cache-type-v f16

This specifies the datatype used for the Value portion of the KV cache.

So the current configuration is:

K = F16
V = F16

This provides high precision, but consumes considerably more memory than:

--cache-type-k q8_0
--cache-type-v q8_0

Given the combination of:

512K context
×
2 parallel sequences
×
F16 KV

this is one of the largest memory-consuming choices in the configuration.

18. KV GPU offload

--kv-offload

This tells llama.cpp to keep the KV cache on the GPU when possible.

That generally improves performance because it avoids repeatedly moving KV data between CPU and GPU.

The desired architecture for maximum performance is therefore approximately:

Model weights → GPU
KV cache     → GPU
Attention    → GPU

assuming you have enough VRAM.

19. Load mode

--load-mode none

This controls the model-loading mechanism.

none means that no special loading mode is being selected.

This isn't a setting I'd normally spend much time optimizing unless you're diagnosing model loading, memory mapping, or startup behavior.

20. Host

--host 127.0.0.1

This makes the server listen only on the local machine.

So the server is accessible through:

127.0.0.1

but isn't directly exposed to other machines on the network.

This is a network/security setting, not an inference-performance setting.

21. Port

--port 8080

The server listens on port:

So your local API is effectively:

http://127.0.0.1:8080

This has essentially no impact on model performance.

Putting everything together

Your command is essentially saying:

Run Qwen 3.8 27B using a Q4 quantization, put as much of the model as possible on the GPU, use MTP speculative decoding with up to eight speculative tokens, support a 512K context by extending the model's 256K positional range with YaRN, process prompts using 16K/4K batches, use 16 CPU threads, support two simultaneous sequences, use Flash Attention, keep the F16 KV cache on the GPU, and expose the model as a local HTTP server on port 8080.

The architecture looks roughly like this:

                    llama.cpp server
                           │
               ┌───────────┴───────────┐
               │                       │
          Request #1              Request #2
          512K max                512K max
               │                       │
               └───────────┬───────────┘
                           │
                       KV Cache
                        F16/F16
                           │
                    Flash Attention
                           │
                  Qwen 3.8 27B Q4
                           │
                     GPU (-ngl 99)
                           │
                   MTP / speculative
                      decoding ×8
                           │
                         Output

What matters most for performance

Not all parameters deserve equal attention.

Highest impact

--spec-draft-n-max 8
-c 524288
-np 2
--cache-type-k f16
--cache-type-v f16
-b 16384
-ub 4096
-fa on

Hardware dependent

-t 16
-tb 16

Usually leave alone

-ngl 99
--kv-offload

Mostly configuration rather than performance

--override-kv
--rope-scaling
--yarn-orig-ctx
--load-mode
--host
--port

The three biggest trade-offs in this particular configuration are:

512K context  ↔  memory

F16 KV       ↔  memory / performance

16K / 4K batch ↔ VRAM / prompt throughput

And for generation speed, the most interesting parameter is probably:

MTP-8 ↔ speculative-token acceptance rate

The optimal configuration therefore isn't necessarily the one with the largest numbers. The goal is to find the point where GPU utilization, memory bandwidth, KV-cache size, batch size, and speculative-token acceptance work together rather than competing with each other.

Learning how to BMAD

Dmitry Amelchenko — Thu, 01 Oct 2026 00:30:46 +0000

My evolution in agentic development has been somewhat typical.

At the end of 2025, it was all about the new thing at the time — Vibe Coding.

Then, at the beginning of 2026, SDD with OpenSpec became a big game changer. It provided a way to scale agent-driven development without letting the codebase turn into a mess.

And the next natural step? Multi-agent agentic workflows with BMAD.

At first glance, BMAD seems vast, sophisticated, and complex.

So where do I start?

The best approach I could come up with was pretty simple: I talked to a friend who has been using BMAD for a couple of months now, which makes him an expert, transcribed our conversation, and asked GenAI to summarize it.

Here’s what I got.

Orchestrating AI: A Blueprint for Spec-Driven Development with BMAD

Software development constraints have shifted. The bottleneck is no longer keystrokes or raw implementation speed; it is cognitive load and context window management.

My colleague Vlad recently scaled an entire production architecture using the BMAD AI framework. By shifting his role from writing syntax to orchestrating architecture, he maxed out Claude’s highest subscription tiers and fundamentally changed his output vector. Tasks that typically rot in a backlog are now executed in a single weekend.

Here is the operational framework for high-leverage execution using BMAD.

The Execution Pipeline

AI-driven development requires strict adherence to spec-driven workflows. You do not ask the AI to "build a feature." You force it to define the product, register the architecture, and validate its own readiness before a single line of code is written.

The Spec-Driven Workflow:
Brainstorming → PRD → ADR → Epics → Stories → Readiness Validation (Loop if Not Ready) → Implementation → Code Review

Domain Research & PRD: Establish the baseline. The AI translates brainstorming sessions into strict Product Requirement Documents (PRDs).
Architecture Decision Registry (ADR): The AI extracts technical dependencies from the PRD, selecting the stack (e.g., databases, infrastructure) and locking in technical parameters.
Epics & Sharding: The ADR is broken down into Epics. If an Epic is too large, the AI shards it into smaller, digestible components.
Implementation Readiness: This is the critical gate. The AI runs a readiness check against the requirements. If it scores below the required threshold (due to contradictions or missing logic), the engineer issues a "correct course" command.
Implementation & Review: The AI generates a comprehensive checklist (often 500+ lines) for a single story, executes the code, and then reviews its own work, prompting the engineer with necessary clarifying questions.

Eliminating Technical Debt at Zero Marginal Cost

Under legacy models, technical debt persists because the ROI of fixing it rarely justifies the engineering hours. AI reverses this calculus.

Vlad’s monorepo CI/CD pipeline was choking on batch scripts, pushing test cycles to 90 minutes. Rather than manually rewriting it, he orchestrated an automated intervention:

Phase 1: Technical Research. BMAD analyzed the repository, identified the quadratic scaling bottleneck in the batch scripts, evaluated Python, TypeScript, and Go, and proposed a Go port.
Phase 2: Execution. After Vlad approved the research, BMAD injected three new stories into the active Epic and executed the Go port over the weekend.

A refactor that would have cost a week of human engineering time was resolved asynchronously while the engineer managed top-level logistics.

Operational Heuristics for AI Engineering

If you are scaling an AI agent like BMAD, adopt these technical guardrails:

1. Enforce Monorepos

Avoid git submodules and multi-repository architectures. Umbrella projects with submodules introduce heavy friction when tracking commit hashes across dependencies. AI agents perform best when they have unified line-of-sight across the entire codebase—front-end and back-end alike.

2. Cap the Context Window

Larger context windows yield higher hallucination rates. While Claude and local models (like Qwen) boast 500k to 1M token windows, pushing past 400k guarantees degradation. The AI will fabricate interruptions or lose the thread entirely. Cap your working sessions between 100k and 260k tokens. Isolate execution by breaking stories down further rather than bloating the context.

3. Automate Traceability

As your project scales to hundreds of PRDs and ADRs, manual validation becomes impossible. Vlad engineered a custom BMAD skill using an open-source requirement flow tool. The skill mechanically sweeps all files to ensure strict traceability—flagging orphan PRDs, missing dependencies, and architectural contradictions before the implementation phase begins.

4. Shift Unknowns Left

Address structural unknowns and technical spikes in the earliest stories of an Epic. By resolving ambiguities at the start of the cycle, the tail end of the Epic becomes highly mechanical, requiring near-zero human intervention.

The Delta

We are exiting the era of the 50-person engineering team split across 10 specialized layers. The future belongs to single-engineer monorepos, where the human acts as the Chief Architect and the AI executes the labor. Focus on the architecture; the speed will follow.

Conclusion

My friend told me he had been burning through an insane number of tokens — couple of thousand dollars worth every month.

He barely writes any code by hand anymore. Instead, he spends his energy making one decision after another: yes or no, keep or discard, proceed or stop.

At the end of the day, it is exhausting. And somehow, incredibly satisfying.

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?

DEV Community: Dmitry Amelchenko

GenAI Changed the Cost of Coding. Why Are We Still Organizing Work the Same Way?

GenAI Changed the Cost of Coding. Why Are We Still Organizing Work the Same Way?

The bottleneck is moving

One PO. One engineer. Working on the same problem.

BMAD is interesting because it connects the workflow

A prototype that would previously have been hard to justify

What if we stopped assuming every feature must live forever?

Rewrite the implementation. Preserve the knowledge.

Community matters more than another internal framework

This is an experiment, not a new organizational religion

Inside My llama.cpp Setup: Tuning Qwen 3.8 27B for 512K Context

Understanding My llama.cpp Qwen 3.8 Configuration

1. Model

2. Speculative decoding / MTP

3. --spec-default

4. Maximum speculative tokens

5. GPU layers

6. Context size

7. Context-length override

8. RoPE scaling

9. Original YaRN context

10. Logical batch size

11. Physical / micro batch

12. CPU threads

13. Batch-processing CPU threads

14. Parallel sequences

15. Flash Attention

16. K cache

17. V cache

18. KV GPU offload

19. Load mode

20. Host

21. Port

Putting everything together

What matters most for performance

Highest impact

Hardware dependent

Usually leave alone

Mostly configuration rather than performance

Learning how to BMAD

Orchestrating AI: A Blueprint for Spec-Driven Development with BMAD

The Execution Pipeline

Eliminating Technical Debt at Zero Marginal Cost

Operational Heuristics for AI Engineering

1. Enforce Monorepos

2. Cap the Context Window

3. Automate Traceability

4. Shift Unknowns Left

The Delta

Conclusion

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

The Threat Model: Common Archetypes

Rule 1: Observe, But Remain Silent

Rule 2: Your Vulnerability Is Their Tooling

Rule 3: Starve the Engine

Rule 4: Weaponize Time

Rule 5: Deprecate Access

Rule 6: Audit Your Own Telemetry

Rule 7: The Master Key — Become Unreadable

Stop Asking Which Agentic Coding Methodology to Use

1. Execution vs. Intent: Superpowers vs. BMAD

2. Context Retention: OpenSpec vs. SpecKit

3. The Autonomy Layer: GSD vs. Ralph

4. The Meta-Layer: Compound Engineering

The Winning Synthesis

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

The Factory Fallacy

The Vector: Optimize for Learning

1. Work Experimentally

2. Compress Feedback Cycles

3. Isolate the Variables

Realigning Metrics

Stop Fixing Engineers. Start Fixing the Environment.

The Cognitive Cost of Survival Mode

The Death of the Risk Vector

Orchestrating a High-Trust, Low-Fear Culture

Institutionalizing Fear: The Performance Management Trap

Conclusion: The Macro Climate and The Final Delta

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

3. `--spec-default`