How to Use AI in Software Development?  | Opinion

Either most people don’t know about AI, or if they know, they know it wrong. Whenever I see content about it, text, image, audio, video, it’s almost always far away from what real AI development actually looks like.

I have been working in this industry for more than eight years, and I have watched these changes happen in front of my eyes, not on Reddit, not on X, not on any social media feed.

Today I am forced (yes, forced) to write this blog by my marketing team, because they wanted something real, information about AI that is actually possible, that can actually be implemented.

So here’s the idea. I’m not going to tell you what AI might do someday. I want to focus on where it has actually reached right now, and how you can use that, today, across your own software development lifecycle.

How Does AI Help at Each Stage of the SDLC? 

Let me go phase by phase. Not everything gets equal space, some of these are still weak, and I’ll say so. 

1. Planning and requirements

This is where AI is more useful than people give it credit for, and less useful than people claim. Feed a vague client ask or a messy Slack thread into a chat based model, Claude or ChatGPT both work fine here, and ask it to turn that into a structured spec: assumptions, open questions, rough scope.  

That part works well. What doesn’t work is trusting it to decide scope or priority. It doesn’t know your users, your deadlines, or your politics. I personally use it to structure thinking and not to make the call. 

2. Design and architecture

AI is a genuinely good sounding board here. Describe a system, ask it to poke holes, ask what breaks at 10x scale, and you’ll get useful angles you might not have considered on your own.  

This is also where the term RAG (retrieval augmented generation) comes up a lot, if your architecture question involves how a model should pull in your own data instead of relying on what it was trained on, that’s the pattern worth researching.  

But architecture suggestions from AI are still a draft from a smart junior, not a senior with context. It will recommend patterns that sound right and are wrong for your specific constraints, confidently. 

3. Coding

This is the phase everyone talks about and almost everyone oversells. The tooling here has genuinely moved past autocomplete, GitHub Copilot, Cursor, and Claude Code are the three tools most teams are actually standardizing on in 2026, and each has a different philosophy.  

Copilot lives inside your IDE and is the most mature for enterprise controls. Cursor is a full AI native IDE, good for fast, multi file changes with a human still driving.  

Claude Code is terminal native and agentic, meaning it can plan and execute multi step coding tasks across a codebase on its own, which makes it better suited to backend and large repo work where understanding relationships between modules matters. A lot of teams now run more than one of these together rather than picking a single winner. 

None of that changes the honest version of this section: AI is excellent at boilerplate, repetitive CRUD, and tight, well scoped refactors. It is not writing your application. It doesn’t understand your business logic or why that one weird function exists because of a client requirement from two years ago.  

Let it write large chunks unsupervised and you pay for it in review, and there’s real data on this: security researchers have found a meaningful share of AI generated code fails security tests or ships with design flaws, so review discipline matters more, not less, as these tools get better. 

4. Code review

AI is genuinely useful as a first pass, catching obvious issues, inconsistent naming, missing null checks, common security smells. What it’s not good at is judgment.  

I personally have seen that it flags a lot of noise, things that are technically true but contextually irrelevant, and a reviewer who blindly trusts it either drowns in false positives or starts ignoring it entirely, which is worse. It works best as a filter before a human review and sorry to say but not a replacement for one. 

5. Testing and QA

This is one of the stronger use cases. AI is good at generating test cases, especially edge cases a tired developer wouldn’t think of at 6pm on a Friday, and decent at spotting gaps in existing coverage.  

It’s weaker at understanding what matters to test, business critical paths versus trivial ones, so someone still needs to curate what it generates. 

6. Documentation

Honestly, this might be the most underrated use case on this list. Nobody wants to write documentation, so it usually doesn’t get written, or gets written once and never updated.  

AI generates it from the code, the PR, or the ticket, and keep it in sync becomes a five-minute task instead of a skipped one. This is a case where the AI hype is actually too quiet, not too loud. 

7. Deployment and monitoring

This is where I’d be most careful about overclaiming. AI is useful for summarizing incidents and sifting through logs faster than a human scanning line by line. It is not making deployment decisions, and it should not be.  

If your tools talk to internal systems, logs, tickets, deployment dashboards, you’ll increasingly see this wired up through MCP (Model Context Protocol), which is basically a standard way of letting an AI tool connect to your existing infrastructure instead of everyone building custom integrations.  

That’s a real, useful piece of plumbing. Full autonomous deployment decided by AI is still the same fantasy as the self-running department. 

Where This Leaves You 

If you take one thing from this post, take this: AI is not going to run your development lifecycle for you, not this year, and probably not for a while.  

What it does is remove friction from the parts of the job that were always friction, boilerplate, documentation nobody wanted to write, the fiftieth edge case you didn’t think of on a Friday evening.  

That’s not as exciting as “AI runs your department,” but it’s real, and it’s already saving my team time every single day. 

The honest advice, if you’re just starting to bring AI into your own workflow, is to start small and start where the risk is lowest. Documentation and test generation are good first steps, high value, low blast radius if the AI gets something wrong.  

Coding and architecture are where you need the most human judgment still in the loop, so don’t hand those over just because a demo made it look easy. 

And be skeptical of anyone, including me, telling you exactly what the “right” tools are. This space changes every few months.  

What matters more than which tool you pick is building the habit of using AI as a fast, occasionally wrong collaborator. Review everything. Trust nothing blindly. That mindset will outlast whatever tool is popular this quarter. 

If you’re figuring out where to start with AI in your own software development process, or want a second opinion on whether something is worth building, that’s the kind of work my team does. Happy to talk through it.