DEV Community: Vladyslav Donchenko

"From Chatbot to Teammate: What Claude Tag Signals for How We Work"

Vladyslav Donchenko — Tue, 30 Jun 2026 07:05:23 +0000

Most AI at work still behaves like a chatbot in a side panel: you open it, you ask, you copy the answer back into wherever the work actually lives. Anthropic's newly announced Claude Tag points at a different model — and it is worth understanding regardless of which vendor you use.

The idea: Claude joins your team. Starting in Slack, you grant it access to selected channels and connect it to chosen tools, data, and codebases. Then anyone can tag @claude and hand off a task while they do other work. Anthropic says 65% of its product team's code is now created by an internal version of this.

What makes a "tagged agent" different from a chatbot

Multiplayer — one agent per channel that everyone shares; anyone can see what it is doing and pick up where a colleague left off.
Learns over time — it builds context from the channels and data it is permitted to see, so people stop re-explaining background on every request.
Takes initiative — with "ambient" behaviour on, it proactively flags things and follows up on threads/tasks that went quiet.
Works asynchronously — set it a task and it works while you focus elsewhere; it can schedule its own work over hours or days, many agents in parallel.

That is closer to a coworker than a tool.

The hard part was never the model — it's governance

An AI teammate with access to your channels, tools, and data is exactly as useful as it is risky if the access model is sloppy. The most important detail in the announcement isn't capability — it's control:

Admins scope which tools and information the agent can use, per channel.
Each setup is effectively a separate identity — a sales-configured agent never leaks memory or data into an engineering one.
Token-spend limits per org and per channel.
An audit log of everything the agent did and who requested it.

That list is the real checklist for deploying any agent in a regulated, data-sensitive business. Before you tag an agent into a channel touching customer PII, financials, or contracts, you need scoped least-privilege access, memory boundaries between contexts, full audit trails, spend caps, and human approval on irreversible actions.

The governance and orchestration layer — not the underlying model — is what turns an impressive demo into something you can run in production.

The takeaway

Claude Tag matters less as a single product and more as a marker of where applied AI is heading: agents that live inside your workflows, accumulate context, and act on their own initiative within tight guardrails. If you want an AI teammate in your operational channels, start with the access model, the audit trail, and the orchestration around it — not the demo.

Full version, with the real-estate / PropTech angle, on the VSBD blog. Source: Anthropic — Introducing Claude Tag.

"LLM Inference Optimization: The Line Item That Decides If Your AI Ships"

Vladyslav Donchenko — Mon, 29 Jun 2026 07:05:33 +0000

Training gets the headlines. Inference gets the bill. If you run LLMs in production, inference is almost certainly your biggest AI line item — a meter running 24/7 on every request. The gap between naive and optimized serving is routinely 5-10x in cost and 3-5x in latency.

The bottleneck is memory, not compute

During token generation, LLM inference is memory-bandwidth bound. An H100 has ~3.35 TB/s bandwidth but ~989 TFLOPS FP16 compute — during autoregressive decoding you're using only ~10-20% of that compute, waiting on weights and KV-cache to stream from memory. Every optimization attacks the same root cause: move less data, use it better.

The levers that matter

KV cache. It's often bigger than the weights. PagedAttention (vLLM) pages the cache like OS virtual memory, dropping waste from 60-80% to near-zero → 2-3x more concurrent requests. Prefix caching reuses the KV for shared system prompts / few-shot / RAG context. GQA shrinks the cache at the architecture level.
Continuous batching. Swap finished sequences out and new ones in every step — utilization goes from ~20-30% to 80-90%. The single biggest throughput win, and why vLLM / SGLang / TensorRT-LLM exist.
Quantization. FP8 / INT8 / INT4 (AWQ, GPTQ) move less data → lower cost and latency, smaller footprint. 8-bit is near-lossless for most tasks; 4-bit is often an acceptable trade. Validate on your own eval set.
Speculative decoding. A small draft model proposes tokens; the big model verifies in one pass → lower latency with no quality loss.
Right-size the model. The cheapest token is the one you never compute on an oversized model — route easy requests down, hard ones up.

In practice

Use a real serving framework (vLLM, SGLang, TensorRT-LLM) rather than hand-rolling. Measure your actual prompt/response shapes first — long shared prefixes favour prefix caching, high concurrency favours batching, long outputs favour KV-cache and quantization work. Track cost-per-1k-tokens, throughput, and tail latency — the numbers the business actually feels.

Inference optimization is where AI economics are won or lost. The techniques are well understood and together routinely cut serving cost 5-10x — often the deciding factor in whether an AI feature ships at all.

Full version on the VSBD blog.

"Sakana Fugu: When Orchestrating Models Beats Owning One"

Vladyslav Donchenko — Fri, 26 Jun 2026 07:05:20 +0000

Every big AI story this year points the same way: the edge is moving from the model to the layer around it. Sakana AI's newly launched Fugu (and the heavier Fugu Ultra) is the most literal version of that idea — a system that beats frontier models by conducting them, without training a frontier model of its own.

What it actually is

Fugu isn't a bigger LLM. It's a small (~7B) model trained to route: take a task, decide which strong model in a pool should handle each part — Gemini 3.1 Pro, Claude Opus 4.8, GPT-5.5 — dispatch the work, and synthesize one answer. It can call itself recursively on long tasks (run, read its prior output, revise). Two tiers ship behind one OpenAI-compatible API: regular Fugu for everyday speed/quality, Fugu Ultra for hard multi-step work with a wider expert pool.

The claimed results — and the asterisks

Sakana reports Fugu beating Opus 4.8, Gemini 3.1 Pro, and GPT-5.5 on 10 of 11 benchmarks:

SWE-Bench Pro: Fugu Ultra 73.7 vs Opus 4.8 69.2, GPT-5.5 58.6, Gemini 3.1 Pro 54.2.
Humanity's Last Exam: 50.0, edging Opus 4.8 (49.8).
GPQA-D: 95.5, top of the field.
Only loss: MRCRv2 (GPT-5.5 94.8 vs Fugu Ultra 93.6).

Two caveats matter as much as the numbers: results are vendor-reported and not independently verified, and Anthropic's strongest models (Fable 5, Mythos) aren't in the pool because they aren't public. So Fugu matches the frontier by orchestrating what it can reach — not the absolute best models. Read the leaderboard as a claim.

The real insight: resilience as a feature

The sharpest part of Sakana's pitch isn't benchmarks — it's framing orchestration as insurance. Routing across providers means that if one model is restricted, rate-limited, repriced, or pulled, Fugu reroutes to the rest of the pool. That's a procurement argument, and it lands: single-vendor dependence is a real operational risk. A routing layer turns "our AI went down because our provider did" into "it failed over."

The takeaway

Whether or not the exact numbers hold, Fugu makes the year's quiet thesis loud: orchestration is becoming a frontier capability in its own right. Frontier-grade outcomes no longer require owning a frontier model — just the engineering to route, govern, and synthesize across the ones that exist. The tradeoffs are real too: added latency/cost, and broader data exposure across every provider you call (the mirror image of self-hosting an open-weight model for sovereignty). Most serious platforms end up doing both, deliberately.

Full version, with the real-estate / PropTech angle, on the VSBD blog. Source: Sakana AI — Fugu.

"One Model, Seven Worlds: What Qwen-AgentWorld Changes About Agentic AI"

Vladyslav Donchenko — Thu, 25 Jun 2026 15:40:57 +0000

Every agentic system today has an engineering debt nobody talks about: every new environment needs its own scaffold. Browser agent — bespoke prompts and error handling. Terminal agent — start from scratch. Mobile agent — same again. Qwen-AgentWorld attacks this at the root.

What It Is

Qwen-AgentWorld (arXiv 2606.24597) is the first language world model capable of simulating seven distinct agentic environments in a single unified model — not by stitching together seven specialists, but by training one model that learns a unified internal representation of how environments work.

The seven domains: MCP/Tool Calls, Search Engine, IDE/Git/CI-CD, Terminal/CLI, Android/UI, Web Browser/DOM, Operating System/Desktop. Trained on 10M+ real interaction trajectories. Three-stage pipeline: CPT injects state-transition dynamics → SFT activates next-state-prediction → RL with hybrid rewards sharpens fidelity.

Two model sizes: 35B-A3B and 397B-A17B (both MoE).

Two Paradigms

Decoupled Simulator — stands in for real environments during RL training. At 4,000-environment scale, synthetic rollouts via the world model yield gains on Tool Decathlon, MCPMark, and WideSearch that exceed real-environment training alone. Simulation at this fidelity means you can train agents for your specific environment without production traffic.

Unified Foundation — world-model training as a warm-up before task-specific RL. A model that has internalized how seven environments respond reaches higher performance on any specific task faster than a general pretrained base.

Why the PropTech Stack Is Exactly This Shape

The seven environments aren't a random selection — they're exactly the stack a real estate or PropTech operation runs across: browser for portals and listings, search for document intelligence, terminal for pipelines and reports, OS for file and document management, mobile for inspection and tenant apps, IDE/CI-CD for platform development, MCP/API for CRM and ERP integrations.

Today each environment needs its own agent, scaffolding, and eval. A world model that understands all of them without bespoke engineering per environment is the difference between one agent system and maintaining seven.

Caveats

GUI environments use accessibility trees, not pixel frames — no visual understanding
Sim-to-real gaps remain; world-model rollouts complement real training, not replace it
Weights/API availability timeline not yet confirmed

The Direction

The number of distinct models you need to operate an agentic system is collapsing. The bespoke-scaffold-per-environment approach is a transitional state. The durable investment is orchestration, policy enforcement, audit trails, and governance — the layer you own long-term regardless of which foundation model sits underneath.

Full take with the PropTech angle: One Model, Seven Worlds

"Your Building Already Knows: Turning Telemetry into Agentic Action"

Vladyslav Donchenko — Thu, 25 Jun 2026 07:05:20 +0000

There's a sharp idea in a recent piece on connected bottle coolers: the beverage industry's richest source of AI fuel isn't a model or a vendor — it's the humble fridge at the point of sale, logging temperature, door-openings, and compressor data every hour. Connect the fleet, and predictive maintenance and autonomous dispatch follow. The advice: stop waiting for the perfect model and treat your operational data as your most valuable asset.

Real estate has the same blind spot, at far greater scale.

Every building is a fleet of "bottle coolers"

HVAC units, energy and water submeters, occupancy and environmental sensors, elevators, access control, leak detectors, and the BMS tying them together. Most of that telemetry is unconnected, siloed, or used at best for a dashboard nobody reads — the biggest under-exploited AI opportunity in property.

Why telemetry beats models

An agent is only as good as the signal it acts on. A frontier model with no live operational data can summarize a lease; it can't tell you the chiller on floor 12 is three weeks from failure. And the advantage compounds in a way a model licence never will: years of how your assets fail, in your climate, under your usage, is a moat a late mover can't buy.

From metric to action: the loop

Sense — a sensor crosses a threshold (compressor hot, after-hours energy spike, leak-like flow signature, elevator fault).
Decide — an agent weighs asset history, warranty, tenant criticality, weather, and current work-order load.
Act — raise the work order, dispatch the right vendor with the right part, adjust a setpoint, notify the tenant — with cost/irreversible actions gated by a human.
Learn — log the outcome; thresholds self-recalibrate, so it gets more precise every event.

Commercial: energy/HVAC optimization, predictive plant maintenance, space-utilization-driven portfolio decisions, automated ESG reporting.
Residential: leak/flood prevention (the highest-cost failure), comfort before the complaint, common-area uptime, turnover signals.

The hard part is the foundation

Most portfolios' telemetry is fragmented and stranded in incompatible systems. Connecting the fleet, normalizing the data, and making it high-frequency and trustworthy is ~80% of the work — and where most "AI initiatives" stall. Agentic action on a weak data base just automates mistakes faster. Autonomy also needs guardrails: human-in-the-loop on cost/risk, privacy for occupancy and any camera data (especially residential), and full auditability.

The winners in real estate AI won't have the biggest model — they'll have connected their buildings first and wired that signal to action.

Full real-estate breakdown on the VSBD blog. Concept adapted from a SecurityBrief piece on connected coolers.

"LLMs for Ambiguity, Deterministic Agents for Policy: Multi-Agent Contract Compliance"

Vladyslav Donchenko — Wed, 24 Jun 2026 13:10:43 +0000

There's a quietly important reference architecture in Google Cloud's contract-compliance-pipeline sample, built on one sharp principle: LLMs are useful for ambiguity; deterministic agents should enforce hard policy.

That fixes the most common failure in enterprise AI. Most "AI compliance" demos let a model both read the contract and decide whether it passes — so the same document can pass on Monday and fail on Tuesday, and no auditor accepts "the model said so." The sample draws the line correctly: LLM for the fuzzy part (extracting messy facts), deterministic code for the exact part (does this violate policy?).

The pipeline

Python + ADK (orchestrator) — FastAPI service using Google's Agent Development Kit handles intake, extraction, and risk assessment.
A2A handoff — a RemoteA2aAgent does an Agent2Agent handshake, discovers the second service via its agent card (/.well-known/agent.json), and sends extracted data as a JSON-RPC 2.0 message.
Go compliance agent (enforcer) — validates facts against thresholds (value caps, term limits, insurance minimums) with synchronous, repeatable checks. No LLM in this step.
Auditable verdict — structured pass/fail with specific violations; the orchestrator renders a compliance certificate; traces are logged.

Two ideas worth stealing

The ambiguity/determinism split. Anything that must be consistent, explainable, and auditable — a compliance verdict, a payment rule, an eligibility check — belongs in deterministic code, not a model's head. The LLM handles the mess at the edges and hands clean structured data to the rule engine.
A2A as the interoperability layer. The Python and Go agents don't share a codebase — they speak a standard protocol with discoverable agent cards. Specialized agents can be written in the best language for the job and scaled or swapped independently. The microservices lesson, applied to agents.

Why it lands in real estate

Leases, vendor agreements, purchase-and-sale, insurance certificates — all carry hard rules ideal for deterministic enforcement: term caps, rent escalation limits, insurance minimums, required clauses. LLM extracts; deterministic agent enforces; you get an auditable certificate at portfolio scale.

Honest caveats: extraction is still the weak link (a mis-read clause gets faithfully enforced on wrong facts — needs its own evals and human review on low-confidence cases); it's a reference sample, not a product; and deterministic enforcement is only as good as the rule library you maintain.

The discipline is the takeaway: let the model handle ambiguity, let deterministic agents enforce policy, and make them interoperate over open protocols. That's how you get agentic systems an auditor will trust.

Full real-estate breakdown on the VSBD blog. Source: Google Cloud ADK + A2A sample.

"GLM-5.2 and the Open-Weight Tipping Point"

Vladyslav Donchenko — Wed, 24 Jun 2026 07:06:22 +0000

For two years the rule held: frontier-quality AI meant renting from a closed lab, and the open models you could download trailed a generation behind. That gap just closed.

Z.ai's (formerly Zhipu AI) GLM-5.2, released mid-June 2026 under a permissive MIT license, now performs on par with the closed-source frontier on coding, reasoning, and agentic tool use — at roughly one-sixth the cost.

The numbers

On Arena's public Code Arena leaderboard (frontend), GLM-5.2 ranks #2 — behind only Claude Fable 5, ahead of Claude Opus 4.8.
Artificial Analysis rates it the #1 open-weights model in the world, #4 overall (behind Fable 5, Opus 4.8, GPT-5.5).
On SWE-bench Pro and Terminal-Bench it lands within a few points of Opus 4.8.
Architecture: ~744B-parameter MoE (~40B active per token), 1M-token context, text-only.

This isn't a cheap imitation of the frontier. It's the frontier, with the weights published.

Why "open weights" is the phrase that matters

The popular framing is a "ChatGPT moment for local AI." The spirit is right, but precision matters: the change isn't that you can run a great model on a laptop. It's that a frontier-class model now ships under a license that permits commercial self-hosting and fine-tuning. You can put it on your own infrastructure, adapt it to your domain, and ship it in a product — without sending a token to a third-party API.

That rewrites three calculations at once:

Data sovereignty — sensitive data never leaves your boundary.
Cost at scale — owned inference undercuts per-token API pricing at volume (and it's already ~6x cheaper via API).
Control & longevity — open weights can't be deprecated, rate-limited, or silently changed under you.

The honest caveats

"Local AI" is the romantic framing; the engineering reality is more demanding:

Datacenter-class, not laptop-class. At ~744B params, even quantized builds target multi-GPU servers or a maxed-out unified-memory machine.
You inherit the ops — serving (vLLM/SGLang/llama.cpp), scaling, monitoring, security, uptime.
You own the governance — access control, audit logging, guardrails are yours to build.
Capability isn't the whole job — a strong model in a weak harness still fails.

The takeaway

GLM-5.2 marks the moment open weights stopped being a compromise. The deciding factor is no longer whether a capable model is available — it's whether you have the infrastructure, orchestration, and governance to run it safely.

Full version, with the real-estate / data-sovereignty angle, on the VSBD blog.

When AI Agents Rewrite Their Own Rules: Self-Improving Harnesses Explained

Vladyslav Donchenko — Tue, 23 Jun 2026 00:04:56 +0000

When an AI agent fails in production, the instinct is to blame the model. Usually that is the wrong place to look.

An agent's behaviour is governed as much by its harness as by the model underneath — the system prompt, the tools it can call, its memory, its verification rules, its runtime policies, and its failure-recovery logic. SWE-agent, Claude Code, Codex, and OpenHands all wrap the same frontier models; what separates a reliable agent from a flaky one is mostly that surrounding layer.

The catch: that layer is almost always tuned by hand. An engineer watches a few failures, forms a hunch, edits a prompt or a rule, and hopes. As Hangfan Zhang of the Shanghai AI Laboratory (lead author of the new Self-Harness paper, arXiv:2606.09498) puts it, the deeper problem is that this paradigm "often lacks a systematic feedback loop." With new models shipping every few weeks, hand-tuning a model-specific harness becomes a treadmill nobody can keep up with.

The idea: let the agent fix its own harness

Self-Harness keeps the model's weights frozen and improves the harness from the evidence of the agent's own execution traces — no retraining, and no dependence on a bigger external model to supervise it. It runs as a three-stage loop:

Weakness mining — Run a batch of tasks with verifiable outcomes, then categorize the failed traces to find model-specific failure patterns.
Harness proposal — A "proposer" role turns each failure pattern into a small, targeted edit tied to that specific mechanism — deliberately minimal, to avoid over-correcting.
Proposal validation — Each candidate edit runs through regression tests and is promoted only if it improves performance without measurable degradation on held-out tasks. Passing edits merge into the next harness version, which seeds the next round.

The acceptance gate is the whole game: improvement without regression, proven on data.

The results

Tested on Terminal-Bench-2.0 (general tool use: artifact management, command use, verification, error recovery) across MiniMax M2.5, Qwen3.5-35B-A3B, and GLM-5 — freezing everything except the harness — held-out performance climbed 33% to 60% in relative terms. Qwen3.5-35B-A3B went from 23.8% to 38.1%.

What makes it more than a benchmark number is what changed. The edits are specific and legible, not "make the prompt longer":

MiniMax M2.5 kept exploring dataset configs until it timed out and shipped nothing. Self-Harness wrote a "loop breaker" into its runtime policy — stop and redirect after 50 tool calls — plus a rule to produce an initial version of any required artifact early.
Qwen3.5 would hit a file-overwrite error, blindly retry the same command, and eventually delete files in confusion. The fix: a strict command-retry discipline — no exact-duplicate commands.

Those are exactly the rules a seasoned engineer would add — discovered and validated automatically.

Why this matters beyond the benchmark

If you ship agents on real workflows, three implications stand out:

Model upgrades stop being rewrites. Swapping in a cheaper, faster model usually means re-tuning the harness by hand. A self-harnessing loop re-discovers the new model's failure modes automatically.
Cheaper models cross the reliability line. A 60% relative lift on hard tasks can move a smaller model into "good enough for production."
Debugging becomes empirical. Ambiguous "the agent looks broken" failures become testable edits with an objective accept/reject gate.

The prerequisite is honest: this only works on tasks where success is machine-checkable. Before you let a loop edit your harness, build the evaluation — a benchmark of real cases with objective pass/fail signals. Without that, "self-improving" is just a word.

This is a syndicated copy. The original, with the real-estate and PropTech angle, is on the VSBD blog. Paper: arXiv:2606.09498.

The Managed Capacity Model: How PropTech Companies Scale Engineering Teams

Vladyslav Donchenko — Mon, 22 Jun 2026 09:14:29 +0000

The Procurement Problem Holding PropTech Back

The two most common software procurement models — Time & Material (T&M) and Fixed Price — were designed for a world where software projects had clear, stable requirements and predictable timelines. PropTech products don't live in that world. Market conditions shift, regulatory requirements change, and the competitive landscape demands continuous product iteration. Both T&M and Fixed Price create friction against that reality.

What's Wrong With T&M for PropTech

T&M gives clients flexibility but no cost predictability. For a PropTech product under active development, a T&M contract creates ongoing budget uncertainty that makes planning difficult and creates adversarial dynamics around scope. Every new feature request becomes a negotiation.

What's Wrong With Fixed Price for PropTech

Fixed Price provides cost certainty but inhibits agility. Defining the scope of a PropTech platform upfront with sufficient detail for a fixed-price contract requires months of specification work — work that often produces documentation that's already outdated by the time development begins. Change management processes slow down iteration and penalize learning.

The Managed Capacity Alternative

The Managed Capacity model — sometimes called Value Stream Budgeting — provides a stable team capacity at an agreed monthly rate, with scope flexibility within that team's skill set. VSBD provides teams with an agreed monthly target headcount (e.g., 2 teams of 10), with volume discounts for longer engagements and flexibility to adjust team composition as priorities shift.

Key characteristics:

Flat monthly rate for core team composition — no per-hour negotiation
T&M for flex capacity — temporary specialists or surge capacity beyond the core team
Scope flexibility within 10% handled by the existing team without change requests
VSBD covers vacation and sick leave — client headcount doesn't dip when team members are out
Volume discounts that reduce the effective rate for larger, longer engagements

KPIs That Make Managed Capacity Accountable

The objection to Managed Capacity is reasonable: if you're not paying per deliverable, how do you know you're getting value? The answer is a transparent KPI framework that tracks delivery velocity, quality, and business outcomes simultaneously:

Development KPIs: Deployment frequency, lead time for changes
Quality KPIs: Change failure rate, mean time to restore, defect containment
Cost KPIs: Cost of delay, rework percentage
Value KPIs: Percentage of validated user stories, business value delivered per sprint

VSBD uses a KPI Pyramid that aligns development metrics to business outcomes — making the value of the engineering investment visible to executives and delivery teams alike.

When Managed Capacity Fits Best

Managed Capacity is ideal for PropTech companies that:

Have a clear product roadmap but expect it to evolve
Need a stable, cross-functional engineering team over 12+ months
Want to avoid the overhead of managing individual T&M time sheets
Value engineering culture and knowledge retention over lowest-cost headcount

VSBD's Managed Capacity engagements have consistently achieved NPS scores above 50 — measured after each quarterly business review — reflecting the alignment between client expectations and delivery outcomes that the model creates.

Originally published on the VSBD blog.

ML-Powered Payment Gateway Optimization for PropTech Platforms

Vladyslav Donchenko — Mon, 22 Jun 2026 09:08:58 +0000

The Hidden Cost of Payment Instability in PropTech

Real estate transactions involve large sums, recurring payments, and complex fee structures — making payment processing failures disproportionately costly. When a payment gateway goes down or routes a transaction sub-optimally, the impact compounds: failed rent collection, delayed closings, and manual reconciliation overhead that scales with portfolio size. VSBD's ML Payment Gateway Cascade project tackled this problem head-on for a real estate financial platform — with measurable results.

The Problem: Fragmented Gateway Landscape

Modern real estate platforms typically route payments through multiple gateway providers for redundancy and geographic coverage. Each provider has different uptime characteristics, fee structures, and performance profiles across transaction types. Without intelligent routing, platforms typically rely on static configuration — which means they can't adapt when a provider degrades, and they leave money on the table by not optimizing route selection based on real-time performance data.

The ML Solution: Cascade Routing

The VSBD team designed a cascade routing system based on an ML model trained on historical transaction data across all gateway providers. The model learns:

Provider success probability per transaction type, amount range, and geographic region
Latency profiles to optimize for time-sensitive transaction types
Fee optimization across provider pricing models for different payment instruments
Anomaly signals that indicate a provider is degrading before it fully fails

The cascade mechanism: if the primary route fails or the model predicts a low success probability, the system automatically routes to the next-best provider — without manual intervention.

The Data Pipeline Architecture

The ML model is only as good as the data feeding it. The VSBD team built supporting data stream pipelines that:

Ingest real-time transaction outcomes from all gateway providers
Normalize provider-specific response formats into a unified schema
Trigger automated model evaluation when performance metrics drift beyond thresholds
Feed a CI/CD pipeline for model updates, enabling rapid iteration without manual deployment

Quality Engineering: Testing ML Systems

Testing payment routing is harder than testing conventional business logic — the behavior is probabilistic, and edge cases can have significant financial consequences. The QA approach included:

Multi-stream integration testing simulating production-like transaction volumes across all provider integrations
Regression suites that verify cascade behavior under simulated provider degradation scenarios
E2E testing of the full payment lifecycle including refund and dispute flows
Load testing to validate cascade routing under peak transaction volumes

Delivered Within Budget: €370k, 6 Months

The project was delivered within the fixed-cost business model commitment: €370k budget, 6-month timeline. The team included a Project Manager, 2 Data Engineers, 1 Data Scientist, 2 Data Analysts, 1 Manual QA, and 1 Automation QA — a lean, focused composition for a well-scoped problem.

Results

40% reduction in payment gateway fluctuations
95% reduction in human error through elimination of manual financial data manipulation
50% decrease in time-to-market for new payment capabilities
25% reduction in support costs through streamlined internal processes
Improved corporate transparency by eliminating manual financial data manipulation

For PropTech platforms handling high payment volumes, ML-powered routing is not a luxury — it's the difference between reliable revenue collection and expensive operational overhead.

Originally published on the VSBD blog.

Top 10 PropTech Companies in Europe and USA to Watch in 2025

Vladyslav Donchenko — Mon, 22 Jun 2026 09:08:27 +0000

PropTech Is at an Inflection Point

The global PropTech market reached $36.55 billion in 2024, with AI adoption accelerating across every category. The companies below represent the most significant innovations in how real estate is bought, sold, managed, and financed — across two of the world's most important markets.

Top 5 European PropTech Companies

1. LEVERTON (Germany)

LEVERTON has built one of the most sophisticated AI document intelligence platforms for commercial real estate. Their NLP-driven contract analysis tools extract, classify, and manage data from thousands of lease agreements simultaneously — reducing manual review time by over 80% for enterprise clients. For engineering partners, LEVERTON represents the kind of deep-domain AI investment that requires MLOps maturity and robust data pipeline architecture.

2. Homeday (Germany)

Homeday has digitized the residential property transaction from valuation to closing. Their platform combines automated valuation models (AVMs) with a network of local agents, creating a hybrid experience that reduces time-to-close significantly. The engineering challenge: building AVMs that remain accurate across Germany's highly fragmented local real estate markets.

3. Casavo (Italy)

Casavo pioneered the iBuying model in Southern Europe, providing instant liquidity to home sellers while building a proprietary data advantage on property pricing. Their platform processes thousands of data points per property to generate real-time offers — an applied ML challenge requiring high-frequency model retraining as market conditions shift.

4. Sensorberg (Germany)

Sensorberg operates at the intersection of IoT and property management, providing smart building solutions that control access, energy, and occupancy monitoring through a unified platform. Their SDK-first approach allows integration with existing building management systems — a model that requires robust API design and real-time data processing at the edge.

5. Spotahome (Spain)

Spotahome has built a video-first marketplace for mid-term rentals across Europe, enabling renters to book properties without in-person visits. The platform's trust layer — which includes verified video tours and professional photography — required novel investment in content quality automation and verification tooling.

Top 5 US PropTech Companies

1. Opendoor

Opendoor redefined residential real estate liquidity in the US by purchasing homes directly from sellers using algorithmic pricing. At peak, Opendoor was purchasing thousands of homes per month — a feat requiring real-time AVM models, integration with title and escrow systems, and pricing engines that hedge against market volatility.

2. VTS

VTS is the operating system for commercial real estate, connecting landlords, brokers, and tenants on a single platform for leasing, asset management, and market intelligence. Their data network across hundreds of millions of square feet of commercial space creates a proprietary intelligence layer unavailable to competitors.

3. HouseCanary

HouseCanary provides the most granular property analytics available in the US market — covering 136 million properties with valuations, forecasts, and condition assessments. Their data-as-a-service model powers lending, investment, and insurance decisions at scale.

4. Compass

Compass built a technology-first brokerage from the ground up, providing agents with proprietary tools for CRM, marketing, and transaction management. Their engineering investment in agent-facing software redefined what brokerage technology could look like.

5. RealPage

RealPage provides the SaaS backbone for multifamily property management — covering revenue management, leasing, maintenance, and resident services for over 20 million units. Their AI-driven revenue management products have attracted both adoption and regulatory scrutiny, highlighting the importance of responsible AI deployment in pricing algorithms.

What These Companies Have in Common

Every company on this list made early, significant investments in engineering quality and data infrastructure. None of them built their platforms on legacy architectures. For PropTech companies at earlier stages, the engineering foundation you lay today determines the ceiling of what you can achieve at scale. Partnering with an engineering firm that understands both the technology and the real estate domain accelerates that foundation-building dramatically.

Originally published on the VSBD blog.

AI Predictive Maintenance for Real Estate: Reducing Downtime and Costs

Vladyslav Donchenko — Mon, 22 Jun 2026 08:06:24 +0000

The True Cost of Reactive Maintenance

Facilities managers in real estate and industrial property management have long accepted reactive maintenance as the default operating model: something breaks, someone reports it, a technician is dispatched. This model is expensive in ways that aren't always visible in the maintenance budget — but show up clearly in operational efficiency, tenant satisfaction, and unplanned capital expenditure.

For large portfolios and industrial facilities, even a single unplanned outage can cost orders of magnitude more than the predictive system that would have prevented it. The VSBD Outage Prediction project — delivered for a natural resource extraction company managing complex facility infrastructure — demonstrates what AI-driven predictive maintenance looks like in production.

The Challenge: Prognosis at Scale

The client operated facilities with hundreds of monitored systems — pumps, compressors, electrical switchgear, HVAC units, and more. Each system generated continuous telemetry data: temperature, vibration, pressure, current draw, and operational cycle counts. The engineering challenge was not data collection — the client already had sensors. The challenge was turning raw telemetry into actionable maintenance predictions before failures occurred.

The AI Architecture

VSBD designed and built a predictive maintenance system composed of three interconnected components:

Anomaly Detection Engine: An ML model trained on historical operational data and known failure patterns, identifying deviations from normal operating profiles. The model distinguishes between noise (normal operational variance) and signal (early-stage failure indicators) with high precision.
Performance Degradation Model: A time-series forecasting model that tracks gradual degradation trends across monitored systems, enabling proactive scheduling of maintenance before failure probability exceeds acceptable thresholds.
Risk Identification Module: A classification system that prioritizes maintenance interventions based on criticality, failure probability, and operational impact — enabling maintenance teams to focus on the highest-risk systems first.

MLOps: Keeping Models Accurate Over Time

Predictive maintenance models face a unique challenge: the very act of acting on predictions changes the data distribution. When maintenance prevents a failure, that failure never generates the outcome data the model expected. Over time, without proper MLOps practices, models drift and degrade.

The VSBD approach included:

Automated model evaluation triggered by performance metric drift
Counterfactual logging for interventions — capturing what would have happened without maintenance action
Continuous retraining pipelines that incorporate new failure events as they occur
Monitoring dashboards that surface model confidence scores alongside predictions

Support Team Dispatch Optimization

Beyond prediction accuracy, the system's operational value depended on how efficiently maintenance resources were deployed. VSBD integrated the prediction outputs with a dispatch planning module that optimized technician scheduling based on:

Geographic proximity and travel time to facilities
Technician skill set matching to the predicted failure type
Parts availability and procurement lead times
Maintenance windows that minimize operational disruption

The result was a 60% improvement in maintenance team dispatch planning efficiency — measured by reduction in wasted travel time and parts mismatches.

Delivered: Under 6 Months, Under €400k

The complete system — from data pipeline through AI models to the operations dashboard — was delivered within the fixed-cost business model commitment. The team composition: Project Manager, Dev Team Lead, Backend Developer, Frontend Developer, 2 Data Engineers, 1 Data Scientist, 1 MLOps Engineer, and 1 Automation QA.

For real estate and facility management companies ready to move from reactive to predictive maintenance, the investment in an AI system pays back within the first year of operation in most deployments.

Originally published on the VSBD blog.