Category: News

Author
Krzysztof Dukszta-Kwiatkowski

Created
June 24th 2025

Introduction

At our last all-hands meeting, my team and I initiated a broader discussion on the relevance of AI for our business. The conversation highlighted multiple perspectives:

1. Offering professional services related to AI/LLMs,
2. Integrating AI/LLMs tools into our daily work,
3. Leveraging AI/LLMs in marketing, documentation, and communication materials.

This essay focuses on aspect (B), particularly on the use of GitHub Copilot and related tools
within Visual Studio Code (VSCode) from the perspective of a frontend developer.

Day-to-Day Use of Copilot in Frontend Work

As a frontend developer, I’ve integrated GitHub Copilot into my daily workflow in Visual Studio Code. It’s not a replacement for critical thinking or domain expertise, but it has become a reliable coding assistant, particularly effective for small, well-defined tasks. Over time, it has shifted from being a novelty to something I now use for routine work.

Where does the Copilot Help?

For narrow, syntactically demanding, or repetitive tasks, Copilot significantly improves both speed and decreases cognitive load. These are the core areas where it consistently adds value:

1. Syntax Recall: Copilot often helps me recall exact JavaScript or TypeScript syntax when switching between libraries, especially around useEffect patterns, event handling, or Promise chains. Instead of looking up syntax or common idioms, I can just start typing a comment or function name, and Copilot fills in a plausible structure.
2. Boilerplate Code: Whether it’s writing React components, styling with CSS Modules or Tailwind, or scaffolding forms and validation logic, Copilot provides solid boilerplate. Even if it doesn’t get it perfect, it gives a strong starting point that saves keystrokes and mental effort.
3. API Familiarisation: When working with unfamiliar Node.js or browser APIs, Copilot acts as a lightweight exploratory tool. Typing a few descriptive lines is often enough to see a valid example, which I can refine. This is especially helpful with APIs like fetch, FileReader, Clipboard, Web Workers, or IntersectionObserver.
4. Rapid Prototyping: For utility functions — like debounce/throttle, sorting logic, object transformations, or edge-case handling — Copilot frequently generates working drafts that are “good enough” to test quickly, then polish later.

How Does It Change the Development Flow?

When working on code, I would often context-switch to Google, Stack Overflow, libraries and tools documentation pages or internal docs – sometimes dozens of times per day. These interruptions, although short, added friction to the flow of coding. Copilot doesn’t eliminate this, but it reduces the number of micro-interruptions.

It acts like a probabilistic code index, constantly offering suggestions based on the local context of my project/s. It doesn’t “know” my code the way a human does, but it’s surprisingly adept at guessing the intent behind keystrokes, especially in familiar framework environments (like React or Next.js).

The experience is somewhat like moving from a card catalogue in a library to a smart assistant that not only fetches the right book but opens it to the page you’re probably looking for.

Net Gains

Since adopting Copilot, I’ve noticed a few clear improvements in my development process:

1. Less context switching: I stay focused on my editor longer.
2. Faster iteration loops: I can move from idea to prototype more quickly.
3. Lower cognitive fatigue: Especially during repetitive UI implementation or wiring up known patterns.
4. Better focus: By offloading low-level recall and routine typing.

Copilot is not magic, and it doesn’t write full apps or solutions for me. But for frontend work – particularly in the component-layer – it’s like having an intern who’s fast, tireless, and occasionally brilliant.

What It Doesn’t Replace

It’s important to note that Copilot isn’t a replacement for understanding technology stack, software architecture and craftsmanship, being up to date with daily used technologies and tools and reading documentation. It can hallucinate without letting the user know about it. It can suggest bad or suboptimal solutions. It can reinforce bad patterns. It doesn’t reason about facts, requirements, or events that haven’t been explicitly provided to it, which live in a human-to-human daily communication.

Drawbacks and Limitations

Despite the value, there are significant downsides that require attention and governance.

The Update Lag

A major challenge with AI code assistants and large language models (LLMs) is their reliance on static training data, which means they do not automatically stay up to date with the latest information. Every time new frameworks, libraries, APIs, or best practices emerge, these models require retraining – a costly and time-consuming process – to incorporate that knowledge. As a result, there’s often a lag between the publication of new developments and the model’s ability to assist effectively with them. This limitation makes it difficult to fully rely on AI assistants for cutting-edge technologies or the latest updates, especially in fast-moving fields like software development.

Skill Degradation

Over-reliance on AI suggestions can weaken foundational skills. Repetition is essential to mastery, and outsourcing that repetition may slow down real learning. It can lead to a situation where developers know how to use the tool but don’t understand the underlying logic of the code that they wrote. A key danger is false confidence. Devs may assume correctness because the output is syntactically clean, leading to bugs that go unnoticed until late-stage QA or even production.

Lack of Determinism

AI suggestions are probabilistic, not logically derived. LLMs generate code based on statistical likelihood, not factual correctness or logical verification. This leads to non-deterministic behaviour. Asking the same question twice may result in different answers. 

Quality Assurance Still Necessary

AI-generated code may look correct, but it can contain subtle logic flaws. For production work, especially in teams, every suggestion must still be reviewed. This sometimes makes it faster to write code manually than to verify an AI-generated version.

Compliance and IP Risk

Tools like Copilot send code to cloud servers for analysis. This creates legal and reputational risk, especially in industries with high compliance requirements (finance, healthcare, defence). Even anonymised code can leak architecture or business logic patterns. Uploading such artefacts may breach contracts or compliance rules.

Cost Considerations

Tools like Copilot are not free, especially at scale. Each seat comes with a subscription cost. Furthermore, cloud-based inference adds latency and external dependency, while local models require substantial compute power and maintenance.

Shallow Understanding of Context

Copilot can understand current file contents and some project-level context, but often fails when deeper architectural awareness is needed. Its suggestions are limited by the visible scope and rarely consider higher-level design constraints.

Review Overhead

Suggested code still needs to be read, understood, and often rewritten. The time saved in typing is often lost in verification, especially in teams that prioritise clean code and sustainable architecture.

Not Ready for Complex Reasoning

AI tools can’t reason abstractly or make architectural decisions. They follow patterns
– they don’t innovate or critically evaluate trade-offs. They’re not ready to be used in core system design or as decision-makers.

Local LLMs and VSCode Agent Mode

To address compliance and cost concerns, the local large language models (LLLMs) can be used. Such tools can run locally but require powerful laptops or internal servers. These models don’t require uploading code to external servers and can be integrated with VSCode using extensions or agent-based interfaces.

Additionally, VSCode Agent Mode enables a more interactive collaboration between the
developer and the AI model, allowing multi-turn conversations, persistent context, and
deeper codebase understanding. These solutions are still maturing but show promise for
future enterprise-grade deployments.

Reflections on the Technology’s Maturity

This is still the early stage of AI coding assistants. Like all young technologies, they bring disruption, excitement, and uncertainty. The full impact on developer workflows, team
dynamics, code quality, and long-term maintainability is not yet clear.

Key open questions remain:

1. Best practices are still evolving.
2. Long-term impacts on code quality, developer skill, and team collaboration are not fully understood.
3. Tooling is inconsistent, with frequent updates and shifting APIs/models.
4. How will junior developers build expertise if they rely on AI too soon?
5. How do we ensure that auto-generated code adheres to internal standards?
6. What kind of auditing or traceability should exist for AI-generated contributions?
7. Can AI tools evolve to support entire teams, not just individuals?
8. What guardrails should organisations establish?

The analogy can be made to calculators replacing abacuses. Just like calculators, LLMs will likely become standard tools, but only when used with understanding, discipline, and clear responsibility. We’re at a point similar to the early days of version control systems or containerization – powerful tools, but still lacking universal norms and safety rails.

Conclusion

GitHub Copilot and similar tools offer real, measurable productivity gains – particularly for frontend developers working in a complex ecosystem of frameworks, languages, tools and often also touching backend and devops layers. They reduce friction and help focus on solving higher-level problems. But these tools must be adopted thoughtfully. They are not a replacement for critical thinking, team collaboration, or professional responsibility. Especially in regulated or client-sensitive environments, guardrails around usage are essential. As AI technology evolves, we must treat it not as a magic solution, but as a new kind of power tool: useful, fast, and risky – depending on how it is handled.

 

June 3, 2025

Rafal Polanski: First of all, how are you today, Łukasz?

Łukasz Ciechanowski: Despite my day being quite busy, as we have a demo in the project I am currently working on, I feel quite well today. Thank you for asking.

RP: Great. I wanted to ask you about the projects and about how in the projects especially in DevOps area of the tools which are very popular now AI tools can help you and are they also able to simplify the work of a DevOps engineer in the in this kind of projects or no or are there may be a problem. What is your opinion?

ŁC:  In my opinion, AI tools/support shouldn’t be a problem except the situations where some kind of client’s policies disallow them to use.  Everything that may help you or may boost your work shouldn’t be treated as an issue. And if we are speaking about how AI tools are helping DevOps in regular professional life, I would say the given help is very similar to other technical areas, like development.

First of all, AI is a source of information needed to solve problems. Two or three years ago, if you had an issue to be addressed first, what you did as an engineer, you went to StackOverflow, raised the question, and tried to find similar problems from the people who had already solved them, as you don’t want to invent the wheel again. Right now, it has changed. AI is the source of the answer, so you are not going to StackOverflow anymore and just directly ask an AI assistant to serve you. Additionally, there is a market push to be involved in AI and consume its goods as much as possible, therefore, the tools providers try to introduce AI capabilities whenever they can. So basically, if you are using some DevOps tools, you are using AI capabilities just like that. Still, some of the AI features are available like experimental options, for instance, in case of GitLab CI/CD there are features which allow you to automatically generate the pipelines, and there are some like autocompletion features which are embedded and present just like that. Of course, they had existed before, but right now they are much smarter, and the suggested outcome is similar to the human being’s outcome.

RP: And if you look at challenges, and with that people report there, I have an impression that many DevOps engineers can be afraid of using AI, and not only DevOps engineers. IT specialists may be afraid of AI. Should they be afraid?

ŁC: Well, this is a difficult question…, but in my opinion, they shouldn’t. Anyway, it is something that they will not avoid. AI is everywhere now. AI can boost our work, so it can’t be ignored. If we want to be competitive in delivering solutions, we need to use it, otherwise, those that benefit from AI will be faster, will be better, and will deliver more sophisticated stuff. In my case, the main fear should be that if I will not be a forerunner, I will be behind. On the other hand, I can understand this fear … if you are hearing news every day with the message that some of the companies are firing people, giving as an explanation the AI expansion … your fear as a working person, having a family and obligations, may grow. On the other hand, let’s say honestly: as for now, AI is not replacing humans. Of course, a statement that AI is just a tool would also be hurtful, as this is a bigger topic / bigger initiative, but in the end, you are deciding what you will consume and what you will use, what you will adopt and what you will decline.

In the past, we also had some tech-trends which brought similar fear to the customers or tech-people like for instance, agile initiative or cloud expansion. When agile was introduced, I heard, so often from the clients, that with an agile approach, they would not get anything valuable, and the software house companies would just burn their money. Nowadays, most projects are realised in this way because the market/customers are educated enough to understand that the biggest problem and the biggest cost is if someone develops something for you that you don’t need. The other example is the cloud transitions. Before it massively happens, I have heard many times that this will backfire on us, and when this approach becomes established, everyone will run away from it. And I never noticed it, at least not on a bigger scale

RP: I also think that many of these fears are the result of the media or and kind of even maybe frenzy, and the approach that you advocate, meaning use the opportunity for you and the tools for you to help you be ahead of the curve, I think is very smart. So I appreciate your answer. Since the new initiatives you mentioned happened, the IT people were even busier, so this fear seems to be unjustified.

Coming back to the DevOps field. How do you see the current challenges that DevOps faces?

ŁC:   I believe that more or less the challenges are similar to the past, but the main differentiator is the scale and the complexity. I think that in simple terms, we can say that right now, everything basic already exists. I know that this is not fully true,  but in most cases clients want to implement more and more sophisticated things as an extension of what they already have, technically realized as a distributed services, scaling horizontally and all of that brings different scale of the problems and enforce some approaches, especially in DevOPS area like for instance CI/CD processes are right now mandatory, smart monitoring is mandatory, vulnerabilities detection on code analysis level and runtime level are mandatory because maintenance effort and stability should remain the same. Also, securing such systems is more difficult because of the software complexity, 3rd parties libraries’ massive presence, and more channels of support, like web or mobile, etc. So it means that the factor of problems has grown, and you need to have the right tools to solve them and thus an area where AI can help. Speed of producing all needed DevOps components in a faster way is important, and it has a direct influence on the delivery cost, which, as I mentioned earlier, must be incurred and must be considered already at the stage of deciding whether to start a given activity or not. So for instance if CI/CD processes and their foundation/skeleton could be intelligently generated, why not benefit from that? .. Or if using tools supporting AI in monitoring will bring important features like smart behavior analysis or smart predictive analysis, which we never had before on that level, why not to have them as security attacks are more and more intelligent? ( .. unfortunately, also thanks to AI). 

If you need to implement something specific for your situation, build a unique script, why not use AI to assist you in that or even generate some needed parts/components for you, which later on you will just tweak or integrate?

Speaking further about challenges, for DevOps, and I think for the others as well, working in “distributed human environments”, where you have several development streams which at some point are connected within the project or program, the knowledge sharing is also a big challenge. In many cases, you can’t be in every team demo or spend too much time to understand where the other team’s focus is having the demo summary generated by AI or documentation created with AI help may simplify your professional tech-live a lot

RP: Thanks a lot. So, you guessed me and you answered two questions in one row because I was also willing to ask you on this how the AI tools are specifically addressing those challenges, but you in fact answered that within. So, as there are probably more than one and that there are more coming, I mean the AI tools in the DevOps area. Would you be able to tell us what your favourite one is or the one that you most often use?

ŁC: Honestly speaking, I don’t have any favourite one and I don’t use just a single tool for solving all of the problems.  DevOps areas and responsibilities are very wide and depend on the type of problem you are using a wide set of tools. Nowadays, in many cases, DevOps is operating on the container level and, of course, to some level,  we (DevOps) don’t care if the system is written in Java, Python, or any other language. Creating a good container is also challenging, so if you are using a good AI agent/assistant, you will not forget about any good rules that should be followed, even if you are not very experienced in this. What I had mentioned is a development AI support example, but for DevOps, AI is even more helpful in runtime.  If you are using a cloud infrastructure, some of the AI capabilities are enforced by the service you selected. For instance, if you are using some kind of API gateways or load balancers from the cloud, most likely you will use AI capabilities offered with them, like traffic anomaly detection, etc.

Back to the question, which tools exactly we are using as DevOps, I will answer a little bit around :)… Since DevOps often supports developers, they’re usually also using tools dictated by the development team (e.g., GitLab, Azure), being in the majority and usually having established preferences :). This also enforces some specific AI capabilities that are a part of those tools. I also don’t want to promote any specific tool

RP: Okay, I understand that you don’t want to promote one, but I would like to maybe try a little bit more push, and I know that you work in a Microsoft environment, and you are one of the very few people who also work in an AWS environment. And  so if you would name the most popular tools that you meet used by both DevOps and programmers separately for Microsoft and separately for Azure, that you have to work with?

ŁC: In the case of DevOps, I can only repeat my previous opinion that we as DevOps don’t develop so much artifacts as developers mostly doing some “dirty work” scripts which AI web assistant is usually enough, container creation rules where AI agent could be helpful but it is not mandatory if you have experience or, pipeline where repository type enforce AI capabilities etc. Maybe I will change my mind when I have more experience with Copilot4devops, AI Assistant for Azure Devops, that we started to play with, but it is too early to share any opinions

If we talk about the runtime part and Azure or AWS, as I mentioned, all of the services offered by them slowly bring some AI flavour. Some obvious AI use cases are for security enhancements and traffic analysis / bad traffic blocking exists in APi gateway, firewall, etc. And all cloud providers are tracking their competitors so they really have similar capabilities, and it is hard to say which is better or more advanced.

In case of development perspective, I can only tell a few good words about Azure Cognitive Search, known as Azure AI, which was well received by the development team and introduced a lot of cool improvements in the project we are working on, which deals with processing, categorising, and cataloging documents of various types

RP: So the environment, both on the DevOps side, but specifically the fascination with AI, creates a lot of new names, a lot of new ideas, and a lot of new hopes for how AI will evolve and help in different areas in the next couple of years. What is your view on the next five, ten years in terms of the AI role? Is it going to grow? How is it going to change?

ŁC: It will grow further as any new initiative :). All software providers, like cloud providers and tool creators, will try to find new use cases where AI could be used.
All existing obvious AI use cases for developers, like some code analysis AI capabilities, code simplification or discovering vulnerabilities capabilities, will be improved as AI will bring new models, new engines, and bigger data sets. There will be more AI in enterprise software for regular users. I see myself that, for instance, LinkedIn is continuously introducing more and more sophisticated search engines offering better profile matching based on more sophisticated criteria, and I’m sure AI has a role here. It’s hard to predict our role in that game, but I still believe that AI will not fully replace us, and engineers still will be present in the management part, in the integration part, and in the verification part.

RP: Okay. And last but not least, I mean, you have invested quite some time in your skill development to become an expert, and you are our CTO. You are also helping younger colleagues develop themselves, and very often you share your knowledge with our customers. If you had a young person in the DevOps area and starting to use the AI tools, what expert advice would you give them? Where should they go to learn?  What should they avoid? In other words, what are to do and not to do for a beginner AI DevOps

ŁC: Yeah. As with everything, the process of learning new stuff is painful, and there is no magic recipe for how to pass it. In my case, the best was always learning by doing. That may sound naive,  but my advice is that for every problem that young DevOps encounter, try to solve it most efficiently, and this efficient way is with AI assistance. If they need to write a pipeline, they should generate it, if they need to write a Dockerfile, they should use a dedicated AI boosting tool, etc. In many cases, this approach can be opposite to how the older engineers will do that, as they have more experience, more working examples from the previous projects, so they will likely base it on them, and start with them, rather than ask AI for help. Usually, in the projects, younger people are supported by more experienced colleagues who do a code review, and such a mixed approach can bring unexpected results. Young people who will be naturally “integrated” with AI from the very beginning can bring freshness to the project approach and thus gain the recognition of people with an already established position and knowledge.. and I probably do not have to emphasize that all this can only have a positive impact on the quality of cooperation and thus the quality of service delivery

RP: Thank you very much. It is nice to listen to you sharing your knowledge.  Thank you for today. We will actually have other interviews like that to get deeper into interesting topics. So this is the first one. I hope we will get some interest from people. Thanks a lot for today.

ŁC: You are welcome. Thanks.

We wish you and your loved ones a peaceful Easter, surrounded by love, sunshine and the beauty of new beginnings. May this period renew your spirit and bring you closer to those you cherish. Happy Easter!