- reading-time:
6-7 min
Agentic Coding with MCP
“Writing code” is more than just writing text. When human engineers work with code, they need a variety of tools to build (a compiler) and verify (several test runners) the software. We can also enable LLMs to run these tools; this offers many benefits. And may introduce huge risks.
In this article, we briefly cover MCP, the protocol that enables agentic AI. But be warned! MCP is extremely powerful,
and —as an LLM has no conscience— it will happily wipe all your work, or worse. More on that in an upcoming
article: “MCP safety”.
Now we focus on how agentic coding fits into the scenery, and how we can speed up engineering by asking LLMs to run
those tools for us.
Automating isn’t new
For years, the software engineering world has been automating itself. Thirty years ago, we used tools like cron for a nightly build. It did run a script to check out a revision, run the compiler via a Makefile, and so on. Gradually, that evolved into the current CI/CD environments. Nowadays, every developer tool runs automatically as set by a configuration file.
So, what’s new with agentic coding? Nothing and Everything!
The same tools are still used. But now the script, aka configuration, is replaced by an LLM. It can start the compiler
or a test tool, etc. and receive the results. As it understands errors and warnings, it can even fix the bug and rerun
some tool with other options. And continue until it decides it is ready.
Again, the basic idea is the same. Better, some will say, since the LLM reacts more flexibly than a traditional
script. Substandard, others will say, as the deterministic script, aka configuration, is replaced by a stochastic
LLM.
Pick your own side; both arguments are legitimate.
Context is relevant
MCP has become the de facto protocol to run all kinds of tools, from searching the web to running developer tools on
your computer. But it started with context.
For example, your LLM may need the docs of a library it wants to use. As it was inconvenient to supply them all
proactively, an alternative reactive way was invented. With MCP, the LLM can request the info it needs by sending a
request to your CodeAI environment (CodeAI-IDE) that uploads it, such that the LLM has all the context it needs.
But MCP is more flexible. It can also ask to search the internet —as the LLM itself has no direct web abilities— by
sending a URL to your CodeAI-IDE, which will load that web page and forward it back to the LLM. Or, more relevant
for CodeAI, read the code, the design document, etc.
There are no limits — also, reading the errors of a compile job gives ‘context’.
Develop & Change
Developing software is more than requesting more ‘context’. We need to change files and run tools. Fortunately, MCP is
flexible: it can run any (non-interactive) tool. Give it a tool to save a text file, and it is able to change code.
In the old CodeAI days, the LLM could also write code — in chat mode. You had to copy it manually into the correct
file. With MCP, that step is automated.
In this way, an LLM can support the programmer. And can –like human programmers– use a huge variety of rigs to handle code.
When you provide a ‘patch’ tool, your LLM will send a patch. But your LLM can also work with a ‘write’ tool — then
it happily sends the complete file. A typical LLM is clever enough to select a tool it can use. Or misuse one, as we
will see later.
Plan & Act
A big change between the initial chat LLMs and ‘agentic AI’ is that it can act. However, there is one important step
in between: ‘planning’. Originally, the chat just continues your story, generating the next (most likely) word, word for
word.
Everybody will remember those examples where the answer started with ‘yes’ and continued arguing it should be ‘no’.
As-if there is no backspace on an LLM.
That changed when ‘reasoning’ was discovered. The key here was a 2-step approach. Instead of sending the question to the
LLM directly, a bit extra is added: “Please don’t answer, but act as a project manager: write a plan on how to solve
it” (and then execute it).
Typically that plan is hidden from the user. When you look into it, however, you will see the same kind of mistakes and
corrections. Still, the answer itself is much better.
The next conceptual step is to use a loop, instead of just 2 steps.
So, we start with a plan, including some ‘reasoning’ on what data and tools are needed. Then the LLM writes text to run
a tool and collects the data. And that repeats.
Again, most of those in-between “chats with itself” are hidden, but in many environments you can see them. Have a look;
it’s fun!
Often, it will describe something like: Maybe I can use tool one, and try it. When it fails, it writes that down,
re-plans, and tries the next one. And keeps “trying” until you run out of tokens or it thinks it is ready. — We all
recognize this loop.
Coding: Engineering or Hacking?
GenAI has made some big steps in a few years. Some people hardly use ‘chats’, which can be seen as a first step. Others
are convinced programming is outdated, as LLMs can write software too.
When you follow headlines, you have seen computers have even mastered the next step: hacking — they can now break
into other systems.
My quest is different, however: Is CodeAI useful as an artificial (software) engineer?
Engineering isn’t only about writing code. It’s also about control, about craftsmanship. It takes years of study and
practice to understand how to construct a complicated machine.
Sometimes, the outcome of an ‘agentic code job’ is amazing. And, at the same time —when we look under the bonnet, as
described above— it feels like a bombshell. When (junior) coworkers behave like that, we call it trial-and-error,
not engineering. And even though I love their enthusiastic, never-give-up mentality, I will plan some sessions to coach
them, to teach them good engineering practices.
I did the same with several CodeAI agents. I failed. They keep responding enthusiastically, promise me improvements and
carry on as usual. Apparently, virtual coworkers have to mature differently.
It’s truly wonderful that LLMs have come so far in a couple of years. More and more, they can take over light coding
jobs —and I’m glad about that.
I’m equally grateful they helped me understand how ‘Agentic’ works and assisted in configuring my lab MCP
environment. Still, it was shocking to read the MCP conversation; the engineering discipline we rely on is fully absent
— they tend to rush to an answer, even with “reasoning”.
A long story short: Yes, it helps. But, for now, I will not swap my deterministic build scripts for the trial-and-error approach of the current agents. Not when we need high-tech, reliable software, not for software in regulated domains, and not when we can’t safeguard it.
See you soon; keep using your own synapses too — ALbert