News

The Rise of AI-Assisted Development: What Changed Since 2022

Since 2022, AI-assisted development has evolved from a novel productivity tool to a core component of modern software engineering. AI coding assistants now support tasks ranging from code generation and debugging to testing, documentation, and workflow automation. This article explores how developer roles, team dynamics, productivity metrics, and software delivery practices have changed over the past few years. It also examines the benefits, challenges, and limitations of AI-powered development, providing a practical perspective on what the data reveals about the real impact of AI on software engineering and what it means for the future of development teams.

Transitioning from Novelty to the Nervous System!

Toward the end of 2022, GitHub Copilot launched, and ChatGPT went live to global hype. In general, the two engineering groups I was connected with were discussing whether this technology would take all of our jobs, or whether it was just a more advanced type of autocomplete tool. They were both wrong.

Three years later, I have participated in and observed an evolution that is quieter, more chaotic, and ultimately more interesting than a fast replacement of developers with AI assistance. AI assistance did not replace developers, nor did it remain a novelty. It has become an everyday piece of infrastructure. Infrastructure transformations, like this one, generally do not affect the major functional pieces of an infrastructure, but instead they change the way people work, how they interact within their teams, and what assumptions they have about their work.

This article does not provide a summary of any products that you have purchased. It provides insight into AI development services and how AI assistance has changed the way we work and how it will continue to change in the future, as well as how to apply the changes to your team.

The Technical Arc: From Autocomplete to Agent

Phase 1: Line-Level Completion (2022)

The first generation of AI development tools, like Tabnine and Kite, serve as examples of coding tools that produce code line-by-line or block by block within the context of a function signature. Once a function signature has been created by the user, the model attempts to produce a body for that function based on all training data up to that point. Thus far, while this model is useful, it has been limited in its transformative capabilities.

The key limitation of these tools is their inability to look past the last few hundred tokens that have been processed in the relationship between tokens. As a result, they can only perform local pattern matching and perform well at predicting the next token in a short sequence of code.

These tools generally did not integrate into a normal developer workflow very well, as they appeared in the editing environment only as ghost text suggestions for the user to either select or decline. While users could select or decline the ghost text suggestion, they could not ask the model for clarification, modify the model’s generated suggestion based on what it perceived as the developer’s intent, or provide the model with sample test cases to validate a given suggestion.

Phase 2: Conversational Assistance (2023)

The way we communicate with computers has been transformed in radical ways: Now that we have all these new tools like ChatGPT, GitHub Copilot Chat, and Cursor’s inline chat, we can start using the words and language we think of as habitually in order to express ideas based on intent rather than simply based on the established context surrounding them.

This change is largely unrecognized. Before, you structured your code so it could leverage the capabilities of smart autocomplete (like an appropriate naming convention allowed the model to suggest a usable piece of code when you requested it). Now, you can simply define what you want “this function to do” (like, “This function should handle null input and write a structured error to our observability layer.”) and your result will be much more aligned with what you intended.

In fact, there has been a tremendous shift in my method of creating new code over the past few months. I no longer write the skeleton of a new function followed by the actual function as often as I did; I create a comment explaining my intent, let the model create the code for me and then evaluate and adjust the output. The change in my process of creating new functions to evaluate and edit previously created drafts more frequently is subtle but very real.

Phase 3: Multi-File and Agentic Workflows (2024–2025)

The most significant change in technology over the past 18 months has been the introduction of contextual expansion along with agencies. The tools Cursor, Windsurf or Claude Code allow you to do the following:

– Read across your entire codebase prior to generating an output.

– Execute code, run tests, and observe results.

– Make multi-file changes atomically.

– Iterate on compiler error or test failure without having to re-prompt.

This is now significantly different from an auto-complete function; in this case, you have an agent who is capable of writing a migration, running it against a test database, observing the failure, fixing the SQL, and re-running it, which makes the agent much more like a junior engineer completing a task.

Technically speaking, the bottleneck in the development process has changed – the limitation has moved from speed of generation to quality of review. I can now produce an actual functional implementation of a moderately complex feature in a fraction of the time that was previously possible; however, my ability to critically evaluate the resulting code in terms of edge cases, architectural implications, and security implications has not scaled at the same rate, and this difference represents the number one technical challenge of our time.

The Cultural Arc: What Changed on the Team

The “10x” conversation got complicated.

Many developers claim that AI tools enable them to be far more productive then what they could otherwise do. Based on my own personal experience, for many of the tasks I’ve been asked to perform, how much additional productivity I can achieve depends on what type of task it is, and not all tasks provide the same level of increase in productivity due to the use of these tools.

When I have very well defined and bounded tasks, such as writing a REST endpoint to a known spec, adding test coverage to an existing class, or converting a component to a new framework, my productivity often exceeds what I could accomplish before because of the new tools. There are many times when I do something in an afternoon using the new tools that would have taken me two days previously.

Once I am working on more open-ended and design-heavy work tasks such as how to model a domain, determining architectural tradeoffs, and debugging a difficult race condition between different distributed state AIs, I see much less benefit in my productivity by using the new tools. The tools can provide me with the various options I can consider using; however, making a judgment about which option is appropriate for your system and constraints is still a very human task.

There is a cultural tension related to this because the groups that frequently measure their velocity based on the number of “features shipped” have seen an increase in velocity. However, these same groups that also looked more closely at their work have noticed that the amount of accrued complexity and technical debt has also increased as a result of their increased velocity. Increased velocity (due to reduced friction) does not translate into moving towards the desired outcome.

Junior Developer Dynamics Shifted

The cultural shift of how we refer to AI tools is probably the most contentious issue among engineering groups, and rightly so.

Historically, the junior developer’s growth path included substantial amounts of implementation work, which developed an understanding of development patterns. For example, a junior developer would build an application from the ground up, developing a set of patterns through experience, followed by debugging their development to develop an understanding of the various causes of failure in an application. The junior developer would also gain an understanding of existing codebases by reading through large chunks of code prior to making code changes. AI tools disrupt all three of these activities.

By having a junior developer on a team generate working implementations of an application without fully understanding the implementation, it is possible to generate a large volume of output at a much faster pace than ever before, but the junior developer will continue to gain speed only; the knowledge gap of understanding the development process will only become apparent during the incident response process or the architectural review process.

Based on my experience, the most effective use of AI tools on teams is to reframe AI tools as academic partners rather than as implementation shortcuts. Junior developers can use the following three steps to develop their understanding of implementation patterns through studying AI-generated code:

  1. Explain the code generated by AI on a line-by-line basis,
  2. Deliberately debug any errors generated by the AI, and
  3. Write an evaluation of the AI’s code prior to accepting any suggestions.

In doing so, the junior developer will have the opportunity to develop a greater number of patterns faster through intentional use of AI.

Code Review Changed More Than We Expected

As the amount of human-written and model-generated code increases, the way code is reviewed has changed significantly in a couple of ways.

The amount of code produced increases with the number of contributors to the project. Code reviews that previously had not been scalable would have created a quality bottleneck from which any velocity increase was lost.

The types of artifacts being reviewed have also changed. Typically, human-written code follows a consistent style and contains programming patterns consistent with the individual who wrote it. AI-assisted programming will usually produce code that is syntactically correct, but it does not follow the architectural conventions and business rules of the organization where the code will be deployed.

Many of the teams I have worked with recently have created a lightweight AI composition disclosure for code review purposes. The disclosure does not introduce additional gatekeepers, simply providing additional context on how the code was developed. An example of such a disclosure would be something like: “The core logic is developed by me, and the boilerplate and tests were developed by AI and reviewed by me.” Having this type of disclosure has created greater efficiency in the code review process without introducing additional steps to the code review process.

What Actually Changed in the Developer’s Mental Model

What I want to express in the clearest way possible is how much AI assistance has impacted my perception of what’s worth spending my time on.

Some of my time was consumed with recollections of syntax, writing boilerplate, and reproducing patterns I know how to do. However, the time I spent thinking about those things has virtually been eliminated due to AI updates.

What is left behind or revealed is typically the difficult nature of work; understanding requirements thoroughly enough to establish when they’re not right, making architectural choices from incomplete data, reasoning about system behaviour under failure instances, and establishing trade-offs with stakeholders.

The developers that I have observed thrive within the environment of AI assistance are already competent in those aspects and look at AI as a collaborator who has ability but requires correct intent, careful scrutiny, and expertise they don’t possess. The developers who do not succeed are those who anticipate that the system will provide them with judgement rather than simply produce a result.

Closing

The evolution of AI-assisted software development since 2022 has been all about developing a new capability and making it an indispensable piece of infrastructure, long before most organizations have upgraded their processes to use it.

The capabilities of these tools have improved dramatically since their introduction. However, the workflows used to leverage those capabilities are still coming into phase with the tools themselves. The core skills that create an effective software engineer, system thinking, domain modeling, critical reasoning, and effective communication, have not yet been automated. In fact, those skills will differentiate the developers who lead the industry in the next few years.

At this moment in time, it is not the developers who are using AI the most aggressively who will be responsible for leading the industry in the future; it will be developers who are using AI in a thoughtful, deliberate way. To facilitate your business with the help of artificial intelligence, you must contact a software development company, which can help you boost your productivity.

Share this