README.md / Alexander Stepanchenko / Product Engineer

A resume is good at showing where I worked, which technologies I touched and what my job titles were. That is what it is for.

Still, a resume does not really show how a person works. There is no place for things like why I may care about the browser Back button, why a slow CI annoys me almost as much as a broken interface, or why I treat tech debt as actual debt rather than a nice phrase from engineering discussions.

This page is about that.

It contains the things that usually do not fit into a resume, social profile or a standard "about me" field. In format, it is closer to a README for a person you may work with.

I am a product engineer. You can give me a complicated and still muddy task where product, design, backend, frontend, integrations, old code and organizational fog are all mixed together. I will unpack it, build a workable plan, get it to release and try not to leave a minefield behind.

I am useful when a task is already expensive, but still badly shaped.

This happens a lot. Everyone more or less understands what needs to be done, then you start digging and suddenly there are requirements, design, legacy, integrations, strange constraints, old decisions nobody wants to touch and something from the "we will explain that later" category.

I am fine with that. I do not wait for a perfect spec, I just dig in, ask questions, look at the whole product and gradually pull a structure out of the chaos, something that can actually be turned into code.

Working chaos does not stress me. Good solutions often appear in that kind of mess, while bureaucracy can kill creativity before it becomes useful.

Still, someone has to pull a consistent structure out of that chaos and translate it into code. I see systems and repeating patterns where others may only see a mess, and I adapt engineering to reality without trying to tidy up the whole company.

AI has sharply lowered the entry barrier. Now a similar service can be assembled in a couple of weeks by a competitor, a small team or one person with a Claude Code subscription. Rougher, simpler, sometimes almost funny, but close enough for users to start comparing.

Just "making it" is not enough anymore.

My value here is quality. The product should open faster, behave more clearly when something goes wrong, work properly on a phone, preserve familiar flows and avoid annoying people in the first few minutes.

A user does not owe you an explanation of why it feels good or bad. They simply stay or leave.

Why this matters more now

An average product used to survive on an almost empty market. There is less empty space now. There will be many similar services, sometimes a lot of them, and if your product feels as raw as another AI-built thing assembled in a hurry, the user does not care how many meetings you had or how nice the roadmap looked.

I actively use AI. I also keep my feet on the ground.

AI speeds up work when it is managed by a person who understands the product and the code. I run agents like an additional team, give them tasks, review the output, make them redo weak parts and watch that the code stays human.

Without that control, speed quickly turns into technical debt. It is a boring thought, but practice keeps confirming it.

For me AI is an amplifier. It is still far from autopilot.

How I keep AI under control

When there is a lot of work and not enough hands, AI really changes the scale. One strong engineer can cover pieces that would have required a team before. The responsibility stays with the engineer though.

Code produced with AI becomes project code. People will read it, fix it, evolve it and explain it to someone new. If a specific AI tool gets expensive, disappears or starts answering worse tomorrow, the project should not fall apart because of that.

I often find engineering moves, small hacks in the good sense, that save budget and time without losing the core functionality.

Sometimes the task can be framed a little differently. Sometimes an existing part is enough instead of new development. Sometimes a small utility is better than a system everyone will have to maintain later. And sometimes a feature should not be built at all, because it drags a month of work behind it and gives almost nothing to the user.

Good engineering cheating, basically.

Writing code is not enough. You need to understand the price of the decision.

Where the savings usually hide

It is easy to cut corners for a pretty date on a calendar. Not very useful if the team spends the next half year paying for that rush. It is much better to understand where the product can become simpler without losing its meaning.

The opposite also happens. A too-cheap solution should sometimes be stopped immediately, because after a couple of releases it will cost more than a normal implementation.

Product code sets the cost of future changes.

I treat technical debt quite literally, as debt borrowed from your future self. You take time now and pay it back later with interest. Sometimes that is fine, sometimes even necessary, but it is worth knowing how much interest will pile up.

I look at the price of an error. What breaks. Who fixes it. How much a rewrite will cost. How painful it will be to bring a new person into the project.

Part of good engineering work looks boring because the bad thing simply did not happen.

It looks uneventful. Good.

I am pragmatic about code. Beautiful architecture matters when it helps the product live longer and more calmly. Sometimes the right abstraction saves months, and sometimes it ties together parts of the system that should stay separate.

The solution has to answer for its price.

What can usually be seen in advance

A random script did not take the service down because the API had limits. Data was not lost because backups existed. A user did not fall out of a flow after pressing Back. A new vulnerability did not turn into a fire. Everyone simply kept working.

A small hack can sometimes fix a real bug faster than a large repair. Duplication can sometimes be safer than a shared function that later drags half the project with it.

A product has to be assembled as a whole.

The user does not care where backend ends and frontend begins. They do not think "well, metadata is missing, but the business logic is good". They open the service and feel whether it is a normal thing or something assembled any old way.

My own product experience helps here. When you have gone from idea to launch, support and marketing yourself, you start looking at the whole cycle instead of a separate ticket.

I notice these things.

I check ordinary flows by hand. I open the service on a phone, go back, reload the page, look at errors, empty states and first loading. It quickly shows how finished the product really is.

What often falls between roles

A product has a layer of things that often belongs to nobody. A frontend developer waits for the designer, the designer does not think about favicon, the product manager did not check the Back button, the backend developer considers it outside their area.

Then production has a framework icon, strange mobile behavior, empty states, broken deep links and a release tool everyone uses through irritation.

Internal tools are products too. If developers, operators or company employees use a bad admin panel, slow CI or awkward release process every day, that is also technical debt. External users just see it later, through product speed and quality.

I started as a designer and then spent years turning other people's mockups into live products. That trained eye still helps.

A Figma mockup is often still. In an app there is loading, error, empty state, transition, microinteraction, animation, sound, vibration and so on.

There is not always enough time to design every state in advance. Then I finish it in place, it has become a habit. First I make the button state clear, add a small animation, check that it does not lag, ask the designer if needed.

I like the idea of MLP. Even a minimal version of a product should be something people want to use, otherwise it is just a technical hypothesis check rather than a proper first contact with the market.

This is often where the feeling of quality comes from.

Where this shows up

When I worked on the flexbe website builder, I deliberately made pages for myself through our own builder, even though writing them in code would have been faster. It immediately shows where the product gets in the way, where it makes you think too much, where the flow technically exists but feels unpleasant to use.

I like when an interface feels alive. No circus. Just enough for it to respond to a person's actions, avoid feeling sluggish and not look like a static picture stretched over code.

If you already have a team, I can make it stronger through normal work.

A large process around this is not required. Reviews, working together, a normal discussion of decisions, help with task framing and informal conversations in between are often enough.

Some of my competence gets picked up and becomes shared.

How this spreads through the team

AI works in a similar way. A team can learn to use agents as a managed engineering tool instead of turning them into a random code generator.

As a result, quality depends less on one person, the team makes decisions with more confidence, raw code reaches production less often and work becomes calmer.