Part 2. From AI strategy to adoption: how Attico approaches SDLC transformation
From AI strategy to SDLC adoption: how Attico helps teams integrate AI into daily workflows and navigate organizational change.
From AI strategy to adoption: how Attico approaches SDLC transformation
In the first part, we already discussed AI itself and its role in SDLC — why it’s needed, where it can help, what benefits it provides, and what principles should be followed when implementing it. But technology is only one aspect of the transformation; the other is how people respond to the change.
In early 2026, the European Commission found that people already using AI at work clearly see its benefits — around 25% of respondents use AI for work and 91% of those using AI at work say it helps them complete tasks faster.
At the same time, 41% of employed AI users are concerned that AI could make them lose their job or make their role redundant.
These are some of the AI adoption challenges companies face. You can’t just tell employees, “Here’s a new AI tool. It’s useful, here’s some training — go use it.” Even when people see the benefits, they may still have questions like “What will change in my day-to-day work?” “What will be expected of me?” “Could AI replace my role?”
Approaching AI adoption
Implementing AI isn’t just about selecting tools and training; it’s also about properly guiding people through the changes — explaining why they’re needed, helping them integrate AI into their daily work, and ensuring the new model truly takes hold.
One of the frameworks for thinking about this process is the ADKAR model, which is popular today.
It consists of five steps:
Many employees already understand, even without the company telling them, that the technology is becoming part of their profession and that they need to learn how to work with it. But an employee’s personal interest in AI and the company’s approach to adopting it are not the same thing.
People still need to understand how the company expects AI to be used. Which use cases are allowed? What data should never be shared with external services? Where does AI-generated output always need to be reviewed by a person? And how does using these tools affect expectations around the speed and quality of work?
If this isn’t defined at the company level, everyone starts making up their own rules. And that creates risks — in terms of quality, security, and simply keeping the process under control.
For Attico, SDLC adoption is about explaining why we’re doing it, setting clear rules, showing how the workflow is changing, training the team, and then helping those new practices become part of the way people actually work.
ADKAR is not the only approach we could use, but it provides a useful framework that helps us look at the transformation as more than just a training exercise.
Where Attico’s AI adoption started
At the start, the situation was pretty straightforward: AI wasn’t officially used anywhere in the company. We had no approved tools, no clear rules, and no formal position on where or how these technologies could be used.
At the same time, our team knew that employees were already using AI in their day-to-day work - they were just doing it on their own. We ran an internal survey to understand who was using AI, how they were using it, and what they were using it for. We conducted such surveys several times, including one immediately before the start of the research and subsequent implementation.
The results showed that employees across different roles were already experimenting with AI — including backend and frontend developers, QA specialists, and project managers. But in most cases, their use was limited to chat-based tools: asking questions, getting help, or generating and refining small pieces of code or text.
There was no common approach, no standard set of tools, and no clear understanding of how AI should fit into the company’s workflows. Employees were using different models and providers, choosing whatever worked best for the task at hand.
Engaging employees in the AI transformation
One of the ways Attico involved employees was through internal AI meetups, which are held periodically. The first one was in November 2025, and the whole team was invited. Even though the meetup took place outside working hours, most employees joined. That alone showed us that there was already strong interest in AI across the company.
At the meetup, our team wanted to show a range of practical AI use cases. We covered the technology’s general capabilities, how it can be used with documents and email, and also ran a separate demo workshop focused on using AI in software development.
After the first meetup, we put together an AI adoption plan, ran some internal experiments, and have now moved on to piloting AI on real projects.
As the initiative has evolved, these meetups have become more practical. They give the team a chance to share real use cases, practical tips, and lessons learned from using AI on projects. For Attico, it’s not just a way to keep people engaged — it’s also part of a broader effort to build a culture of knowledge sharing around AI across the company.
For developers involved in the pilot and using corporate AI licenses, we also created a dedicated channel. It gives us one place to collect feedback and discuss issues as they come up. Training materials were prepared so that new pilot participants don’t have to figure out the basics on their own and can get up to speed more quickly.
We also spoke separately with managers and team leads about how we planned to introduce AI into the SDLC — which stages already had solutions in place, where we were still experimenting, and what areas we planned to explore next. For managers, it was important to understand more than just the technical side. So our team also discussed things that directly affect project management, including billing, reporting, and how changes to the development process could affect the way the team works.
As a result, for Attico, employee engagement isn’t about a single meeting or training course. We try to keep the AI transformation adoption visible and relevant over time — making sure people understand where we are now, what’s already working, what we’re still testing, and where we’re heading next.
From research to controlled rollout
One of the main takeaways from the research was pretty straightforward: developers were already using AI, but mostly through chat-based tools. They could ask questions, get help with code, or generate small pieces of it, but they were hardly using agentic tools that can understand the project context, read the codebase, and make changes across multiple files.
By that point, tools like these were starting to develop quickly, and that was an important signal for us. We realized there wasn’t much value in separately teaching the team traditional prompting or how to work with chat-based tools. It made more sense to focus on AI adoption in software development and learn how to use AI as part of the workflow from the start.
At the same time, there was nobody in the company who already had the kind of experience we could simply build on or scale. We were figuring it out ourselves. So it became clear that building that expertise in-house had to come first.
We didn’t want to try to train the whole company on something we were still figuring out ourselves. That would have been too risky. First, we needed to make sure the approach actually worked, build up our own experience, and understand what we should teach the rest of the team.
This meant that developers on projects weren’t starting from scratch. They already had basic guidelines, proven approaches, and experience that the research and development (R&D) team had built up along the way.
Right now, one of our main sources of learning is feedback from the teams. We collect real use cases, look for patterns in what people are doing, see what works consistently and what doesn’t, and turn that experience into shared guidelines, checklists, and practical guidance.
Our team also decided to roll out AI gradually. We started with senior and middle+ developers because they can not only use AI themselves but also help their colleagues. For us, this is a way to build up internal expertise faster, directly through real project work.
At the same time, we’re not limiting access to this group. If a junior developer is interested and wants to work with AI, they can join too. The priority at the first stage was given to those who could later share their experience with others.
Current focus of the AI transformation
Looking at the bigger picture, the goal is to use AI across different stages of the SDLC. But right now, we’re not trying to roll everything out at once. The main focus is on the developer’s day-to-day work, because it’s one of the most time-consuming parts of the process and one where the practical impact is easiest to see.
At the same time, we’re experimenting with automated test generation and gradually moving into testing. There are other AI initiatives happening across the company too, but those are separate areas.
Attico’s target for the current stage is pretty straightforward — we want AI to become a normal part of developers’ day-to-day work, not just another tool they open in a browser from time to time.
Once this approach is in place and we know it works consistently, we can scale it further — across other teams and other stages of the SDLC.
In the next part, we’ll walk through how our team set up the experiment, which projects and tasks they chose, what results the company got, and what was learned from them. We’ll also look at how this experience shaped our next steps in the AI transformation and changed the way we think about what systematic AI use in development should look like.
Previous: read about why AI amplifies existing processes and the principles behind our transformation in Part 1: Vision and principles.
Next: find out how we tested AI on real development tasks and what results we got in Part 3: From adoption to impact.
Related insights
Let's start with a complimentary consultation
Whether you have a small urgent task, or a large ambitious project, we can help