# AI-assisted Development: Context, Tests & Ownership | Yahya Erturan Canonical: https://yahyaerturan.com/en-GB/blog/yapay-zeka-iyi-yazilimci/ Language: en-GB AI-assisted development AI Is Good for Software Development — If You Already Know Your Craft AI can generate code. Defining the task, checking the result and releasing it safely still take engineering. Yahya Erturan·About 4 min read Plan an online meeting ↗ All articles ↗ Using AI to write code can be a good thing. Building good software still requires understanding the problem, recognising boundaries and evaluating the result. AI does not remove that work; it often amplifies sound engineering habits. The phrase “if you are already a good developer” is not intended to exclude beginners. New developers can learn from AI, experiment and explore code more quickly. The difference is understanding what the generated code solves and what risks it introduces. When AI produces something, you still need to judge whether it is right. Where AI is a good fit AI can be useful for bounded, reversible tasks with observable outcomes: drafting a data transformation, proposing test cases, simplifying documentation, explaining an unfamiliar API or suggesting options for repetitive refactoring. The task must be clear. “Modernise this module” is vague. “Extract these three repeated checks into a separate method without changing this endpoint’s response format; keep existing tests and add edge-case coverage” sets a much clearer boundary. Experience helps me ask the questions that come before code Being a good developer means more than knowing a language or framework. It takes translating product needs into technical requirements, understanding the architecture, seeing the boundaries a change affects and weighing alternatives. When a model proposes a solution, these questions still require engineering judgement: Does this change meet a real user need, or just match the requested screen? Are data and access boundaries correct? Could sensitive information go to the wrong place? Have errors, empty values, repeated requests and stale data been considered? Do the tests check behaviour, or merely repeat the code’s own assumptions? Does it add dependencies, maintenance effort or unnecessary abstraction? Will the team be able to read and change this code in six months? A model can help with these questions. Accepting its answer and validating it are not the same thing. Why vibe coding cannot be a production strategy Experimenting with code is useful for quick prototypes and early user feedback. The problem comes when a prototype becomes production software without resolving the uncertainty. Shipping code without understanding it, defining acceptance criteria or testing it can turn speed into accumulated risk. “Seemed to work” is not enough for authentication, payments, personal data, permissions, deletion or automated actions in external systems. A production defect may mean data loss, a security vulnerability or an incorrect customer transaction, not just a visible bug. A controlled AI-assisted development workflow Write down the task clearly. Make the purpose, exclusions, current behaviour and acceptance criteria explicit. Do not let the model invent missing context. Ask for an approach first. For larger changes, ask for a plan covering files, dependencies, risks and small steps before requesting code. Review and refine it. Keep the change small. A diff focused on one responsibility is easier to verify and roll back. Do not let the model change unrelated files. Discuss testing from the start. Define errors and edge cases as well as the happy path. Check that tests actually run in the real environment. Review independently. Do not validate the solution by asking the same model whether it is correct. Use code review, type and lint checks, and security scans. Release in stages. Define staging, feature flags, monitoring and rollback. Add human approval to automation that affects the outside world. Set data and cost boundaries. Agree as a team which sensitive information may be sent to which tools, the access permissions and the model/API cost limits. When AI is not the right choice If requirements are unclear, data is unclassified or results cannot be measured, close those gaps first. Do not leave irreversible or high-impact decisions to fully autonomous workflows. Adding a model to every task is not efficiency; a simple rule, SQL query or small automation may be cheaper and more reliable. An AI tool’s reliability depends on more than its model. Scope, access, context and validation all matter. “AI wrote it” is not a quality mark; “a human wrote it” is no guarantee either. What matters is whether the team understands the change and can test it with evidence. Being a good developer does not mean opposing AI Getting value from AI does not require a romantic attachment to writing every line by hand. Letting tools handle repetition can free people to focus on product decisions, architecture, testing and user impact. But developers must still direct the process, rather than treat a model as a magical team member that knows what to do next. For me, good AI-assisted development means clear tasks, limited permissions, small changes, working tests, human review and a way to roll back. Without that foundation, software does not simply get built faster; it becomes harder to understand faster. If your team uses AI tools but is unsure what to delegate, how to check results or how to measure quality, I can start by reviewing the current development workflow. Don’t miss new articles Would you like an email when a new blog article is published? Follow via RSS ↗