You’re Not Coding Alone Anymore: Coding in the Age of Agents

You sit down at your desk, coffee in hand. You don’t open your IDE. You type a message: “MCP, draft three architecture options for the new billing feature.” Five minutes later, you’re reviewing tradeoffs between microservices, event-driven, and monolith-plus-queues — with CI configs and test plans included. Welcome to your new morning routine. It seems everyone now has a software agent (not James Bond). Scroll through Twitter or GitHub, and you’ll see examples of developers using agents to fix bugs, open PRs, write tests, and deploy code with minimal human input. The mantra “just prompt it” is evolving into a powerful software development strategy. Yet, among this excitement, we must ask: What does this truly mean for our daily work as developers? The tech industry often inundates us with buzzwords that promise revolutionary changes but rarely deliver. This time, however, the emergence of tools like GitHub Copilot signals a profound shift in software development. We are moving toward a collaborative landscape where we partner with machines to create rather than diligently writing code ourselves. This transformation is not just a trend; it’s a game-changer! What Are We Talking About? (LLMs, MCPs, and Code Agents) Let’s get the terms straight before diving deeper. LLMs (Large Language Models) are where it all starts. Models like GPT-4, Claude, and Gemini are trained on absurd amounts of text and code. They can reason, explain, and spit out surprisingly good answers to tricky technical questions. But here’s the thing: LLMs by themselves don’t build software. They don’t understand your codebase. They don’t hold long-term context. They don’t test, refactor, or ship. They predict the next token based on probability. That’s it. Sure, they can generate a function here or a config file there. But without memory, tooling, or a sense of what they did five minutes ago, they can’t handle real-world development tasks end to end. To build software, you need structure. You need goals, tools with execution rights, orchestration across tasks, memory to keep track of progress, and feedback loops to know if something worked or failed—basically, what every human developer needs. LLMs are the brain. But brains alone don’t build apps — they need hands, tools, and a plan. MCPs – Multi-Agent Code Platforms are where things get interesting. Instead of relying on a single LLM to do everything, you spin up a team of specialized agents. One’s good at debugging, another handles testing, another plans the architecture, and maybe one writes docs all day (the real hero of this squad, honestly). It’s like having your squad of tireless, lightning-fast devs who’ve read every GitHub repo, Stack Overflow thread, and RFC in existence — and who never get tired, distracted, or ask for a coffee break. Anthropic was one of the first to formalize this pattern, showing how multiple agents can work together toward a goal. Now, tools like AutoDev, Devika, and DSPy are implementing that idea. LLMs are the brain. But to build real software, you need more: tools, coordination, and human guidance. Want to build a CRUD app from scratch? You describe it, and the planner agent breaks it into tasks, the implementer writes the code, the tester runs validations, and the reviewer gives you feedback — all in minutes. It’s not just about automation. It’s about coordination, and it’s the key to making LLMs useful in complex dev workflows. And then we’ve got Code Agents — autonomous tools built on LLMs that can get things done. You give them a task like “add authentication to this API,” and they’ll plan, write the code, run some tests, and sometimes even open a pull request for you. We’re already seeing this in tools like: Claude’s Code Interpreter can reason through complex tasks, make edits across files, and explain the changes step by step. GitHub Copilot started as a smart autocomplete but now offers Copilot Workspace, a full planning and coding assistant that walks you through issues and solutions. Cursor (the AI-powered IDE), where you can talk to your repo and ask it to refactor, generate code, or debug with context awareness. These agents don’t just give you snippets — they help you build. You stop writing every line by hand. Instead, you describe the goal, guide the steps, and review the results. You’re not just coding anymore. You’re leading a tiny (and tireless) team. A Developer's New Day You don’t start your day opening your IDE anymore — you ask your MCP to explore a few architecture options for that new feature. It spins up code, runs tests, and lays out the tradeoffs. You pick the best one, give high-level feedback, and let your agents scaffold the project, set up CI, write tests, and even draft the docs. Your job? Guide, refine, and make sure everything makes sense for the product and the domain—and yeah, review the AI’s slop code, too (lol). Tools like AutoDev, GPT Engineer, and Claude Code alread

Mar 29, 2025 - 06:41
 0
You’re Not Coding Alone Anymore: Coding in the Age of Agents

You sit down at your desk, coffee in hand. You don’t open your IDE. You type a message: “MCP, draft three architecture options for the new billing feature.”

Five minutes later, you’re reviewing tradeoffs between microservices, event-driven, and monolith-plus-queues — with CI configs and test plans included.

Welcome to your new morning routine.

It seems everyone now has a software agent (not James Bond). Scroll through Twitter or GitHub, and you’ll see examples of developers using agents to fix bugs, open PRs, write tests, and deploy code with minimal human input. The mantra “just prompt it” is evolving into a powerful software development strategy.

Yet, among this excitement, we must ask: What does this truly mean for our daily work as developers? The tech industry often inundates us with buzzwords that promise revolutionary changes but rarely deliver. This time, however, the emergence of tools like GitHub Copilot signals a profound shift in software development. We are moving toward a collaborative landscape where we partner with machines to create rather than diligently writing code ourselves. This transformation is not just a trend; it’s a game-changer!

What Are We Talking About? (LLMs, MCPs, and Code Agents)

Let’s get the terms straight before diving deeper.

LLMs (Large Language Models) are where it all starts. Models like GPT-4, Claude, and Gemini are trained on absurd amounts of text and code. They can reason, explain, and spit out surprisingly good answers to tricky technical questions.

But here’s the thing: LLMs by themselves don’t build software.

They don’t understand your codebase. They don’t hold long-term context. They don’t test, refactor, or ship. They predict the next token based on probability. That’s it.

Sure, they can generate a function here or a config file there. But without memory, tooling, or a sense of what they did five minutes ago, they can’t handle real-world development tasks end to end.

To build software, you need structure. You need goals, tools with execution rights, orchestration across tasks, memory to keep track of progress, and feedback loops to know if something worked or failed—basically, what every human developer needs.

LLMs are the brain. But brains alone don’t build apps — they need hands, tools, and a plan.

MCPs – Multi-Agent Code Platforms are where things get interesting. Instead of relying on a single LLM to do everything, you spin up a team of specialized agents. One’s good at debugging, another handles testing, another plans the architecture, and maybe one writes docs all day (the real hero of this squad, honestly).

It’s like having your squad of tireless, lightning-fast devs who’ve read every GitHub repo, Stack Overflow thread, and RFC in existence — and who never get tired, distracted, or ask for a coffee break.

Anthropic was one of the first to formalize this pattern, showing how multiple agents can work together toward a goal. Now, tools like AutoDev, Devika, and DSPy are implementing that idea.

A flat-style digital illustration showing a human developer collaborating with multiple floating AI agents. Each agent represents a task—coding, testing, planning—while the developer orchestrates the entire process with calm focus in a futuristic workspace.
LLMs are the brain. But to build real software, you need more: tools, coordination, and human guidance.

Want to build a CRUD app from scratch? You describe it, and the planner agent breaks it into tasks, the implementer writes the code, the tester runs validations, and the reviewer gives you feedback — all in minutes.

It’s not just about automation. It’s about coordination, and it’s the key to making LLMs useful in complex dev workflows.

And then we’ve got Code Agents — autonomous tools built on LLMs that can get things done. You give them a task like “add authentication to this API,” and they’ll plan, write the code, run some tests, and sometimes even open a pull request for you.

We’re already seeing this in tools like:

Claude’s Code Interpreter can reason through complex tasks, make edits across files, and explain the changes step by step.

GitHub Copilot started as a smart autocomplete but now offers Copilot Workspace, a full planning and coding assistant that walks you through issues and solutions.

Cursor (the AI-powered IDE), where you can talk to your repo and ask it to refactor, generate code, or debug with context awareness.

These agents don’t just give you snippets — they help you build. You stop writing every line by hand. Instead, you describe the goal, guide the steps, and review the results.

You’re not just coding anymore. You’re leading a tiny (and tireless) team.

A Developer's New Day

You don’t start your day opening your IDE anymore — you ask your MCP to explore a few architecture options for that new feature. It spins up code, runs tests, and lays out the tradeoffs.
You pick the best one, give high-level feedback, and let your agents scaffold the project, set up CI, write tests, and even draft the docs.
Your job? Guide, refine, and make sure everything makes sense for the product and the domain—and yeah, review the AI’s slop code, too (lol).

Tools like AutoDev, GPT Engineer, and Claude Code already let you describe a system and watch it come to life — with actual code, tests, and configs.

This shift changes how we work:

  • Less typing, more prompting
  • Less linear execution, more orchestration
  • Less firefighting, more design
  • Less solo work, more agent collaboration

But this new workflow needs new skills:

  • Prompting: not just asking, but steering
  • LLMOps: debugging, sandboxing, managing behavior
  • System thinking: less syntax, more strategy

The Revolution That Already Happened

This isn’t just future hype; it’s already happening quickly.

Over 1.3 million developers use GitHub Copilot, which assists with boilerplate code, suggests functions, and saves time on repetitive tasks. Copilot Workspace now includes planning capabilities, such as breaking down issues and guiding implementations.

Claude Code can read and explain entire codebases, aiding in refactoring with detailed explanations resembling pair programming. Devika analyzes repositories, develops solutions, writes code, and creates pull requests, coordinating multiple language models for decision-making.

Cursor allows direct chatting with your code in your IDE, while tools like AutoDev and DSPy enable synchronized workflows with specific roles for planning, implementation, and testing. This shift in software engineering is moving towards agent coordination, focusing on autonomous systems that assist in planning, building, and maintaining software.

A clear pattern is emerging, and a recent survey paper captures it well: software engineering is shifting from code generation to agent coordination. It’s no longer just about typing less while coding; it’s about utilizing autonomous systems that assist in planning, building, and maintaining real software.

This shift isn’t about replacing developers; it’s about providing us with greater leverage.

Not Magic. Not Yet.

LLMs don’t have persistent memory. They hallucinate, lose track of context, and get confused in large codebases.

They’re great at generating a function. But integrating that function into a real system — with legacy databases, side effects, and edge cases — is a different game.

Even when the code looks clean, it’s hard to tell if it’s safe, correct, or maintainable without a deep review.

There’s also risk: overdependence, potential shell access, and slowly forgetting to think through problems yourself.

So yeah, the tools are powerful, but we still need human judgment. It’s not hands-off—it’s just hands-different.

When Vibes Replace Understanding

A digital painting in a semi-realistic style shows a focused developer in a dark hoodie, surrounded by swirling neon energy. The coder appears to be transcending, immersed in a deep flow state as abstract symbols and code fragments float around.
When vibe coding takes over: the dev transcends into flow while the AI does the heavy lifting (bugs included).
When vibe coding takes over: the dev transcends into flow while the AI does the heavy lifting (bugs included).

Or: Why “just prompt it” isn’t always enough.

There’s this new mindset floating around called “vibe coding.” (ref and ref) The idea is simple: describe what you want, the LLM spits some code, and you... ship it. You don’t understand what’s happening under the hood — but hey, the thing runs, right?

And yeah, that’s powerful, especially for beginners, non-devs, or people trying to automate something quickly.

But for professional developers? Here is where things get dangerous.

If you stop understanding the code you’re deploying — if you can’t explain the logic, reason through a bug, or catch a subtle mistake — then you’re no longer building software. You’re just crossing your fingers and hoping the AI knows what it’s doing.

Real example? A junior dev used GPT to generate a “delete user” endpoint. Looked fine. Except it deleted all users from the database because it didn’t validate the user_id. The AI did what it was told — the prompt didn’t cover the edge case.

Another: a dev used Copilot to “secure” an API, adding a JWT check but forgetting to verify the signature. It gave a false sense of security. It worked in staging, broke production, and exposed data.

Here’s what Claude Code generated he asked it to “Add JWT-based auth to this API endpoint”:

app.post('/login', async (req, res) => {
const token = jwt.sign({ userId: user.id }, process.env.JWT_SECRET, { expiresIn: '1h' });
res.json({ token });
});

It’s not bad, but it forgot to verify the signatures on incoming requests. That’s where you (as a developer) come in.

This is the risk when we optimize for speed and vibes over understanding.

Long-term, this can lead to real issues:

Code rot — agents generate code that nobody fully understands or owns.

Debugging turns into archaeology — digging through AI-generated logic to determine what went wrong.

Security risks explode — because “working” isn’t the same as “safe.”

Skill erosion — you slowly lose your edge as a dev by outsourcing the thinking.

Code agents are beneficial. But they need to be treated like junior developers: fast and tireless but in desperate need of supervision.

If you don’t know how to code, you don’t know how to review code. And if you can’t review what the machine gives you, you’re just shipping hope in a CI pipeline, and This is the risk when we optimize for speed and vibes over understanding.

But here’s the twist: while some worry about AI replacing developers, I see the emergence of two new dev niches. On one side, beginners and non-devs are launching new products and prototypes using tools like Claude and Copilot. On the other hand, there’s a rising demand for experienced developers who can step in later to scale, secure, and maintain this type of code or product generated in this way.

Instead of killing jobs, AI is reshaping the field, creating more work for people who can read between the lines of what the machine produces.

Instead of killing jobs, AI is reshaping the field, creating more work for people who can read between the lines of what the machine produces.

Let’s not vibe our way into production disasters.

Myself, 2025

Embracing the Machine Without Losing Ourselves

 friendly digital illustration of a smiling software developer shaking hands with two cheerful humanoid robots, symbolizing collaboration between humans and AI in software development.
_Not man vs. machine — but man with machine. The new dev stack is built on trust, tools, and teamwork.
_

In a previous post, I wrote that we should be friends with our tools. That still holds. LLMs are undoubtedly powerful, but they’re still just tools - just it.

The best developer in this new era will be the one who doesn’t write the most code. It’s the one who can turn a vague idea into a clear, actionable plan that an agent can execute. It’s the one who knows how to review, adapt, and improve what the machine gives back.

Want to get better at this? Start small (but START!)

Try Claude Code for a feature you know well. Refactor a function, fix a bug, or add tests — then review everything it did, as you would with a junior dev.

Use GitHub Copilot like a pair, not a prophet. Let it suggest, but you decide what’s worth keeping.

Explore your repo with Cursor. Ask questions, try a refactor, break stuff on purpose, and see how it handles recovery.

Spin up your LLMs using Ollama and Docker. This video, made by my friend Erick Wendel (whom I had the pleasure of working with), walks through running models like DeepSeek and Gemma locally or in the cloud—super useful if you want to get hands-on and see what’s under the hood.

This will definitely be our workflow from now on: less typing, more thinking, less brute force, more design, collaboration and more machine delegation.

And yeah, this article? It was co-written with the help of a few LLMs. They helped me find papers, structure ideas, and fix clunky phrases. I still made the decisions—they just made it faster.

What about you?

Are you leading your agents — or just vibing through the chaos?

I’d love to hear what tools you’ve tried, what worked (or didn’t), and how you adapt.

What tools are you using? How are you adapting?

Leave a comment, reply, or ping me (you can find me @ kaic.me).

Let’s (always) build something together with this new workflow together!

Subscribe for newsletter to receive new posts and support my work.- https://kaicbento.substack.com/about.

Resources & References

Want to dive deeper? Here’s a mix of tools, demos, and foundational reads worth exploring: