Foresight mode on : The impact of Gen AI on engineering

Short Version: Get ready to move, the party is about to start

Long Version:

I write these lines after managing a Cursor AI pilot, an IDE with an AI agent, which brought together 35 people for 2 months. In parallel, I’m involved in the Generative AI committee of our organization, which allows me to have an overview of the ongoing topics related to GenAI. Finally, I’ve followed an initiative to rewrite an old poorly mastered feature, by putting a dedicated team of 7 software engineers in a room for 2 weeks. I see trends and I start to connect the dots towards the future.

For software engineers, what will change?

To begin with, I do not believe in a decrease in the number of software engineer s, replaced by AI. It is an accelerator for technical profiles that saves time on repetitive tasks like tests, which produces a good first code base that needs to be polished, but whose quality level is not sufficient to go into production on complex applications at the risk of generating technical debt and overcomplexity. Reducing the number of software engineer s would also reduce the capacity to innovate.

The corollary is that software engineer s must understand their professional gestures well to be able to detect when AI goes down the wrong track. It is necessary to be able to put it back on the right track. With AI, it goes faster and issues can cost more. As we go along, I am convinced that we will understand in which use cases it is interesting and in which case that’s a waste of time. It will also be necessary to tame the beast and know how to use it well.

If I talk about profiles “at risk”, I would say that they are those who today are very much in execution mode. I could talk about QAs who only execute tests written from functional specifications. I could also add software engineers who “code for the sake of coding” without understanding user needs and business logic.

A small digression in passing: we have found that the quality of the code produced by a duo software engineer-AI agent is directly related to the skills… of the software engineer. It’s like a software engineer approving code from a pull request from another software engineer. In this case, the other software engineer is an AI Agent. The quality of the code produced will be determined by the skills level of the software engineer who reads the AI’s code. Will he let “If 1 = 1” pass, or will he leave the code clean ? We return to the usual question of what is a code of good quality.

At this point, I take a step back by stating that a software engineer is not just someone who writes code. It is someone who puts the right solution in front of the right problem. This is where I see a new change. With AI, the software engineer delegates part of the writing to an AI agent. There is a rise of abstraction for the software engineer. For old people like me, it reminds me the transition from C++ to Java. We stopped managing memory very finely. With AI, the software engineer rises another notch. This means that he becomes more functional. And this gives even more importance to the good understanding of the problem to be solved. The consequence is that the work around the right problem takes on more importance What I mean by that is that it is not about developing the solution requested by a user, nor solving a problem formulated by pure intuition, but to make the effort to validate that the identified problem corresponds to a real incapacity, experienced by the user.

The consequence is that the software engineer will be more autonomous to find solutions and probably more anchored to a given industry. A software engineer in e-commerce will not be a software engineer in the banking industry.

What will this change for the team?

Today, the main model for a team is the value stream aligned team of Team Topologies, namely a team capable of taking a business problem and responding to it alone and putting a solution in front of it alone. It takes a minimum of people to have all the necessary skills in the team for that.

With AI on the software engineer side, the game is changing, because AI helps us a lot on our areas of weakness. I have in mind backend software engineers who have developed an interface in React with little knowledge of this Front End technology. They were able to do it independently and ask for validation at the end from a React specialist. Previously, they would have had to work with a specialist from the start.

I will continue to draw the line by explaining my assumptions:

• The software engineer has risen a notch in abstraction level and is closer to business problems.
• There is a need for fewer people involved to be able to put a solution in front of a problem.

My conclusion is that team size will decrease. However, there is a need to limit cognitive load by not switching people overnight to subjects they do not know. I am talking about both business knowledge and technical knowledge. I expect to see slightly larger teams, with a well-defined functional scope. The main driver comes from the need to have a coherent business scope and to limit dependencies between teams. I want to have as few teams as possible involved in one initiative. I had said smaller teams and now I say the opposite. Because the devil is in the details. I expect this large team to organize itself daily into sub-teams with people who take a subject in its entirety. There is only to rotate between software engineers according to the needs that come in.

I will now explain some potential changes:

• Prioritization: at the global level only. Sub-teams are autonomous in execution.
• Backlog: necessary only for user behavior changes and not product behavior changes. End of overly detailed backlogs — often documentation for oneself. It’s the death of Jira, the rise of Devbooks.
• Documentation: automatically generated from the code by AI, for audit and traceability. The code becomes the reference documentation.
• Synchronization: no more systematic daily meetings in sub-teams. Global coordination times to be defined. Risk management will take new shapes.
• Continuous improvement: fewer periodic retrospectives. Rather formats on the fly: stop-the-line, lean standards, targeted feedback.
• Attribution of subjects: ephemeral sub-teams, regularly recomposed. No permanent overhaul, but a Shape Up type logic with 6-week cycles and an “internal transfer window”.
• Dev-Product-Design trio: to be nuanced. Not all subjects justify strong involvement of the three profiles. Better to reason in necessary skills on a case-by-case basis.
• Architecture & Design: critical subject. Everyone remains co-responsible. Today, AI does not have a sufficient overview to manage trade-offs between short-term performance and long-term scalability.

I would end with an important point, if AI pushes us to rethink the way we work, it is not about using AI to help us do faster and better tasks that we do today. Which would mean mapping AI to our existing practices. We must start from the beginning, from why we do things and rethink how we should do them in light of AI’s contribution. To give an example, is it useful to have an AI that helps us make beautiful user stories if in the end we no longer need user stories?

Foresight mode on : The impact of Gen AI on engineering was originally published in Peaksys on Medium, where people are continuing the conversation by highlighting and responding to this story.

Short Version: The Cursor pilot highlighted a heterogeneity of development practices. With the arrival of IDEs integrating AI agents, new uses are emerging. It’s time to take a step back and rethink what it will mean to be a software engineer tomorrow.

Long Version

As a reminder of previous episodes, we launched a pilot to test Cursor AI, an IDE with an AI agent, with a representative group of our Tech ecosystem. The last point is important because we did not seek only pioneers in the pilot, but rather a broad panel. This choice of a diversified panel — and not limited to early adopters — was deliberate: it had to reflect the real variety of our practices.

A month after the start of the pilot, I looked at the statistics available for Cursor AI administrators and one indicator particularly caught my attention: the number of tabs (use of autocompletion) and requests (requests made to the AI agent). I shared the dashboard with the principal engineers and immediately received the following remark: “It’s funny, you can immediately see who codes and who doesn’t.”

At first, I thought he was talking about me… but no. By cross-referencing the quantified data with the usage feedback collected in interviews, we saw four typical profiles or personas emerge:

• The Analyst: I start with my personal case since I tested the tool by putting myself in the shoes of a product people. I used the tool to explain the current product’s behavior. So I made requests asking the tool to analyze a code base. I also used it to help me in other activities with access to code like setting up SSH keys. However, I never wrote a line of code and therefore never used code autocompletion alias the tab. Architect-type profiles fall into this category.
  A large number of requests with tabs at zero.
• The “vibe coder”: He pilots the AI agent, but does not develop himself. This profile remained scarce in our pilot. We identified it in greenfield development cases, on a technology little mastered. Like the previous persona, the request rate is high with a number of tabs close to zero. It is through the interview that I managed to sediment the analyst from the vibe coder. In practice, I hardly saw this type of profile. I encountered it in the case of green field development on a technology little mastered at the base. Outside the pilot, we have the intuition that profiles coming out of school today could fall into this category.
  A large number of requests with tabs close to zero.
• The “Lucky Luke of code”: These are software engineer s who already used tools like Copilot and find that Copilot with AI agent is more powerful and faster. This allows them to choose their LLM and have better quality autocompletion proposals. The number of tabs is impressive. At the same time, the number of requests remains low. The tool is hardly used to generate code. Requests are mostly used for searches that could be done outside the IDE. These profiles are strongly represented on Legacy code. Note that the number of requests has increased over time, which suggests that they are increasingly using the tool to its full potential.
  A large number of tabs with requests close to zero.
• The “native AI agent”: My formulation is necessarily a bit provocative. It designates profiles that use all the features made available by Cursor IA. They code and this is seen by a significant number of tabs. They also use the AI agent by letting it write code. They are both pilot and copilot, with changes in positioning related to their current activity.
  Tabs and requests. With data, the number of tabs divided by the number of requests is between 0.1 and 1.

And now, what can we conclude from all this?

We can say that the uses are more varied than we anticipated. We had rather bet on a strong proportion of “native AI agent”, whereas they only represent a third of the panel. Is it surprising for all that? Not so much, because we put a new tool in the hands of a panel without immediately training good practices (which we were unable to do because we were still discovering the power of the tool).

To be more precise, what we have learned is that the diversity of development contexts leads to a diversity of uses — and that is normal. This should not hinder adoption, but rather guide our support.

We will therefore start on change management around 3 axes: the pilot also taught us or confirmed that the contexts are not the same, it was not surprising that the usages are not the same. However, we see that IDEs with AI agents are changing the daily lives of software engineer s. We will start on change management in three axes:

• Acculturate and train with training modules like videos or open hacks
• Support new uses in the field, via companionship, pair or mob programming. in the field new uses with a companionship mode. This can be put into music with pair and mob programming.
• Take the time to rethink expectations around software engineer job. There is no point in running in all directions at the risk of ending up in contradictory injunctions. As an example of implementation, we will organize a prospective workshop with the principal Engineers, then we will cross with the VP Engineers and CTO.

To be continued

In the next article, I will present the different questions that the appearance of AI agents raises both at the level of the software engineer profession and the organization. This series is finally longer than expected. 😊

There are as many uses of Cursor as there are software engineers was originally published in Peaksys on Medium, where people are continuing the conversation by highlighting and responding to this story.

Short Version: The pilot allowed us to answer the question of whether or not to scale AI-boosted IDEs. We decided that we had enough information to move to the scaling phase.

Long Version

When we launched our pilot with Cursor AI, we had a strong intuition: that IDEs with AI agents could represent a significant source of productivity gains. This intuition was based on a POC conducted with a small group. Before generalizing the use of this type of tool across the company, we wanted to move from intuition to certainty.

Before generalizing the use of this tool across the company, we launched a pilot that was supposed to allow us to be sure that we should do it. And this notion of certainty is important: it implies that a hypothesis is validated by tangible data from the field. Between intuition and certainty, there is an intermediate step: conviction, carried by a set of converging clues, but without formal statistical validation.

To summarize:

• Intuition: A form of knowledge without using conscious reasoning or logical analysis. It is often based on the experience of the person proposing it.
• Conviction: A set of concordant elements that support a hypothesis, without measurable proof. You might also call it an opinion.
• Certainty: A hypothesis validated by data, with a representative sample and a controlled margin of error.

If I go back to our pilot, here’s where we were:

• Intuition: We had already passed this stage with our POC.
• Conviction: As planned from the start of the pilot, we had interviewed the 35 participants after one month, asking them open questions to know what Cursor AI had changed for them. Their feedback was also completed 2 weeks later by a survey to collect the software engineer s’ NPS. Results: 13 promoters, 2 passives, and no detractors. On the qualitative indicator side, the expressed satisfaction was strong.
• Certainty: From the start, we knew that our sample was limited. With 35 people, we are in the lower range to have reliable statistical truth. Moreover, some limitations listed in previous articles — such as the absence of debugging on .NET — have hindered the 100% adoption of Cursor AI by software engineer s. A month after the start of the pilot, we looked at the statistics and concluded that we would probably never have certainty, even by waiting six months as initially planned.

At the same time, Github Copilot has just released its solution with an AI agent. As we already have the licenses for this tool, we just had to change a setting so that software engineer s who used GitHub Copilot today can benefit from the AI Agent option.

The question we asked ourselves at that moment is whether we should open the use of IDEs with AI agents more widely. The answer seemed quite obvious to us: we had the conviction that we had to go for it and that extending the pilot would not bring us any additional certainty.

The next step is to industrialize access to these tools for all software engineer s and to exit pilot mode. We assume that each software engineer should be able to choose their IDE with an AI agent, from a closed list of authorized tools, for security reasons and simplified license management.

Two topics remain to be explored. We now have to manage change management on the software engineer s’ side, and the potential impact on the organization.

It’s time to stop (asap) our Cursor AI pilot to scale (asap) was originally published in Peaksys on Medium, where people are continuing the conversation by highlighting and responding to this story.

Short Version: AI-enhanced IDEs can lead to rethinking the Dev-Product relationship with joint work, especially to test a new feature or explore a hypothesis.

Long Version

During my tests with Cursor, the AI-boosted IDE, I’ve tried to check its ability to restore stock control management rules. As I knew the functional side well, I was able to compare its answers to the actual behavior of the code. Verdict: the rules described by Cursor were consistent with what was coded. At that moment, I told myself that if “In codum veritum” remains relevant to understand the functioning of an application, it no longer necessarily means that you have to be a software engineer to access it.

I continued my test by asking Cursor to modify the availabity check. For this, I used a different formalism than the famous “As a, I want to… because…”. I asked Cursor to describe the initial behavior of the application. I specified that this would be its starting point. Then, I specified the future behavior of the application. In my example, I modified the stock control so that it is not done based on the warehouse closest to you, but across all of France. In the end, Cursor proposed the lines to update and I just had to validate its action.

I must admit that at this stage, I was still a bit scared because I was not sure about the proposed modifications. But I had everything I needed to generate beautiful user stories. And very quickly, I mainly told myself that with a software engineer by my side, he could have validated the proposals live and launched the action. For documentation, we could also ask Cursor to trace the changes in a given form to guarantee traceability needs.

Having worked in Digital Factories, I clearly see the use case here: a new business case with uncertainty, where the goal is to quickly go to production to test user appetite. In this context, product-software engineer pairs, accompanied by an AI IDE, can be very effective, allowing quick modifications, and so quick feedback loops.

Will this lead to changing team configuration? No certainty today. I have the intuition that the size of the teams will decrease, with the consequence of an increase in the number of teams, as the overall workforce will remain stable.

AI-boosted IDEs: From pair programming to Dev-Product pair work was originally published in Peaksys on Medium, where people are continuing the conversation by highlighting and responding to this story.

Short Version: Let’s not rush on AI-boosted IDEs, there is a need for some perspective on long-term code quality

Long Version:

In his talk at the last FlowCon, entitled “AI and software engineer obsolescence: is this the beginning of the end?” Seb Rose drew a parallel between the arrival of AI and that of No Code in the software development world.

In both cases, some announced, with great fanfare, the end of software development as we know it. The software engineer profession seemed doomed to disappear. In practice, we have seen that No-Code has not made software development disappear. This approach has proven very effective for relatively simple applications, but much less so for more complex systems — like a high-volume e-commerce site, like ours. The question of managing complexity in large software has therefore not been resolved by these new tools.

Regarding the development of large applications, Seb Rose goes further and demonstrates a correlation between the increase in the number of lines of code, and the decrease in the number of refactorings. An observation that raises an essential question: what about code quality in the long term? From our first tests, Cursor has proven very effective on greenfield cases, with a very strong production of lines of code and judged as good quality by our experts.

But — and this is where I come to our “Rose moment” — we wondered if we should add success criteria to our pilot to know if we were not producing faster poor quality code.

This is why we decided to add new success criteria to our pilot: in addition to productivity indicators, we now also track classic code quality indicators, such as cyclomatic complexity (via Sonar).

To return to Seb Rose’s talk, he showed the relationship between the number of lines of code going up and the number of refactorings going down with what appears to be a correlation. The question this raises is about code quality in the long term. From our first tests, we have been able to observe that Cursor is very effective for green field type applications with a very strong production of lines of code and judged as good quality by experts.

However, and this is where I come to our Rose moment, we wondered if we shouldn’t add a success criteria to our pilot to know if we weren’t producing faster code of poor quality. And that’s what we did, namely to track in parallel with the productivity indicator, classic code quality indicators like cyclomatic complexity. I should note that our source will be Sonar.

As our panel was representative of all our software engineer s, it was not initially concentrated on a single technical asset. However, quality indicators are linked to a given asset. We therefore resolved this bias by integrating all software engineer s of the same asset into the pilot.

As I write these lines, it is still too early to draw conclusions on the quality of code produced in the long term with Cursor. But I am convinced that we will have an informed opinion in a few months.

Stay tuned.

Our Rose Moment was originally published in Peaksys on Medium, where people are continuing the conversation by highlighting and responding to this story.

Short Version: Products evolve too fast to debate for long about the “best IDE”, but we know we will need an IDE.

Long Version:

Since the appearance of IDEs, debates on the choice of the “best” development environment are frequent: IntelliJ or VSCode is a good example with each having its supporters. For AI assistants, a similar debate is emerging.

At Peaksys, we chose Cursor because, at the time of our POC, it seemed the most promising to us. We could just as well have explored other solutions like Windsurf. A few months later, GitHub offered a very similar alternative. This is why comparisons of AI-enhanced IDEs quickly become obsolete — sometimes in less than a month.

To go further, it is now possible to choose your LLM directly in Cursor, from a first list of available models. Today, we mostly use Claude, the default model. But as I write these lines, Gemini has just been released in a version announced as very competitive. Here too, the benchmarks evolve (too) quickly.

I draw several lessons from this. I have exchanged with software engineer s very attached to their IDE, sometimes heavily customized. Changing their environment is not easy. Today, I don’t think that’s a good idea to cherish only one. I’m not saying we need to change IDE every day, but we need to be ready to learn to use a new one. Especially since an IDE that’s too customized can quickly become a barrier to pair programming.

I also tend to think that tools evolve too quickly to fit into centralized validation processes with, at the end, a single recommended tool for everyone. An example: to date, Cursor does not yet allow debugging on .Net code. This is a technical limitation specific to a language on a given tool.

As I write these lines, I have the intuition that the transition to an AI-boosted IDE is inevitable in the short or medium term for software engineer s, as it allows a real time gain. However, it is unlikely that a single tool will remain relevant over time. The one that is most suitable today may no longer be tomorrow. This is why we have transformed our Cursor pilot into an AI-boosted IDE pilot. The question is no longer to validate a generalization of Cursor, but a generalization of AI-boosted IDEs. For this, we still have to move from intuition to conviction and if possible certainty.

We don’t really care about a product, we care about the tool was originally published in Peaksys on Medium, where people are continuing the conversation by highlighting and responding to this story.

Short Version: We need to explore a few options to improve design and architecture with Cursor.

Long Version:

In the world of Domain Driven Design, there are business domains that describe the how experts understand a given business. For each business domain, I’m talking about a name, a description, data for which they are responsible, and how to call the domain. This often emerges from a workshop called event storming. We are then in the world of the problem talking only about “business”.

Then, there are bounded contexts which are how we have design the code related to business domains. They give the limits of responsibilities in technical assets. A while ago, I couldn’t see in which use case, business domains and bounded contexts could be disjoint. Thanks to Cursor, I now see the difference clearly. I asked Cursor to give me the bounded contexts related to a part of the information system. I then compared it with our functional mapping and came to the following conclusion: “In theory, practice and theory are identical. In practice, they are not”. I didn’t have that many differences, but enough to be interesting. This allowed me to visualize the responsibility gaps between theory (business domains) and practice (code). Cursor helped me visualize functional debt.

To give an example, there’s the language used by business people and there’s the language in the code. I was able to observe a vocabulary misalignment with possible misunderstandings. What goes into production is what the software engineer understood. Cursor helped me see these “cognitive dissonances”, which increases the cognitive load of teams.

To go further, a pilot participant “tested” a code base analysis to evaluate the implementation of Domain Driven Design patterns and Supple Design principles”. The idea is to quickly obtain recommendations for improving existing code. The prompt looks like this “using the evaluation described in @ddd-evaluation.md analyze the code in the folder @src”.

What do I conclude today? That we need to dig deeper because the recommendations make sense and the comprehension gaps are real. I see limitations like having to clone a lot of code repos to have something interesting, but it’s worth looking into. This could help us make the code cleaner.

DDD & Cursor: The impact on design was originally published in Peaksys on Medium, where people are continuing the conversation by highlighting and responding to this story.

Short Version: Cursor brings many positive points. However, there are too many drawbacks to fully trust it. It’s a tool for software engineers.

Long Version:

If some say there is no longer a need for software engineer s today, we do not share this opinion. A month after the start of our pilot with 35 people embarked on 2 times 3 months, we have observed some unexpected behaviors of the tool.

Once upon a time, there was a software engineer who wanted to add a new business rule in code used by end users. While writing the code, Cursor proposed to refactor the code. I won’t give a course on refactoring, but it roughly corresponds to making code cleaner through successive layers of modifications. Our software engineer looked at the refactoring proposed by Cursor. The problem is that while the code was well optimized, Cursor changed a business rule in passing. You’ll understand that this is a bit problematic. Our advice of the day is to commit often enough to notice such changes, in order to frequently run unit tests and catch these regressions.

In the same style, following the addition of a new business rule, a test no longer passed. The software engineer pointed out to Cursor that the test was broken and that it was a problem. Following this remark, Cursor modified the business rule to make the test pass instead of modifying the test. That’s a bit problematic.

In the same style, but regarding code reading, Cursor has, at times, provided incorrect explanations on business rules. This is the story of a software engineer trying to understand code, asking Cursor to explain, being a bit doubtful about the explanation, asking to see the code… and Cursor tosay, it was wrong and that the real business rule is different.

I could add other problematic behaviors like adding unrequested features to a Chrome extension, changing framework mid-development, or forgetting to add logs… In summary, we must remember that it’s a generative AI and by definition non-deterministic. It therefore sometimes goes off-track without us understanding in which precise cases.

“Our conclusion at this stage is not that we should discard Cursor, but that it is essential to know its limits. It is an assistance tool intended for software engineer s, to improve their efficiency. Its use still requires careful supervision.”

Even a chief can code… or not was originally published in Peaksys on Medium, where people are continuing the conversation by highlighting and responding to this story.

Short Version: Cursor saves time, especially on topics where we are less skilled.

Long Version:

For reminder, we launched our Cursor pilot with 35 software engineer s a month ago. This already allows us to have initial concrete feedback, and notably use cases where the tool proves to be very effective.

A striking example concerns a software engineer who had to create a Chrome extension to track the consumption of tokens of a new generative AI-based search algorithm. This was a “greenfield” development case (no pre-existing code) on a technology he did not know.

This extension was not intended to be used in production, but for internal experimentation purposes. Thanks to Cursor, the development was completed in half a day, where it would probably have taken several weeks without assistance. The time saving is very significant in this type of case.

In the same logic, some software engineer s were able to create small products in technologies they did not originally master. Cursor accompanied them by guiding them step by step, allowing them to progress effectively, even on unknown ground.

One might naturally wonder if the quality of the generated code remains up to par. To verify this, we asked other software engineer s, experienced in the concerned technologies, to evaluate the code produced with Cursor in addition to our automatic analyses via Sonar. Their feedback after the code review: a quality deemed satisfactory.

That said, Cursor can show limitations with projects involving a heavy or poorly structured technical legacy (“brownfield” code), or even voluminous. We will return to this limitation in a future article.

Cursor is also an interesting companion for proposing ways of doing things to a software engineer seeking ideas. It proposes relevant solutions when we ask it for help on how to do better.

Let’s be clear: this article deliberately highlights the cases where Cursor brings real added value. The next publications will be an opportunity to share more nuanced feedback, particularly on its limitations.

A month after the launch of the pilot, we already have several concrete feedbacks, such as: “I was able to create 4 internal applications in 2 weeks”. These were applications intended to accelerate code production or experiment with new use cases.

On the business production side, it is still too early to draw solid conclusions. We currently lack perspective on productivity metrics. However, the qualitative feedback is very encouraging, with a very positive software engineer NPS.

I can code anything, anytime, anywhere was originally published in Peaksys on Medium, where people are continuing the conversation by highlighting and responding to this story.

Our test with Cursor AI : The why & the how

Short Version: We launched a pilot on Cursor AI and we will share our learnings

Long Version:

Sometimes we hear that AI could soon replace software engineer s. Since the software engineer ‘s job is much broader than just producing code, we preferred to form our own opinion on the value added by generative AI in the daily life of engineers. This is why we decided to test Cursor AI, the integrated development environment (IDE) boosted by artificial intelligence. In this serie of 10 articles, we will share our experiences — with full transparency. It will not be a commercial showcase: we will talk about what works… and what works less.

Let’s start by explaining what Cursor AI and its agent mode are. If I simplify, it’s the interface that a software engineer will use to describe the behavior they expect from an application. I should note that if a software engineer writes code, they also spend a lot of time reading it. So far, nothing new, you might say. But this time, the IDE embeds features made possible by AI, such as writing code “on behalf of” the software engineer .

Before moving to the pilot, we started with a proof-of-concept aka POC to discover the possibilities that Cursor offers that traditional IDEs don’t:

- With its AI dopamine, it can read code and describe what it does. You can ask questions like: Explain the evaluation criteria for payment in 4 times. Cursor will then read the code (and not the documentation) to extract the business rules from the code. This first use case corresponds to a classic case of generative AI, namely synthesizing a content base.

- Cursor can generate code without copying/pasting from a knowledge base like Stack Overflow. It generates code in a number of important languages based on requests. You can ask it to create an application that manages expense reports with whatever technical specifications you want. This second use case corresponds to a classic case of generative AI, namely generating content from a request.

- Cursor also has an agent mode. No need to go ask an AI what to do, then do what the AI proposed. Cursor asks you if you want to do what it proposes, and it does it if you choose yes. For example, I needed to generate an SSH key, and Cursor launched the command line I needed. It can also create directories, modify code, … in short, lots of things.

After our initial tests to validate the proof of concept, we decided to launch a pilot by increasing the number of people involved. This is how we now have a pilot in progress with 35 people using this new AI-enhanced IDE. While we think Cursor can help us generate documentation and/or improve design, we’ve set only one objective: Improving dev efficiency. We have two success criteria :

• A quantitative indicator: the number of commits per day and per person.
• A qualitative indicator: a NPS (Net Promoter Score) to measure software engineer s’ satisfaction with Cursor.

The participants do not have individual objectives related to the pilot. They are a representative sample of our software engineer population. We launched this pilot one month ago, for a duration of six months, with an intermediate evaluation at mid-course.

Our test with Cursor AI : The why & the how was originally published in Peaksys on Medium, where people are continuing the conversation by highlighting and responding to this story.