DEV Community: Mykola (Nick) Skalenko

Intelligence Is a Budget: The 4-Level Pyramid I Use to Run AI Agents in Production

Mykola (Nick) Skalenko — Wed, 28 Oct 2026 15:53:50 +0000

Why running a general-purpose agent harness on a large model spent 1,000+ tokens to log a coffee, and how I balance autonomy and strict rules across my stack.

Running a general-purpose agent harness on a large model burned 1,000+ tokens just to log a coffee.

The first version of my personal expense tracker ran inside a general-purpose AI agent harness backed by a large model smart enough to pass a financial analyst exam, even though its entire job was to log "coffee, 120".

When I first wired the bot up in a messenger, I took the obvious shortcut: I connected incoming messages straight to a full agent harness with tool calling. The problem was not just the size of the model. It was the combination of a heavy model and a broad, general-purpose agent harness.

Because a general-purpose harness is built to handle almost any task, it is not specialized for any single workflow. In practice, it burns roughly the same baseline token overhead on logging a coffee as it does on investigating a DevOps incident. Every message forced the harness to reload AGENTS.md instructions, the full catalog of available tools, tool-selection reasoning, and tool-call requests. Logging one coffee cost 1,000+ tokens, and whenever the agent inspected state or chained calls, a single entry reached tens of thousands of tokens for a parsing job that only needed a few hundred.

Too much freedom also hurt reliability. Within a week of running daily entries in one long chat session, context piled up, responses slowed down, and the model started drifting on repetitive entries. Because an unconstrained LLM is non-deterministic, sending the exact same expense item on different days produced slightly different category names or landed in different categories altogether.

That pushed me toward a simpler architecture: replace the open-ended agent with a deterministic backend application, keep just a drop of intelligence at the entry point to turn voice or text into structured data, and tune the application rules and the parsing prompt separately. Model cost dropped close to zero, latency disappeared, and the data became consistent.

Building and breaking that tracker shaped how I design all of my AI systems today as a Senior Backend Engineer and AI Solutions Architect at a private marketing company in Thailand.

A Continuous Balance, Not Rigid Walls

The 4-Level Intelligence Pyramid: a continuous scale balancing reasoning freedom against strict rules.

Coming from traditional backend engineering (PHP, Go, Python, SQL, Redis, RabbitMQ, and Elasticsearch), I am used to treating compute and memory as budgets. Combining heavy models with broad agent harnesses creates a huge space for optimization once I treat intelligence the same way.

I map my stack as a 4-Level Intelligence Pyramid with the Human at the apex.

The levels of this pyramid are not rigid walls between isolated tools. They represent a continuous balance between autonomy and rules. Moving up the pyramid adds more intelligence, broader freedom of action, higher token cost, and more variance. Moving down the pyramid tightens the rules, increases speed and determinism, and handles much higher volume.

At the very top sits the Human (ideas, product intent, and final accountability). Below that apex sit four execution layers, and any workflow can slide up or down between them depending on how much freedom it actually needs.

Level 1: Strategic Agents (Architecture and Direction)

Level 1: High-level agents work with broad context to plan architecture and produce approved technical briefs.

Right below the human apex sit Level 1: Strategic Agents. This is where top reasoning models and broad exploration actually belong.

When I start a new service or redesign a workflow, I intentionally state my vision at a high level so low-level implementation details do not clutter the core idea. A Strategic Agent helps me expand that vision: weighing trade-offs across data models, service boundaries, and security rules, and deciding which parts of the system genuinely need model intelligence and which parts should be plain code. Because architectural planning happens a few times per feature rather than thousands of times a day, paying for broad context and deep reasoning here makes sense.

A Level 1 agent never types production code or touches live servers. Its output is an approved technical brief for the level below.

Level 2: Dev-Team Agents (Full Agents Inside a Static Pipeline)

Level 2: A static pipeline orchestrates the workflow, while each step runs a specialized agent with its own toolset.

Once I approve the brief, the work drops to Level 2: Dev-Team Agents, where strong models turn that brief into working code.

When coding agents are given too much freedom inside an open-ended harness, two things happen: they make unrequested decisions outside their scope, and side problems pull them away from the original plan. To prevent that, my development workflow is structured like an application with a strict, static pipeline: a lead agent splits the approved brief into small, atomic tasks, developer agents write the code, an independent review agent checks the diff against the spec, and automated test suites gate the merge.

Inside each step of that static pipeline, however, the worker is still a full AI agent. A developer or reviewer agent has real autonomy to inspect files, run commands, and solve problems, but it is constrained by three things: a narrow task, an isolated context, and a fixed set of tools matched to its specialty. Splitting work into small, single-task sessions eliminates roughly 90% of context bloat while keeping every agent on track.

Level 3: Apps with a Drop of AI (Scripts Decide, Small Model Structures the Data)

Level 3: Scripts control every decision, calling a small model at a single point only to turn unstructured data into a strict schema.

It is easy to confuse Level 2 and Level 3 because both combine code and AI, but the degree of freedom is completely different:

At Level 2, the outer pipeline is fixed, but each step runs a full agent that chooses which tools to call and how to solve its narrow task.
At Level 3, there are no agents and no tool-calling choices at all. Level 3 is essentially a Level 4 script with a drop of intelligence at the entry point: whenever incoming data is unstructured, a small model (optionally paired with speech-to-text) converts that raw input into a strict schema first, and then deterministic scripts execute the rest of the structured flow.

My rebuilt expense tracker lives here. When I send a voice note or text message, speech-to-text transcribes the audio and a small (~24B parameter) self-hostable model extracts amount, currency, and a category chosen strictly from a fixed list stored in my database. Standard backend scripts then show me a quick confirmation, write the validated record to the database, or run spending queries over any date range. Whenever I want to improve the tracker, I can either adjust the deterministic application rules or tune the narrow parsing prompt independently.

When I build Level 3 services, I follow one rule:

I don't hope the model won't fail. I assume it will.

Because I assume the model can fail at any moment, the model never controls application flow or touches storage directly. Deterministic scripts wrap that single inference call on both sides and validate every field before anything is saved.

Level 4: Plain Scripts (Pure Tools, Already Structured Data)

Level 4: Purely deterministic scripts and tools that operate on structured inputs with zero AI.

At the base of the pyramid sits Level 4: Plain Scripts, where inputs are already structured and there is no unstructured data to interpret at all.

Level 4 serves two roles in my stack:

Standalone static workflows that run on a schedule or a button press with zero AI.
Hard-coded CLI tools for higher layers: when an agent at Level 2 or an app at Level 3 needs to trigger a critical action, it calls a Level 4 script with strict rules and predefined parameters so it cannot improvise flags or break the system.

My deployer is the clearest example. When I tried letting capable agents run deployments directly, they occasionally added extra steps or skipped checks. Now my deployer is a pure Level 4 tool built on standard deterministic scripts. Whether I trigger a release from a button or through a voice command, the script runs the exact same sequence every time: fast, cheap, and identical on every run.

Sliding Up and Down the Pyramid: Start Smart, Then Make It Dumber

Each level does only what it is best at. The smarter the level, the fewer the tasks.

As the pyramid diagram above shows, this architecture works in two ways at once.

First, a single project flows top-to-bottom through the layers: I start with an Idea at the apex, Level 1 turns it into an architectural Plan, Level 2 agents build the separate Parts inside a static pipeline, Level 3 apps Assemble unstructured runtime inputs into structured flows, and Level 4 scripts mechanically Polish, test, and deploy the result.

Second, individual workflows migrate down the pyramid over time as I learn their edge cases (start smart, then make it dumber):

Explore at Level 1 or Level 2: When a task is new and unpredictable, I use high-level agents to discover what real inputs look like and where the edge cases hide.
Tighten the pipeline at Level 2: Where agents still need to reason and use tools, I lock their outer workflow into a static state machine with narrow tasks and isolated contexts.
Compile into Level 3 and Level 4: Where intelligence is only needed to turn unstructured data into a schema, I replace the agent with a single small-model parse inside a Level 3 script. Where the input is already structured, I lock the logic into a pure Level 4 script.

This also answers how a system keeps its context when tasks move down to smaller models or scripts. Persistent memory does not have to stay in a raw chat history reloaded on every turn. In my setup, each lower level of the pyramid is the compiled context from the level above, materialized as static pipelines, fixed database categories, and deterministic scripts.

Spend reasoning tokens where real decisions happen, and lock repeatable patterns into rules and scripts.

Each level of the pyramid does only what it is best at, and the smarter the level, the fewer tasks it handles. Whenever a workflow becomes predictable, I dial down the open-ended intelligence and dial up the rules. Spend the intelligence budget where real decisions happen, and let deterministic code handle the rest.

I am Mykola (Nick) Skalenko, a Senior Backend Engineer and AI Solutions Architect building distributed backend systems (PHP, Go, Python) and multi-agent engineering workflows. More of my architecture notes are on LinkedIn and X (@NikolaySkalenko).

From ~9 Commits a Month to ~700: How I Moved from Writing Code to Directing an AI Engineering Department

Mykola (Nick) Skalenko — Tue, 27 Oct 2026 10:46:33 +0000

What changed after 7+ years of backend engineering in PHP, Go, and Python when I stopped typing every line by hand and built a role-based pipeline of AI agents.

2019 vs. 2026: Moving from writing every line by hand to running a role-based pipeline of AI agents.

In 2019 and 2020, my personal GitHub account averaged ~9 commits a month. Back then, I wrote every line by hand, spent evenings tracking down missing characters in my IDE, and handled every part of a feature myself, from database schema design to deployment.

Over the last 30 days in 2026, that same personal GitHub account logged ~700 commits (roughly 75x my 2019-2020 pace) and 328 merged pull requests across 14 repositories. Every commit came from a small, focused pull request with automated tests, and I typed almost none of the application code by hand.

After more than seven years of backend engineering in PHP, Go, and Python, my day-to-day work at a private marketing company in Thailand shifted from writing code myself to writing system specs, setting service boundaries, and running a role-based pipeline of AI agents. Below is how that pipeline works in practice, where agents break things when a spec is vague, and the CI and deployment checks I put in place to keep those repositories stable.

1. Writing Specs Instead of Hunting Typos

Why coding agents shift the effort from fixing syntax errors to writing unambiguous technical specifications.

When I first started using coding agents on backend services, I tried giving them short, two-sentence prompts and letting the model figure out the details. On a real codebase, that fell apart within a week. Coding agents rarely make syntax typos, so I no longer lose hours to a missing semicolon or an off-by-one loop counter. Instead, things break when a task description leaves an edge case open to interpretation.

A concrete example came up in my internal server fleet service, where I needed an endpoint to "probe the machine connection" and verify whether a remote host was reachable. Because my initial brief did not specify what should happen when a host is down, the agent had to guess: should the endpoint return HTTP 200 with an "unreachable" status saved in the database, or fail closed with HTTP 409? When five agents work on related tickets across parallel branches and the spec does not spell that out, each agent invents its own retry loop and status convention. At merge time, nothing fits together.

Because of that, I now review technical specs with the same care I used to put into code reviews:

Which state transitions are valid, and which ones must be rejected?
Which database fields are read-only metadata, and which ones represent server configuration that triggers an update when changed?
What is the exact HTTP status code, error payload, and timeout for every failure path?

If I define those rules up front, the agents write clean, predictable code. If I leave a gap in the spec, five parallel agents will write five incompatible workarounds inside half an hour.

2. Why Backend Experience Still Drives the Architecture

Seven years of PHP, Go, and Python backend work now go into system boundaries, database performance, and failure recovery.

Before I built this workflow, I spent over seven years working on backend systems under production load. Over those years, I built order-lifecycle state machines handling thousands of orders a day, company-wide authorization and 2FA services handling thousands of requests per minute, and distributed VoIP telephony services covering contacts, billing, and call routing. A lot of that work meant profiling PHP and SQL queries down to the millisecond, tuning Elasticsearch indices for large-scale analytics reports, and splitting the heaviest domains out of monolithic Yii2 and CodeIgniter codebases into Symfony services and compiled, concurrent Go microservices.

I still rely on that exact same backend experience every day. Any decent model can generate a FastAPI endpoint, a Go binary, or an Alembic migration in ten seconds. What the model will not notice on its own is that a new query filters on an unindexed column that will lock a production table at peak traffic, or that an error handler might dump raw SSH keys or tokens into an application log.

The model handles the boilerplate and language syntax. Deciding where service boundaries sit, how state machines recover from partial failures, and how data moves between queues and databases is still on me.

3. Why One Long Chat Fails, and How My 5-Role Pipeline Works

How work is split across five distinct roles so no single agent gets lost in a long chat thread.

Early on, I tried doing everything inside a single long chat session: brainstorming the architecture, editing ten files, pasting stack traces, and debugging deployment scripts in the same thread. By turn twenty, the context window was full of abandoned ideas and contradictory instructions, and the model started undoing its own earlier fixes.

To keep each agent's context small and focused, I split the workflow into five separate roles, much like a regular engineering team:

Architect (Me): I define the system architecture, service boundaries, data contracts, and security rules, and I do the final review before anything merges.
Tech Lead Agent: Reads my initial task brief, inspects the target repository, and writes a detailed technical specification.
Team Lead Agent: Breaks that approved spec down into small, self-contained GitHub issues with explicit acceptance criteria.
2 to 5 Developer Agents: Pick up individual issues on isolated Git branches, write the code and tests, and open pull requests.
Review Agent and Automated CI: Check the pull request diff against the issue requirements and run the full test and migration suite before the PR reaches me for squash-merge.

From a voice note in a messenger to a reviewed, squash-merged pull request.

Each role only sees the artifact it needs: a spec, a single GitHub issue, or a pull request diff. No agent has to read through fifty messages of back-and-forth debugging history.

Most days, I start a task by sending a voice note in a messenger while away from my desk. An orchestrator service transcribes the audio into a draft brief, I review and approve the resulting spec, and the pipeline picks up the implementation. A full feature goes from voice note to merged PR in under 2 hours, and for small, well-defined changes, the whole loop finishes in 5 to 7 minutes.

4. Production Guardrails: What Changed After a Credential Rotation Froze a Deploy

Shipping ~700 commits and 328 pull requests in a month requires strict automated checks before anything reaches production.

When 328 pull requests land across 14 repositories in a single month, writing the code is no longer the slow part. The real work is making sure five parallel branches do not conflict on database migrations, expose internal ports, or leave a server half-deployed.

I learned this the hard way early on, when rotating a database and API credential froze a production deployment for hours because the deploy script relied on cached environment variables that had been set manually on the host months earlier. When one developer ships nine commits a month, manual server tweaks and "works on my machine" rarely hurt right away. When five developer agents push pull requests all day, any hidden state on a server will eventually break a release.

Every pull request runs against a clean Postgres container and port policy checks in CI.

Today, every repository in my stack runs four automated checks before code can reach production.

First, every pull request runs against a clean Postgres database in CI. The runner boots a fresh container, runs every schema migration from scratch (alembic upgrade head), and executes the test suite. If a migration fails on an empty database or conflicts with another branch, the PR is blocked automatically.

Second, CI renders the full Docker Compose configuration and checks port policies to make sure internal services never publish unintended ports on the host interface.

Third, agents never SSH into servers or run manual deploy commands. All deployments go through a deterministic, manifest-driven deployer that writes scoped secrets at runtime with 0600 permissions and checks /health/live endpoints before marking a release healthy.

Finally, no agent has permission to merge to main. Every squash-merge requires a green CI run and my sign-off on the diff.

5. Same Engineering Fundamentals, Different Layer

The daily work moved from typing syntax to defining architecture, specifications, and deployment checks.

Seven years of writing PHP, Go, and Python taught me how backend systems fail when traffic spikes, migrations lock tables, or network calls time out. Stopping hand-coding did not change any of those failure modes. It just moved my job up one layer: writing clear specs before any code is generated, keeping each agent in a narrow role, and letting automated CI and deterministic deployers catch mistakes before they hit production.

About the Author

Mykola (Nick) Skalenko is a Senior Backend Engineer and AI Solutions Architect with 7+ years of experience building distributed systems in PHP, Go, and Python. He currently designs and directs multi-agent engineering and automation systems for a private marketing company in Thailand.

LinkedIn: Mykola Skalenko
X (Twitter): @NikolaySkalenko