From ChatGPT copy-and-paste to coding inside Cursor

In April 2023, I opened a client’s bespoke eCommerce system in Cursor and started using it for real feature work.

I can’t name the client or describe the system in identifying detail because the work remains under NDA. I also don’t have screenshots or account records from that first month. What I can describe is the workflow, why I adopted Cursor as my daily editor, and what repeated use revealed. This is the part of the story for developers maintaining real systems, rather than trying an agent on a disposable example.

Before Cursor, ChatGPT sat beside the development environment. I used it for a mixture of guidance, generated snippets, error analysis, and open-ended questions. Every useful exchange depended on me copying the relevant code or error into ChatGPT, explaining enough of the surrounding system, then carrying the answer back into the editor.

It worked, but the boundary was manual. I was the integration layer.

Cursor moved the model into the work

Cursor released version 0.0.37 on 14 March 2023. By the end of that month, its public repository described code generation, proposed edits shown as diffs, chat that understood the current file, and help with lint errors, tests, and comments.

Version 0.2.0 arrived on 6 April, moving the editor from CodeMirror to a VSCodium fork. Cursor described its direction as an IDE built for pair-programming with AI.

I started using it regularly that month. Three changes mattered together:

• The model had more useful context from the code I was working on.
• It could propose and apply changes inside the editor instead of returning code for me to paste.
• Questions, edits, corrections, and follow-up questions stayed in one working loop.

None of those changes would have sounded radical in isolation. Together, they changed AI assistance from a separate activity into part of development. Cursor was editor-integrated assistance, not autonomous development: it reduced the distance between the model, the code, and my next decision.

Better context changed the questions I could ask

My first use was feature delivery, but I did not keep Cursor confined to tightly specified implementation work. I used it across greenfield additions, brownfield changes, refactoring, technical-debt repayment, and bugs it surfaced while examining existing code.

The most revealing prompts were intentionally open. I would ask variations of ‘help me improve the architecture’ and inspect what followed.

That was not an instruction to accept whatever it produced. It was a way to test what the model understood. Did it recognise the real boundary between two responsibilities? Did it notice a dependency pointing in the wrong direction? Was it simplifying the design, or merely moving complexity somewhere less visible?

A precise implementation request showed whether Cursor could follow instructions. An open architectural question showed what knowledge it could apply without being led to the answer.

More code context was not system context

Early Cursor could see more than the fragments I had pasted into ChatGPT, but context was still its main limitation.

The eCommerce system contained business rules that were not obvious from one file. Some lived in neighbouring components. Others existed in tests, operational behaviour, or decisions made years earlier. A plausible local change could still violate an architectural boundary or a rule the model had never seen.

That is where experience before AI mattered.

Architecture helped me identify which surrounding components and invariants belonged in the decision. Domain knowledge helped me recognise when a technically neat proposal misunderstood commerce behaviour. Testing discipline treated every generated edit as untrusted until the relevant behaviour had been exercised.

Cursor could make a proposal quickly. It could not decide which consequences were acceptable on behalf of the client.

Daily use changed how I delegated work

I adopted Cursor as my daily editor because removing the mechanical friction was valuable. I no longer had to reconstruct a small version of the problem in a separate chat before asking for help.

That changed the shape of the work. I still asked for explanations and snippets, but I also began delegating bounded changes: inspect this area, propose a refactor, find what is inconsistent, or implement this feature within these constraints.

The distinction mattered. Asking for code left me responsible for integrating an answer. Delegating a change let the tool participate in the codebase, but increased the importance of deciding the boundary first and reviewing the result afterwards.

The faster loop did not reduce the need for judgement. It increased the amount of work to which judgement could be applied.

This was not autonomous development

This was not autonomous development. I still selected the work, set the boundaries, and owned the outcome. Cursor did not independently select tasks or understand the whole system.

It closed the gap between the editor and the model. I was beginning to wonder whether a tool built around the repository and terminal might take that idea further, but I did not yet have an answer.