For many of us, programming will never be the same again. Whether you believe the AI hype or not, change is already here. Feeling like we’re in the middle of this transformation — without being entirely sure where it’s heading — I want to share what I’ve learned so far.
I’m basing the reflections in this article on a large, multi-year ETL project written from scratch in Python. As a team, we started using Copilot in our IDE very early on, and then moved on to other tools in the same category, trying different options (Cursor, Claude…). I still remember that first rush of excitement: I was doing a refactor, and the AI correctly renamed variables, so I didn’t have to write a complicated regex. I don’t think anyone expected how fast we’d move from there.
This article is a snapshot — a pause to collect thoughts in the middle of an ongoing revolution. When I say “AI” here, I mean coding assistants. This is not a prediction, a prompt-writing guide, or an article about code quality. I’m aware that the capabilities and the practical scope of AI differ across industries, depending on criticality and system maturity. I’m not focusing on AI-generated code problems, and I’m not trying to judge the direction of the changes. Instead, I want to outline some less-discussed, non-technical aspects that are already affecting how developers work. I am the author of this text, AI was only used to translate it into English (and then checked by a human).
Below I describe how these tools are changing collaboration, costs, and how work is evaluated in teams. I want to ground this in experience from a large, structured, production system — one where iteration speed is still high thanks to LLMs, and quality is ensured through architecture, tests, and contracts.
AI instead of meetings
Let’s start with what shows up first: how AI changes day-to-day collaboration and a team’s rhythm. Despite the stereotype of introversion, developers have always been trained to work in teams, applying all methodologies, communication, and presentation skills. Hours-long meetings and discussions about architecture and the consequences of changes. Planning, retros, refinement… on repeat for years. Outside of work, we built communities that traded ideas and code across forums.
Until recently, that model relied on constant interaction: questions, consultations, and reaching solutions together. Recent signals (for example: declining Stack Overflow traffic, the Tailwind CSS case) and everyday experience suggest we increasingly bring our problems to AI. The answer comes instantly, it’s tailored to the context, and it doesn’t interrupt anyone else’s work. Many “how do I do this?” questions simply disappear. A real example: a few prompts recently sped up our data loading by 30% after we corrected overly literal modeling. Without AI, it would have cost us many hours of meetings, and then coding. In a sense, we need the team less to explain “how” in order to deliver daily results.
It’s worth remembering that AI doesn’t replace all team interactions. It shifts the center of gravity from “how” to “what” and “why.” Recently, the role of the contract between the business and the engineering team has become even more important. Blind trust in AI on business decisions — especially those based on guesses and poorly defined domain language — is a straight path to code that works but answers the wrong questions.
If it works, we use it more
And here’s the catch: we start using AI not only for edge cases, but for everything. Using AI fuels more AI use. On one side, there’s convenience — why write a simple script or use native commands when you can just ask AI? I think we’ll quickly see the erosion of basic skills among the developers (the first one I notice: a fading ability and need to use Linux commands). Once you use AI for “everything,” the question of boundaries follows fast: what are you allowed to send outside? Convenience overtakes common sense — roughly at the speed of pasting company data into an LLM.
But that convenience has a second side that only becomes apparent later. Code generated by AI can often be maintainable only with the help of AI. Not because it’s magical. Simply because it’s produced faster than we can truly understand it and internalize it. I remember projects where onboarding took months (sometimes ending with an “exam” before your first commit). Back then, to learn a new codebase after joining a team, you’d get small tasks or single bug fixes, and early expectations were quite low. It’s getting harder for me to imagine that onboarding into the code itself still has to take months (although onboarding into the business layer can absolutely remain long). The pace of AI-assisted work makes it possible for components to exist that you don’t actually need to know about. On one condition: every subsequent change is also made through AI. Otherwise, you become a newcomer in your own project that needs to learn the codebase from scratch.
Once AI becomes part of the process, it stops being “just a tool.” It becomes a budget line item — and a potential bottleneck. For many months we’ve been testing different AI solutions across the organization. For the last few billing cycles, we’ve been right at the edge of our paid plans. And we’re only warming up; adoption keeps accelerating. I don’t think we yet know the final cost of the tools we’re becoming so dependent on. The real questions are still ahead: how do we account for developers who exceed token usage? Do we stop delivering when the quota runs out a week before the deadline? So far, cost estimates have been based mostly on delivery time; soon we may have to add a “tax” paid to AI vendors as well.
The cost in your head
The cost doesn’t end with the invoice. Another load that falls directly on developers is maintaining their focus. AI tools can “think” logically for longer and longer, leaving the operator idle. Then they flood you with information, and digesting it requires climbing back out of the weeds. Over and over again — often dozens of times a day. Reviewing AI-generated code can be both exhausting and boring at the same time, and that may soon become developers’ main job.
As a result, the developer’s role shifts: less time spent writing, more time supervising. I’ve seen many cases where the best engineers, after being promoted to lead roles, stopped coding and spent their days writing Jira task specs or getting stuck in endless meetings. You could say they “programmed through documentation” — through other developers’ hands. Today, with AI available, everyone becomes that kind of lead. Prompts, skills, .mdc files — the whole context fed into AI tools becomes a core part of writing good code. I’m also noticing that stable project growth requires a return to solid documentation.
That role shift has consequences for the whole team: knowledge flow, authority, and how standards are set. For years, we fought to break down knowledge silos. Now I see a growing role for leads, architects, and managers in shaping the project’s direction. We used to have countless meetings about coding style, the Definition of Done, and tools for validating assumptions. There were authorities in the team, but reality was far from perfect. Standardizing new code has never been easier. It’s tempting to believe that a single LLM context file describing the project’s assumptions will solve every problem — without the discussions where especially younger team members build their skillset, ask questions, and bring fresh ideas. And more and more often, a line we hear in daily conversations is: “I’ll ask AI and come back with an answer / make a decision.”
You can see it best in the pace of change: big refactors have stopped being events and become routine. 20 percent of the 20 largest commits in our project repo were created in the last 20 days. Before, we allowed ourselves big changes only after careful analysis, knowing the cost of introducing them would be huge. Now, with AI, we aren’t afraid to do planned refactoring — and we do it incredibly fast. We’re not pretending the pace of shipping code allows for a line-by-line review.
Back then people talked about a maximum of 500 lines of code per pull request, and even that could be a heavy load for reviewers. Recently I made controlled changes that rebuilt the domain model and touched 10k lines of code. Earlier I kept postponing those changes because of cost and risk. With AI support, I did it in a controlled way in two days instead of two weeks, with no incidents after deployment. I think we’ll see more actions like that, because they often carry enormous business value. The way we communicate as developers changes along with it. We focus on reviewing documentation, the prepared plan, alignment with requirements, and the test plan. We expect the developer to properly supervise how AI executes those. Even more than before, we have to invest in CI and observability. And it’s easy to see that if review doesn’t scale with the pace of change, quality control has to shift from reading code to tests, contracts, and automated “brakes.”
If the pace and the delivery model change, a question becomes unavoidable: how do you measure good work in these conditions at all? Measuring developer effectiveness was never simple; no KPI was ever perfectly aligned with results. Now, on top of that, we don’t really have tools to assess the efficiency of AI-assisted coding. How many tokens should a single feature consume? How many experiments with a system that is, after all, stochastic, should a developer be allowed before they reach the desired outcome? We won’t get clear answers to these questions anytime soon.
This problem doesn’t stop with teams that already work together. It starts much earlier — at the hiring stage. Hiring has been turned upside down too. CVs written or polished by AI are then evaluated by AI. Some companies are even deploying AI interview screening systems. Usually we ban AI during interviews. After all, everyone would answer those cookie-cutter questions perfectly. And yet in day-to-day work, using AI is allowed — or even expected. Expectations raised over the last few years, combined with meticulous interview processes, have become even more detached from the work that is actually done. A whole discussion lies ahead about how to hire in the age of AI, when the expected skillset is critical thinking and experience.
And then there’s something else we talk about less openly: what this does to motivation and job satisfaction. Keeping your passion for programming will be a challenge. Just a year ago, I regularly and enthusiastically solved problems that were so deep they required hours of manual debugging. Today, with good prompting, corner cases tend to surface on their own. AI can pull the invalid state out of noisy data much faster, saving the time of preparing a minimal dataset that reproduces the bug. For me, that shift comes easily, because I’ve been working on higher-level project planning for a long time, and the boost in that space is also tremendous. But for someone immersed only in coding, the arrival of AI can genuinely be a challenge to stay in their current role.
The race and outages
At the organizational level, the same mechanisms look even sharper, because budgets and team decisions enter the picture. Starting and maintaining an IT project has always been expensive. Some companies believe AI will replace specialists. “Coding CEOs” shine on LinkedIn. I agree that building an MVP will be significantly easier. But in the case of real products, it will be very hard — at least for now — to replace entire teams. Someone still has to operate the AI, respond to outages, and redefine requirements. Those who can afford to keep teams can already build an advantage over competitors who chose to save money and cut the crew.
On top of that comes market pressure: solutions change week by week, and we’re all trying to keep up. No AI solution is complete yet. Practically, every week we can download another tool update. They copy features from one another and race for our (company) money. Progress is visible everywhere. It’s hard not to feel like we’re all participating in massive, paid beta tests. We teach tools our behavior, and they return better and better results.
And if we’re talking about dependency, it’s worth asking the simplest question: what happens when the tool just stops working? How many companies grind to a halt when developers see “We’re experiencing high demand” or “Unable to reach the model provider”? We’re introducing another degree of freedom that can determine the success of a project. Thankfully, we can still file global unavailability under science fiction — for now. Either way, the discussion about limits, prioritization, and fallback plans when AI is unavailable remains open.
Challenges ahead
The software profession has been changing rapidly for a long time. AI isn’t just another framework or IDE — it’s a new layer of abstraction to learn. Once again in my career, I’m watching the center of gravity shift toward planning, documentation, tests, and defining the right criteria for project evolution. Mitigating the risks of incorrect AI usage will become the domain of specialists, and responsibility for generated code will still end up assigned to a concrete team.
Teams now face a new challenge: resetting the rules of the game — how to get as much as possible from AI without losing identity and without losing control of the project. Watching our projects evolve, I believe that after the experimentation phase, using AI will become part of a structured process. I also expect that companies that can already afford intensive AI use while building software will lead this transformation — though plenty of mistakes still need to be made along the way.
