DEV Community: XB Software

The Hidden Cost of "Fast Development" Nobody Talks About

Sergey Laptick — Fri, 07 Aug 2026 08:51:08 +0000

The tech industry is currently obsessed with a single metric: how fast AI can write code. We celebrate closed tickets, generated lines of code, and feature delivery times cut in half. However, there are some hidden costs that come with AI coding. For instance, accelerated debt accumulation.

The biggest danger of AI isn't bad code or syntax hallucinations. AI makes it absurdly easy to create technical debt faster than organizations can even recognize it exists. The bottleneck in software engineering has officially shifted from writing code to understanding the consequences of shipping it.

Technical Debt Used to Grow Slowly

Before LLMs took over our IDEs, technical debt had a natural speed limit.

Accumulating architectural mess took manual effort. A developer who wanted to introduce a poorly designed abstraction layer had to sit down, type out every interface, write the boilerplate, set up the dependency injection, and explain the implementation during a design discussion or code review. Typing speed, mental stamina, and review cycles acted as physical friction.

That delay gave teams a window to ask questions: Do we actually need another microservice for this? Is this dependency necessary? Couldn't we solve this with a simple function? You couldn't easily build five unnecessary services in an afternoon because your hands and your calendar simply wouldn't let you.

Today, as the Google Cloud 2025 DORA Report points out, AI acts as an amplifier. When you remove physical friction, you accelerate the rate at which downstream problems compound in your architecture, testing suites, and long-term maintenance.

AI as a Decision Multiplier

Every time you hit tab or accept a suggestion, you are accepting a series of design choices made by a probabilistic model:

A new abstraction layer;
A bespoke helper utility;
An extra API endpoint;
Another third-party dependency.

For example, data from GitClear's 2025 research shows that in AI-assisted repos duplicated and repeated logic rose 8x and copy-pasted code blocks rose from 8.3% to 12.3%. When the cost of adding complexity approaches zero, human nature dictates that we will add more complexity. But while generating software has become less costly, maintaining it remains painfully expensive.

Why Technical Debt Compounds Faster Than Ever

The acceleration of technical debt happens through a few distinct mechanisms that are quietly playing out across dev teams.

1. More Code Ships

When developers produce three times more code, they also ship three times as many hidden assumptions, edge cases, and subtle failure modes. Code generated by LLMs often contains security vulnerabilities out of the box. Add to that what the Stack Overflow 2025 Developer Survey calls the "Almost Right" tax: 45% of engineers identify "nearly correct" code as their biggest headache, with 66% reporting that they waste significant hours debugging logic that appeared sound at a glance.

2. Less Architectural Thinking

When solutions appear in your editor instantly, teams stop asking “Should we build this?” and start asking “Can AI build this?”

Those two questions lead to wildly different codebases. The first encourages minimalism and domain modeling. The second encourages feature creep, bloated interfaces, and solving simple problems with heavy infrastructure just because the prompt made it easy to spit out.

3. Nobody Fully Understands the System

Imagine a standard workflow today:

Developer A generates a module using Copilot;
Developer B generates a complementary feature using Cursor;
Developer C uses Claude to refactor the interaction between the two.

Six months later, a production incident occurs. The on-call engineer opens the file and realizes that nobody on the team actually designed the mental model behind the code. Understanding becomes the new bottleneck. This dynamic has triggered a trust crash. According to Stack Overflow's 2025 analytics, developer trust in AI-generated code dropped to 29%.

4. Review Becomes Impossible

Pull requests are growing larger while human attention spans remain fixed.

When a PR contains 800 lines of AI-generated boilerplate and helper methods, true peer review collapses under the sheer volume. As discussed in the article from XB Software's COO about AI impact on software engineering, AI changes how engineering work is evaluated: polished output no longer guarantees deep understanding. The same dynamic affects code reviews, where approvals can become a judgment of appearance rather than architecture.

Fast Development Creates Slow Organizations

This leads us to a strange paradox. Engineering managers look at their dashboards and celebrate. Ticket velocity is up! Commits are multiplying! Sprint burn-down charts look incredible!

Yet, on an organizational level, everything feels stickier:

Lead time for complex changes drifts upward;
Bug fixes take longer because tracing execution paths requires extra effort;
Onboarding a new developer takes months because the codebase lacks a coherent design narrative;
The team develops a deep fear of touching core modules.

Deployment gets faster, but fundamental change becomes slower.

The Honeycomb DORA 2025 report frames this as a systems problem. Optimizing local velocity (how fast an individual engineer pushes code out of their IDE) without an overarching design framework eventually degrades organizational velocity. Your mean time to recovery (MTTR) rises because when things break, nobody has the system-level intuition required to fix them quickly.

AI Didn't Create Technical Debt. It Removed Its Speed Limit

Software engineering was never just about typing speed. Now that those barriers are gone, only deliberate engineering discipline stands between a clean architecture and complete entropy. The solution to AI-driven debt is to put structure in place before the prompts start running.

A great real-world example of this shift comes from a practical experiment conducted by XB Software engineers on a mature, four-year-old legacy codebase. Rather than letting AI assistants generate code directly from loose user stories, they tested a spec-driven development approach.

Using tools like GitHub Spec Kit paired with Jira via Model Context Protocol (MCP), our team shifted AI's role to the planning phase. The AI was first tasked with analyzing existing legacy behavior and generating functional specifications before any implementation began. By establishing a solid specification as the source of truth, the team reduced ambiguity, avoided speculative architecture decisions, and proved that AI yields the highest return when used to enforce engineering structure rather than bypass it.

How Good Teams Prevent "AI Debt"

If you want your team to ship fast without drowning in maintenance costs, skip the generic productivity advice and focus on structural engineering habits:

Build less. Not every feature or helper module suggested by an LLM deserves to exist. Treat code as a liability, not an asset.
Delete aggressively. Celebrate PRs that net negative lines of code. If AI makes writing replacement code trivial, make code removal a core productivity metric;
Review architecture, not syntax. LLMs can handle syntax and formatting. Human code reviews should focus exclusively on boundary design, data flow, and architectural decisions;
Enforce design reviews before prompting. Require written design docs, type definitions, or OpenAPI specifications before developers generate feature implementations;
Track maintainability metrics. Stop measuring commits or lines of code. Watch your deployment frequency, rollback rates, MTTR, cycle time, and developer onboarding times. Those metrics reveal the true cost of hidden debt.

Teams that successfully navigate AI-assisted software development establish explicit architecture guardrails and review standards that keep high execution speed from turning into unsustainable long-term maintenance costs.

Conclusion

Fast development can be dangerous because organizations can now accumulate years of structural technical debt in a matter of weeks without realizing it. The bottleneck in modern software engineering is comprehension. The engineering organizations that thrive over the next decade will be the ones that build the strongest engineering discipline around the code they choose to keep.

Manual vs. Automated Software Testing With AI Supercharges

Sergey Laptick — Fri, 31 Jul 2026 08:20:36 +0000

With applications growing ever more intricate and release cadences tightening, development houses are constantly revisiting their quality assurance practices. The long-running discussion around hand-performed versus scripted checks has now gained a fresh dimension: AI-powered testing.

While automation has traditionally been the means to accelerate repetitive verification, the real advance is the shift away from rigid, predefined scripts toward flexible, context-sensitive approaches. Throughout this article, we’ll explore both manual and automation testing, and illustrate how Playwright MCP and AI agents are redefining QA.

What Manual Testing Entails and Where It Still Proves Essential

Manual testing consists of a human examiner stepping through test scenarios without any automation aid, checking whether the software’s functions, usability, and overall response match expectations. The tester clicks through the interface, fills in fields, and monitors outcomes, just as a real user would operate the application.

Far from being obsolete, this practice continues to be crucial in many contexts. Manual effort excels when human discernment, observation, and spontaneity are indispensable. It becomes especially powerful when requirements shift frequently or when the user interface and experience demand direct, subjective assessment. Likewise, it remains the preferred route for exploratory, ad‑hoc, and usability testing, and situations where a prewritten script cannot foresee all the ways a person might interact with the system.

Skilled testers lean on their intuition, reshape their approach as the product evolves, and often catch defects early in the development of web-based applications. They log manual procedures and any flaws uncovered during free-form exploration, which feeds into adaptive planning for upcoming iterations. Building consistent feedback channels with developers helps resolve reported issues quickly, lifting the overall level of software quality.

Key Weaknesses of Manual Testing

For all its advantages, it has issues as well:

Manual verification is slow;
Susceptible to oversight;
Tough to scale under rapid delivery schedules.

These limitations are what have driven many teams to adopt automation for the bulk of repetitive work.

Automated Testing and Its Core Strengths

Automated testing runs pre-authored scripts at high velocity through dedicated tools and frameworks, validating application functionality without ongoing human intervention. It forms the engine of contemporary CI/CD pipelines, letting QA teams execute thousands of checks within minutes with exceptional precision.

The main advantage lies in handling large-scale and recurrent activities effectively. Automation boosts correctness, cuts down on human mistakes, and slots neatly into continuous integration and continuous testing workflows. The approach delivers high dependability for tests that are stable and repeatable, and scales readily as features adjust or the system expands. This makes it a natural fit for regression packs, performance evaluations (both load and stress scenarios), and bulk execution of extensive test suites.

“New or fast-changing functionality is often best validated manually first. Once a scenario becomes stable, repeatable, and business-critical, it becomes a strong candidate for automation.”

Denis Matsiush, QA Engineer

Automated Software Testing with Playwright

To ground the discussion, consider a real illustration using Playwright, a browser automation framework that works across Chromium, Firefox, and WebKit. The script snippet below replicates how a customer might search for an item on an online store:

test('should filter products when searching', async ({ page }) => {
  // 1. Locate the element using its ID
  const searchInput = page.locator('#search-input');

  // 2. Simulate user action: Typing "keyboard" into the field
  await searchInput.fill('Keyboard');

  // 3. Perform action: Click the search button
  await page.locator('#search-button').click();

  // 4. Verification: Expect the results to show exactly one product
  const products = page.locator('.product-card');
  await expect(products).toHaveCount(1);

  // 5. Verification: Ensure the product contains the correct text
  await expect(page.locator('.product-info h3')).toContainText('Keyboard');
});

This script identifies the search input using a CSS selector #search-input. It then uses the .fill() method to type text and .click() to submit. Finally, it uses assertions (expect) to verify that the application responded correctly by showing the expected item. This level of detail and precision makes scripts invaluable for repetitive validation.

What Are the Drawbacks of Automated Testing?

Automation is not a magic wand:

It takes time to set up;
Requires skilled resources;
It's not ideal for usability or exploratory testing.

Moreover, scripts can be brittle: any change in the UI’s structure often breaks the test, requiring manual updates.

Manual vs. Automated Software Testing: A Head‑to‑Head Comparison

Let’s summarize the key differences between manual and automated approaches across accuracy, speed, ideal use cases, and cost:

How AI Expands the Boundaries of Test Automation

Modern software testing taps into large language models to produce checks that are not only automated but also context‑aware, resilient, and capable of self‑repair. A key enabler in this transformation is the Model Context Protocol (MCP) that establishes a structured, bidirectional link between AI models and external applications.

It powers Playwright MCP and forms a browser automation system in which agents perceive web pages through organized accessibility snapshots. As a result, the AI can interpret the layout, locate elements by their semantic roles, and flexibly respond to interface modifications without the tests falling apart.

Inside an AI‑Driven Test Flow with Playwright MCP

A typical AI‑powered testing cycle unfolds in several stages:

Setup. The MCP server is deployed and configured to translate incoming instructions into browser operations;
Capability Discovery. The client asks the server what actions are available (e.g., navigation, clicks, text entry, screen capture);
Command Generation. The model outputs JSON‑formatted commands that correspond to a given test scenario;
Browser Execution. The MCP server receives the commands and uses Playwright to execute them in a real web browser, engaging with the real user interface and recording the resulting state;
Contextual Feedback. The server sends back accessibility snapshots and operation logs, which the AI uses to plan its next moves and correct course.

This iterative loop enables the AI to mimic genuine user journeys, surface edge cases that static scripts might overlook, and automatically recalibrate test steps when the UI evolves.

What AI Brings to Software Testing

Self‑healing tests. AI‑powered models locate and work with web elements by understanding their context, drastically reducing failures caused by minor layout tweaks;
Intelligent test creation. Leveraging LLMs, teams can auto‑generate test cases from application data, boosting coverage without writing every script by hand;
Edge case surfacing. Autonomous agents uncover unexpected behaviors that conventional, rigid tests often miss;
Self‑maintaining suites. The entire test portfolio adapts as the product changes, reconfiguring flows on the fly;
Parallel and distributed execution. Multiple browser instances can run concurrently, slashing total execution time and raising throughput.

The Growing Ecosystem of AI Testing Tools

Beyond Playwright MCP, several other tools are making testing more accessible and practical for teams of all sizes:

KaneAI is an AI‑native automation solution that allows users to plan, author, and evolve end‑to‑end tests using natural language. It supports web applications as well as Android and iOS native apps, and integrates with over 120 tools, including Jira for defect tracking;
Autify offers an AI‑agent‑powered test automation platform. Autify Nexus features a chat‑based agent that generates scenarios from natural language and automatically repairs broken tests. Autify Genesis uses generative AI to design test cases from specifications or even uploaded PDF documents;
BetterBugs focuses on the bug reporting side of the process. It allows testers to record a session (screen recording, console logs, network requests) and then pass that session, along with a prompt, to Claude for automated root cause analysis and proposed fixes;
Testmo has introduced AI Test Case Generation, which generates structured, reviewable test cases directly from requirements. Teams can provide clear requirements, let the system propose an initial set of test cases, and then review and refine them before generating real ones that live in the repository. This approach maintains full traceability and integrates seamlessly with existing management workflows.

COO's Insights: AI Has Broken an Unspoken Rule of IT. And That’s a Problem We Haven’t Fully Understood Yet

Conclusions

Manual approach remains the irreplaceable human lens for exploratory sessions, usability critiques, and rapidly changing features where intuition leads the way. Automated scripts bring relentless speed and consistency to regression suites and performance checks, forming the backbone of continuous delivery pipelines. AI‑enhanced tools add a layer of intelligence: tests that heal themselves, adapt to shifting interfaces, and uncover subtle defects that static approaches overlook.

How to Ensure Application Compatibility When Modernizing a Web Application

Sergey Laptick — Thu, 30 Jul 2026 13:18:16 +0000

Application compatibility, in the context of software modernization, means many things. For instance, preserving seamless data exchange, ensuring API compatibility, and maintaining user experience (UX) continuity. Integrating a modern frontend with a legacy application that wasn't built for it or overhauling a UI without alienating users requires deliberate technical and human-centered strategies.

This article explores a dual-pronged strategy. First, we examine the architectural patterns that ensure technical integration. Second, we dive into UX methodologies that prevent user resistance.

Architectural Patterns for Technical Compatibility

When modernizing a web application, the greatest risk often lies in the backend. Legacy databases, outdated APIs, and codebases were not designed to interface with modern services, including cloud-based platforms. To ensure technical compatibility, developers turn to proven incremental patterns.

The Strangler Fig Pattern for Gradual Replacement

The Strangler Fig pattern (a term introduced by Martin Fowler) helps ensure app compatibility by enabling a controlled, piece-by-piece migration from a legacy system. Instead of replacing everything at once, you gradually substitute old components with new applications and services. Over time, the new application absorbs all the valuable functionality of the old one, allowing you to retire the original application completely.

How the pattern works:

Step 1. Set up a routing layer. Place a proxy (or facade) between client applications, the legacy system, and the new environment. Initially, the proxy directs nearly all traffic to the old system, keeping operations running without interruption;
Step 2. Shift incrementally. With each development cycle, you move more features to the new application. The proxy gradually reroutes requests away from the legacy app, steadily reducing its role;
Step 3. Retire the legacy system. Once every function has been migrated, the proxy sends all requests to the new system. You then remove the proxy, and clients connect directly to the modernized application.

When to use. Large, complex applications where a full-scale rewrite would be too risky. However, watch out for potential bottlenecks. The proxy must be designed for high availability and performance, as it becomes a critical traffic hub.

The Strangler Fig pattern fits naturally into any app modernization strategy because it lets teams progress at a sustainable speed. You keep your existing system productive while gradually introducing improvements, prioritizing high-value replacements first. This incremental method ensures compatibility, reduces disruption, and avoids the classic "big bang" failure where a single migration attempt breaks everything at once.

The Anti-Corruption Layer (ACL): Shielding the Modern System

While the Strangler Fig pattern handles incremental replacement, the Anti-Corruption Layer pattern addresses the semantic mismatch problem. Old applications often have convoluted data schemas, obsolete APIs (e.g., SOAP instead of REST), or business logic that doesn’t align with modern architecture and breaks compatibility. If your new application communicates directly with the legacy system, you risk "corrupting" your clean design with legacy quirks. The ACL acts as a translation layer between the two systems:

Translates Requests. Your modern application talks to the ACL using your clean, sensible API. The ACL performs all translation, transforming requests into the format the old system expects;
Shields Your Codebase. The ACL quarantines all legacy-specific logic. Your domain models, APIs, and services remain pristine and uninfluenced by outdated protocols;
Preserves Architectural Integrity. The old system continues to function, receiving the data it needs, while your new system maintains its modern technological approach.

When to use. The ACL approach is especially valuable when your modernization project requires app compatibility during gradual migrations where new features must interoperate with existing resources. It allows different subsystems with different semantics to communicate without either side compromising its design.

The ACL adds another service to manage and monitor, and it introduces some latency. But the trade-off is worth it. Your app modernization efforts remain clean, maintainable, and future-proof, and don’t become entangled in legacy complexity.

Business and Product Methodologies for UX Continuity

The way people work today has evolved far beyond what software from ten years ago was designed to support. Over time, old applications collect countless small inefficiencies, such as outdated workflows, clumsy workarounds, and interface quirks. Each of them adds to the daily burden on users. Yet moving from an old interface to a modernized one comes with its own challenge, including user resistance.

Even when a new design delivers clear improvements, people tend to push back against anything that disrupts their established habits.

The Incremental UX Redesign Strategy

For better application compatibility, rather than ripping off the bandage, smart modernization teams adopt an evolutionary UX approach. This involves updating interface elements section by section while preserving core architecture. You update navigation patterns in one module, gather feedback for two weeks, then move to the next section. This minimizes disruption and allows teams to validate impact and adjust iteratively.

Practical techniques for UX continuity include:

Progressive Disclosure. Introduce new features gradually, allowing users to adopt them at their own pace and not overwhelming them with a completely new interface;
Keep existing workflow structures intact. Don't alter the step-by-step processes your team relies on every day. Stick with terms users already know when those terms still carry the right meaning;
Provide a switch to move between old and new interfaces. Give people the option to flip back and forth from the original application to the updated version. This approach works especially well for business-to-business setups, where keeping operations running without interruption is paramount.

A fresh design will often be perceived as a worse design simply because it is new and breaks user habits. A better strategy is to play up familiarity and build on users’ existing knowledge of how an application works. This means avoiding complete overhauls in favor of modular, testable changes.

Role-Based Interfaces and AI-Embedded UX

UI/UX modernization that makes usual things smarter also helps to avoid rejection of the new. Modern ccompanies that provide app modernization services incorporate two major trends:

Role-Based Dashboards. Stop giving every employee the same dashboard. A manager needs different data than a floor worker. Context-aware design shows users only what they need for their specific job, reducing clutter and speeding up decision-making. Role-based design should also govern data access, ensuring that sensitive information is only available to authorized roles;
AI-Powered Interfaces. Features like predictive inputs, natural language processing, and intelligent data analysis can improve outdated workflows. Users can type or speak commands to retrieve data without complex queries. AI can suggest the next best actions based on patterns and past behavior, helping users stay on track with minimal input.

AI in app modernization helps automate code analysis and accelerate migration while also transforming the end-user experience.

XB Software’s Application Compatibility Modernization Approach

At XB Software, we recognize that legacy modernization services must address both technical integration and user adoption simultaneously. Over the years of delivering web app modernization projects, we have developed a systematic approach that preserves what works while evolving what doesn’t.

For instance, during SaaS API integration, we modernize outdated applications by integrating them with cloud-native SaaS platforms and APIs. Our approach includes designing multi-tenant architectures, implementing secure and scalable APIs, and automating updates. We maintain strict API compatibility through versioning strategies and consumer regression tests.

From a UI/UX perspective, rather than forcing users into an entirely unfamiliar interface overnight, we prioritize incremental, human-centered UX updates. A proven technique from our practice, demonstrated in the UI/UX modernization project, is the old/new UI toggle, that allows employees to switch between the old interface and the modernized version at will. This eliminates fear, builds confidence gradually, and results in zero downtime and minimal resistance.

Conclusions

Modernizing a web application while maintaining compatibility is a continuous balancing act between technical integrity and user trust. For organizations seeking legacy modernization solutions, the path forward is clear: they need to adopt a phased, modular approach that prioritizes compatibility at every layer. It’s also important to consider the human factor as seriously as the technical one, because an application that users refuse to adopt delivers no ROI.

How We Automated a Production-Grade Traccar Deployment

Sergey Laptick — Mon, 20 Jul 2026 14:28:48 +0000

GPS tracking systems have become essential infrastructure for fleet management, logistics, delivery services, and field operations. Companies that manage vehicles, assets, or mobile workers need reliable visibility into where things are and where they have been.

Traccar is a mature open-source platform that handles such functionality well. The challenge is how to get it running in a production environment with monitoring, security, and the ability to customize it without spending weeks on setup.

We built an automated deployment script to solve this. We use it to deploy production-ready Traccar environments, then customize them according to our clients’ needs. This article explains how it works and what we deliver.

What Available Traccar Deployment Options Lack

Traccar is a system for tracking anything that moves: couriers, drivers, fleets, assets, etc. It includes a server, a frontend interface, and mobile applications that can function as GPS trackers themselves. The open-source version is available on GitHub, and anyone can download and try it. However, launching it and running it in production for years are two different things.

Most companies that need GPS tracking software do not want to spend time figuring out which database works best with Traccar, how to set up production environment monitoring so they know when something breaks, or how to configure a firewall to prevent data leaks. They want a system that works, stays running, and alerts them before it breaks down.

The default deployment options available today have gaps:

AWS Marketplace offers a basic Traccar instance at about $0.03 per hour. You get the software running, but the monitoring is whatever AWS provides by default. Limited styling, no tailored alerts, no ability to change how the system behaves;
Traccar's own hosted server for 50 devices costs around $49.95 per month in the US. It includes some branding options (logo, name and colors) with no UX or functional changes available. The server runs in Traccar's environment, not on the client's infrastructure. All data lives on Traccar's servers. For companies with a preference to keep their operational data on their own hardware, this is a non-starter;
Deploying Traccar yourself on your infrastructure from the open-source repository means your company owns and manages the entire stack. This option includes figuring out deployment, database configuration, reverse proxy setup, monitoring, alerting, and security. It is doable, but it takes time and expertise that most operations teams do not have to spare.

Here is how the available options compare and where we bring our expertise to the table:

What We Built: Automated Production Environment Deployment

When a client came to us needing a production-ready Traccar deployment without the usual headaches, we delivered it quickly and reliably. Here is what we built and how it works.

Instead of treating Traccar as a standalone application to be installed manually, XB Software built an automated deployment script that creates a complete production environment around it. The script runs on a Linux machine and handles everything needed to get Traccar running in a production-ready state.

Here is what the deployment includes:

Traccar backend and frontend;
PostgreSQL database;
Prometheus for metrics collection;
Alertmanager for sending notifications when things go wrong;
Nginx as a reverse proxy for monitoring interfaces;
Node exporter for Linux machine metrics;
PostgreSQL exporter for database metrics;
Firewall configuration using UFW/iptables to expose only necessary ports.

The script checks environment variables, installs Docker and Docker Compose, and generates configuration files from templates. It then sets up the firewall, clones the frontend repository (either standard Traccar frontend or a custom one), builds the stack, and starts everything. The logic strictly separates application, production environment monitoring, and data storage layers. When we update the Traccar interface or Alertmanager settings, the script performs smart, targeted restarts and rebuilds only the affected containers while leaving others untouched. This protects data from corruption, preserves active GPS tracker sessions, and maintains database uptime.

The deployment process with the script is fully idempotent. It never damages the system or creates duplicate resources. All original configuration templates remain on the server.

If a client needs to change monitoring passwords, update email alert settings, or modify any other configuration, there is no need for developers to edit complex files manually. They can update the corresponding variable in the centralized .env file and rerun the script. The infrastructure applies the changes without risking production stability.

For production-level reliability, we separated deployment logic from service management. Systemd handles stack availability, ensuring all containers restart automatically after a server reboot, while build and update tasks remain isolated within the deployment script.

System Architecture: Simple, Flexible, and Production-Capable

All the components listed above work together in a simple but production-capable architecture. Everything runs in Docker containers on a single server. For small to medium deployments this is more than sufficient. If tracking volume grows, the client can simply move the deployment to a more powerful server.

The Traccar backend and frontend are packaged in a single container. This is how Traccar's official Docker image works, and it keeps deployment straightforward. The frontend is written in React, and the backend runs on a custom Java server. The mobile applications (Traccar Client for drivers and Traccar Manager for fleet supervisors) are available from the official app stores.

For the database, we went with PostgreSQL. Traccar supports multiple databases, but PostgreSQL handles geospatial queries better than MySQL and manages high loads more effectively. For most fleets, the difference between databases is not dramatic, but PostgreSQL gives more headroom if tracking volume grows.

Prometheus and Alertmanager run in their own container. Prometheus scrapes data from two exporters. The Node exporter exposes such Linux machine metrics as CPU, memory, disk, network (these are the basic ones that can be extended if needed). The PostgreSQL exporter exposes database metrics. Together, they provide visibility into the health of the entire stack.

Nginx sits in front of everything. It routes traffic to Traccar, Prometheus, and Alertmanager. We added basic authentication to the monitoring interfaces so that metrics are not publicly accessible.

Why Traccar Integration Matters for Fleet Operations

Companies don’t buy tracking software and logistics solutions because they enjoy looking at maps. They buy them because they need to know where their vehicles are, how long drivers spend on routes, whether deliveries are on time, and whether assets are being used efficiently.

When the tracking system goes down, operations suffer. Dispatchers cannot assign jobs. Customers cannot get delivery updates. Managers cannot verify that routes were followed. The business loses visibility, and visibility is the whole point.

Our deployment approach addresses this directly.

Monitoring and Alerting: Knowing Before It Breaks

We built a deployment that not only works today but also tells you when it might stop working tomorrow. More vehicles get added. More trips get tracked. The database grows. Memory usage creeps up. CPU spikes during peak hours. Without monitoring, the first sign of trouble is often the system going down.

Our observability stack provides early warning. The alerts we configured track:

Host health: CPU, memory, disk usage, network activity;
Database health: PostgreSQL connections, query performance, storage;
Service availability: whether Traccar and its components are responding.

When metrics cross predefined thresholds, Alertmanager sends notifications. The client can see exactly what is happening on dashboards and plan upgrades before the system fails.

Security: Basic But Solid

Security follows the same principle as the rest of the stack: simple and effective. The script configures iptables (a traditional utility used to configure and manage IP packet filtering and NAT rules in the Linux kernel) to block all ports except those needed for the application to function.

This is essentially the same approach major cloud providers use with their security groups, just without the fancy UI. All internal traffic (database queries, exporter metrics collection) is fully isolated within Docker's private virtual networks and physically hidden from the outside world.

Customization: Frontend and Backend Modifications

A production environment also has to reflect the client's needs. One of the reasons companies choose Traccar is that they can customize it. In our experience, clients typically prioritize UX improvements. So we built flexibility into the deployment script accordingly. The repositories it uses are defined in environment variables. The frontend repo variable can point to the standard Traccar frontend on GitHub, a private repository with custom styles, or even a local directory.

This means we can:

Apply branding: replace the Traccar logo with the client's logo, adjust color palettes;
Modify UI elements: add, remove, or rearrange features in the frontend;
Update the frontend: pull new versions from the repository without changing the deployment script.

Most clients do not ask for backend changes. But for those who do need backend modifications (custom business logic, integrations with existing systems, specialized tracking features) we can handle those as well.

Support: Ongoing Maintenance, Adjustments, and Troubleshooting

Deploying the system is only the first step. When something drifts out of spec (memory spikes, database connection bloat, or unusual latency) we can diagnose it, and adjust the server or Traccar configuration before it becomes a problem.

Future Enhancements for Traccar Production Deployments

The deployment script is a foundation. As we work with more clients, we will refine the monitoring rules, expand the customization options, and improve the deployment process.

One area we are exploring is using AI-assisted development to accelerate frontend customization. Instead of manually modifying React components for each client, we could generate custom interfaces based on client requirements.

This is still in the exploration phase, but the potential is significant.

We are also considering how to handle larger deployments. Docker Swarm or Kubernetes would provide better scaling for fleet management software that works with hundreds or thousands of vehicles. The current script is a starting point, and we can build more complex architectures as client needs grow.

Conclusions

Traccar is a powerful GPS tracking system. But power without reliability is useless, and reliability without visibility is dangerous. Our automated deployment creates a production environment that combines Traccar's capabilities with the monitoring, security, and customization that businesses actually need.

Senior Developers Don’t Write More Code. They Prevent Disasters

Sergey Laptick — Thu, 09 Jul 2026 13:10:47 +0000

Imagine this. A team celebrates a massive release with dozens of features, thousands of commits, and months of late nights. Then, six months later, that same system is a maintenance nightmare. Bugs crop up everywhere. Onboarding new engineers takes weeks. Every small change breaks something else.

The problem is that many companies still measure senior engineers the same way they measure juniors: by output (more features delivered, more code in the repository, etc.). But that misses the real layer of seniority and results in production systems that fail from decisions that were never challenged.

Hidden Work of Senior Engineers

A senior developer’s day rarely looks like a productivity dashboard. They’re not constantly pushing commits or closing tickets. Instead, they’re doing things that look like they’re doing nothing:

Sitting in architecture discussions;
Mapping out failure modes;
Pushing back on vague requirements;
Asking “why” five times before anyone writes a spec.

None of this “ships.” But everything becomes safer because of it.

What actually separates a mid-level from a senior engineer in 2026 isn’t syntax mastery or knowing the latest build tool. It’s strategic thinking, technical influence, and the ability to balance trade-offs between speed, scalability, and maintainability. You can teach someone React in a week. Teaching them to see around corners takes years.

This invisible work is why senior engineers prevent problems that junior engineers cannot yet see:

Scaling bottlenecks before they exist;
Data consistency issues that only appear under load;
Dependency risks in third-party integrations;
Over-engineering disguised as “future-proofing”;
Under-engineering disguised as “MVP speed”.

A production outage is rarely a surprise. It’s a delayed decision that a senior engineer might have spotted six months earlier if anyone had listened.

The Paradox of Deleting Code or Why More Code Isn't Always Better

Here’s a counterintuitive truth that keeps coming up in engineering circles: your value as a developer becomes inversely proportional to the amount of code you write. Here’s how this so-called Deletion Paradox works. Junior engineers are busy adding features while senior engineers are quietly removing thousands of lines that never should have existed.

Why does that matter? Because every line of code is a future maintenance liability. It adds to the cognitive load, increases the surface area for bugs, and creates hidden coupling that will snap under pressure.

In mature systems, more code rarely means more value. It often means more operational complexity, more maintenance overhead, and more places where things can go wrong. The best way to improve a system is often to remove code, because you understand what happens after it ships.

Outcome Vs. Output: The Real Measuring Stick

This is where the shift from output to outcomes becomes concrete:

Output is what your team produces: a shipped feature, a release, a line of code. It’s easy to count, easy to celebrate, and easy to fake as progress;
Outcome is the measurable change in user behavior that creates business value: higher activation, better retention, more expansion revenue.

There’s this concept of “Feature Factories”, describing a situation where teams that celebrate activity and features delivered instead of business value and changed system behavior. The issue is that building a feature without an expected outcome is just a guess shipped at full cost.

Senior developers look at the backlog through the lens of hypotheses rather than blind commitments. They ask: “What are we trying to learn?” “What will change if this works?” “What’s the metric that moves if we get this right?”

This is why their most valuable contribution is often saying “don’t build this yet.” Not because they’re lazy or risk-averse, but because they can see that a feature will create long-term maintenance cost, or that an abstraction will break under real usage patterns, or that a shortcut will become technical debt faster than anyone expects.

At XB Software, we’ve seen this play out repeatedly in legacy app modernization projects. Sometimes the most valuable thing you can do is to know which parts of an old system to preserve and which to retire.

A UI redesign that strips familiar workflows can break user habits that took years to build. A senior engineer’s job is to see that coming and push back before anyone writes a line of code. That’s why we emphasize careful planning. The absence of a bad redesign often delivers more value than a dozen new screens.

What Changes When AI Generates Half Your Code

The Sonar 2026 State of Code Developer Survey found that 42% of production code is now AI-generated or assisted. 72% of developers who’ve tried AI coding tools now use them every day. That changes what “coding” means.

Anyone can generate massive amounts of code now. However, the hard part is knowing what not to generate, what to delete, and what to constrain.

As the VibeCoder Engineering Blog points out, a senior developer’s value in the AI era is building the guardrails. They write .cursorrules or CLAUDE.md files that encode project conventions, architecture patterns, and forbidden anti-patterns. The AI then generates code that follows their standards instead of generic best practices.

This is a form of systemic decision-making that happens before AI-generated code exists. AI cannot reliably make engineering trade-offs under business constraints. It doesn’t know when to choose simplicity over software scalability, or when to exchange speed for correctness. Those are still human judgments, and they’re exactly what senior engineers get paid for.

So while AI makes code cheaper, it makes engineering decision-making more valuable. The bottleneck here is editing, deleting, and deciding what not to build. The senior engineer’s job has shifted from writing code to writing rules that constrain the machines.

So What Does Seniority Actually Look Like?

Junior engineers optimize for “correct implementation.” They want to build the thing right. Senior engineers optimize for “sustainable system behavior.” They want to build the right thing, and sometimes that means not building anything at all.

The most important contribution a senior engineer makes is often invisible: shaping the system before it becomes expensive to fix. That’s the work that doesn’t show up in commit logs. But it’s the work that separates a stable product from a sinking one.

Senior developers don’t “do more.” They make sure the system doesn’t accumulate problems faster than the team can understand them. And in production, that is what defines success.

AI Can Write Code, But It Can't Own Production Systems

Sergey Laptick — Thu, 02 Jul 2026 13:36:27 +0000

AI is getting scary good at writing code. Drop a prompt into Lovable or Claude Code, and minutes later you have a working prototype with a modern tech stack. It feels like we solved all big problems in AI-assisted software development.

Then production happens. And production does not care how clean your code looks. It cares whether it survives reality. Can it handle traffic spikes or recover when a dependency fails at 2 AM? Can a person who inherits it six months from now actually understand what it does?

The uncomfortable truth is AI can generate code at scale, but it cannot own what happens after you deploy it.

The Illusion: "Perfect" Code from AI

What AI actually produces is impressive. Clean structure. Readable functions. Fast prototypes. Even decent architecture suggestions if you prompt it right. From the outside, it looks like senior-level output.

But here is the thing. AI does not understand business risk. It does not know what happens when your database connection pool runs out under load. It cannot tell you which of two equally valid solutions will survive a 10x traffic spike. It generates what looks right based on what it has seen before, not what is right for your specific system with its specific constraints.

Andy Anderson, a researcher at IBM, spent four months building a Kubernetes dashboard from scratch using Claude Code. No team. Just him and the AI. The first two weeks were exhilarating. Code poured out at a pace he had never experienced. Features that would normally take days appeared in hours. It felt like having a tireless junior developer who typed at the speed of thought.

Then the limitations hit. All at once: broken builds, wrong architectural patterns, scope creep, the AI trying to modify files Andy did not ask it to touch, etc. The problems were cascading: fix one thing, three others break. The researcher ended up spending more time reviewing and reverting than he would have spent writing the code himself.

We saw the same pattern with a scheduling app we built recently. Lovable generated a working prototype in hours with React frontend, Node.js backend, and PostgreSQL database. The calendar looked fine in the demo. But when we tested it, the AI-generated scheduler could not handle recurring events or drag-and-drop reliably. It was a concept car made of clay. So we swapped that component for DHTMLX Scheduler, a production-grade library, and rebuilt the backend for real-world scale. The prototype was useful, but the production system needed actual engineering.

This pattern shows up everywhere. The tools are great at generating code but terrible at understanding what the code is for.

Where Things Break: Production Reality

In production, systems behave differently. Traffic is unpredictable. Dependencies fail. Data grows. Users do things you never expected. Integrations become fragile. And suddenly, that “perfect” AI-generated code becomes just one layer in a very messy environment. The problem is not the code but everything around it

A large-scale study analyzing 302,600 verified AI-authored commits across 6,299 GitHub repositories found something sobering. AI-generated code introduces real issues, such as code smells, correctness problems, or security vulnerabilities, and 22.7% of those issues survive long-term, silently accumulating as technical debt in production codebases. More than 15% of commits from every AI coding assistant introduce at least one issue. Code that looks fine in a PR can quietly rot in production for years.

Stéphane Maes, who writes about software engineering, calls this the “Great Toil Shift.” The time you save generating code gets entirely consumed by the downstream work. This includes architectural review, security auditing, code understanding, documentation, and ongoing maintenance. The efficiency gains are not what they seem.

This is a common thing for teams that go all in on AI-generated code. The prototypes ship fast. Everyone is excited. Then the first production incident hits. The AI-generated code does something unexpected under load. Nobody fully understands the system because nobody wrote it. The team spends days debugging something that would have taken hours if they had built it themselves.

The Missing Piece: Engineering Judgment

Here is where the conversation needs to shift. What AI does is options generation. It gives you suggestions, often good ones. But someone still has to decide which suggestion to take. Someone still has to understand the trade-offs.

And they are the hard part:

Architecture trade-offs: Do we use a message queue or direct calls?
Failure handling: What happens when this service goes down?
Performance constraints: How many requests per second can this handle?
Security decisions: Is this endpoint properly authenticated?
Long-term maintainability: Will someone understand this in two years?

This is where experience matters more than output. Two solutions can both "work" in AI terms. But only one survives production load.

Andy Anderson's central finding from his experience report is worth quoting directly: "The intelligence of an AI-driven development system resides not in the AI model itself, but in the infrastructure of instructions, tests, metrics, and feedback loops that surround it."

In other words, AI is just a tool. The real system is everything you build around it. The tests. The review process. The deployment pipeline. The monitoring. The on-call rotation. The institutional knowledge about why things are the way they are.

In production environments, organizations fundamentally need what they call a "throat to choke," a human engineer who holds ultimate accountability, who can assess blame, who possesses the systemic intuition to troubleshoot complex, real-world failures. A machine cannot sign off on a Service Level Agreement (SLA). It cannot face a compliance audit. It cannot absorb liability for downtime.

This is not a philosophical point. Researchers who analyzed the terms of service for nine AI coding assistants found a consistent pattern: while users own the generated output, full liability, responsibility for correctness, and downstream production risk rests on the human user. The providers explicitly disclaim warranties and allocate responsibility to the developer.

If your AI-generated code causes a production outage, the AI company is not getting the pager duty alert. You are.

What This Means for How We Build Software

None of this means the tools are useless. They are incredibly useful. They can generate boilerplate, write tests, refactor code, and help you explore solutions faster than ever before. But the tools do not replace judgment. They do not eliminate the need for testing. They do not make architecture decisions for you. And they definitely do not own the systems they help you build.

The real skill in modern AI-assisted development is learning how to integrate generated code into a system that you fully understand, can debug, and evolve over time. It is knowing when to accept a suggestion and when to rewrite it.

Some teams are figuring this out. They use AI for rapid prototyping, like the Lovable-generated scheduler that we built, which validated the concept before replacing the AI-generated components with a production-ready solution. The prototype was useful for testing and validation. But the production system required real engineering: understanding the domain, handling edge cases, and ensuring the component could actually survive real-world use.

AI changes how fast we build software. But it has not changed what it means to be responsible for it. And in production, responsibility is still the hardest part.