A Web Developer’s Day with an AI Agent

The first real push to dive into Copilot fully came from a talk at FrontKon 2025 in Brno. It made me stop seeing AI as a curiosity and start treating it as part of everyday work.

Morning: Teams, code review, and getting started

My day starts pretty classically: a quick check of Teams and email, replies to messages. Then straight into code review of colleagues’ changes. That’s where I found that Copilot helps even with things I used to handle purely on my own. It quickly understands the context of changes, suggests a comment, and occasionally flags a potential issue I’d easily have missed.

Then comes the actual work: a new feature or a bug. And this is where Copilot really kicks in. You know that feeling when you have an empty file and don’t know where to start? Copilot helps me get past that first blank-page paralysis: it suggests a component structure in an Nx monorepo, generates a service skeleton, prepares the initial boilerplate. I don’t have to start from scratch, and I can focus right away on what matters: architecture, UX, and concrete decisions.

One metaphor captures it well: AI is like a junior on the team. It helps get things rolling, speeds up the start, but doesn’t own the final solution. That responsibility stays with me.

Late morning: Copilot as a coding partner

Where does Copilot genuinely save time? Practically everything that’s part of my Angular workflow:

• Standalone components, services, pipes: it generates the base, I refine the details.
• Signals and RxJS patterns: it handles newer Angular patterns surprisingly well.
• Refactoring existing code: even in an Nx monorepo it can propose a cleaner variant.
• Writing Vitest tests: I write tests continuously, but it’s also an area where we want to invest more. Copilot significantly lowers the barrier here, the mechanical grind of writing tests stops being a reason to put them off.
• Analysis and planning: I use Copilot Chat as a thinking partner for working through solutions before the actual implementation.

Copilot isn’t just for completing a line of code — it covers the entire workflow from planning through implementation to the commit message. The more context I give it, the better the result. One simple rule holds: the more precise the prompt with a clear specification of what I want, what the context is, and what I expect as output, the less time I spend fixing things afterward.

Workflow for larger features: from idea to review

For larger features I’ve developed a concrete process that has significantly improved my results:

1. Planning: I switch Copilot into planning mode. It actively asks clarifying questions: what exactly do I want, what’s the context, what are the constraints. The result is a structured implementation plan that I review and adjust before giving the green light.
2. Implementation: Once I’m happy with the plan, I let Copilot start coding. Because of the earlier planning it has enough context and the result is noticeably better than if I’d sent it straight to coding.
3. Testing: I manually test the new functionality. Any issues I work through directly with Copilot in the same session.
4. Code review in a new session: After finishing the implementation I open a new session and have Copilot review its own changes. A new session means a fresh perspective without the context of the original development, so Copilot evaluates the code more objectively and regularly catches things it would have missed in the original session.
5. Iteration: If the review surfaces weaknesses, the cycle repeats: fix, test again, review again in a clean session.

This approach showed me that AI works best as a series of focused steps, not as one big “just do it for me.” Splitting into planning, implementation, and independent review dramatically raises the quality of the output.

Afternoon: standup, analysis, and where AI hits its limits

After lunch comes standup, then either continuing the morning’s work or analysing a new problem. And this is where moments appear when AI stops being a smooth partner.

I maintain several repositories: shared Angular components, one large legacy frontend with an older codebase and technical debt, and three newer projects. It’s precisely with that legacy code that Copilot runs into trouble: it leans on existing code. If that code is full of outdated Angular patterns, the agent picks them up and propagates them further. The output looks correct at first glance but uses patterns we abandoned long ago.

The solution I gradually arrived at is a three-step approach:

1. AGENTS.md and custom SKILLS: AGENTS.md is the foundation where I define conventions, style, and what the agent should not do. But it isn’t enough on its own. Equally important is defining custom SKILLS: pre-prepared prompts for recurring tasks such as code review, writing tests, refactoring, or generating documentation. Instead of composing a prompt from scratch every time, I have ready-made templates I can trigger with a single command. It saves time and ensures consistent output across the whole team.
2. Knowledge base: I have the agent generate a structured overview of modern Angular (standalone, Signals, the latest API, correct patterns).
3. Custom MCP server: from that document I build an MCP server that attaches to every prompt as context. The agent then always knows what modern Angular looks like and stops copying legacy patterns.

And then there are the classic risks you’re probably familiar with:

• Hallucinations: the code looks correct but doesn’t work. AI writes it confidently, as though everything is fine.
• Outdated patterns: especially without the right context, it generates code that would have passed code review three years ago.
• False confidence: AI answers convincingly even when it’s wrong. And that’s dangerous once someone stops checking.

That’s why critical thinking, code review, and the developer as the final responsible party remain essential. AI is a partner, not an autopilot.

End of day: from code to merge request

The end of the day often belongs to preparing the merge request. Here too Copilot helps: it summarises changes, suggests an MR description, and makes it easier for colleagues to review. That speeds up not just the implementation but also team communication. A well-prepared MR improves the review process and reduces friction, and in practice that’s often just as valuable as the code itself.

How is my role changing? Less “writing code from scratch by hand,” more “directing, prompting, reviewing.” And with that comes a new skill: clearly specifying the problem is just as valuable as knowing how to solve it.

Key takeaways

Six months with Copilot taught me a few things:

• AI saves time on routine work, not on decisions. Where I need to think, it won’t help.
• It’s best as a collaborator, not an autopilot. Collaboration works; blind copying doesn’t.
• Without oversight it doesn’t work. Whoever doesn’t read the output risks hallucinations and outdated code.
• Context is everything. AGENTS.md, custom SKILLS as pre-prepared prompts, and an MCP server as a knowledge base dramatically improve output quality.

I’ve made the journey from ChatGPT for general questions to Copilot right inside VS Code for the entire workflow. What’s the next step? I want to try Copilot CLI and see what it offers outside the editor. I’d also like to define custom agents and experiment with a multi-agent workflow where several specialised agents collaborate on a single task.

Give it a try yourself, but approach it thoughtfully. Set up your AGENTS.md, define custom SKILLS for recurring tasks, experiment with your own MCP server as a context layer, and never stop thinking about what AI is actually giving you.

Inspired by a talk from FrontKon 2025.