AI and Software Engineering: More Than Just Coding
Coding Is Only a Fraction of the Job
As a leader and senior engineer, I’ve learned that coding is only a fraction of the job. Most of my time is spent gathering requirements, evaluating solutions, refining stories, creating documentation, reviewing code, and making decisions that shape the system long before any code is written.
So why does the conversation around AI in software engineering focus almost entirely on coding?
We all know that engineering is more than writing code. It’s cognitive work: planning, communication, verification, decision-making, documentation, and review. Code is the output, but a significant amount of effort goes into making that output possible.
That raises an obvious question:
Can AI help with those other parts of the job, or is it only useful as a coding assistant?
In my experience, the answer is clear: AI can do far more than just generate code, and it can save a surprising amount of time doing it.
AI as a Force Multiplier Across the Workload
Most engineers don’t want to spend their day updating Jira tickets, maintaining documentation, or wiring things together so dependency graphs stay accurate. Those tasks are necessary, but they’re often done begrudgingly so we can get back to the work we enjoy.
But what if AI handled the bulk of that overhead?
With tools like MCP, you can connect an LLM directly to your ticketing system and documentation. Instead of manually juggling context, you can talk to your LLM about your work and let it pull the relevant information itself.
In practice, that means things like:
-
Chatting with your LLM about existing tickets with full context
-
Turning technical documentation into well-structured stories
-
Updating stories and defects as understanding evolves
-
Commenting on and updating ticket status as work progresses
All of that adds up to less cognitive load and less time spent doing administrative work by hand.
Does the LLM make mistakes? Absolutely. Does it need correction and guidance? Of course. But even with occasional course correction, the efficiency gains are real.
Real-World Example: Preparing a Feature for Work
When I’m preparing a new feature and breaking it down into stories, I’ll provide the LLM with the relevant context (technical documentation, mock-ups, constraints, and any other material it needs) and give it clear instructions on how to structure the work.
When doing this, it'll come back with some great thoughts on the work; however, this is where the real work begins. While the AI will give a pretty good general understanding, it will often make many assumptions around the details that you didn't expliclty state. Your job now is to thoroughly review what it gave back to you to ensure it has an accurate understanding of what you want, correcting any details that it didn't quite get right.
This will usually take at least a few back and forths with the LLM before it gets things right. Once I’m comfortable with its understanding, I ask it to create the stories directly in Jira.
A few moments later, I have a feature with concrete, well-written stories underneath it, often with more detail and clarity than I’d normally write myself. The work is done faster, and the quality is higher.
Instead of spending my energy on repetitive setup and refinement, I can focus on validating the approach, thinking through edge cases, and getting the team unblocked sooner.
Where This Breaks Down
As powerful as generative AI is, it’s not magic, and it’s not a substitute for engineering judgment.
LLMs are extremely eager to be helpful. Most of the time, that’s exactly what you want. Other times, that eagerness leads them to make assumptions, fill in gaps incorrectly, or confidently push ideas that don’t actually align with the product or system.
Left unchecked, this is where things can go off the rails.
One of the most common failure modes is confidently wrong output. Stories may look complete but miss critical edge cases. Documentation may sound authoritative while glossing over important nuance. Diagrams can appear correct while subtly misrepresenting reality. This is why AI output always needs review, especially when the cost of being wrong is high.
This is also why I frequently use plan mode in tools like Cursor or Claude Code. By asking the model to explain what it plans to do before it does it, I can catch incorrect assumptions and small (or sometimes large) deviations early. That feedback loop prevents slop and helps guide the AI toward the outcome I actually need, rather than cleaning things up after the fact.
Another limitation is context. Today’s LLMs still struggle to hold the full shape of a complex system in a single context window. That means you need to be deliberate about what information you provide and focus on giving only what’s relevant to the current problem. Yes, this can mean the model misses patterns or historical decisions. In practice, a quick reminder or correction is often enough to get it back on track.
How do you decide what to include in the context? I like to think of how I'd explain this to a new employee. The employee may have a great general understanding of how things work, so I don't need to explain the very basics or why we chose an architecture, but I do need to explain what files are interesting and where the issue actually is. This will allow the LLM to quickly identify where the issue is as well as neighboring files or where the code is used that may be helpful to understand.
There’s also the risk of false progress. Tickets get created, documentation gets updated, and diagrams get generated, but none of that guarantees the work is actually correct or well understood. Without deliberate review, it’s easy to confuse activity with understanding.
This is where your work shifts. Instead of coding the things yourself, you're reviewing everything the AI generates, constantly checking its output against the desired outcomes and correcting quickly when things start to deviate. This is where the AI's eagerness to be helpful is beneficial. LLMs take correction extremely well and are quick to admit their mistakes. That doesn't mean they'll always get it right after that, but it does mean they take correction without any friction and do their best to make the corrections you note.
The key is intent. The goal isn’t to delegate thinking to the AI. It’s to offload friction. When AI handles structure, synthesis, and repetition, engineers can focus on validation, tradeoffs, and decision-making. Those are the parts of the job that still require human judgment.
Used this way, AI doesn’t replace engineering discipline. It amplifies it.
Why This Matters
The biggest benefit of using AI this way isn’t speed for speed’s sake. It’s leverage.
By reducing cognitive friction across planning, communication, and refinement, AI helps teams move with more clarity and less rework. Features get ready sooner. Expectations are clearer. Engineers spend more time solving meaningful problems and less time pushing information around.
In other words, AI’s real value shows up before the first line of code is written and after the last one is merged.
The Shift
If you’re only using AI to help write code, you’re missing a significant part of its value.
Try involving AI earlier and at higher levels of abstraction. Use it to clarify ideas, structure work, surface assumptions, and reduce the overhead that slows teams down.
You may find that the biggest productivity gains don’t come from writing code faster, but from spending more of your time on the work that actually matters.
This article focused entirely on the individual contributor aspects of the role of a senior engineer and didn't dive into how this can be applied at the team level. I'm interested in hearing your thoughts on this. How do AI tools and spec-driven development work at the team level? What challenges does this introduce and how are you addressing them? This will be a topic I revisit in future writings and I'd love to hear your thoughts about it.