Before and After AI: How it Changed Our Way of Writing Software

In this article, we’ll share how the AI revolution has transformed software development at Irya Solutions. We’ll explore what our daily work was like before this boom, the tools and practices we adopted, and the direct impact we’ve seen on projects and client relationships. Alongside practical examples, we’ll discuss the skills that have become essential for developers in this new context and our perspective on what lies ahead.

The Before

Founded in mid-2018, Irya Solutions began its activities in a time before the pandemic, when the daily use of artificial intelligence for various purposes seemed like a distant reality. Our routine consisted of opening Gitlab, picking up an unfinished task from the previous day or starting the next highest-priority one, updating the branches, and beginning to code.

When starting a new task, we would set some time aside to design the solution, taking into account both functional criteria (whether the solution would produce the behavior expected by the client) and non-functional criteria (whether the solution met Irya's quality standards). It was common for us to search the documentation of the tools used in the project for features that, either alone or combined with others, would achieve our goals.

Our plan B was to search the Internet for open-source libraries that already implemented what we needed, since common problems like user authentication have well-known solutions. If both approaches failed, we would look for articles, written tutorials, or videos that taught how to solve a similar problem.

The last resort was to move forward with a completely custom solution. The reason for this approach was to deliver a task quicker and to follow community development standards. The former ensures that we are focused on solving the client’s specific problem and not wasting time reinventing the wheel. The latter serves one of Irya’s core values: transparency. By following well-known standards, we ensure that the client is free to continue a project with us because they trust our quality, and not because they are locked in by a solution that is difficult to understand. However, even when we found solutions that could be reused, they were rarely “ready to go”: it was necessary to modify the logic to meet the client’s specific requirements. Sometimes this could be solved with configuration, but other times the required changes were more complex.

Most cases fit into this type of targeted custom solution. When we encountered implementation difficulties, we would search the Internet. Often, we found answers, but almost always had to adapt them and ensure the code quality remained high—there are many solutions out there that are actually just quick fixes.

When we found a solution that would work for our case, and we were highly confident about how everything would function, we proceeded with Test-Driven Development (TDD). If we had any doubts or needed to experiment before settling on a final solution, it was common for tests to come later.

In the end, we spent most of our time researching, studying, and thinking about the best solution to the problem.

The After

As we like to stay up to date, we started testing GitHub Copilot as a programming assistant. In mid-2024, once we were more confident that confidential client code would not be used for AI model training, we subscribed to the enterprise plan.

Copilot suggests code snippets through the autocomplete feature in text editors. In this context, our workflow remained almost the same up to the configuration and implementation stage, when we actually started writing code. For us, Copilot was useful for:

1. replicating repetitive structures;
2. coding complex JSON structures that would be tiresome to create manually;
3. assisting with implementations in programming languages we are less experienced in; and
4. writing automated test snippets based on existing patterns in our own code.

Indeed, in those scenarios Copilot really sped code delivery up.

On the other hand, with Copilot:

1. when a solution was suggested, our instinct was to evaluate it, and in cases where we were creating something new that didn’t exist in the code, the suggestion was often incorrect. We would end up spending more time reviewing various proposed solutions instead of simply writing the implementation ourselves, and
2. code suggestions were also invasive: whether we wanted them or not, a solution would always pop up for autocomplete.

While searching for a tool that we could use only when needed and that would bring us more benefits, we found Claude. It’s a program you run at the root of your repository, through the command line. It analyzes files using bash commands and regular expressions, and produces a code diagnosis with details about the architecture, tools used, directory organization, and more. From there, you can use it as an interactive assistant

This approach changed some of our procedures. Now, the assistant is involved not only in the implementation phase, but also when designing the solutions. For us, Claude has been useful for:

1. creating quick proof-of-concept projects where code quality isn’t a concern;
2. writing complete automated test files, especially when they are written after the implementation;
3. serving as a modern rubber duck, meaning we interact with it to stimulate our own reasoning;
4. performing an initial quick review of merge requests, immediately pointing out aspects that can clearly be improved, such as vague commit messages;
5. making changes that involve more than one file in the codebase.

Using it for proof-of-concepts helps us present different solution options to the client, reducing the feedback cycle. Another benefit is faster code delivery while maintaining quality standards.

The main limitations we’ve noticed with Claude are:

1. it rarely suggests using libraries, preferring to write solutions from scratch;
2. if the commands given to Claude aren’t precise, there’s a high chance of introducing technical debt;
3. some suggestions are incomplete and require additional commands to finish the implementation;
4. recommended implementations can be broken or use deprecated code;
5. writing a command and waiting for Claude’s response takes time, unlike Copilot. Therefore it's inefficient for very simple tasks.

Conclusion

AI tools can undoubtedly be great allies in software development for speeding up solution delivery, testing ideas, and delegating the implementation of "brainless" code chunks. However, to achieve the best results, programmers still need a solid understanding of the technologies, the system, and the business rules. With this knowledge, we can leverage AI tools to produce reasonable solutions. Without it, it’s almost inevitable that the system won’t be sustainable in the long run. Furthermore, a technical outlook is still needed to evaluate suggested solutions, make adjustments, and occasionally start over, all of which require a strong grasp of abstractions, coding standards, and experience in identifying common mistakes. Therefore, we still spend most of our time as programmers researching, studying, and thinking about the best solution to the problem at hand.

What we envision for the use of AI at Irya in the near future is:

1. we'll dedicate more and more time to understand business rules, competitive advantages, and user experience;
2. we'll use an assistant for bureaucratic tasks and answering institutional questions;
3. when a specific visual project isn’t needed, we'll create prototypes with tools like v0.