Agents Don't Fix Broken Engineering Organizations — They Accelerate Them

Most practitioners writing about agentic engineering come from either hyperscaler-sized teams or greenfield startups. Who were you building for, and why does it matter?

Oleh Mamchych: The CTO in the middle. Real revenue, real engineering, real cost pressure, a stack wide enough to be hard to hold in your head — and a real struggle to get agents to actually work inside that setup. I believe thousands of small and medium ISVs are in exactly that shape right now. Most of what gets published assumes you either have a platform org of two hundred engineers or nothing to break. Neither describes our situation. And these are exactly the companies showing up at SoftServe's door right now, asking us to help them figure it out.

The Prerequisites: What Has to Be True Before Agents Can Help

If you were starting over from day one, what's the first thing you'd put in place? 

Oleh Mamchych: Metrics. In any transformation, it's critical to ensure the product is wrapped in metrics before you wrap it in agents. Agents will land code fast. You need to see, the next day, whether what just landed made the product better — and revert if it didn't.

I keep three buckets:

• North-star: revenue, MAU, NPS — the numbers on which the company is actually built.
• Day-to-day: DAU, sign-up to subscription, activation milestones — the numbers a feature team owns.
• Counter-metrics: infrastructure cost, churn, availability, latency — the numbers that catch the regression you didn't predict.

When code starts landing at agent speed, this is your safety net. Anything that misbehaves shows up in a counter-metric within a day and gets reverted. Without that net, you're flying blind at three times the speed.

What about infrastructure? Where does IaC fit into this?

Oleh Mamchych: Second, immediately after metrics. If you let agents prompt your cloud directly, sooner or later they will hallucinate something into production, and you won't realize what just happened. A Terraform repository fixes this completely. Every change is a diff you can read. And if you ever want to know what's different between dev and prod, you can ask the agent, and it will tell you in seconds — because the answer is just a directory diff.

Pair that with a dev environment that's genuinely cheap to spin up and tear down. Experimentation has to be friction-free, because the whole point of agentic engineering is to try more things, faster. If standing up a dev environment is a half-day chore, the agent won't bother. Neither will your engineers.

You're known for a strong view on service size and structure. What's the real reason that matters?

Oleh Mamchych: It's really about context management — that's the frame people miss. When we started, models behaved badly beyond roughly 100k tokens of context, and even within that window, quality degraded long before the limit. Every line of code the agent had to hold in its head to make a change was a tax on the change.

The pragmatic fix was to carve the codebase down to a size the model could actually hold — and then keep it carved. Microservices, in other words, but the goal was never 'microservices.' The goal was: the agent should not have to read code that has nothing to do with the task.

Two things made it work. First, the services shared a standard shape — every backend service had at most a few possible components: a REST API (mandatory) and, optionally, a database, a cache, an input queue, and an output queue. Second, contracts between services were explicit and stable, so the agent working on one service almost never had to load another to understand the boundary.

I'll add that the model curve has changed the prescription — current models work well over large, well-structured codebases, and the cost of carving everything into small services is real. But the underlying principle hasn't changed: control how much context the agent has to operate in, and keep it as small and uniform as you can.

Closing the Loop: Specs, Tests, and What It Means to Own a Feature

You describe 'closing the loop' as the most important step. What does that mean in practice?

Oleh Mamchych: With metrics, IaC, and clean small services in place, you now have the conditions to let the agent run a real production loop: try, verify, iterate, until acceptance criteria pass. Two things make that loop reliable.

First, spec-driven development. The spec is the asset, not the code. When a hallucination happens — and it will — you revert, clear state, refine the spec, and start from scratch. The cost of a restart is small precisely because you wrote the spec down. If you only have the code and the chat transcript, the rollback is expensive, and the next attempt repeats the same mistake.

Second, tests — ideally end-to-end. On backend services, with a mocked local database and well-defined input and output contracts, end-to-end tests work like magic for an agent. They're the acceptance signal the loop needs, and the constraint that keeps the agent honest.

What happened to your engineering team's role when most of the code was being written by agents?

Oleh Mamchych: The bigger shift wasn't headcount — it was what the engineers I already had actually did. With most of the code being written by agents, the role had to evolve, or it wouldn't survive. Engineers stopped being defined by the code they typed and started being defined by the feature they owned.

Owning a feature meant that on day one, before any code was written, you set up your own analytics dashboard for it — so that when the feature landed, you were the one watching it move, or not move, against the metrics. That single change pulled people out of the 'agent-tamer' mindset and into being actual result owners. Over time, those engineers became visibly more T-shaped: they kept their depth, but they picked up the analytics instinct, the product judgment, and the customer-facing thinking that the old role had outsourced to other functions.

This is the piece I'd emphasize most if I were starting over, and the piece I almost missed the first time.

Where did agents consistently underperform for your stack, and what did you do about it?

Oleh Mamchych: The UI was our hardest case, which surprised a lot of people. On a clean codebase, agents often do well on UI. Ours was the opposite: pixel-perfect expectations from a designer-CEO who inspected every screen, years of legacy code across both mobile and web apps, and a UI surface under constant small iteration — new flows, A/B tests, polish, features. The combination was the worst-case scenario for an agent: a codebase that was always being touched, never structurally cleaned up.

The refactor required to make agents productive was real, and pausing the customer-facing surface to do it wasn't a risk our investors would sign off on. So I made the bet the other way: no new backend or DevOps hires, and instead invest in mobile and frontend engineers. Over time, those people did the refactor themselves — splitting the frontend into micro-frontends, standing up the design system, wiring in the Figma integration — and that's what eventually unlocked agentic speedup on the UI side.

The lesson: find the spots where agents are weak for your stack and your team. Hire there. And give the engineers you already have a bigger surface to own, because the role is changing whether you plan for it or not.

Data, Architecture, and the Power of the Prototype Data engineering was the core of your business. How did agents perform there?

Data engineering was the core of your business. How did agents perform there?

Oleh Mamchych: For pipelines, the spec-driven recipe worked beautifully — spec-driven development plus a good local sandbox where the agent could verify its pipelines produced the right outputs. The harder problem was data architecture: which storage shape, which index, which partitioning strategy. Agents weren't great at that.

What unlocked it was POCs. Every time we had an idea like 'what if we restructured the storage so retrieval latency drops,' an agent would build a quick proof of concept against that data model and populate it with realistic data. We'd measure ingest speed, retrieval speed, and storage footprint directly. The agent couldn't pick the right architecture from first principles — but it could build the experiment that picked it for us.

Don't undervalue that step. POCs are the bridge across the part of the design space where agents are weak.

You also replaced SaaS UIs with pipelines. Can you explain that shift?

As a small-company CTO, you wear every hat: analytics, marketing, product, sales, and engineering. We used many external tools — Amplitude, HubSpot, Klaviyo, Google Analytics, Stripe, and several others. The unlock was unexpectedly simple: every external tool dumps its raw data into the data lake every day. An agent wrote me a handful of pipelines that produced exactly the datasets I needed to answer the questions I actually had. It turned out to be faster than clicking through any of those tools' UIs.

The same pipelines fed one-pager dashboards the whole company used, so the analytical layer of the business sat on infrastructure we controlled, not on five different vendor UIs. When the UI was genuinely the right interface, we kept it. But the default flipped: pipelines first, UIs only if they earned their place

The Real Thesis

After a year-plus of running this, what's the one thing you'd want a CTO to internalize before they start?

Oleh Mamchych: Agentic SDLC is not really about agents. It's about how you reshape the organization so that agents can thrive: the measurement layer, the infrastructure layer, the code structure, the dev loop, the staffing plan, and the data layer. Once those are in place, agents are obvious. Without them, agents become a liability that pushes bad code out faster.

This is exactly what we at SoftServe do every day for our clients through the Jumpstart program — also known as Activation PODs: help organizations transition to a world where agents can be the most successful versions of themselves.

Has the prescription changed as models have improved over the past year?

Yes and no. Microservices, for example, no longer feel like a hard requirement — current models work well over large, well-structured codebases. But the underlying discipline is unchanged: control how you measure the product so you can tell if you're doing well, then find the places where agents are strong and the places where — for your specific stack and team — they are weak, and act on both.

The prescription will keep moving. The discipline of looking honestly at where agents help and where they hurt, and shaping your organization in response, will not.