![\"\"](\"https:\/\/dailybusinessgroup.co.uk\/wp-content\/uploads\/2026\/10\/numan-ali-llNtovr7ctk-unsplash.jpg\")
By Dmitry Baraishuk, chief technology officer and partner at<\/em> Startups are using vibe coding and will continue to do so. However, the limits of vibe coding will never go away, and clean-up specialists will still be needed.<\/strong><\/p>\n Let\u2019s consider two typical problems that startup founders have recently brought to Belitsoft.<\/p>\n One startup used vibe-coding tools to reduce costs before showing a product prototype to investors in order to raise money. When the demonstration was over, they faced a serious problem. As it turned out, only the front end actually worked, and the product was not ready to make money. For instance, a high user load caused the system to fail. Thus, we needed to strengthen the back end.<\/p>\n The situation can be even worse. Another vibe-coded project couldn\u2019t even be shown to investors, because it wasn\u2019t possible to implement all the ideas in time with limited resources even with vibe-coding tools.<\/p>\n That is why a startup might need a rescue service to launch: its team urgently needs help developing a working prototype.<\/p>\n This is where senior AI developers come in. Previously, these professionals were expensive and time-consuming to hire, which didn\u2019t suit startups.<\/p>\n Now they\u2019ve become cheaper, better, and faster. Still, not all of them have: only those AI developers who know which strategy and tools to use have.<\/p>\n So what\u2019s the right way? Here\u2019s how senior AI developers at Belitsoft work with AI and use vibe-coding best practices to deliver higher-quality code for startups. It is also cheaper than before, because the code doesn\u2019t have to be rewritten after the demo.<\/p>\n Senior AI developers are able to direct the design of a new feature in three ways. They can write the plan themselves, or edit a draft created by the agent, or ask the agent to revise a plan written by a human.<\/p>\n A developer always reviews the base plan, even when they ask the agent to create it for a new assignment. To ensure that every suggested implementation step can be tested in an integrated manner, they rely on general software engineering experience throughout this process.<\/p>\n Why does it matter? Full control over design planning ensures that stakeholder requirements are met and proprietary information stays intact.<\/p>\n You have to be really detailed about most things, because AI might go completely crazy and you would have to spend more time correcting it than you gained. One developer in a study conducted by researchers from UC San Diego and Cornell compared the AI to an intelligent child that has no knowledge of you or the outside world.<\/p>\n Senior AI developers include the ten most common types of context in their prompts: technical terms, domain objects, the new feature or requirement, references to input files, specific libraries or APIs, descriptions of interaction, the purpose of the feature, UI or design terms, references to output files, and references to a step in the plan.<\/p>\n A single well-formed prompt can use seven of these ten types and still restrict the agent to do just step one of the plan to avoid premature execution of a complex request.<\/p>\n Developers can also add screenshots, file references, examples, step-by-step thinking, and external information through Model Context Protocol (MCP) servers. Some developers use external agents to refine prompts.<\/p>\n To keep things under control, even plans with more than 70 steps are executed in chunks of no more than six steps, and across all developers the median is under two steps per prompt.<\/p>\n How does it work? A typical prompt lists the steps to follow and then states: \u2018We will do these steps one at a time. Please do just step 1 now.\u2019<\/p>\n Developers save plans in external files. Also, they use separate local files to preserve agent context and memory between sessions. Drafting detailed multi-step plans in distinct files is quite useful for difficult tasks, as long as the agent is limited to implementing the plan in manageable chunks.<\/p>\n Developers apply user rules to enforce project specifications, provide general guidelines, or correct agent behaviours. Developers encode their readability and test-driven development preferences into user rules.<\/p>\n \u2018I am a software engineer, I prompted by applying the lessons of software engineering to narrative\u2019, as one engineer put it, where \u2018narrative\u2019 means the content of the prompt itself.<\/p>\n Regardless of the task, all senior AI developers control the implementation at some level. However, there are two modes of supervision.<\/p>\n If they\u2019re working on something they don\u2019t know, they set the requirements and let the agents do the implementation. They don\u2019t necessarily review the generated code, but they follow the agent\u2019s decisions and program outputs carefully and sceptically. For instance, they reject dependencies the agent tries to install and use a debugger to resolve AI-generated code that misbehaves.<\/p>\n Those working within their domain of expertise carefully review every agentic change. They revise it either by prompting the agent, so that everything stays in the chat context, or by changing the code manually, which saves time in the long run because nothing has to be re-explained later. Manual user interface testing, examining diffs, utilising debuggers, and executing tests via the command line are all part of their code verification toolkit.<\/p>\n Senior AI developers do not just wait for the agent to finish a task. They monitor its thinking process, revise code to demonstrate good practices such as readability, and override behaviour using human expertise.<\/p>\n While some choose not to \u2018waste time with them\u2019 at the system level, others delegate the debugging of agent-generated problems to agents.<\/p>\n Why participate? Because agents do more than they are asked to: they can generate additional files, modify entire sections of code, or add unnecessary packages. The idea that the agent will just start changing and changing stuff without truly knowing what\u2019s happening is something that developers dislike.<\/p>\n When given clear plans, senior AI developers find that agents can speed up simple, repetitive, and straightforward tasks. Writing tests, documentation, general refactoring, and simple debugging are some of these activities.<\/p>\n Agents remove the mundane from such tasks. They assist in writing boilerplate or scaffolding code \u2018that we wish we didn\u2019t have to write in the first place\u2019.<\/p>\n Agents succeed at following well-defined plans, although this requires clear prompting. They can be surprisingly good at writing general tests for already existing code, and highly effective at fixing a bug when pointed to a specific failing test. Additionally, they are adept at breaking down confusing stack traces and suggesting possible causes.<\/p>\n With an LLM, creating a framework or prototype of the solution that is about 2,000 lines of code is simple and can even be effectively vibe coded. Agents suit throwaway demos and experiments, and this is exactly the place for vibe coding. Agents might be useful for building user interfaces, but not for controlling specific visual details.<\/p>\n Agent suitability declines as task complexity rises. Agents struggle at complex tasks, not necessarily big ones: specifically, at complex logic and at complex refactoring or improving architecture. When making complex, multi-step, boundary-crossing modifications across codebases that require coordination, developers steer clear of agents.<\/p>\n Business logic that necessitates extensive context and domain expertise is inappropriate for agents. Studies have found that developers do not consider agents a replacement for human decision-making, and our experience confirms this. The decision on implementing an agent-generated plan, option, or modification lies with the developer, who takes time thinking about its implications before giving a thumbs-up.<\/p>\n Agents are not seen as appropriate for fully autonomous operation. Senior AI developers tend to never allow the agent to be fully independent. Instead, they constantly read the output and provide guidance.<\/p>\n Why? LLMs are unsuitable for one-shotting code without modification or verification, and for handling details. The generated code has to be cleaned up, verified, or revised.<\/p>\n Integrating with existing code or managing legacy code, where the agent frequently creates bespoke code for pre-existing functions in core libraries, is a commonly reported issue.<\/p>\n Developers also consider agents unsuitable for writing performant code and for handling CI and deployment infrastructure. They prefer to do this work by themselves. The same applies to high-stakes, privacy-sensitive, or security-critical code, given little room for error.<\/p>\n Senior AI developers are divided on whether to use agents to plan and architect the entire system or just a feature.<\/p>\n Some avoid agents here because system design is too important to delegate. They would never trust LLMs with architectural challenges and will not utilise agents for system design because many of the agents\u2019 architectural choices can backfire due to careless delegation.<\/p>\n Others like the back-and-forth design with AI. They employ agents to brainstorm and talk out problems, like full-time rubber ducking or asking a co-developer for questions and insights without fear of being judged. One developer specifically asked the agent to challenge them and make sure that what they were proposing was correct. Another does not use agents for high-level planning, though agents help them avoid blind spots. It is a lot of back-and-forth, so agents are never left to work on that without human input.<\/p>\n In the end, agents can participate in system and architecture design as a collaborator rather than an independent driver. Senior AI developers prefer to use agents as a way to collaborate with the human in the loop, rather than handing off work entirely. They like to be in control during brainstorming: leading the conversation, doing the thinking themselves, and treating agents as mere inspiration.<\/p>\n Senior AI developers may not always read agent-generated code. They take care to maintain control, though, and do not allow agents to operate entirely on their own, especially by having the agents work on only a few tasks at a time.<\/p>\n Instead of delegation, they usually favour using agents as a source of collaboration. They believe agents are appropriate for scaffolding, repetitive work, and simple tasks. However, they don\u2019t employ agents for complex tasks or core business logic, and there is disagreement about developing plans with agents.<\/p>\n For a startup, this is the difference between a vibe-coded demo and a product that can be shown to investors and then make money without a rescue service.<\/p>\n As chief technology officer at a software development company Belitsoft that aims to accelerate the development process at each stage and deliver results for our clients faster, I agree with one of the developers in the study: AI agents are amazing, as long as you are the driver and reviewing their work.<\/p>\n About the author<\/strong><\/p>\n Dmitry Baraishuk is partner and chief technology officer at<\/em> Belitsoft<\/em>, a custom software development company founded in 2004 and now part of the Noventiq group. For the last 20 years, he has been heading the custom software development department at Belitsoft, managing hundreds of delivered projects for startups and enterprises in the United Kingdom, the United States and Canada. His department\u2019s expertise covers AI software development and AI integration with a focus on fintech, healthcare and enterprise SaaS.<\/em><\/p>\n \t <\/div>\n![\"\"](\"https:\/\/dailybusinessgroup.co.uk\/wp-content\/uploads\/2026\/10\/DmitryBaraishuk.jpg\")
<\/figure>\n