This post covers how the engineering team I lead is using AI tools in our day-to-day work: what we use, how it works, and what it has changed.
The pressure is real: we are building something genuinely new while simultaneously maintaining several existing products. Speed and quality both matter. We cannot sacrifice one for the other. AI tools are not a pilot or an experiment in that environment. They are how we make it workable.
Cursor: AI-powered development Link to heading
The first tool is Cursor. The important thing to understand about Cursor is what it is not: it is not a smarter autocomplete. In agent mode, Cursor understands your entire codebase and can plan work, edit files across the project, run commands, and iterate until a task is done. The shift is from typing to delegating and reviewing.
The workflow the team uses has four steps.
Plan. Before any code is written, the engineer describes the problem and lets Cursor ask clarifying questions. What format? What constraints? What does success look like? The brief is shaped collaboratively before implementation begins.
Implement. Once the plan is agreed, Cursor builds the solution. The engineer steps back. Cursor writes the code, handles edge cases, adds error recovery.
Review. The engineer runs and examines the output with their own judgement. This is not rubber-stamping. It is a genuine review. Domain knowledge and an eye for quality are the checks that matter.
Correct. The engineer brings feedback back and they iterate together. The engineer directs; Cursor executes the corrections.
A real example of this in practice: I ran a proof of concept to explore whether an LLM could effectively analyse and categorise a large volume of qualitative feedback. I described the problem to Cursor; it asked clarifying questions about output format, category structure, and whether the pipeline needed to be resumable for an overnight run. Cursor then wrote three scripts in about 20 minutes. On reviewing the output I noticed it was identifying only one topic per message when I expected more. I brought that back; Cursor suggested a prompt improvement and updated the code. The pipeline ran overnight and processed the full dataset. The whole thing was built in under a day, and the answer to the original question was yes.
A second example from the team: on a new greenfield project, running the continuous deployment workflow I wrote about earlier, we required automated test coverage on every feature from day one, with no room for manual test writing in a workflow that ships multiple times daily. A QA engineer picks up a story from the backlog, points Cursor at it via a Jira integration, and Cursor builds out a full Playwright test scaffold: page objects, test cases, folder structure, naming conventions, across the codebase. The QA engineer’s role shifts from writing boilerplate to reviewing and improving what Cursor produced. Test coverage ships alongside every feature, from sprint one.
The adoption across the team has been high and has grown steadily since we introduced Cursor. That is not something you can mandate: it reflects that the tool genuinely makes the work better.
CodeRabbit: AI code review Link to heading
The second tool is CodeRabbit. Code review is one of the most important quality gates in software development and, in my experience, one of the most variable. The quality of a human review depends on who is doing it, how tired they are, how familiar they are with that part of the codebase, and what time pressure they are under. CodeRabbit makes review instant, consistent, and thorough on every code change, automatically.
The process: an engineer submits a code change for review. CodeRabbit scans the entire change in seconds, flags bugs, security risks, and quality problems as inline comments, and the engineer reviews the feedback and addresses what matters. Human engineers do not disappear from the process; they become more effective, spending their time on bigger-picture decisions rather than issues CodeRabbit has already caught.
A concrete example: as one of our teams built out a new feature, CodeRabbit reviewed every change automatically as the code was written. It caught a number of issues and they were fixed before the feature reached customers, including duplicated logic that could have caused silent failures in future and a bug that would have broken the build. The point is the timing: the problems were surfaced as the code was written, not after it had shipped.
Catching those issues automatically gives senior engineers that time back for work that actually requires their judgement.
What changes Link to heading
The before-and-after is worth being direct about.
| Without AI tools | With Cursor and CodeRabbit |
|---|---|
| Significant time on repetitive, predictable coding tasks | Repetitive work handled by AI; engineers focus on complex problems |
| Code review quality varies by reviewer, time of day, and familiarity with the code | Instant, consistent review on every change |
| Issues sometimes reach production before being caught | Problems flagged automatically before code ships |
| Bringing new engineers up to speed takes longer | New team members contribute meaningfully earlier |
The shift is not that engineers do less. It is that they operate at a higher level.
The pattern applies beyond engineering Link to heading
The four-step workflow (Plan, Implement, Review, Correct, followed by an independent fresh-eyes review) is not specific to writing code. It applies to any piece of knowledge work: a presentation, a proposal, a report, a strategy document.
The starting point in each case is the same. Before asking an AI to build anything, have a conversation to agree what is needed. Let it ask questions and shape the brief together. That changes the quality of everything that follows.
When it is done, start a brand new conversation and ask for an independent review, exactly as CodeRabbit reviews code before it ships. Fresh context, honest read, no attachment to what was already written.