Coding agents are no longer just a buzzword—they’re tools that can actually change the way developers work. From writing code snippets to building entire applications, these AI-powered assistants are becoming part of everyday development. But how effective are they really, and where do they fall short?

To answer that, we turned to Stanislav Bielkov, Delivery Manager at AMC Bridge, who has been experimenting with coding agents hands-on. In this article, he shares his experience gained on real projects—the successes, the frustrations, and the lessons learned—and explains why this trend is important for every developer to pay attention to.

How Coding Agents Work

Most people are already familiar with ChatGPT™. It is a large language model (LLM) that can take your text request and generate an answer. But LLMs can do much more than just text generation. With the right setup, they can be integrated into developer environments to read and write files, generate code, search the web, use different tools, and more. That’s where coding agents come in.

Here’s an example: you can open Visual Studio Code with an empty folder, install GitHub Copilot™, Claude Code, Gemini™ CLI, or any similar extension, and then ask an LLM to do something for you. For instance, you might tell the agent: 'I want to build a web application. It should have a 3D viewer with the ability to zoom, rotate, and pan.' (Of course, this is a simplified instruction and cannot be used to get exactly everything you want.)

The agent will “think” for a while, maybe ask some questions, and then start generating code. Line by line, and request by request, it will build a prototype. You may not even need to write a single line of code yourself if you know what to ask. Sure, not everything will work right away—some things might break—but you can iterate with more requests and eventually get it working. That’s what a coding agent is. Is it perfect? No—it usually needs polishing. But in many cases, tasks that would take a developer longer to do manually can be completed more quickly with an agent.

When Agents Work Well—and When They Don’t

This really depends on the task, the LLM, the set of tools used alongside it, and the training.

In general, from what I’ve seen, they work well in the following cases:

• For simple, repetitive tasks (like adding another button or extending existing functionality), the agent often wins—faster and good enough.
• For generating new functionality when the specification and acceptance criteria are defined, or can be defined with less effort than the code development itself.
• For test generation.
• For familiarizing yourself with a project: an agent can answer questions about the code base, generate architectural diagrams, etc.
• For creating supplementary scripts.
• And similar cases.

I would avoid using agents in the following cases:

• For ambiguous tasks: the agent might generate something, but it will likely just be a waste of time. Make sure you know how to describe the expected results. If you don’t, you can chat with an agent first to help define the criteria before starting code generation.
• For tasks where the required context exceeds the agent’s technical capabilities. Context engineering is just as important as prompt engineering, and such tasks need to be split into smaller pieces.
• For tasks that require a large number of detailed instructions to be completed properly. Most likely, these should be broken down into smaller sub-tasks.

It’s important to note that almost every week a new LLM or tool is released. By the time this is published, there’s a good chance some new, game-changing tool will already be available that can handle even more.

A Shift, not a Replacement

Over the past 18 months, interest in integrating AI into software development has exploded. I believe it will eventually change the industry in fundamental ways.

No, I don’t believe AI will fully replace developers—but it will reshape their roles. Think of website builders: these already let non-coders create pages. Still, we need real developers for complex systems. Similarly, coding agents will take over routine tasks, making development faster and more scalable, while people will still need to review, ensure quality, and design the bigger picture.

One of the key limitations right now is context—how much information a model can “see.” For instance, GitHub Copilot currently limits the context of any model to about 110k tokens, which is roughly 11k lines of code. But imagine if it could handle your entire project at once—thousands of files. That would change everything again.

For now, the safe approach is to view agents as helpers. They can boost your productivity, but only if you understand the main nuances of their usage upfront.

Why I Started Experimenting

I’ve been interested in coding agents for a while because the potential benefits are huge—every developer and every project could gain from them. On one project, we had a chance to use them to build a project from scratch. That gave a space to test, fail, learn, and document what worked best.

Out of this, I created a practical guide—a set of best practices I’ve gathered so far. It’s short, straight to the point, and written specifically for developers. Just real tips that improve performance and results. Putting it together wasn’t instant—it took a couple of months of trying, testing, making mistakes, and then writing down what worked.

And the guide isn’t “finished.” It’s a live document—I keep updating it with new experiences and tricks as I learn more.

To make it easy for you to check it out, we’ve added a QR code right here in the article. Scan it, and you’ll get direct access to the document.

Some Lessons Learned

• It is important to understand a model’s capabilities in order to choose the right one.
• It is important to understand a tool’s (like GitHub Copilot) capabilities and limitations.
• Don’t give vague instructions. If you say, “create a viewer,” you’ll get some random viewer. Be specific.
• Always debug the output. Beautiful code might not run as expected.
• Start experimenting whenever possible to build a real understanding of when to use agents—and when to avoid them. No documentation can replace practice.
• Remember security and company policies: only use approved tools, and only when project rules allow it.

Ultimately, I see coding agents as part of the natural evolution of software development. Whether we like it or not, they’re becoming part of our daily work. And soon enough, not using them will feel like trying to build software with pen and paper while others are using modern IDEs.

Final Thoughts

This whole area is rapidly developing, and we need to keep up with it. I’ve taken a couple of courses on AI and coding agents, and I plan to take a few more soon. It helps to see how others approach the same challenges, especially those with more experience.

If you’re curious too, here are a couple of courses I’d personally recommend:

• AI Fluency Framework: Foundations—a great introduction that explains the general mindset and strategies for working effectively with AI. 
• Claude Code in Action—focused on Claude Code as a coding assistant, but, the lessons and approaches apply to working with many other AI tools.

Coding agents will keep improving, and so will the way we work with them. It is a great time to stay curious, keep experimenting, and be ready to adapt. As developers, we can already see how fast things are shifting: what took a whole team before can now be done by just a few people with the right tools. That doesn’t make our work less important; it makes the quality of our thinking and problem-solving even more important. The challenge isn’t just writing code anymore; it’s learning how to guide these new tools and get real value out of them.

In my view, that’s where the opportunity lies. The developers who keep improving, who stay open to change, will shape the future of this industry.

All third-party trademarks belong to their respective owners. For more details, please refer to the Third-Party Trademarks list on the Privacy and legal notices page.