Forem: Nevena

Code Testing Fundamentals: How to Do It Right

Nevena — Mon, 09 Mar 2026 09:00:01 +0000

DataArt's Senior Developer Alexey Klimenko explains why testing matters and how to approach it in practice. This guide covers core concepts, test types, working strategies, best practices, and a risk-based mindset to help teams make testing a natural part of engineering culture.

Why Do We Need Tests?

Testing often gets buried under buzzwords: coverage, reports, pipelines, TDD debates. Strip that away, and the idea is simple. Tests exist to give us confidence.

A clear testing strategy delivers tangible benefits:

Higher product quality, with fewer production bugs and hidden issues
Fewer regressions, reducing stress when shipping new features
Lower long-term costs, since refactoring and fixes become safer and faster
Reduced business risk from broken core flows

In essence, tests create a safety net. They make growth possible without turning every change into a gamble.

Understanding Test Types:

Instead of memorizing labels, it helps to look at testing from three perspectives:

By level — what exactly we're testing
By approach — how we write and run the tests
By goal — what this particular test is meant to cover

By Level: From Unit to E2E (End-to-End)

Unit Tests

Unit tests validate small, isolated pieces of logic: functions, utilities, methods.

A good unit test is fast, independent of the database/network/timing, and focused on a specific behavior.

Example:

// utils/calcDiscount.js
export function calcDiscount(price, percent) {
  if (percent < 0 || percent > 100) {
    throw new Error('Invalid percent');
  }
  return price - (price * percent) / 100;
}

// calcDiscount.test.js (Jest)
import { calcDiscount } from './calcDiscount';

describe('calcDiscount', () => {
  it('applies percentage discount', () => {
    expect(calcDiscount(100, 10)).toBe(90);
  });

  it('throws on invalid percent', () => {
    expect(() => calcDiscount(100, 150)).toThrow('Invalid percent');
  });
});

Component Tests

Component tests focus on UI components in isolation: different props, states, and events.

Example:

// components/Counter.jsx
export const Counter = ({ initial = 0 }) => {
  const [value, setValue] = React.useState(initial);

  return (
    <div>
      <span aria-label="value">{value}</span>
      <button onClick={() => setValue(value + 1)}>+</button>
    </div>
  );
}

// Counter.test.jsx (React Testing Library + Jest)
import { render, screen, fireEvent } from '@testing-library/react';
import { Counter } from './Counter';

it('increments value when user clicks plus', () => {
  render(<Counter initial={1} />);

  const value = screen.getByLabelText('value');
  const button = screen.getByText('+');

  expect(value).toHaveTextContent('1');

  fireEvent.click(button);
  expect(value).toHaveTextContent('2');
});

Integration Tests

Integration tests verify how multiple modules of the system work together: controller + validator, component + API(mocked).

Example (a hypothetical service + external client):

// services/userService.js
export async function createUser(userData, { userRepo, emailService }) {
  const user = await userRepo.save(userData);
  await emailService.sendWelcome(user.email);
  return user;
}

// userService.integration.test.js
import { createUser } from './userService';

it('creates user and sends welcome email', async () => {
  const savedUsers = [];
  const sentEmails = [];

  const userRepo = {
    save: async (userData) => {
      savedUsers.push(userData);
      return { id: 1, ...userData };
    },
  };

  const emailService = {
    sendWelcome: async (email) => {
      sentEmails.push(email);
    },
  };

  const result = await createUser(
    { email: 'test@example.com' },
    { userRepo, emailService }
  );

  expect(result.id).toBe(1);
  expect(savedUsers).toHaveLength(1);
  expect(sentEmails).toContain('test@example.com');
});

E2E (End-to-End) Tests

This is the whole user journey through the system: from the UI down to the database and back. E2E tests are more expensive and slower to maintain, but they give us tremendous confidence that real-world scenarios actually work.

Example:

// e2e/checkout.spec.js
import { test, expect } from '@playwright/test';

test('user can buy a product', async ({ page }) => {
  await page.goto('https://my-shop.example');

  await page.getByText('Fancy Mug').click();
  await page.getByRole('button', { name: 'Add to cart' }).click();
  await page.getByRole('link', { name: 'Cart' }).click();

  await page.getByRole('button', { name: 'Checkout' }).click();
  await page.getByLabel('Card number').fill('4242 4242 4242 4242');
  await page.getByLabel('Expiry').fill('12/30');
  await page.getByLabel('CVC').fill('123');

  await page.getByRole('button', { name: 'Pay' }).click();

  await expect(page.getByText('Thank you for your purchase')).toBeVisible();
});

By Approach: How Tests Are Created

Manual Vs. Automated

Manual — a tester/developer goes through scenarios by hand.

Automated — scenarios are written as code and run in CI.

Manual testing isn't going anywhere, but as a project grows, having an automated "safety layer" becomes increasingly valuable.

TDD (Test-Driven Development)

TDD follows a simple loop:

Write a failing test (red)
Write the minimum amount of code to pass the test (green)
Remove duplication / clean up the code (refactor)

BDD (Behavior-Driven Development)

BDD focuses on a shared understanding of how the system should behave.

BDD-style tests do not have to be a formal BDD process with lots of meetings and Gherkin files. You can use the approach partially, simply as a convenient way to keep your focus on behavior.

Key ideas:

We talk in terms of behavior, not implementation details
We use the Given/When/Then structure
Scenarios are understandable to developers, QA, analysts, and business people
Tests become a form of living documentation

# cart.feature
Feature: Shopping cart
Scenario: User can add an item to the cart. Given the user is on the shop page and the cart is empty
    When the user adds an item to the cart
    Then the cart shows "1 item in cart"

import { Given, When, Then } from '@cucumber/cucumber';
import { expect } from '@playwright/test';

Given('the user is on the shop page', async function () {
  await this.page.goto('https://my-shop.example');
});

Given('the cart is empty', async function () {
  // reset the basket state, e.g. ensure it's empty
});

When('the user adds an item to the cart', async function () {
  await this.page.getByText('Add to cart').click();
});

Then('the cart shows {string}', async function (text) {
  await expect(this.page.getByText(text)).toBeVisible();
});

Exploratory Testing

It relies on curiosity: what happens if…?

Examples:

Rapidly switching between tabs to see if the UI breaks
Clicking a button 10 times a second
Entering unexpected values
Killing the network
Reloading the page in the middle of a request

Exploratory testing often identifies bugs that formal test scenarios miss entirely.

By Goal: What Is Being Validated

Functional Testing

We check what the system does. Common categories include:

Boundary — test edge cases and limits (e.g., min/max values, “just below/just above” a limit, Input limit is 10 characters → testing 9, 10, 11)
Regression — ensure existing functionality still works (e.g., new feature added → old flow still works)
Smoke — quick “does it run at all?” check (e.g., you fixed payment modal → check app loads, login works, basic flows still function)
Sanity — quick validation of a specific fix or feature (e.g., you fixed the payment modal → check only the payment modal behavior)

Non-Functional Testing

Here, the focus is on how the system behaves:

Performance — speed, load, response times
Security — vulnerabilities, permissions, attacks
Usability — how easy it is to use
A11y (Accessibility) — screen readers, keyboard navigation, contrast, etc.
Compatibility — different browsers/devices
Reliability — stability over long runs, restarts, and network issues

Specialized Test Types

Snapshot Testing

Snapshot tests compare a saved version of the UI/DOM to the current one. They're handy for components.

Example (Jest + React Testing Library):

// Button.test.jsx
import { render } from '@testing-library/react';
import { Button } from './Button';

it('renders primary button', () => {
  const { container } = render(<Button variant="primary">Click me</Button>);
  expect(container.firstChild).toMatchSnapshot();
});

Visual Regression/Screenshot Testing

Tools like Playwright or Storybook can compare screenshots pixel-by-pixel. For example, you can see if a button moved after a CSS change.

Mutation Testing

Tools like Stryker deliberately “break” your code (e.g., change operators or conditions) and check whether your tests can catch it. The idea is simple: if you can break business logic and the tests are still green, the quality of your tests is low — even if coverage is high.

Why so many classifications if, in the end, we are just checking that everything works? Separations are needed not for the sake of theory, but for the sake of risk, time, and cost management.

Why So Many Test Categories

The goal is not theory. It is risk management.

In real projects:

Time is limited
Money is limited
Risks vary
There are many changes

Therefore, testing is divided into types to understand:

What needs to be tested deeply
What can be tested quickly
What can be tested superficially
What must be tested after changes

Reducing Flaky Tests

Flaky tests (sometimes red, sometimes green with no code changes) destroy trust in your test suite.

To reduce instability:

Use stable test environments
Control your data (fixtures, factory functions)
Isolate from unstable external services (mocks/fakes)
Make tests deterministic (fake timers, control randomness)

FIRST Principles of Good Tests

Strong tests usually follow the FIRST model:

Fast — the test runs quickly

Independent — doesn't depend on other tests

Repeatable — gives the same result in any environment

Self-checking — validates itself (green/red) without manual log inspection

Timely — written at the right time (not a year after the feature was implemented)

Key Testing Realities

⭐ Bugs are inevitable
The goal of testing is not to "prove there are no bugs", but to reduce the risk of serious problems. We test not because someone writes bad code, but because errors are a natural part of software development.

⭐ You can't test everything
The space of possible inputs and scenarios is infinite. So, you have to make choices. We must choose what to test based on importance and risk, rather than attempting to cover everything.

⭐ Adopt a risk-based mindset
Focus your testing effort on areas that:

Break most often
Are critical for the business
Are complex and challenging to understand
Have tricky integrations

Testing is an investment. We put more effort into areas where failure would be costly.

⭐ The pesticide paradox
If you keep running the same set of tests, they eventually stop finding new bugs, like pests getting used to the same poison. Your test suite needs to be updated and expanded periodically. Tests must be reviewed and improved regularly; otherwise, they become noise and lose their value.

⭐ Quality is a team responsibility
It's not "the QA’s job" or "whoever writes tests". Architecture decisions, deadlines, scope, and attitude to technical debt all affect quality. Everyone (Dev, QA, PM, DevOps) contributes to product quality, so testing decisions and responsibilities must be shared.

Coverage: What Do 80% Actually Mean?

Coverage (line/function coverage) is often turned into a KPI. But it’s important to remember: Coverage ≠ test quality.

You can have 90% coverage and still:

Never test boundary values
Fail to catch real bugs
Ignore important branches in conditions

Use coverage to identify blind spots:

Untested modules
Untouched code paths
Rare scenarios

For many projects, 70–90% is reasonable, but what really matters is what exactly is being tested, not the number itself.

Testing as Part of Engineering Culture

Testing is not a luxury or a "nice-to-have if there's time left". It's part of the engineering discipline.

When the team has a basic understanding of the types of tests available, what value they bring, and how to think about coverage and risk, you can start arguing about details like Jest/Vitest, Cypress/Playwright, and how many E2E tests are needed.

But the foundation is the same: Testing = Engineering discipline.

Treat testing as risk management, not bureaucracy. Teams that adopt this mindset ship faster, break less, and release with confidence.

*The article was initially published on DataArt Team blog.

RASP: The Silent Ninja Handling the Threats You Don’t See

Nevena — Mon, 23 Feb 2026 08:24:07 +0000

What is RASP, and why does it matter? DataArt's Security Engineer, Kirill Chsheglov, explains this in-app security technology, compares leading commercial solutions, and examines what the open-source OpenRASP project brings to the table.

What is RASP?

RASP (Runtime Application Self-Protection) is a security technology that runs inside an application and protects it in real time. Think of it like a bodyguard that rides along with your app, monitoring activity and stepping in when something suspicious happens.

Where a traditional WAF (Web Application Firewall) only sees incoming traffic; RASP has full visibility of the app’s internal activity, including function calls, database queries, and more.

Why Does it Matter?

Many clients still depend on legacy systems that can't be easily patched. Perimeter tools help, but they often lack context, create noise, or miss threats that unfold within the application itself.

RASP closes that gap, quietly monitoring and reacting right away when something goes wrong. Unlike WAFs that raise too many alerts, RASP works silently and effectively, like a ninja, calmly whispering: "Relax. I see everything. I've already caught them."

Why Should Clients Turn to RASP?

"Don't touch the legacy code, it still works." RASP can cover security holes without changing the code, which can be troublesome.
WAF screams, RASP acts. Fewer false positives mean fewer alerts and no SOC meltdowns every Friday.
Zero-day? Stay calm. Even without a CVE (Common Vulnerabilities and Exposures), RASP can spot suspicious behavior and stop attacks.
Attacks have gotten smarter. Old perimeter defenses don't help much with microservices, APIs, or serverless—but that's where RASP works.
RASP may seem expensive, but it can save millions by stopping cyberattacks—for example, in oil and gas environments.
RASP works in production, unlike SAST and DAST, which work before deployment.

In short, RASP is an in-app security layer that understands context and acts immediately.

Leading Commercial Solutions and an Open-Source Option

Fastly employs a hybrid approach, combining edge-level protection with in-app agents. Malicious traffic is filtered globally before reaching your infrastructure. Agents inside the app runtime (Java, .NET, etc.) provide deeper inspection. A central cloud engine manages analytics and rule updates.

Imperva RASP offers a lightweight plugin that sits directly inside the application (JVM, .NET, Node.js). It utilizes grammar-based analysis to detect threats at runtime, including zero-day vulnerabilities. With no proxy or network dependencies, it works well for legacy apps or strict environments.

Contrast instruments deep code to add security directly into the application flow. By hooking into core runtime APIs (like java.lang.instrumentation), it accesses full stack traces, queries, and execution data to accurately detect and block attacks. Designed for DevOps, it integrates via CI/CD pipelines, containers, and Kubernetes, providing accurate in-app protection with minimal false positives.

OpenRASP is a fully open-source, server-layer solution. It integrates seamlessly into key operations, such as database access, file I/O, and networking, in languages like Java and PHP. With taint-tracking and context analysis, it flags and logs malicious behavior. It's customizable, but requires solid internal development, management, and tuning.

Performance Impact

The Fastly RASP engine is built for real-time decision-making, which reduces false positives and minimizes the impact on web performance (See Fastly's documentation for details).

Imperva's grammar-based RASP uses formal language parsing to achieve high detection accuracy with low runtime impact. End users won't notice it running (Read the datasheet for more information).

Contrast Protect reports that 80% of requests incur a latency of under 0.5ms, with 96% processed within a few milliseconds, matching or outperforming similar WAF solutions (See more at Contrast Security's glossary).

What do these tools have in common? RASP doesn't just protect, it does so quietly, blending into production like it was always there.

When RASP Makes Sense?

You run high-value web apps or APIs.
You need runtime protection while fixing complex issues.
You want real visibility into production threats.

Additional Reading

Check out the following material to learn more:

RASP isn’t a silver bullet. But it delivers something traditional tools can’t: a view from inside the application, paired with the ability to act immediately. While WAFs’ perimeter defenses raise alarms, RASP stays focused on stopping the threat at the point where it matters. A silent hero in a noisy world.

*The article was initially published on DataArt Team blog.

5 Ancient Lists of Data That Changed the World

Nevena — Mon, 09 Feb 2026 10:21:48 +0000

The new DataArt Museum project explores millennia of data mastery— from baboon bones to AI brains. For our blog, Alexey Pomigailov, DataArt Museum curator, selected from this remarkable online catalog 5 ancient lists of data that changed the world.

There’s a common myth that data is a 21st-century invention. In reality, data engineering has been around for thousands of years. Our need to record, calculate, and analyze information has always existed. Over the centuries, humans have used records, counts, and tracking to build something bigger than what came before: from notching a baboon bone with a fingernail, to creating the first lists of taxpayers to run ancient empires, to compiling cargo lists to track Viking goods. These early innovations eventually led to punch cards, Excel spreadsheets, online shopping, and even chatting with AI agents today.

1. The Uruk Clay Tablet (Sumer, c. 3200 BCE)

A clay tablet recording barley and malt deliveries for beer production was found in modern-day Iraq. It can be viewed as the birth of Tabular Data. By separating the "label" (malt) from the "value" (quantity) using a grid, Sumerian administrators invented the row-and-column structure. It was the world's first spreadsheet, decoupling data types from data values.

2. The Pinakes of Callimachus (Alexandria, c. 250 BCE)

A bibliographic registry of the 500,000 scrolls in the Great Library of Alexandria was the invention of Metadata and Indexing. Callimachus, an ancient Greek scholar and librarian, realized that data is useless if it isn't "addressable." He created a system that mapped a logical record (title/author) to a physical location (shelf), the ancient ancestor of the SQL index and the URL.

3. Nuova Cronica by Giovanni Villani (Florence, c. 1348 CE)

A chronicle of Florence tracked birth rates, grain prices, and mortality during the Black Death. It represents the shift from simple logging to Descriptive Analytics. The Italian chronicler Giovanni Villani didn't just record history; he used statistical data to describe the economic and demographic health of the city, arguably creating the first Business Intelligence report.

4. Liber Beneficiorum (Krakow, 1470–1480 CE)

Jan Długosz’s "Book of Benefices" is a massive register of church assets and endowments in Poland. As a precursor to State Statistics and ERP (Enterprise Resource Planning), it was a centralized database of decentralized assets, designed to give the "headquarters" (the Diocese) a unified view of geography, economics, and taxation across the region.

5. The Computus (Medieval Europe, c. 222–1200 CE)

Computus was a system of complex calculations used by the Church to synchronize lunar and solar cycles to determine the date of Easter. It can be viewed as the first Algorithm. Unlike a static lookup table, the Computus required "loops" of logic and conditional processing. It proved that mathematics could govern social time, paving the way for the clock cycles inside every modern CPU.

Our recent DataArt museum project, Recount, Sort & Figure Out, traces the evolution of these concepts and highlights the massive role this technology played in shaping civilization.

Seen through this lens, you realize that data engineering isn’t new — we just have faster tools. The logic of organizing the world into rows, columns, and addresses is one of humanity’s oldest survival skills. Explore this multi-millennial catalog to see how the art of handling data has shaped culture, technology, and imagination. to see how the art of handling data has shaped culture, technology, and imagination.

*The article was initially published on DataArt Team blog.

Preparing for the GCP ACE Exam: What You Should Know

Nevena — Mon, 02 Feb 2026 08:49:48 +0000

Thinking about the GCP Associate Cloud Engineer (ACE) certification? Eugene Kiselev, a seasoned engineer from DataArt with over 13 years of experience in various cloud-related projects, walks you through his preparation process, exam experience, and key takeaways. Here’s what he learned and recommends to anyone planning to take the exam.

Why I Took the ACE Exam

Although I already hold the GCP Professional Cloud Architect (PCA) certification, most of my recent work has focused on AWS or Azure. I still remember the core concepts; those are quite consistent across providers, but I’d lost touch with some of the practical nuances (like the color of some buttons) in the GCP console.

To refresh that knowledge, I chose the ACE exam. According to the description, it’s a hands-on certification that tests your ability to manage infrastructure, debug issues, and apply best practices, without diving into advanced topics like IoT or advanced ML pipelines. It sticks to the essentials: compute, storage, security, and high availability. It may not focus on GenAI, but it’s still a valuable skill set.

You may still encounter ML-related scenarios in the questions, simply because that’s the current reality. Yet, the exam focuses on infrastructure, not ML algorithms or pandas code blocks.

Scheduling Proctoring: What to Expect

Scheduling the exam in Poland was simple and affordable. One thing I like about Google exams is that you book a specific time slot, not a generic voucher. That suits my approach; by the time I schedule, I’m ready. This is a personal preference, of course. Some people prefer the flexibility of scheduling after payment.

Pro TIP: Pay close attention to AM/PM, especially if you’re aiming for a 12:00 slot. Google/Kryterion lets you switch between 12-hour and 24-hour formats, which you can use to double-check your time.

Google sends multiple email reminders confirming your exam time and date.

I opted to take the exam at home, but test centers are also available. Prices were identical in my case, so I went with convenience.

One advantage of test centers is that you won’t risk interruptions due to unstable internet or power issues. Also, test centers tend to be less strict about minor behavior, like briefly looking away from the screen. Likely to wipe away tears — Just kidding, it's not that hard!

Home-based proctoring, on the other hand, is more rigorous. Proctors might ask you to show your surroundings or end a session if they consider your actions suspicious. Reddit is filled with stories of such experiences, so it’s best to be cautious.

If you choose to take the exam at home:

Prepare a clean, quiet, private room where no one will interrupt you.
Before the exam, the proctor will ask you to show your room, desk, ID, wrists, and glasses (if applicable). Watches, smart glasses, or headphones are not allowed.
Kryterion now supports showing the room using your phone, which is 100% more convenient than using a laptop camera. You just scan a QR code, and then remove the phone after inspection.

My experience went smoothly: no issues or interventions, no technical problems. I used macOS, installed the testing software, and it worked perfectly.

Preparation Materials and Strategy

The official exam guide accurately reflects the topics covered, so I used it as my primary resource. Carefully reading it helped me identify areas for improvement. I highly recommend referring to it throughout your preparation.

My main study platform was Cloud Skills Boost due to the high quality of the lectures. These same lectures are likely available via Coursera as well. Cloud Skills Boost also includes hands-on labs, which are super important. Most labs give you a deep understanding of GCP services, how to operate/administer them, and how to answer tricky exam questions. They also teach best practices, which help you identify correct answers in scenario-based questions.

TIP: Many questions include several technically correct answers, but only one works in the real world. Practical experience helps you eliminate nonsense quickly.

Important Topics

While every topic matters, I found certain areas more prominent in the exam:

Billing, Projects, Organizations, and Folders

Engineers in large companies often don't deal with these directly (especially billing) since dedicated teams handle them. And due to security restrictions, you can't really practice billing on platforms like Cloud Skills Boost. So, I highly recommend creating your own GCP projects and exploring billing configs. You don't need to spin up resources; just work with folders, projects, and IAM policies. It's extremely valuable.
Google provides a nice architecture diagram, so you can try building something similar.

Kubernetes (GKE)

My background includes CKA and CKS certifications and deep Kubernetes experience, so this section was familiar. But the exam questions go beyond the basics. They no longer ask, “What is a Pod?” but focus more on debugging real-world issues, understanding GKE setups, high availability, and security.

The Kubernetes course in the official learning path is a good start, but not enough on its own. I suggest:

Deploying more than just a basic Nginx pod. For example, you can build something like the image below. Make sure it works, then update the nginx deployment with a different version of Nginx and finally delete pods and see what will happen. Try to break and fix things. This is extremely valuable for the exam and for everyday work.

Practicing debugging
Using Minikube or Killercoda for hands-on work. CKA labs in Killercoda is a good level, CKS probably too much

Cloud Run & Cloud Functions

The official learning path didn't cover these extensively, but there are other dedicated courses on the platform.

For additional preparation, I used the GCA Cloud Engineer Certification Prep course on LinkedIn Learning. It’s well-structured, comprehensive, and covers gaps in other resources. If you have access to it, it can serve as your main study resource.

Final Thoughts

What’s great about GCP exams, even practical ones like ACE, is their focus on understanding concepts, rather than memorizing UI details or CLI flags like AZ-104 (sorry, Microsoft). Some questions might seem like that at first, but if you read them carefully, you’ll realize they are testing your comprehension of how things work.

This means your knowledge won’t become outdated with a UI redesign. Plus, the skills you develop can be easily transferred to other clouds.

The ACE exam is a solid benchmark, if you are comfortable with:

Building scalable infrastructure
Debugging real issues
Analyzing logs
Applying good security and high availability practices

It's a certification that rewards hands-on skills, and a worthwhile addition for anyone looking to prove their ability to solve real-world administrative tasks in GCP.

*This article was initially published on DataArt Team blog.

From Idea to Prototype in 60 Minutes

Nevena — Mon, 26 Jan 2026 11:36:09 +0000

How does an idea evolve into a working prototype? Delivery Manager Andrey Sadakov and Product Owner Viktoriya Zinovyeva walk through the process in a recorded webinar and the text below. It’s a practical, step-by-step path from initial concept to prototype. They explain how to develop an MVP, utilizing effective coding practices that enhance development speed, recommend prototyping tools, and introduce semantic annotation.

Prototyping Video Demo

Watch the full webinar below or go through the article first.

Why AI Prototyping

Before AI-assisted development, execution carried most of the weight. Today, AI code generation has lowered that barrier.
AI helps us generate many ideas quickly, but human judgment still determines which directions are worth exploring.
AI speeds up development and improves quality, shifting the balance between ideation and execution; close to “implementation is nothing”.
Prototyping with AI streamlines discovery, requirements gathering, stakeholder alignment, and getting buy-in much faster. You can quickly build and show a prototype to evaluate potential early.

Product Idea

Imagine an app that helps diagnose pain and improve posture by analyzing user photos. It all started with Viktoriya's knee pain. A simple problem led to an idea: a posture analysis app.

Step 1: Shaping the Idea

The goal is to challenge the initial idea and generate alternatives using different perspectives.

Recommended Model: Use a reasoning-focused model for best results

Instruct the AI to:

Stay neutral and support recommendations with reasoning, pros, and cons for each option.
Ask about gaps or unclear points.
Present counterarguments when needed.
Provide the top three alternative strategies, including trade-offs.
List 5-7 questions to answer before moving forward.

Step 2: Market Research

This step identifies both supporting and opposing arguments for your chosen option, as well as the assumptions underlying them.

Recommended Model: Deep research mode

Include the results from step 1 for context. Then, instruct the LLM to:

Offer multiple viewpoints, and flag uncertainty levels where relevant.
Collect the strongest available evidence for and against each point.
Identify the five most critical assumptions.

This is the standard flow for market analysis: research competitors, look for signals from customer forums, social posts, and other customer insights. AI is suited to handle these exploratory tasks efficiently.

Step 3: Defining the Requirements

The goal is to design a clear specification for the AI prototyping tool.

Use the results from step 2 as input to give the full context. Ask for a Product Requirements Document (PRD) tailored to your specific tool (for example, Loveable). Adjust the PRD as needed, including elements such as personas, user stories, and functional requirements.

Specify the results format:

Use clear, simple language.
Cite pros and cons when suggesting alternatives.
Keep paragraphs short (under 4 lines).
Use bulleted lists where they clarify structure.

How a Prototype Differs from an MVP

Aspect	Prototype	MVP (Minimum Viable Product)
Purpose	To visualize and test ideas quickly, often used for concept validation or stakeholder buy-in	To validate a product in the market with real users and gather feedback
Functionality	Simulated or partial functionality; may not be fully operational	Core, working functionality that delivers actual value to users
Goal	Demonstrate feasibility, design, or workflow	Test market demand, usability, and product-market fit
Testing	Usability tests, concept validation, internal review	Live testing with users, real-world data, and customer feedback
Risk Mitigation	Reduces design/technical risks early	Reduces market and business risks
Iteration Speed	Very fast, since it's not fully functional	Slower than prototypes, but still faster than a full-scale product
Outcome	Helps decide whether to move forward with building an MVP	Provides insights for scaling or pivoting to a better product version

Technical Comparison: Prototype vs MVP

Aspect	Prototype	MVP (Minimum Viable Product)
Code Quality	Often quick and dirty, may use throwaway code, mockups, or scripts. Not built to scale or maintain.	Production-grade (even if minimal). Uses maintainable code that can be extended later.
Backend	Usually faked (e.g., mocked API responses, static JSON files, or stubs).	Real backend services, even if basic—often with database, APIs, and authentication.
Frontend	May be static screens or interactive mockups with limited or no logic.	Fully functional UI connected to backend, handling state and real interactions.
Deployment	Usually not deployed; runs locally, in a demo environment, or as design mockups.	Deployed in production (cloud, app stores, or web), accessible by real users.
Longevity	Disposable—meant to validate ideas before coding seriously.	Foundation for future development—can evolve into the whole product.
Code Quality	Usually faked (e.g., mocked API responses, static JSON file, or stubs).	Production-grade (even if minimal). Uses maintainable code that can be extended later.

Vibe Coding Best Practices

Build iteratively. Don’t try to generate an app from a single prompt. Start simple and build up in steps.
Choose a standard tech stack. LLMs can work with many frameworks, but JavaScript frameworks such as ReactJS, as well as Java or C#, are more reliable.
Provide context. Share relevant documentation, app functionality, business goals, and technical details. The more context the AI has, the better the results will be. Protocols like MCP help keep documentation up to date.
Set coding rules. Coding standards vary by language (e.g., JavaScript, NodeJS). Add these rules to prompts to help the AI produce better code.
Use semantic annotation.

Semantic Annotation

Just as we comment on code and update documentation for others, we use the same principle for AI. Create a readme.md file in markdown to explain your app’s business logic. Add clear comments in the code to describe its purpose, inputs, outputs, and side effects. You can also use XML to annotate the code. This helps AI understand the code's intent, not just how to run it. Use semantic markup to make this easier.

Recommended Tools

Loveable: A platform for quickly turning concepts into web applications. Best for creating clickable prototypes
Replit: An online IDE with AI features. Balances automation with developer control. Suitable for both speed and functionality.
Local Setup: Use Cursor with the Caluse Sonnet model for a hands-on, developer-driven approach. Best for full-scale development.

What to Do Next

With a clear structure and the right tools, anyone can create a prototype. Good documentation and small, well-defined steps make it easier to turn an initial idea into functional products quickly and easily. Start iterating and see where your ideas lead!

*The article was initially published on DataArt Team blog.

AI Coding Assistants: Helpful or Harmful?

Nevena — Mon, 19 Jan 2026 10:09:36 +0000

Denis Tsyplakov, Solutions Architect at DataArt, explores the less-discussed side of AI coding agents. While they can boost productivity, they also introduce risks that are easy to underestimate.

In a short experiment, Denis asked an AI code assistant to solve a simple task. The result was telling: without strong coding skills and a solid grasp of system architecture, AI-generated code can quickly become overcomplicated, inefficient, and challenging to maintain.

The Current Situation

People have mixed feelings about AI coding assistants. Some think they’re revolutionary, others don't trust them at all, and most engineers fall somewhere in between: cautious but curious.

Success stories rarely help. Claims like “My 5-year-old built this in 15 minutes” are often dismissed as marketing exaggeration. This skepticism slows down adoption, but it also highlights an important point: both the benefits and the limits of these tools need a realistic understanding.

Meanwhile, reputable vendors are forced to compete with hype-driven sellers, often leading to:

Drop in quality. Products ship with bugs or unstable features.
Development decisions driven by hype, not user needs.
Unpredictable roadmaps. What works today may break tomorrow.

Experiment: How Deep Does AI Coding Go?

I ran a small experiment using three AI code assistants: GitHub Copilot, JetBrains Junie, and Windsurf.

The task itself is simple. We use it in interviews to check candidates’ ability to elaborate on tech architecture. For a senior engineer, the correct approach usually takes about 3 to 5 seconds to give a solution. We’ve tested this repeatedly, and the result is always instant. (We'll have to create another task for candidates after this article is published.)

Copilot-like tools are historically strong at algorithmic tasks. So, when you ask them to create an implementation of a simple class with well-defined and documented methods, you can expect a very good result. The problem starts when architectural decisions are required, i.e., on how exactly it should be implemented.

Junie: A Step-by-Step Breakdown

Junie, GitHub Copilot, and Windsurf showed similar results. Here is a step-by-step breakdown for the Junie prompting.

Prompt 1: Implement class logic

The result would not pass a code review. The logic was unnecessarily complex for the given task, but it is generally acceptable. Let’s assume I don't have skills in Java tech architecture and accept this solution.

Prompt 2: Make this thread-safe

The assistant produced a technically correct solution. Still, the task itself was trivial.

Prompt 3:

Implement method List<String> getAllLabelsSorted() that should return all labels sorted by proximity to point [0,0].

This is where things started to unravel. The code could be less wordy. As I mentioned, LLMs excel at algorithmic tasks, but not for a good reason. It unpacks a long into two ints and sorts them each time I use the method. At this point, I would expect it to use a TreeMap, simply because it stores all sorted entries and gives us O(log n) complexity for both inserts and lookups.

So I pushed further.

Prompt 4: I do not want to re-sort labels each time the method is called.

OMG!!! Cache!!! What could be worse!?

From there, I tried multiple prompts, aiming for a canonical solution with a TreeMap-like structure and a record with a comparator (without mentioning TreeMap directly, let's assume I am not familiar with it).

No luck. The more I asked, the hairier the solution became. I ended up with three screens of hardly readable code.

The solution I was looking for is straightforward: it uses specific classes, is thread-safe, and does not store excessive data.

Yes, this approach is opinionated. It has (log(n)) complexity. But this is what I was going to achieve. The problem is that I can get this code from AI only if I know at least 50% of the solution and can explain it in technical terms. If you start using an AI agent without a clear understanding of the desired result, the output becomes effectively random.

Can AI agents be instructed to use the right technical architecture? You can instruct them to use records, for instance, but you cannot instruct common sense. You can create a project.rules.md file that covers specific rules, but you cannot reuse it as a universal solution for each project.

The Real Problem with AI-Assisted Code

The biggest problem is supportability. The code might work, but its quality is often questionable. Code that’s hard to support is also hard to change. That’s a problem for production environments that need frequent updates.

Some people expect that future tools will generate code from requirements alone, but that's still a long way off. For now, supportability is what matters.

What the Analysis Shows

AI coding assistants can quickly turn your code into an unreadable mess if:

Instructions are vague.
Results aren’t checked.
Prompts aren’t finetuned.

That doesn’t mean you shouldn’t use AI. It just means you need to review every line of generated code, which takes strong code-reading skills. The problem is that many developers lack experience with this.

From our experiments, there’s a limit to how much faster AI-assisted coding can make you. Depending on the language and framework, it can be up to 10-20 times faster, but you still need to read and review the code.

Code assistants work well with stable, traditional, and compliant code in languages with strong structure, such as Java, C#, and TypeScript. But when you use them with code that doesn’t have strong compilation or verification, things get messy. In other parts of the software development life cycle, like code review, the code often breaks.

When you build software, you should know in advance what you are creating. You should also be familiar with current best practices (not Java 11, not Angular 12). And you should read the code. Otherwise, even with a super simple task, you will have non-supportable code very fast.

In my opinion, assistants are already useful for writing code, but they are not ready to replace code review. That may change, but not anytime soon.

Next Steps

Having all of these challenges in mind, here's what you should focus on:

Start using AI assistants where it makes sense.
If not in your main project, experiment elsewhere to stay relevant.
Review your language specifications thoroughly.
Improve technical architecture skills through practice.

Used thoughtfully, AI can speed you up. Used blindly, it will slow you down later.

*The article was initially published on DataArt Team blog.

The Best and Worst of IT in 2025: Highlights, Scandals, Innovations

Nevena — Thu, 15 Jan 2026 14:57:20 +0000

As the new year begins, Andriy Silchuk, DataArt’s Head of R&D Center and Delivery Director, looks back on a turbulent 2025. From defining trends and high-profile scandals to breakthrough innovations and rare bright spots, he recaps what shaped the IT and hi-tech world—and shares his outlook for 2026.

Ladies and gentlemen, we’re lucky once again to have made it to the end of the year, so let’s officially tally up the year-end results.

As before, let’s follow a familiar route: we’ll briefly recall last year's forecasts, then look at the major trends, scandals, the good, and the bad that we all experienced in 2025. We’ll also examine the big names we lost this year, determine the heroes and villains, and recall 2025’s surprises. Then we’ll end the program with our 2026 forecasts.

So, pour yourself your favorite drink – and let's go!

A Brief Look at Last Year’s Forecasts

At the end of 2024, we predicted that we’d get real AI agents, turbulence in the US IT industry, changing requirements for engineers, "data as oil," and a growing lag between Europe and the United States in 2025.

What we actually got:

AI agents have truly made their way from being the subjects of presentations into full production: ChatGPT agents and a bunch of other tools are already walking around the sites themselves, pressing buttons, executing scripts, and the Linux Foundation is even launching an initiative based on agentic AI standards.
Turbulence in the United States IT industry hasn’t gone anywhere: antitrust lawsuits against Google/Meta, content wars, regulation — it was all present again this year.
The requirements for engineers have changed drastically: "I know how to work with AI tools" is now a basic required skill. Big Tech is introducing KPIs for using AI, and those who resist are told to look for a new job.
Data and infrastructure are truly the "new oil." The problem is not even about data, but about servers, GPUs, memory, and energy — everything is becoming more expensive and scarce.
Europe has cemented itself as the regulatory champion, with the EU AI Act, record DSA fines for X, etc. In the US, meanwhile, they’re more so debating how to regulate IT, rather than actually doing any regulating.

Our predictions were right practically across the board. Not because we’re prophets, but because the trends were blatantly obvious.

Four Most popular trends of 2025 (they’re all about AI)

1. Agency AI: From "chats" to real assistants

2025 was a turning point: the focus shifted from "generative AI" to agentic AI. ChatGPT agents and similar systems no longer just respond, but also perform tasks themselves—they open websites, monitor statuses, book, write, and edit documents. Businesses are churning out their own agents for support, sales, and back office, DevOps, and domain tasks, and at the same time, a whole zoo of multi-agent frameworks is growing. We've officially gone from "a chat who advises something" to "an assistant who does the job but still needs supervision."

2. GEMINI, GPT, CLAUDE and others – a new level of "smartness"

Google has finally shown that it’s still alive and very strong, with its Gemini 2.x and 3 models, Nano Banana, and other tools, and deep integration into Search, Android, and Workspace. OpenAI rolled GPT-5/5.1 out of "thinking mode" and made it the default in ChatGPT, effectively dragging a bunch of niche tools under it. Anthropic with Claude 4.5 is seriously putting the pressure on its competitors in coding and reasoning. Meta continues to pump Llama in open source. For the user, it is no longer "one model is better than another", but a whole forest of ecosystems that fight to be your main "superstructure in work." The high level of competition is always in our favor.

3. Data centers as new "capitols" with Heroes 3

The capitol is an extremely necessary thing in Heroes III, but it costs a lot of money. It’s the same with data centers. The IEA and the European Commission predict that data centers already consume about 1.5% of all electricity on the planet, and could double this consumption by 2030, largely due to AI. Energy demand in the United States for data centers jumped 20% year over year, and AI servers are taking an increasing share of capacity. Big Tech is responding in its own style: it’s buying up solar/wind plants, it’s building gas and small nuclear projects, it’s turning old coal-fired power plants into data centers, and its signing contracts for building its own nuclear power plants. Nuclear power plants, Karl!

4. Regulations, courts, and "AI psychosis"

The EU AI Act has officially started, and DSA is starting to bite with real fines. In the United States, state attorneys general issue warnings to large AI companies about mental health risks. The first lawsuits have appeared where ChatGPT and other models appear in real tragedies — from suicides to murders, where AI allegedly added fuel to the paranoia. Regulation has traditionally lagged behind technology, but politicians and courts are already in play, and 2025 has clearly shown that "it's just a chat" no longer works as an excuse.

Five most high-profile scandals of 2025

1. DeepSeek: China's "nightmare" for the market

At the beginning of 2025, DeepSeek released its models with an embarrassingly low price and pretentious claims about "ridiculous training costs." The market panicked, NVIDIA shares sagged. Then it turns out that everything is not so simple as "cheap" training. The quality of "supermodels" from China took a hit, too. But the shock of just how one release can collapse half the market remains.

2. X becomes DSA’s first major "patient"

The EU decided to demonstratively apply the Digital Services Act and issued X an estimated $140 million fine for manipulative blue ticking and refusal to provide data for research. This is the first major case DSA in action, and hardly the last. The signal is clear: playing "I do whatever I want" in Europe won’t work anymore, even if you really love freedom of speech in your own interpretation.

3. TikTok: Banned, then not banned, with an eternal "window for agreement"

The TikTok saga in the US was reminiscent of a soap opera. The law required that either TikTok sell itself to an American owner or leave the market. TikTok defiantly shut down its service in the United States before the deadline, the administration dragged out the time, and then Trump came. He extends the "window for agreements" several times (he’s the master of the “art of the deal,” let's not forget). As a result, bidding continues for a year, names of possible buyers are announced, but they never do get full control — formally everything has been signed, but in reality everyone just pretends to be very busy, and postpones the final steps.

4. Google: Antitrust wars and the shadow of selling Chrome

Google is simultaneously focused on several different fronts: dominance in advertising and search, abuse of its mobile platform, and the use of the web to train models. Against this background, there was even a lot of talk and rumors that the company could be forced to sell Chrome, and there was a long queue of those who wanted to buy it. Hyenas can sense blood from far away, as they say. The sale didn’t take place, but the very fact of discussing the sale of the #1 browser shows how tightly Google was squeezed.

5. OpenAI's exit from Microsoft's influence

OpenAI and Microsoft are officially "restarting" their partnership: Microsoft remains a large shareholder, but without total control. Azure's exclusivity is being diluted, and some OpenAI services are moving to other clouds. In the end, the companies declare friendship, but in fact they are preparing for a "civilized" departure: OpenAI wants to make decisions on its own and have freedom, while Microsoft wants the right to develop its own AI separately. At least, that's what they say. OpenAI gets certain advantages from separating, that's clear, but what Microsoft will get out of separation is still a question.

Three most positive events of 2025

1. AI in Medicine: From promises to real-world treatments

2025 was the year when AI in medicine finally showed something more serious and applicable than just promises on paper. Results of clinical trials of AI-developed drugs against cardiovascular and oncological diseases are emerging, and Rentosertib for the treatment of idiopathic pulmonary fibrosis has demonstrated safety and benefits. Furthermore, AI approaches to early diagnosis of cancer and liver diseases are actively developing. This is not yet "AI cured cancer," but real steps in this direction are already being taken.

2. Quantum Computers: Less hype, more benefit

After years of promises about how cool quantum technology can be, we are slowly but surely moving towards practical applications. New systems like Quantinuum, Helios, and Google Willow show progress in bug correction and stability. It's still expensive and niche, but it looks less and less like PR, and more and more like a long-term bet.

3. Global IT demand comes to life

India's IT services exports grew by about 12.5% to $224 billion in fiscal year 2024-25 after several sluggish years. For the industry, this means a simple thing: enterprise money is again used not only for cost optimization, but also for new projects and digitalization. For Ukrainian outsourcing, this means not a direct contract, but a very positive indicator: customers are ready to buy again. If the money returns to India, then it will reach us.

Four worst IT news in 2025

1. Massive declines in global services

In October, there was a long-term crash in AWS us-east-1, which in turn “crashed" Slack, Atlassian, Snapchat, and a million more. In November and December there were two big Cloudflare failures, one of which knocked out up to 28% of the world's HTTP traffic. The conclusion is banal, but painful: the Internet is too dependent on several infrastructure players. The words "multi-region/multi-cloud" on presentation slides are not a guarantee of real sustainability.

2. AI-enhanced cyberattacks

Cybercriminals are awake too: tools like PromptLock are emerging, which use generative AI to automate phishing and more complex attacks. The year 2025 saw a series of major leaks and ransomware attacks on energy, logistics, and other critical systems. AI increases the productivity not only of developers, but also of all the "bad guys".

3. Giant data breaks

Prosper Marketplace in the United States lost the data of 17.6 million people, and the South Korean company Coupang lost another 33.7 million accounts. In total, there are more than 50 million records with names, addresses, documents, and order histories. The reputation of fintech or e-commerce can now be lost in one bad year.

4. Mass layoffs in tech

According to TrueUp and other trackers, in 2025, almost 700 waves of layoffs in tech companies took the jobs of more than 200,000 people — an average of 600+ dismissals every day. The headlines are the same again: Amazon, Microsoft, Google, Intel, Meta, etc all laying off employees. Increasingly, companies are saying bluntly: we are cutting people to invest in AI and automation. So either we learn to work with AI, or AI will replace us, little by little. Don't forget this simple rule.

Six most interesting releases and announcements of 2025

1. ChatGPT Atlas and Comet — AI-browsers

OpenAI launched ChatGPT Atlas — a Chromium browser with ChatGPT at its heart: sidebar, summarizing articles, comparing products, working with documentation directly in a browser window. Perplexity rolled out Comet — also on Chromium, but with a focus on a personal agent who does its own research, deletes unnecessary tabs, and rakes mail. These are no longer add-ons on top of Chrome, but a new class of products: "a browser as a shell for an AI agent."

2. AGENTS.md — README for agents

In August, AGENTS.md appeared — a simple file at the root of the repository that explains to AI agents how to live in a project. How to collect and test code, where the entry points are, and what the rules are. In just a few months, tens of thousands of repositories pick it up, GitHub adds guides, and the Linux Foundation with OpenAI/Anthropic formalizes it as part of the standard for agentic AI. Starting this year, documentation is divided into human-made (README.md) and agent-made (AGENTS.md) — and it looks like it’s here to stay.

3. Claude 4.5 is a "programming neighbor" for developers

Anthropic updated its entire lineup: Opus 4.5, Sonnet 4.5, Haiku 4.5. Opus seriously improves reasoning, long contexts, and tool/agent handling. Sonnet has become a workhorse at an adequate price. Haiku has become an ultra-fast, high-volume option. In reviews, Claude 4.5 is often cited as one of the best dev assistants for real-world projects, not just for template tasks or pet projects.

4. Gemini — Google shows it can do it all again

Google rolled out Gemini 2.0 (Flash / Flash-Lite), then 2.5 Pro / Flash / Deep Think, and at the end of the year, Gemini 3 Pro. The models are getting faster, smarter, and are heavily tied to the Google ecosystem. The most important thing is total integration: Gemini lives in the search, Gmail, Docs, Android, and Google AI Studio. This is no longer an attempt to catch up with competitors, but a separate ecosystem that can really be used on its own. Many note that this is one of the best AI releases of the year.

5. Starlink Direct-to-Cell and Ukraine

SpaceX launches commercial Starlink Direct-to-Cell: satellites work as base stations, SMS texts are sent from ordinary smartphones through space without special devices! And then Kyivstar becomes the first operator in Europe to launch D2C together with Starlink: first for SMS and basic messages, then they plan to add voice and mobile Internet. For Ukraine, this is not just another feature, but an important element of resilience during blackouts and shelling.

6. Bonus: Sora and the first step to a "dead internet"

OpenAI released Sora 2 for video generation and a separate application — a conditional "Instagram," purely for AI videos, called Sora. Feeds are clogged with synthetic video, people are delighted, and at the same time, many are wondering: if social networks begin to massively switch to generated content, how much "live" Internet will we have left? On my side, I can admit I myself sometimes get caught up in this content. And yes, sometimes I can't even distinguish it from real content.

Five "most" interesting hardware inventions of 2025 — once again it’s all about the metal

1. Most innovative device: the Meta Ray-Ban Display

The first AR computer to be really similar to a daily device, in the form of normal glasses. Meta AI's messages, navigation, translations, and replies are all right in sight. Special attention should be paid to the Neural Band, a bracelet that reads muscle impulses and allows you to control the interface with gestures. There are still plenty of questions about the product, but as far as a direction of innovation goes, it’s very interesting.

2. Hobby of the Year – Logitech MX Master 4

Yes, it's "just a mouse," but the MX Master 4 with the new Haptic Sense Panel and Actions Ring was one of the most pleasant changes to the working day. Ergonomics, multi-device, and a bunch of custom shortcuts that really save time. As the owner of the previous version, I can honestly say: this is a device that’s difficult to pass up.

3. Disappointment of the Year – iPhone 17 Pro

On paper, there’s the A19 Pro, a new camera, Apple Intelligence, and marketing bull shit. In practice, there’s a controversial design, aluminum instead of titanium, and the main AI features arrived late to Europe and in a stripped-down form. If you’re looking for an Apple, then check out either the iPhone 17 Air, albeit with questions, but at least it’s something new, or the regular iPhone 17, which turned out to be much more successful.

4. An Interesting Niche Product – Oura Ring 4

Although Oura Ring 4 was released last year, it received a cool ceramic version this year, and looks like the king of niche devices: tracking sleep, stress, and activity in the format of a beautiful piece of jewelry, not just another screen on your arm. Not for everyone, but for those who bother, wellness is a very nice gadget.

5. Garbage of the Year – Samsung Galaxy XR

Formally, it’s the first Android XR device and flagship in cooperation with Samsung, Google and Qualcomm. In fact, it’s a rather expensive demo. Albeit lighter than Vision Pro, it’s not very ergonomic, with an external battery, damp software (very raw), unstable tracking, and a poor catalog of applications. Against this background, even the already-mentioned, not very successful Vision Pro looks cooler.

Big IT names we lost in 2025

The traditional block where you want to press F and cry.

Bill Atkinson was a legendary Apple engineer, creator of MacPaint and HyperCard, and the man who shaped the look of early GUI.
Steve Shirley is a pioneer of outsourcing and remote work, the founder of Freelance Programmers, who built an outsourcing business long before it became mainstream.
Margaret Boden is one of the founders of cognitive science and AI research, and the author of classic works on the interaction of artificial and human intelligence.
David Benaron is a doctor and entrepreneur whose developments formed the basis for the sensors of modern fitness trackers and smartwatches.
Udo Kier is an actor, but for us he is forever Yuri from Command & Conquer: Red Alert 2.

This is only a small cross-section of the people whose work "lies quietly under the hood" of the things we use every day, and that we have lost this year.

And separately — R.I.P. Skype, a piece of our everyday life, to which time still said "that’s it" and left.

Other 2025 Highlights

IT Hero of 2025 — Jensen Huang, CEO of NVIDIA

Under his leadership, NVIDIA briefly touches the $5 trillion capitalization bar on October 29, becoming the most valuable company in the world. The demand for their chips is rewriting records, and NVIDIA itself has finally turned from a "company for gamers" into a monopolist of infrastructure for generative AI. The man in the black leather jacket became the face of the era – more than anyone else.

2025 IT Villain — Astronomer CEO Andy Byron

We could easily give the statuette to one famous billionaire again, but this year the anti-hero award goes to Astronomer CEO Andy Byron. He became famous not for his products, but for his very loud personal story and the memes around it. Sometimes the villain of the year is not the one who breaks the market, but the one who coolly spoils his reputation because of an affair at a Coldplay concert. The story will go away, but the memes will stay with us forever.

IT anecdote of 2025

On the one hand, there’s Ilya Sutskever and Mira Murati, who collected billions for a startup based on a "bare name," without a product. It's very cool, but I would believe in such a joke only in an anecdote.

On the other hand, there’s a wave of madness around the new image generation model in GPT-4o: the Internet is turning into an anime carnival, Sam Altman complains that there’s not enough power, and users can’t stop. True surrealism.

IT Surprise of 2025 — Oracle and Media Triples

Oracle suddenly becomes an AI cloud star: its shares soar more than 40% in a day after news of giant contracts and OpenAI connections, its capitalization approaches a trillion, and Larry Ellison overtakes Musk in the ranking of the richest people in the world by several hours.

In parallel, Netflix, Paramount, and Warner Bros. Discovery play out a complex love triangle with purchase claims and political overtones. The content market is shrinking, and we are gradually approaching the world of "one app for all videos." Jobs willing, one day it will be so.

Mobile 2025: Liquid glass and Epic vs Apple

This year I decided to add such a nomination. Apple is importing a complete redesign of iOS in the style of liquid glass - beautiful, loud, uncomfortable in places, but definitely hype.

And Epic is finally winning a small but important victory in the fight against Apple. It was definitely a pebble that, albeit a little, changed the issue of commissions in mobile stores. Not a revolution, but it is from such microcracks that large monopolies begin to gradually rethink their behavior.

Five predictions for 2026

Alright, let's move on to the forecasts!

1. AI agents will become the new daily software, and the hype will continue

In 2026, the average engineer will have not one chat or tool, but several AI agents who will do the routine: walk through Jira/Confluence, rake mail, and write drafts. The item "experience in building and managing AI agents" will increasingly appear in vacancies.

2. Energy will be the main limitation on the AI boom

We’ll see the first cases when the construction of data centers is directly limited by access to energy and water. Investments in energy, especially nuclear energy, will become a part of Big Tech's AI strategy.

3. Regulators will move from chaotic fines to a system of rules

The first real AI certification frameworks for medicine, finance, and education will appear in 2026. They will still be bureaucratic, but they won’t look like chaotic steps any longer. At the same time, we can expect high-profile court cases against AI platforms for damage to health, people’s wallets, or their reputations.

4. Fake AI profiles and content will become commonplace

What now looks like "strange Insta accounts" and individual cases will become a massive buzz in 2026. Generated faces, stories, news, bloggers, individual content will become the new normal. The question of the year will be "is there anything real here?"

5. Internal AI platforms will become the standard for companies

If in 2025 proprietary LLMs or internal AI platforms were a feature of a few, then in 2026 an internal AI platform with access to documents, code, and processes will become a new "corporate standard." Someone will buy ready-made solutions, someone will assemble it themselves, but "enterprise AI" will cease to be a pilot, and will become an obligatory part of the infrastructure.

Closing 2025

This year was difficult. At times it was extremely difficult. For many people it became the most difficult year in their entire career and life. But from the point of view of IT, this year turned out to be incredibly rich. AI became smarter, data centers became hungrier, regulators got angrier, Big Tech got fatter, and Ukrainian IT got even more inventive.

*The article was initially published on DataArt Team blog.

Modern Java: Why Old Rules No Longer Apply

Nevena — Tue, 23 Dec 2025 11:35:32 +0000

Is Java no longer relevant? Denis Tsyplakov, Solutions Architect at DataArt, doesn’t think so. Java's reputation issues stem less from the language itself and more from outdated practices. This article revisits long-standing Java dogmas, identifies shortcomings, and offers modern alternatives to improve our development workflows.

Note: Code review standards vary by company and project. Apply these ideas thoughtfully; abrupt changes to enterprise projects can disrupt teams.

Setters and Getters

One common complaint is that Java code gets cluttered with setters and getters. They were initially popularized in the 1990s due to the influence of The Gang of Four (GoF) Design Patterns, which promoted implicit behavior in classes. However, implicit behavior is now seen as bad practice: data and functions should be separate. Most times, setters and getters aren't required unless you're using specific libraries like JPA.

Alternatives:

Class with Fields: Suitable when transporting 3-5 fields between methods.
Records: A standard solution for storing data in Java, creating immutable data classes equipped with hashCode, equal and getters. However, they enforce a "stateless state" paradigm, which is fine in 95% of cases. Unless you have a 10 MB+ data structure requiring modification of individual data class fields in real-time, then use a DTO.
Advanced Future Solution: Project Valhalla for lightweight data structures.

One Class, One File Rule

The "one class per file" rule has been a golden standard since Java's early days. While this structure made sense when IDEs were less advanced, it's become less relevant today. Modern development environments offer robust search and navigation capabilities, allowing for more flexible file organization.

Problems with the rule:

Decreased Readability: Jumping between multiple files to follow a single logic flow.
Broken Nesting Logic: Classes like DTOs or callbacks make sense only within the context of their parent class. However, the project structure does not show that relationship.
Local Block Scope: Exposing classes outside the method spoils the class structure.
Domain Leaks: Moving non-sharable classes outside their natural context introduces fragility.

Alternatives:

Place dependent classes/interfaces within their parent class where they belong.
Group tightly coupled DTO records under a single parent class. For example, serialize the main class BookingDTO to JSON and put nested classes InvoiceDTO, ItemDTO, etc, inside BookingDTO.
If you need a data structure inside the code block, declare the class and do not expose it.

In general, make sure your code does not make you jump between classes too often and does not make you scroll for too long. Your code will be easier to read if you have 20 files with 20 lines of code instead of 80 files with 5 lines.


`public record DBDataInfo( 
    int documentsCount, 

    int documentsUnProcessedCount, 

    String dbSize, 

    int docProcessingErrors, 

    int archivedDocCount, 

    List<SourceInfo> sourceInfo 
) { 
    public record SourceInfo( 

        String name, 

        int raw, 

        int digest 

    ) {} 
} `

Custom Exceptions

The Java exception system is one of its strengths, and one of the reasons why I started using it over 20 years ago. The primary purpose of the exception mechanism is the ability to handle unique scenarios. In this paradigm, we usually have one exception for each scenario that can be compensated for.

However, in microservice architectures, compensation becomes less relevant and is often streamlined to the service level. It usually involves cognitive complexity that exceeds the average. For example, in a medium-sized system, you may compensate for 2-3 types and nothing more.

Java (and frameworks like Spring) offer many standard exception classes that cover 95% of cases, such as IllegalArgumentExceptions and IllegalState exceptions. Most often, developers are unaware of the standard exceptions and declare a class structure that's hardly digestible and can ruin your code.

Alternatives:

Consider scenarios that can be compensated and stick with standard exceptions otherwise.
Design an exception hierarchy around those cases.
In a microservice architecture, 80% of sync call exception handling cases fall under two patterns: retry and circuit breaker.

Remember: Creating a new class can add some cognitive load. Think about how it might affect different situations. If you don't plan to use it, it might be best to skip it.

Example:

@io.github.resilience4j.circuitbreaker.annotation.CircuitBreaker( 

    name = "weather",  

    fallbackMethod = "offlineWeather" 

) 

public WeatherDto current(String city) { 

    return restTemplate.getForObject( 

        "https://api.example.com/weather?city={}",  

        WeatherDto.class,  

        city 

    ); 

} 

  

/**  

 * Fallback when circuit is OPEN or the call itself fails.  

 */ 

public WeatherDto offlineWeather(String city, Throwable ex) { 

    return new WeatherDto(city, "???", "service-unavailable (cached/default)"); 

}

Mapping

In a classic enterprise app structure, you map controller parameters to a DTO, which maps them to an entity. Then, the entity passes to a repository (DB or REST), and you receive another entity in exchange, return to the service, map it to a DTO, and return to the controller.

Real-life example: In a microservice, we receive a 1MB+ flight search XML reply from NDC, map it to a data structure, extract the airline code, add it to the response header, and pass the reply along. But parsing the reply and serializing it takes several seconds (10+ seconds in the worst case).

Solution: Read the reply as a byte stream, parse it with a NanoSAX parser, set the header, and return the bytes as the body. This would take less than 10 milliseconds.

However, a more critical problem is creating mappings for hundreds of fields when your code only needs a dozen. This makes simple microservices hard to read and digest.

Alternatives:

Avoid Unnecessary Mapping: If you only need a few fields from a JSON object with 100+ fields, read it as a JSONNode and extract fields to a clean DTO.
Use Declarative Transformers: Wherever it’s applicable, use XSLT(c) for XML, use libs like JSLT, Jolt, JSONata-for-Java, etc.
Minimize Hierarchies: If one is enough, avoid creating both entity and DTO layers. Just use a DTO, but track any data leakage.

Dependency Hell

Java engineers like mapping data structures and frequently create system-name-dto.jar, using it as a library in all services. All incoming data is mapped to one of the library DTOs and serialized back to JSON/XML when sending HTTP with RESTTemplate/Feign. This approach creates problems such as decreased performance and changes in the library when the DTO library is used in 30 different services deployed to prod 24/7.

There is no universal solution to this, but you can try a few of these guidelines:

If more than two services use a big DTO, you probably need to rethink the service design.
If you just pass through a big data structure, stick to that and don't mutate or inspect it.
Make the mutated part a separate DTO if you need to mutate it.

Separation of Interface and Implementation

Theoretically, it seems like a good idea. You define the interface of a service or class and then create an implementation. If you need more, you make more. This practice results in writing more code than needed.

The typical explanation for this was:

Enforce Class Contract: Even though Java classes have public contract methods.
Unit Testing and Mocking: If your code needs to be changed to facilitate unit testing, you should probably rethink your test strategy.
Prepare for Future Extension: Do it when needed, not in advance.
Multiple Implementations: Nowadays, we usually don't have more than one implementation of an interface.

So, how to deal with it? Just don't do it, that's it. If you'd like to explore this topic in more detail, read this article.

Reactive Code

The main argument is that all reactive frameworks for Java are dead. There are several reasons for this:

Virtual Threads (Project Loom, GA in Java 21) make the classic "one-thread-per-request" model memory-right and massively scalable, eliminating the core performance reason for adopting reactive I/O.
Structured Concurrency and scoped values give you simple, imperative flow control and tracing without the cognitive load of reactive streams, but with equal or better throughput.
Mainstream HTTP Frameworks: Spring MVC, JAX-RS/Jakarta REST, Micronaut HTTP, Quarkus RESTEasy run unchanged on virtual threads and now match WebFlux/Vert.x-style stacks in latency and QPS, but with cleaner code and easier debugging.
Blocking JDBC Sudden Scales: A single JVM can spawn hundreds of thousands of virtual threads that wait on the same java.sql calls. So, you no longer need reactive drivers (R2DBC, jasync-sql) just to keep database I/O from becoming a bottleneck.
Reactive Frameworks bring complexity:
Non-linear control flow
Back-pressure plumbing
Tricky error handling: yet their performance edge has vanished
Copilot-like tools better digest the sequential blocking flow of operations. Post Java 21, the cost/benefit equation flips in favor of simple blocking APIs.

2Spring and Beyond

Another typical dogma is, "Java is not always Spring." While Spring is one of humanity's most advanced and remarkable frameworks, it still has some flaws; it requires you to write your application in a certain way and increases memory consumption.

There were some attempts to create something better. Quarkus, for example, was quite popular a few years ago, but is not a buzzword now. There is no comparative framework to replace Spring, except for some niche tasks.

So, the main points here are:

Java has frameworks for everything.
Don't avoid Spring; use it if you can.
If you have a specialized task, do your research: most likely, there is a Java framework/library for it.

Enterprise-class app hierarchy

The classic Java class hierarchy goes like this: Controller>DTO>Service>Entity>Repository

The main goal of a standard class hierarchy is to make the class layout predictable. It's useful for applications with over 200,000 lines of code, enabling developers to quickly find a class with specific business logic.

But if you have a small microservice, you don't need to follow the same pattern. You will probably have just 5 controllers with 10+ methods.

Ask yourself:

Can a controller go directly to the repository?
Do you need to remap an entity to a DTO?
If a service needs one SQL query, can it be done directly inline?

Granularity matters, but oversplitting small services can create unnecessary bloat. Sometimes fewer layers mean clearer, more maintainable code.

Let's test the limits and see how far we can distance ourselves from the dogma.

@PostMapping(🌐“/api/booking”) 

public void saveBooking (@RequestBody BookingDTO bookingDTO) { 

record BookingReply( 

UUID uuid, 

String transactionId) { 

{ 

jdbcTpl.update(sql… 

update booking set transaction_id = :transactionId where uuid = :uuid 

…, Map.of( 

k1: "uuid", bookingDTO.uuid, 

k2: "transactionId", restTpl.postForObject( 

url: http://booking.api/booking , 

bookingDTO 

BookingReply.class).transactionId) 

); 

}

This code is functional, with 17 LOC that shows all the logic end-to-end. Nonfunctional aspects, such as error handling and validations, are handled at the service level. Would this be fine as a part of a 200 LOC microservice? I'm not brave enough to try.

So, one controller that does the rest call and saves the results to the database in just a few lines of code. The reply is in line with everything. Is this legal? Probably not. If I see this in production code, I will probably ask to separate work with the database and HTTP into two different classes due to a mix of concerns.

This would be acceptable on other platforms and languages. Imagine writing 17 lines of code in one file or 5 times more lines for the same logic. The latter sounds better. But don't take this as advice; we were only testing the limits here.

Performance Myths

“Java is Slow”

Many people say Java is slow, but that's not really the case! This perception comes from needing to switch to other frameworks or languages to make things faster. If you check out some performance tests, you'll find that Java actually performs well. Indeed, it may not be as fast as C or Rust, but it still holds its own.

If you're looking to speed things up, consider using the GraalVM Compiler! It's simple to set up with Spring—just add one line to your configuration, and you'll see a boost in performance. You can test it by checking out these links:

“Java Slow Startup”

25 years ago, it might have taken a few seconds to start. But nowadays, numerous ways of speeding things up are essential when designing a microservice architecture in a Kubernetes cluster. A good solution for this is called the Coordinated Restore Checkpoint. It allows you to capture the state of an already started container and deploy it into production. If you follow this link, you'll see how to speed up your application's startup 100 times.

Why Change How We Write Java

There are several reasons for this:

Code Assistants: Copilot and similar assistants work best with linear text. You can have one file with data objects; Copilot will know which to include. So, you should write your code to be more readable for assistants since they are our future.
Language Evolution (Java and Spring have changed significantly): Design patterns from 20 years ago simply don't work anymore.
New Generation Pressure: You should adapt and embrace new approaches. Others don't see a reason to follow old practices.

Conclusion

To keep Java relevant, we must rethink old conventions.

Action points:

Stay updated with Java 11, 17, and 21.
Study the latest Spring Framework documentation.
Explore the broader Spring ecosystem: Spring Data JDBC, Spring Cloud, etc.
Question current best practices: Are they relevant today?
Experiment with TypeScript or other languages to broaden your programming perspective.

Java isn’t outdated; it’s evolving. The real challenge is ensuring our coding habits evolve with it.

*Originally published on DataArt Team blog.