The agent generates code, the tests are green, and defects keep growing. I find out exactly where the development process breaks, and fix it.
My name is Andrey Yeremenok. I'm the CTO and co-founder of Comngo, a company that has been building B2B platforms for the Israeli travel and insurance market for over 10 years.
I work on systems that pull data from dozens of external sources and bring it together in one working interface. It's integration work: different APIs, different formats, each supplier's own business logic, plus requirements for speed and fault tolerance.
In 2009, I graduated with honors from LETI (Saint Petersburg Electrotechnical University) with a degree in Computer Science. I've been writing commercial Java code for 20 years. I started as a developer; after that came architecture, hiring and growing teams, development and support processes. These days I'm working out how AI tools change the way developers work, and writing about it in articles and in my channel.
Four statements I hear most often. If any of them sounds familiar, the conversation will be a concrete one.
The team ships more code per unit of time. Whether that made things better or worse, there is nothing to measure it with. It feels like there are more fixes after release, but there is nothing to confirm that either.
Every change in the old code is a risk. The team routes around those places, deadlines stretch, and the real reason never gets said out loud.
The solution has already been named and the budget is already being drawn up for it. Nobody has offered a cheap way to test the hypothesis underneath that solution.
Without hiring a full-time CTO. Find out what is actually going on inside development, and get it in writing.
Every step ends with a document. The next step starts only once the previous one is closed.
30 minutes, free. Afterwards I send it in writing: what I see and what I suggest testing.
Paid, bounded in scope and in time. The output is a document with findings and priorities.
A few hours a week. The boundaries are fixed in writing: what is included, what is not, and how we end it.
Entry is paid. Only the first conversation is free β after that, a contract with a fixed scope.
What people ask before the first conversation.
Entry is paid. Only the first conversation is free β 30 minutes. After that, a contract with a fixed scope.
Every step ends with a document. After the first conversation I send it in writing: what I see and what I suggest testing. Diagnostics ends with a document of findings and priorities.
Three formats: diagnostics, regular ongoing support, and full-time by arrangement. Ongoing support is a few hours a week, with the boundaries fixed in writing: what is included, what is not, and how we end it.
It is an outside view of the development process without hiring a full-time CTO: find out what is actually going on inside development, and get it in writing. Scope and timing are bounded by the contract.
Most often one of four: we rolled out an AI assistant, speed went up and quality is opaque; legacy nobody dares to touch and a team that can't keep up; a stakeholder is certain we need to build X; we need an outside view of the development process.
Within a day. Write and tell me what's going on with your development β we'll set up 30 minutes.
The two patterns I apply most often. Examples are anonymised.
The client arrives with a solution already chosen. Before building it, I pull out the hypothesis underneath and work out the cheapest way to test it.
Often the test kills the solution and saves a quarter.
In B2B2C the intermediary is the main blocker: they don't hand over data, and sooner or later they become a competitor.
Products built as a tool for them move faster than products built through them.
On each of these products I was the CTO: I designed the architecture, built the team and the process, and wrote code.
The agent pastes the client's message exactly as it arrived β Hebrew, WhatsApp shorthand, an unfinished sentence β and gets a filtered set of options out of about fifteen hundred hotels, with the reason each one made the cut.
From that set the agent assembles a collection that reaches the client under the agent's own name: supplier names and B2B prices technically never reach that page.
The system never acts on its own at any step: between parsing the request and running the search there is the agent's confirmation.
Anti-hallucination here is handled at the architecture level. Prices, availability, and cancellation rules are not generated by the model β they are read from supplier responses and carry their source and timestamp. Carrier text is quoted verbatim and attributed. The reference point is Moffatt v. Air Canada (BCCRT, February 2024), where a vendor was held liable for what its chatbot said. The reason here is legal.
The mobile terminal is built on top of an already working platform and live supplier contracts.
Every screenshot on the product page is the running application, captured by an automated test suite in Hebrew and English. There are no mockups there.
The same page publishes the build status table: what works against live inventory, what is in build, what is planned. I publish the unfinished parts deliberately β that's how I work with clients too: status is visible before anyone asks for it.
Israeli travel agents stopped keeping a dozen supplier sites open. Searching, comparing, and booking flights, hotels, and tour packages happen in one interface, and settlements with the agency happen in one place.
A query goes out to every connected supplier at once, and the responses are merged into a single result under one price model. On top of that: a credit line for agencies (Obligo), multi-currency, a commission panel, and automated invoicing, so nobody counts money by hand.
10+ suppliers: Sabre, Amadeus, Travelfusion, charter operators, hotel aggregators. Each has its own API, its own data model, its own pricing logic β merging them into a single result was the main architectural task.
An insurance agent sees quotes from twelve Israeli insurers in one window and issues a policy without switching between the insurers' portals. The client base, sales, and documents live in the same place.
Inside is the full policy lifecycle, from quote to claims settlement, plus agency CRM: user hierarchy, sales tracking, document flow, electronic signature.
Twelve integrations, from modern REST APIs to legacy SOAP services with proprietary formats. The product model, the underwriting logic, and the data requirements differ from company to company.
20 articles on Habr, around 173,000 total views β habr.com/ru/users/aeremenok. Published in Russian.
Three of them form one line of reasoning: why AI projects fail at the level of the organisation, what is happening at the level of the code while that goes on, and how architectural decisions change as a result.
The technology has almost nothing to do with it: what fails is organisational maturity. Trying to skip a level costs more than the tool itself.
Read on HabrWhat happens one level down. The agent reads "write tests" as "make the tests pass" and adjusts the mocks and the assertions. The defect does not go anywhere β it just stops being visible until production.
Read on HabrAnd what follows from that for architecture. Half the classic reasons to split a monolith rested on the fact that a human cannot hold the whole context. When the agent holds the context, the decision changes.
Read on HabrMy Telegram channel. I write about AI tools and how they actually work out in practice. Also about mountains β and the "mountain boost" they give productivity. Sometimes it drifts into observations somewhere between tech and non-tech.
No schedule, no content plan. I write when I have something to say: a review of a new tool, impressions from a ski trip, thoughts about Tarkovsky and neural networks β in roughly that order of randomness.
Subscribe: t.me/pcnc_pro
Debug Camp is a set of outdoor retreats for IT professionals who need a reset. There's a program: orienteering in the forest, workshops on personal organization, meditation, campfire gatherings. I'm a co-organizer.
The format came out of an observation: after a few days in the forest without internet, your mind works differently, and tasks that seemed impossible start getting solved. Physiology and a change of context. Debug Camp just makes that kind of reset a regular thing.
The next retreat is on 5 September 2026.
More about Debug Camp
A voice running coach for blind runners β a social project.
A VK bot that runs a training session by voice: it builds a personal plan and guides the person through the workout without a single visual element. A professional coach recorded the audio. The project started with work with a club of blind runners in Saint Petersburg, and in 2026 it became a finalist in the national sports project competition "Ty v igre".
Open the bot on VKWrite and tell me what's going on with your development β we'll set up 30 minutes. I respond within a day.