I want to share my approach to using AI coding assistants as someone who has been in software development for over 20 years. I have a computer science background and have been working with .NET since its early days. My experience includes backend development, microservice architecture, and cloud systems at several large corporations.
The Challenge of Experience
As I’ve gained more experience, I’ve noticed that jumping into new codebases and business domains takes longer than it used to. The volume of information in modern systems can be overwhelming, and I found I needed a better way to get up to speed quickly.
My AI-Assisted Development Process
Initial Setup
I start by using AI to help me understand three key areas:
Business terminology and concepts
Technical vocabulary specific to the project
Code organization and architectural patterns
Step-by-Step Workflow
1. Prompt Enhancement
I use a prompt optimization technique called Lyra to improve the quality of my AI interactions. This helps me get more focused and useful responses.
2. Task Preparation
Before starting any development work, I rewrite user stories or tickets with AI assistance. This creates cleaner context for the actual coding work.
3. Work Breakdown
I ask the AI to split large tasks into smaller, manageable pieces. Then I work on one piece at a time.
4. Controlled Scope
This is crucial - I limit what the AI can modify. Sometimes I define interfaces first, sometimes I focus on specific methods, and often I start with test cases. The key is keeping outputs small enough to review quickly.
5. Iteration
I refine each piece until it meets my standards before moving to the next chunk.
Results
This approach helps me stay effective in complex environments where the learning curve would otherwise slow me down significantly. The AI doesn’t replace my experience but amplifies my ability to process and organize information.
For other experienced developers who might be skeptical about AI tools based on recent studies showing mixed results, I’d suggest that the key is having a structured process rather than using AI as a simple pair programming partner.
Your workflow is similar to what I’ve been building this past year, just from a different angle. The business terminology part really clicked for me - especially with legacy systems where the domain knowledge is spread across team members who aren’t around anymore. AI works well as a translator between technical debt and business needs. One thing I’ve learned: prompt optimization is huge when you’re dealing with enterprise codebases that span multiple architectural eras. Without careful prompting, AI loves suggesting modern patterns that clash with existing constraints. Keeping the scope controlled saves you from refactoring nightmares down the road. What caught me off guard was how this actually made me better at reviewing junior devs’ code. Going through the process of systematically breaking down problems with AI made me spot when their logic jumps around without building proper foundations first.
Thanks for sharing this approach. The controlled scope part really hits home - I wish I’d learned that earlier. I wasted months getting massive code blocks from AI that were harder to review than just writing it myself. One thing I’d add: keep your own coding standards file to reference in prompts. Without it, AI gives you syntactically correct code that looks nothing like your style. Coming back to it weeks later feels weird. Your user story rewriting idea is genius for catching vague requirements early. I started doing the same after realizing bad requirements meant endless AI regeneration cycles - actually slower than coding it the old way. The skepticism from senior devs is totally real, especially those who’ve seen every “revolutionary” tool come and go. But this feels different when you treat AI as an information processor, not a replacement for actually thinking through architecture.
Honestly wasn’t expecting much from AI tools, but your Lyra technique sounds interesting. I’ve been doing .NET for 15 years and you nailed the biggest pain point - jumping into legacy systems where half the business logic isn’t documented. Might try this instead of my usual “read every class file until something clicks” approach lol