I have been writing software for a long time, and I still catch myself asking a basic question.
What does a senior engineer actually do, day to day, when the interesting part is no longer only how fast someone can produce code?
I ask it more often now because I use Cursor and other AI tools extensively. They can draft functions, tests, migrations and UI changes quickly. That speed is useful. It also makes the role feel slightly unsettled. If an agent can implement a ticket in minutes, which parts of “senior” still matter?
I am working through that question while drafting an AI-assisted software development handbook for myself: a place to refresh practices I value, not a claim that I already embody every one of them. There is no single official definition of “senior engineer” that every company uses. Titles vary. Teams vary. What follows is a set of habits I am learning to value more deliberately. They are not a checklist that proves anyone’s seniority, and they are not a claim that every senior engineer must use AI.
Before anyone writes the change
1. Understand the problem and the desired outcome before choosing a tool
It is easy, especially with AI nearby, to jump straight to implementation. Prompt the agent. Accept the first plausible patch. Move on.
The habit I am trying to protect is older than any coding assistant: state what is broken or missing, who feels the pain, and what “done” would look like before deciding whether the answer is a library, a feature flag, a config change or a new service.
A hypothetical example: a report page is slow. One instinct is to ask an agent for caching. Another is to ask whether the page is loading ten times more data than anyone reads, whether a simpler query would do, or whether the real need is a nightly export. The tool choice comes after that conversation, not before it.
AI can help explore options once the outcome is clear. It does not replace naming the outcome.
2. Estimate work and make assumptions visible before committing
Estimates are forecasts, not guarantees. Their detail should match the decision someone is trying to make.
What I am learning to value is not theatrical precision. It is making the fog visible early: which parts are known, which depend on another team, which need a spike, and which will stay rough until someone opens the code.
Imagine a stakeholder asking how long a “simple export” will take. A useful answer might sound like: “Two days if the data already exists in the reporting schema. Longer if we discover fields that only live in an old service. I will confirm that before we lock a date.” That is not hedging for its own sake. It is protecting trust.
I have also learned, including in earlier freelance work, how costly silent scope growth becomes when assumptions stay unspoken. Saying the assumptions out loud is part of the job.
3. Say “I don’t know yet” and make a plan to find out
“I don’t know” can sound unsafe in rooms that reward confidence. “I don’t know yet” is usually more accurate, and more useful when it comes with a next step.
A hypothetical: an alert fires on a service you do not own. Pretending certainty wastes time. Saying you need fifteen minutes with the dashboards, the recent deploy list and the owning team’s channel is a plan. Seniority, as I am learning it, is often the courage to buy that clarity instead of performing an answer.
With AI, the temptation is to ask the model first and treat its confidence as yours. Models can invent APIs, misread logs and sound sure. Useful assistants still leave you responsible for checking the claim against the system.
While the change is being shaped
4. Simplify or remove code when it improves the system
Removing code can be a gift. It can also become a vanity metric if you treat “lines deleted” as proof of wisdom.
The useful version is narrower: prefer the smallest design that solves the problem you have now, and delete paths that no longer earn their keep.
Google’s code review guidance (opens in a new tab) warns reviewers about over-engineering: solving a speculative future problem before its shape exists. That matches what I see when an agent cheerfully adds abstractions “for later.” Sometimes later never arrives. Sometimes later arrives looking nothing like the abstraction.
A concrete, still hypothetical case: three near-identical validation helpers grown over a year. Collapsing them into one tested function can reduce the places bugs hide. Counting deletions for the pull request summary is not the point. Fewer wrong places to edit is.
5. Explain technical choices and trade-offs without dismissing people
A senior voice is easy to confuse with a loud voice. I am trying to practice the other kind: name the options, the costs and the recommendation without treating disagreement as ignorance.
“We could sync this nightly, which is cheaper and slightly stale, or on every write, which is fresher and more expensive. For this report, stale by a few hours is acceptable.” That sentence invites a product conversation. “Anyone who wants real-time clearly doesn’t understand databases” ends the conversation and teaches people to stop bringing you problems.
AI drafts can make this worse if you paste them into a thread unchanged. Generated certainty without shared context still reads as certainty. The human still chooses the tone.
6. Review changes with their future operation and maintenance in mind
A pull request (a proposed change waiting for review before it lands) is not only a question of whether the happy path works today. It is also a question of whether the next person can run, observe and recover the thing.
When I review, including AI-authored diffs, I am learning to ask:
- How will we know this failed in production?
- What happens on retry, timeout or partial success?
- Is there a safe way back if the change misbehaves?
- Did the tests prove the behaviour we care about, or only that a function exists?
That last question is personal. I recently watched a control pass automated checks while a real click still did nothing. The lesson was not “never trust AI.” It was that verification still needs a human who knows which claim the test actually supports.
Google’s published review guide also asks reviewers to consider design, complexity, tests and documentation updates when behaviour changes. None of that disappears because an agent wrote the first draft. If anything, the draft arrives faster, so the review has to stay sharper.
I lead a small POD where we review each other’s work. The point is not to create a bottleneck around one senior person. It is to keep judgment shared, so the team gets stronger rather than more dependent.
7. Help less experienced teammates learn and become independent
Helping junior colleagues is valuable. Becoming the only person who can unblock them is not.
The habit I want is closer to teaching the fishing route than handing over the fish every time: sit together for the first unfamiliar deploy, then ask them to lead the second with you watching, then review their write-up of the third. Share the why. Leave a trail they can reuse without you.
AI can accelerate that if you use it as a study partner (“explain this failure mode,” “draft a checklist we will edit together”) and still slow it down if juniors learn to accept opaque patches they cannot defend. Independence includes being able to explain the change without the chat history open.
