When Knowing How to Code Is Not Enough

Being a good programmer doesn't make you good at managing agents.

•7 min read
When Knowing How to Code Is Not Enough

Disney’s 1940s cautionary tale on how NOT to instruct an agent.

For a lot of people AI assisted coding is basically fancy autocomplete. Understandable. Copilot was some point the biggest AI product ever. Most devs had their first exposure to AI-assisted coding with that. And we all know that’s not that incredible as a product. You’re saving a lot of keystrokes, that’s for sure. But it doesn’t fundamentally move the needle.

Then, at some point circa 2024 people started talking about coding agents and maybe you tried it again. “Ok… that’s cute, I guess”. But you could still argue that it removes the “craft” from coding, or that it could stil not handle the complexity of a bigger codebase. That’s also a fair take.

Nonetheless, I’m here to tell you that if you think agentic coding isn’t happening, it is likely because you have not seen what is currently possible or you lack a bit of imagination.

The engineer’s actual job

We need to be honest about why we are on the payroll. You are not hired type code. You’re hired to contribute to the bottom line using technical skills. Software is simply a means to an end.

I mean, I know that can sound awfully dark and sad from an IC POV. I have to say that I got into this because I love coding. I like looking at it. I’ve spent countless hours writing the same thing in different ways and deciding what feels best. What looks more elegant as a solution. The good old 100% pure, old-fashioned, homegrown human handcrafted code.

But I also have two eyes. And I’d wager that if you’ve given cursor or claude-code (these are the most popular) an honest try by now (late 2025), you’re convinced they’re good enough for a LOT of things. And that set of things is not decreasing.

Gatekeeping, Changes and Pragmatism

In my first semester at Uni I learned basic C. Mallocs, pointer arithmetic, manual memory management. Next semester: Java and Python. Oh, you don’t need to do that anymore?

But then, the online forums were full of people saying that garbage collection created freezes and lead to memory leaks and that software was getting slow and bloated. Real programmers managed their own memory. But we know how that played out. Eventually, CPU cycles became cheaper than developer hours and soon enough we had enough CPU to spare.

I’m not here to tell you we’re losing our jobs or that hand written code is going away, but we need to be aware of what’s up. If you can contribute to the bototm line without manually writing every line, you’re still doing your job. In fact, in some cases you might be doing it better.

The bottom line is that this shift opens up massive opportunities. Look at some of the internal tools at your company. They are probably terrible. You know that. Think about the friction caused by bad internal software or the recurrent tasks that eat up your week.

Previously, you might not have justified the time to build a tool to fix these flows. With agents, the cost of writing software for these “small” problems drops to near zero. You can improve workflows and automate the mundane work that gets in the way of the interesting engineering problems. And in some cases it will let start coding in a higher abstraction level.

There are places where you don’t want that and I could make an argument for where that’s the case. This is not the point of this article though, so I won’t go there.

Context engineering

I know a lot of good programmers with years of experience who are still unsure how LLMs can actually build useful code.

The thing is that being a great coder does not automatically make you good at agentic coding.

Getting results from an agent requires a different set of muscles. Some people call this context engineering. It is a mix of technical understanding and being able to codify that into the LLMs workflow. You have to take the mental model inside your brain when approaching a specific project and put it onto paper markdown effectively (and timely). And for that you need to be aware of the constraints and of some of its internals.

You cannot just let an agent loose on a repo and hope for the best. You need to build guardrails. Ideally, you have to instrument the agent for your specific codebase and your specific workflows.

Tools like Claude Code work well because they have heavy instrumentation built on top of it. It’s more than just the model. So to get the most out of an LLM in a codebase, you often need to build your own harness on top of that foundation. You need to customize how it interacts with your environment to mitigate damage and ensure it behaves as you expect it. Things like commands, skills, rules, subagents and concious context window management make a huge difference in the quality of results.

The problem is that this requires actual effort. It’s not free. Coding, as you may know, is something very personal. You pick 10 devs and look at how they code and you’ll likely find 10 different workflows. And it’s the same thing with agentic coding. You’ll likely have to build your workflow preferences into the agent before it you start trusting it, and that will require a LOT of trial and error.

Getting on the train

We are still in the phase where we are figuring this out as we go. There are no standard textbooks on context engineering yet. The industry is still settling on the patterns and it seems every other week someone comes up with a different .md file you have to manage.

But I recommend you gradually start incorporating the new agentic features I mentioned before as you learn how to use the agents. Build something and see how far you get. Give it a go.

Because, to me, the direction is clear. The ability to instrument agents and build high-quality context is just as important, in this new way of coding, as knowing the syntax of the language itself.

Where to go from here?

I find that you can learn a lot by understanding the mental model of the people that actually build the agent harness, then you can distill some of those ideas into your workflow. Some of interesting links:

Conclusion

If you approach this topic like a curious engineer approaches any other tech I think you may find out that there’s a LOT of engineering involved in getting the best out of it. This non deterministic coding is definetly challenging and has many quirks, but can also be incredibly fun to do when you looked at from the right angle.

I’ll share some of personal workflows in another article. Cheers!

#ai#agentic-coding#claude-code#tools