Inside Svitla Systems: The honest math of AI in engineering work  

We asked Svitla engineers across product, design, frontend, backend, QA, DevOps, and data how AI changed their working day. The answers ranged from “10x faster” to “we barely use it.” 

90% of experts at Svitla Systems are senior engineers. It is clear without saying that they know how to write clean code, run a sprint, and ship to production. So, when we talk about growth, we mean the work someone can take on now that they couldn’t a year ago. 

AI has made that question a lot more interesting. In two years, it went from a topic in technical discussions to something our teams use every day in their code editors, terminals, and project boards. So, a routine week of senior engineer looks different: less typing and a way more decisions to make. 

After more than eight years of building Java backends, I judge tools by what they change in a working day. Of course, AI headlines keep coming. Still, I wanted a bit of a practical answer: what does AI change for the people I work with every day? 

So, I asked colleagues across Svitla teams, from Product Owners to DevOps, to walk me through their real routines, and two patterns kept showing up. 

• Our engineers grow sideways. A backend lead builds a full frontend. A data scientist runs pipelines that used to need a whole team.  Engineers often move into new layers of the stack, building breadth alongside seniority. 

• Our engineers work at the product level. With routine work handed to AI, they spend more time on the questions clients care about. Does this feature make sense? What will it really cost to build? What could break in production? 

Below is an honest look at a normal working day for each role: the wins, the edge cases, and the parts we still do by hand. 

Product: from stakeholder request to Jira tickets in a day 

A Product Owner’s calendar looks predictable from the outside: back-to-back meetings, stakeholder alignment, and a mountain of user stories to draft. I half-expected our POs to say, “I brainstorm product ideas with ChatGPT.” That was well off the mark. 

A Senior Product Owner on one of our client projects walked me through a setup that connects five tools: 

Before AI. The core job hasn’t changed. You still work with stakeholders, take their raw business requirements documents (BRDs), and push back: Do we need this? Should we validate it with users first? The difference now comes down to speed and tooling. 

The workflow. The longest end-to-end flow looks like this: 

1. Discuss the BRD with the stakeholder. 

2. Upload reference screenshots and the app’s design system to Google AI Studio, then prompt Gemini for the target screens. The output is a clickable prototype. 

3. Iterate with the stakeholder until they sign off. 

4. Switch to Claude and Rovo to file Jira tickets for the designer and the writer, with the prototype, adapted screen designs, and proofread copy attached. 

5. Draft technical requirements for development and QA, then plan the work into the sprint. 

The result. Prototyping used to take one to three days, including change requests. Now it takes up to a day, and most of that is waiting for the stakeholder to reply.  

Over the week, the PO estimates saving 15–20% of their time. “That time goes to harder, more interesting tasks. Or, honestly, to 15–20% more coffee breaks.” 

For the client, the sprints now kick off with an approved prototype on the table. 

Where a human is still needed. Read everything AI writes for a spec carefully. Once, the PO trusted Claude Sonnet 5 in extended-thinking mode, with full context and Jira access, and skipped the review. Later, a developer pointed out that the spec expected the backend to pass parameters it doesn’t pass today. Built as written, the feature would take a week instead of the two hours the team had agreed on. The AI model had filled a gap with its own assumptions about backend behavior. 

Explore how to choose the right model and understand the difference between Haiku, Sonnet, Opus, and Fable. 

Frontend: less file-hunting, more UI logic 

Frontend work means matching the design and keeping application state under control, often while the interface itself keeps changing. A “simple” form update can mean edits across dozens of components and stylesheets. I wanted to know how AI handles that messy, interconnected code without breaking the UI that’s already in place. 

A Senior Frontend Engineer on one of our e-commerce client teams uses two AI tools: Claude Code in the terminal for planning and multi-file changes, and GitHub Copilot in VS Code for inline completion and as a backup. 

Before AI. Refining tickets and making broad changes, like updating forms across dozens of files, used to take hours of manual searching and editing before the code was ready for review. 

The workflow. 

• Sanity-check tickets. Pull up the live code in the terminal to confirm a ticket is feasible before committing to a plan. 

• Build in a loop. Describe the task, review Claude Code’s proposed change, and refine it step by step.  

• Automate the overhead. Custom skills generate PR descriptions, compile release notes from Azure DevOps tickets, and run a first automated code review. 

The result. Refinement and coding both go noticeably faster now. Developers no longer write boilerplate or search through dozens of files, so they can spend that time on UI logic. 

Where a human is still needed. “It’s a supporter, not something to trust blindly.” AI still slips in subtle bugs, logic errors, and the occasional hallucination, so human code review stays mandatory. Most delays still come from tickets with unclear or missing requirements. 

UI/UX design: two honest, opposite answers on artificial intelligence 

Sometimes the product vision asks for something the technology can’t deliver, and design has to find a way through. Code completion gets the headlines, but design workflows are changing too. I asked two designers. Their takes are miles apart, and it’s worth hearing both out. 

“AI cut my execution time several times over” 

One UI/UX Designer works with ChatGPT and Figma’s built-in AI agents. Before, technical specs meant manual searching across Google, specialized sites, and forums, and a lot of routine work was done by hand. 

Now AI runs the research phase: testing hypotheses, clarifying technical limits, and gathering insight on user behavior patterns and design testing. It also generates and processes images, animations, and visual assets. And it works as a sparring partner for brainstorming and validating design ideas. 

By the designer’s estimate, many tasks now go several times faster, and the process feels more structured. What's more important is that now there is more time to focus on design itself.  

“I now have far more time to create and validate core product hypotheses.” Either way, the approach doesn’t change. Every AI answer gets reviewed, and none of them go straight into the final work. 

“We’re barely using it, and here’s why” 

A UX Designer on one of our e-commerce client teams gave the opposite view. “We're not using it much, which is a way to say we're not using it at all. The main reason is that UX is among the last places where we're trying to understand the (human) users, and so if AI could do that, then it would be truly intelligent.” 

The team still ran experiments: 

• Google’s AI design tool generated screens for a new feature. The result was acceptable but overworked, and it ignored the company’s styling. 

• Figma Make, fed the full design library, did slightly better on look and feel but still didn’t match the website. More prompting might have helped. Compared with a skilled designer and a complete design library, though, it saved no time. 

• Figma’s AI assistants were useful for one narrow job: bulk-updating text to match the live site’s menu items. It saved time, but the team rarely needs designs identical to the website. 

“If we reuse anything, it would be the Figma assistants. Every now and then.” 

Both designers agree on what matters most: product thinking and understanding users stay human work. One uses AI to make room for it. The other protects it by keeping AI out. 

Backend: from author to editor 

Backend is my home turf, and I’ve heard every take on AI. One camp says developers are getting lazy and can’t write a single line without it. The other turns AI suggestions off completely. “I don’t want a machine telling me how to write my code,” as a colleague put it. 

I don’t want to argue either extreme. My view: AI takes the edge off the daily grind and moves a developer from author to editor and reviewer. A real person still reads, checks, and tests the output. Three backend stories show what that looks like in practice. 

"20% faster, and 20% more mental load"

A Senior Backend Engineer runs a setup built around agents: 

• Claude for complex logic, planning, and documentation 

• OpenCode and Junie (JetBrains) as coding agents in the terminal and IDE 

• GitHub Copilot for inline completion 

• MCP connections to every external tool that supports them, so agents pull system context on their own 

Most of the effort now goes into the start: detailed prompts and plans before any code exists. Recurring tasks become dedicated skills or agents. Every change passes an automated agent review first, then a human code review. At the same time, edge cases still get tested by hand. 

The net gain is about 20%. Some tasks finish much faster, others need slow refinement. “My cognitive load went up by the same 20%. Managing agents, writing prompts, and reviewing their output is work too.” 

AI is good at gathering context and writing syntax. It stumbles on business logic, domain nuance, messy real-world data, and keeping architecture simple. That part stays human.

Work with AI engineers who already use AI in daily delivery and know where its output needs a second look. Forward deployed engineering

"Almost no time on raw code, more time on the problem"

Another Senior Backend Developer described the old pain differently. Juggling more than two or three tasks at once was exhausting. Developers joined requirement discussions late. Finding cross-repo dependencies took a lot of manual digging. 

The current setup: 

• Claude and Copilot, balanced to work around usage limits. Through MCP, Claude even drafts replies to PR review comments, which are always reviewed before sending. 

• A bookkeeping system of context files (TODO.md, WORKLOG.md, TICKET_CONTEXT.md, CLAUDE.md) and custom skills that keep context across long sessions and many topics. 

• Haiku 4.5 for quick early feedback. It makes more mistakes than larger models, but its speed keeps decisions moving. 

During early analysis, Claude breaks initiatives into user stories and drafts technical docs. Later, it helps with discovery, feature branches across several repositories, automated tests, PRs, and scenarios for manual testing. 

“I spend almost zero time writing raw code. My focus is on understanding problems and describing solutions.” Switching between many in-progress initiatives is now close to effortless. Because the analysis is ready sooner, the developer joins requirement discussions at the architecture stage, where a backend view changes the outcome most. 

Still, the limit is clear: “I haven’t found a model that can complete a complex requirement at the expected quality. A human still makes the decisions.” 

A production database migration in 2 days instead of 8 

A Principal Software Engineer shared a recent case. The team’s semantic product search runs on Weaviate, a vector database. It had been live in production on a single node. The task was to scale it to three nodes for high availability and load distribution. He had never done this before, and it was a production database. 

He used Claude Code with a plugin of built-in skills for debugging, brainstorming, architecture design, coding, and code review. The work ran in four steps: 

1. Map the current Weaviate setup. 

2. Write a spec and a detailed plan. 

3. Rehearse in the test environment and update the plan after every failed attempt. 

4. Apply the final version of the plan to production. 

He set clear boundaries. Claude got read-only access to the AWS cluster to build the plan. He turned off auto mode to approve every AWS command Claude wanted to run. Every step that changed the cloud, such as applying changes or updating secrets, he did himself. He also documented the parts of the process the team might need again. 

The rehearsal popped up a lot of issues and fixing them early meant the production migration ran with minimal disruption. The whole job took two days. His estimate without AI: about eight. That’s roughly 75% less time. 

The lesson learned? Claude made many assumptions that only the rehearsal caught. “If I’d insisted from the very beginning that it take everything from official documentation instead of guessing, we could have saved even more time.” 

This is the kind of work clients trust a senior engineer with: a risky production change, planned, rehearsed, and owned by a person, with artificial intelligence doing the legwork. 

QA and test automation: from blank page to a connected loop 

QA protects reliability through accuracy and edge-case coverage. Our two QA stories sit at opposite ends of AI adoption. One engineer uses it as a daily helper. The other helped build a connected system around it. 

AI as a first draft 

A QA Engineer works with ChatGPT for problem-solving and brainstorming, Claude for writing and refining test code, and, until recently, GitHub Copilot inside VS Code. 

There are no complex prompt templates. The workflow is a conversation: describe the task, share code snippets or error logs, explain the goal, and refine. Claude and Copilot act as coding partners in the IDE. ChatGPT is an outside thinking partner for sanity-checking ideas. 

The biggest win is the end of cold starts. AI drafts the baseline for test scripts, documentation templates, test cases, and bug reports, and the engineer adapts to it.  

The limits are just as clear: 

• Data privacy. Sensitive or proprietary information can’t go into external models. Context gets cleaned up first, or AI is skipped for restricted tasks. 

• Project context. AI lacks a deep understanding of project architecture and UI nuance. Stable UI locators in complex environments still need a person. 

“AI is an assistant that generates a basic solution. I set the direction, review the result, and make the final call.” 

A loop from Jira ticket to bug report 

A Principal Automation Test Engineer (Java) helped build a system of AI skills that links Jira, Confluence, Figma, Testomat, and test code into one loop. 

Before, the job meant constant switching. Read requirements in Confluence, cross-check designs in Figma, draft manual test cases, move them into a test management tool, write automated scripts, and log bugs with screenshots and logs by hand. 

Now the whole team, from developers to manual and automation QA, shares role-specific skills in one repository. MCP connects Jira to Figma, Confluence, Testomat, and monitoring. Datadog handles log analysis. 

The loop works like this: 

1. A Jira AI skill gets a link to the automation task. Through MCP, it reads the linked Figma designs and Confluence specs, writes a manual test case, and exports it to Testomat. 

2. The QA engineer reviews the test case and approves it, with small edits if needed. AI then applies the right labels in Testomat. 

3. A second skill turns the approved case into an execution plan and an automated test script. The engineer reviews the code. 

4. When a test fails, a skill logs the bug: the report, screenshots, tags, the failing test, and the relevant Datadog logs. 

The system is still being tuned for full adoption, but the team estimates execution is about 10 times faster. Every step of the pipeline is visible to everyone involved. 

The human role is well defined: approve test cases, review automated scripts, and validate complex business logic. 

DevOps: from a day of log-reading to a few minutes 

Incident response is one of the most time-sensitive jobs in engineering. Logs hold the data, but tracing a failure across distributed services under pressure takes real effort. 

Before AI. When something broke in production, a DevOps Engineer on our team went through the Kibana logs for each service by hand, matched events by timestamp, and worked out where the chain of errors started. The initial analysis took about a day. 

The workflow. During active incidents, the engineer now runs Kiro as an agent, with project documentation and the codebase connected through MCP. The agent pulls Kibana logs for each service, rebuilds the chain of events, and cross-checks it against the docs and code. The output: the likely spot in the code where the bug occurred and what to inspect first. 

The result. Initial analysis now takes a few minutes. That’s the engineer’s own estimate, not a formal metric. 

Where a human is still needed. “The agent gives me a starting point, not a diagnosis.” An engineer still checks the hypothesis against raw logs and code, then decides what to fix or whether to roll back. 

Data engineering: one specialist, the output of a team 

Data science has always relied on pipelines and automation. AI changed something else: the role itself. 

Before AI. A Data Scientist on our team described the work as SQL, Python, and predefined architectures or pipelines. That setup handled model training and inference with little manual coding. But it didn’t scale to large applications, where good results depended on working closely with software developers. 

The workflow. Early GPT-3.5 didn’t change much. “The code was mostly boilerplate, the insights were useless, references were faked, numbers didn’t add up, and code that looked good on the surface was buggy.” Code quality improved over time, but the real turning point came last year, when reasoning models and agentic coding tools took off. “Agents finally had the context, and the wits, to build code based on the ideas you formulate.” 

The result. Today the role is closer to an AI developer than an analyst. “I babysit the coding agents. I look at their output and judge whether it makes sense, whether it’s cost-efficient, and whether it solves the problem.”  

Routine analyst questions take less time. The overall workload, though, is far higher than it used to be. Pipelines and applications that once needed a whole team can now be handled by one specialist working with coding agents. 

Where a human is still needed. The agents write the code, but the judgment stays with the specialist: whether the output is correct, worth its cost, and fit for the problem. 

My own setup: deeper reviews and a full-stack side project 

Beyond what my colleagues shared, AI changed three things in my own routine as a team lead. 

Code reviews. Reviewing by hand in Bitbucket means staring at isolated file diffs, and the bigger picture is easy to miss. AI reads whole classes and multi-file context at once. My self-reviews and my reviews of teammates’ PRs are now faster and more thorough, with fewer edge cases slipping into production. 

Changes across microservices. Tracing a feature through a chain of connected services used to be a headache. Now I use Context7 in two ways: 

• Standard setup. My agents get the latest documentation for external libraries, which keeps syntax hallucinations close to zero. 

• Custom setup. I indexed all our internal repositories locally and connected their MCP to my IDE. 

With that in place, AI maps the execution paths across every service in a flow, lays out the current architecture, and drafts a step-by-step plan for the change in seconds. 

AI has no feel for product strategy and no accountability for the system. For me, the point here is not the time saved but the quality of the result. 

Jira without leaving the editor. I connected the Atlassian Rovo MCP to my IDE, so Jira work happens in plain conversation: “Implement the changes from JIRA-123, run a code review on the result, and create a bug ticket for point 4.” No tab-switching, no copying ticket details, no filing tickets by hand. 

Learning frontend in weeks 

I’m a bit obsessed with automation. My favorite thing is spotting a repetitive task and turning it into something that runs on its own. 

Right now, I’m building my own web service from scratch: frontend, backend, and infrastructure. With eight years of backend behind me, the REST API was never the hard part. Frontend and UI/UX were new ground. I had never written frontend code, didn’t know how to structure or build a frontend app, and I have no visual design background (and, honestly, no love for pixel-tweaking). 

Without AI, I’d have spent months learning frameworks and design basics. With AI, I can bring the whole project to life in a few weeks. 

Of course, there are trade-offs. I can’t review frontend code with the same authority as backend code, and generated code doesn’t always follow best practice. My workaround is multi-model review: I ask several models to audit the frontend, read their reasoning, and decide what to change. 

Even on backend, where I’m the expert, blind trust is a trap. When I flag an issue, the model replies right away: “Good catch, I’ll fix that.” Then I ask it to run a strict review of its own fix, and it can find a high-severity bug it just introduced. 

The numbers at a glance 

None of these figures come from formal measurement. They’re the engineers’ own estimates, and they vary a lot by task. 

What it adds up to 

Across product, design, frontend, backend, QA, DevOps, and data, the same pattern kept showing up. AI moved our work from making things to curating them. It clears out boilerplate, speeds up prototyping, and makes jumping between repositories far easier. And every colleague, independently, said the same thing: a human in the loop is non-negotiable. 

I often hear the worry that with AI, developers won’t be able to write code on their own anymore. I think of it like navigation. With Google Maps, most of us stopped using paper maps and compasses. If they vanished tomorrow, could we relearn the old way? Probably. Would it be pleasant? Not really. Is going back the plan? No. But good navigation doesn’t mean you switch off your brain at the wheel. 

Here is what I take away: 

• Experience matters more. Models hallucinate, make risky assumptions, and introduce serious bugs. Judging the output, knowing why a system is built the way it is, and rejecting a bad suggestion take real expertise. Teams that try to replace experienced engineers with AI will pay for it in outages, corrupted data, broken infrastructure, and codebases no one can maintain. 

• Senior engineers grow sideways. With routine work handed off, our people pick up new stacks and new parts of the product. A backend lead ships frontend. A data scientist delivers what used to take a team. A developer joins architecture discussions from day one. 

• Engineers move closer to the product. Less time on mechanics means more time on system design, requirements, and quality. POs bring approved prototypes to sprint planning. Production changes get rehearsed before they ship. That’s the level where our engineers earn the right to speak as experts on a client’s project. 

AI speeds up execution and clears the routine noise. Human judgment stays at the wheel. 

Make AI part of delivery We build AI-assisted engineering workflows around your stack and your review standards. AI Development Services

Written by

Iryna Lukashevych

Senior Java Backend Developer at Svitla Systems