Костянтин

OPEN TO FULL-TIME & CONTRACT

Kostiantyn
Biektin
[открыть контакты](см. выше в блоке «контактная информация»)
[открыть контакты](см. выше в блоке «контактная информация»)
Full-stack developer · Kyiv, Ukraine github.com/kostyabek

Five years of building back-ends in C#, front-ends in React, and shipping the whole thing to Azure.
Disciplined about task execution and about life balance — quick on the uptake, punctual, always open to a
conversation.

WORK Full-stack Developer → Dev Team Lead, Aloto 07/2023 — now

› Acted as principal engineer for the whole product.
› Primary feature owner — guidance, consultations and reviews for the team.
› Solo-built the foundational layer and common libraries; maintained infrastructure for all
environments.
› Ran engineering interviews for positions from trainee to middle level.
› After becoming dev team lead, migrated the system from microservices to a modular
monolith — faster development and a smaller cloud bill.
From microservices to a modular monolith → overleaf
What agentic development changed → overleaf

Trainee → Middle Full-stack Developer, GlobalLogic 12/2021 — 07/2023

› Part of several teams on one large veterinary-domain platform.
› Contributed across the stack, from unit tests to microservice communication.

Junior .NET Developer, LegioSoft 07/2021 — 11/2021

› Back-end developer on a solution for busy real-estate agents.
› Worked directly with a foreign client on solutions and clarifications.

Senior Assistant, Petro Mohyla University 12/2020 — 09/2021

› Maintained several computer labs, their legacy equipment and software.

SKILLS
C# ASP.NET TypeScript React Azure DevOps PostgreSQL

Microsoft SQL Server Agentic AI Development MUI Auth0 Stripe Cloudflare

Leadership Team Management

EDUCATION Master's, Computer Science 09/2023 — 12/2024

Petro Mohyla Black Sea National University

Bachelor's, Computer Science 09/2019 — 06/2023

Petro Mohyla Black Sea National University

LANGUAGES OFF THE CLOCK
ALSO
Ukrainian C2 Volleyball and the gym keep the week
English B2 structured. A quiet interest in fragrances,
and very rare gaming sessions.

[открыть контакты](см. выше в блоке «контактная информация») [открыть контакты](см. выше в блоке «контактная информация») github.com/kostyabek 1 / 6
ALOTO · DEV TEAM LEAD

From microservices to a modular
monolith
CASE STUDY PERIOD 11/2025 — 02/2026

A service-per-domain architecture chosen for a team that never grew to fit it. Consolidating it into a
modular monolith kept the domain boundaries that were working, removed the network hops that were not,
and cut monthly cloud spend by 40%.

STACK C# ASP.NET Core PostgreSQL Azure Azure Service Bus Azure DevOps React

TypeScript

OUTCOMES -40% 8 → 1 4× faster
Cloud spend Deployable units CI pipeline
Azure bill, falling with each Eight services, each with its Full build and deploy of the
service merged own database and pipeline, into core services
one API host

CONTEXT The product is a B2C/C2C marketplace for sustainable shoppers, built and run by 4
engineers.

The system had been built as 8 independent services communicating over HTTP and a
message broker, each with its own database and deployment pipeline. That shape was
chosen by the previous technical leadership, to leave room for scale.

THE PROBLEM Microservices trade local complexity for distributed complexity. That is a good trade when
independent scaling and independent deployment are worth paying for. Neither was true
here:

› Cost — every service carried its own always-on compute and its own database, so the
floor of the bill was set by service count, not by traffic.
› Change cost — a typical feature touched 2–3 services: a pull request and a deploy for
each, plus a contract version to keep in step.
› Debugging — a single user action usually crossed at least 2 network boundaries, so
tracing one failure meant correlating logs across all of them.
› Team shape — 4 engineers, 8 services. Nobody owned a service exclusively, and
everyone paid the coordination cost.
› Data — reads that should have been a join became fan-out calls, and consistency had to
be reassembled in application code.

WHY A MODULAR The domain decomposition was not the problem — the deployment decomposition was.
MONOLITH, NOT A The services drew sensible boundaries around identity, payments, affiliate integrations
REWRITE
and brands, and those boundaries were worth keeping. What they did not need was a
network between them.

So the target was one deployable unit containing the same modules, with the boundaries
enforced by project structure instead of by the network. Each module is a separate
project, cross-module references are restricted, and everything a module offers the others
goes through an explicit contracts project that acts as its public API.

A boundary crossed the wrong way now shows up in the reference graph rather than in a
production trace, and is easily spotted in review.

[открыть контакты](см. выше в блоке «контактная информация») [открыть контакты](см. выше в блоке «контактная информация») github.com/kostyabek 2 / 6
 The alternative was a partial rewrite — merging some services and leaving the rest as they
were. It was rejected because it would have meant holding two architectural mindsets at
once.

ARCHITECTURE One host process serves the API. Each module is a separate project holding its own
endpoints, with no reference to any other module's implementation, and a single
PostgreSQL instance holds one schema per module.

› In-process calls against published contracts for synchronous work, and Azure Service
Bus for the rest — identity changes and data invalidation.
› One database, one schema per module. Replication gave way to database-level views.
› No project may reference another module's implementation — only its contracts.
› The front-end apps needed a configuration change and nothing else; routes and
payloads stayed as they were.

RUNNING THE Services were folded in one at a time rather than in a single cutover, so the two
MIGRATION architectures ran side by side for 4 months.

Feature work continued throughout. The capacity reserved for it dipped, but not by
enough to break delivery consistency.

OUTCOMES Azure spend fell 40%, and a full build and deploy went from 12 minutes to 3.

Day to day, a feature that used to span several repositories is now one pull request against
one solution. A new engineer gets a working local environment in 10–15 minutes, rather
than 1–2 hours. Tracing a request no longer means stitching logs together across services
— there is one process, and one trace.

TRADE-OFFS AND The monolith has costs of its own, and they are real. Scaling is all or nothing: a module
WHAT I'D under load can only be given headroom by scaling everything around it. A one-line change
REVISIT
redeploys the whole application. A single faulty module can take the rest of the process
down with it. And boundaries the network used to enforce now rest on project structure
and review discipline, which is the weaker guarantee.

Splitting a module back out stays on the table, and per-module usage is monitored with
that in mind.

[открыть контакты](см. выше в блоке «контактная информация») [открыть контакты](см. выше в блоке «контактная информация») github.com/kostyabek 3 / 6
ALOTO · DEV TEAM LEAD

What agentic development
changed
CASE STUDY PERIOD 01/2026 — 08/2026

Coding agents write faster than a small team can review. The work was not adopting them — it was building
the contracts, skills and gates that make their output checkable, so that a standard stops being a
document nobody reads and becomes a build that fails.

STACK Claude Code Codex MCP Playwright Figma C# TypeScript React ESLint

Azure DevOps

OUTCOMES 0 → 29% 583 → 75 0 → 826
Commits agent-assisted Grandfathered violations Automated tests
Share of monthly commits Legacy adaptivity debt, cleared A published package that had
across the team's repositories, across 8 pull requests in 14 none; its next major built
by 08/2026 days behind a suite written alongside
it

CONTEXT Four engineers on a live marketplace, and 41 repositories between them — eleven API
repositories consolidating into one, eight React front-ends, fifteen NuGet packages,
scheduled jobs, edge workers and internal tooling.

Coding agents removed the constraint that used to set the pace. They did not remove the
one that replaced it: at four people, review capacity is the ceiling, and an agent that writes
ten times faster than a human reads is not ten times more useful.

I led this and wrote most of it. Agent-assisted work stayed concentrated in two of us —
which is the honest shape of it, and part of why the enforcement had to live in the
toolchain rather than in a convention everyone was asked to remember.

THE PROBLEM An agent will do what the surrounding code does. That is usually the point, and
occasionally the whole problem:

› The buyer portal carried seven brand greens and 611 raw hex literals across 147 files.
Asked to match a design, an agent would faithfully reproduce the mess, because it
could not tell a deliberate variant from a typo.
› Standards lived in documents. A written rule that no tool enforces decays the moment
delivery pressure arrives — and an agent has no way to read a convention that exists
only in a reviewer's head.
› Agents mark their own homework. Left alone, one signs off by reading its own diff —
which catches the defects it already knew about and none of the ones it did not.
› Instructions did not travel. Every new repository, and every new session, started by re-
explaining the same conventions from scratch.

WHAT WAS BUILT Three layers, each addressing one of those. None of it is model-side — it is ordinary
engineering applied to a new kind of collaborator.

› Agent contracts — one instruction file per repository, holding the rules that override an
agent's defaults rather than restating them. Where the pattern is fully rolled out it lives
under a tool-neutral filename, so the same contract serves whichever runtime opens
the repository.

[открыть контакты](см. выше в блоке «контактная информация») [открыть контакты](см. выше в блоке «контактная информация») github.com/kostyabek 4 / 6
 › Portable skill bundles — three skills covering design-to-code, adaptive layout and
browser verification. The procedure files are identical across repositories; porting the
bundle means rewriting one profile per skill, its data maps, and a small harness adapter
— everything else copies verbatim.
› A profile field can be a value, or it can be none — meaning the rule genuinely does not
apply here, stop looking for it. An absent row reads as an oversight and invites the agent
to improvise; an explicit one reads as a decision.
› Gates in the toolchain — the adaptivity standard compiles down to lint rules and a
static scanner whose error messages cite the rule by ID and name the file that explains
it. A rule violation is a failing build, not a review comment.
› Verification runs in a real browser across eleven widths, three of them sitting just below
a breakpoint — 599, 899, 1199 — because that is where the defects are, rather than at
the round numbers the designs are drawn at.

WHAT THE MODEL One rule turned out to matter more than any other, and it arrived independently in three
DECIDES, AND different projects before I noticed it was the same rule: the model does perception and
WHAT IT MUST
judgment; deterministic code owns every identifier.
NOT
A hallucinated identifier is the worst class of defect an agent can produce, because it is
indistinguishable from a correct one at review time. It looks like a GUID. It passes a glance.
It fails in production, on a row nobody was looking at.

› A product-seeding skill classifies garments from photographs into the taxonomy —
genuinely a judgment task — but every identifier it emits comes from a command-line
lookup, and the instruction is blunt about it: never invent GUIDs.
› An affiliate-feed job has a model map supplier feed rows onto that same taxonomy, then
hands the output to a separate deterministic validation stage on the stated principle
that LLM output is not trusted. Its end-to-end proof run produced zero invalid
identifiers, behind 146 tests at release and 186 by the time the follow-on work paused.
› A taxonomy cleanup ran as re-runnable scripts behind a hard validation gate rather than
as hand edits, so the ship criteria were assertions — eight checks, exit zero — rather
than a reviewer's judgment. It produced the taxonomy file the catalogue seeder
consumes.

WHAT CHANGED IN The clearest before-and-after is structural rather than a stopwatch. A published package
PRACTICE that had no tests at all now has a breaking 2.0.0 built behind 826 of them — written beside
the release rather than promised after it, with the upload deliberately held pending re-
verification. The adaptivity standard went from a document to a build failure, and the
legacy debt it exposed fell from 583 grandfathered entries to 75 over 14 days and 8 pull
requests.

The ratchet holding that number down is the part worth copying: entries may only be
removed, never added, and an entry that no longer matches a real violation fails the scan.
New work cannot be grandfathered, and the list cannot quietly rot.

Review moved earlier. An adversarial review pass runs before a human sees the branch, and
across nine phases in the two back-end repositories it raised 119 findings — each one
triaged, fixed or consciously deferred with a note, before reaching the one thing four
engineers cannot manufacture more of.

Scope per unit of calendar time moved with it. Folding the standalone identity service into
a module of the monolith — four phases, eleven plans — closed across two days of
sessions, and the whole skill bundle ported to the second front-end in one.

Breadth is the summary of all of it. Agentic artifacts now cover 12 of the 41 repositories
and nine carry a written agent contract — chosen rather than blanketed, the ones with
enough ongoing change to repay the setup. Across the tree, 423 commits carry an agent
co-authorship trailer, reaching 29% of commits by August 2026. That count tracks one
runtime's trailer only, so it understates rather than flatters.

[открыть контакты](см. выше в блоке «контактная информация») [открыть контакты](см. выше в блоке «контактная информация») github.com/kostyabek 5 / 6
TRADE-OFFS AND The discipline has a bill, and it comes due in three places.
WHAT I'D
REVISIT › Verification the agent cannot run gets deferred indefinitely. The API repository has no
test suite, so its acceptance checks need a running host — twelve of them accumulated
unclosed over one milestone. Nothing was fabricated, which is the important part, but a
gate only a human can close is a gate that waits.
› The system carries real overhead. Planning, research, review and verification artifacts
run to tens of thousands of lines. It earns that on migrations and releases; on a one-line
fix it plainly does not, which is why an out-of-band lane exists for small work.
› The skill bundles are duplicated per runtime and kept in step by hand. They have drifted
before. A recursive diff catches it; nothing automated does, and that is the next thing I
would fix.

[открыть контакты](см. выше в блоке «контактная информация») [открыть контакты](см. выше в блоке «контактная информация») github.com/kostyabek 6 / 6