From Vibe Coding to AI-Assisted Engineering | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

From Vibe Coding to AI-Assisted Engineering: Lessons From Real Projects

Eriton Silva

11 min read·<br>4 hours ago

Listen

Share

How I improved my AI coding workflow with specs, context, agent skills, frontend references, and memory.<br>Press enter or click to view image in full size

Like many developers, I have incorporated AI into my daily software engineering routine.<br>I use AI across different parts of the software development lifecycle: refinement, architecture, infrastructure, quality, troubleshooting, observability, monitoring, documentation, and even product thinking.<br>At first, my approach was simple: I opened Copilot, Codex, Devin, or another AI coding assistant and asked it to fix a bug, create a feature, explain a piece of code, or generate an endpoint.<br>It worked.<br>But it was inconsistent.<br>Sometimes the result was impressive. Sometimes it was too literal. Sometimes the code worked but the architecture was weak. Sometimes the frontend looked ugly. Sometimes the assistant lost context, repeated mistakes, or forgot important project decisions.<br>That was when I started to realize something important:<br>The real difference is not only the AI tool you use. The real difference is the engineering system you build around the AI.

This article is a practical reflection on what I am learning while using AI in personal and professional software projects. I am not presenting a final framework. I am sharing lessons from the journey of moving from “vibe coding” to a more professional AI-assisted engineering workflow.

1. Vibe coding is useful, but it does not scale<br>I started using AI in a very natural way: chatting with the assistant.<br>For example, I would write prompts like:<br>Create an API with these endpoints:GET product by IDResponse:<br>"productId": "string",<br>"product_name": "string",<br>"description": "string"<br>}Or I would use a more conversational prompt:<br>You are a software developer specialized in Go.<br>Develop an API endpoint to get a product by ID.<br>The response should include productId, product_name, and description.I have not benchmarked these two approaches yet, so I cannot say scientifically which one is better.<br>My current feeling is that formatting alone is not the main factor. A structured prompt helps, but the real improvement comes when the AI receives better context, clearer constraints, examples, expected artifacts, and feedback loops.<br>In other words, prompt quality matters. But prompt quality is only one part of the system.

2. The biggest improvement came when I used AI before coding<br>One of the most useful experiments I did was using Devin for task refinement before implementation.<br>I had a task to migrate a low-code feature to an API written in Go. Instead of asking the AI to immediately write code, I asked it to refine the task as if it were a senior software engineering tech lead.<br>The prompt was something like this:<br>You are a senior software engineering Tech Lead specialized in Go.Your mission is to refine a task to migrate a low-code software feature to an API in Go.You need to deliver these artifacts:1. Diagram of the as-is solution.<br>2. Diagram of the to-be solution using Mermaid, Excalidraw, or Draw.io.<br>3. A detailed solution refinement including development, tests, performance tests, functional tests, monitoring, observability dashboards, and documentation.<br>4. A task breakdown, sprint roadmap, estimations, and risks.<br>5. Insights that I may not have considered.Use the low-code solution documentation as context.The result was impressive.<br>The AI generated markdown files, diagrams, a detailed delivery plan, a risk analysis, testing ideas, observability suggestions, and even a responsibility matrix. One of the best outputs was a map showing how each new API feature would replace the corresponding low-code feature.<br>Of course, the result was not perfect. I still needed to review it, adjust assumptions, and improve details.<br>But the quality of the refinement changed the way I looked at AI coding assistants.<br>The AI was not just helping me code. It was helping me think.

3. Specs are the bridge between idea and implementation<br>Later, I realized that this approach was very close to Spec-Driven Development.<br>Instead of jumping directly from idea to code, you first create a specification that explains what should be built, why it matters, how it should behave, how it should be tested, and how it should be operated.<br>That changed my mental model.<br>Before, I was asking AI to generate code from vague intent.<br>Now, I try to make the intent explicit through artifacts such as:<br>Feature specs<br>API contracts<br>Mermaid diagrams<br>User journeys<br>Acceptance criteria<br>Test scenarios<br>Observability requirements<br>Architecture decisions<br>Risk analysis<br>Implementation plans<br>This is especially important when working with AI agents.<br>An AI agent can produce better results when it has a clear spec to follow. Without...