This content originally appeared on HackerNoon and was authored by Ryan
Have you ever watched an LLM write code? It can feel like it is reciting the answer rather than working through the problem. Don't get me wrong, what AI agents can produce is mind-blowing. But I still write better code, unfortunately, at a much slower rate. That leaves us with the classic trade-off: quality vs speed.
\n But I want more. Is it too much to ask for both?
\
Coding agents train on answers, repositories and git commits. But software engineering is a process. For coding agents to become software engineers, they need to train on the process. They need to see experiments, reversals, cleanups and the decisions that connect them.
\n The key point is that software engineering is not the act of producing source code. It is the process of changing a system while validating against reality. Writing a scientific paper is not the same as doing science. In the same way, writing code is not the same as doing software engineering. The solution matters, but the process is where the discipline lives.
\n Around a year ago, I watched Andrej Karpathy's video "Deep Dive into LLMs like ChatGPT".
https://www.youtube.com/watch?v=7xTGNNLPyMI&embedable=true
In that video, there is a chapter called "models need tokens to think". He uses a math problem to make the point. The model is more likely to get the correct answer if it breaks the problem down first. This gets at what feels wrong when an agent produces code top to bottom. The issue is not only that the model needs more tokens. Software engineering needs real feedback. A failing test, a compiler error or an unexpected API response can all change what you do next. By working in small steps, developers use the code to assist their thinking. When an agent takes large steps, it misses out on this thinking.
\n Another way to say this is that software engineering is a feedback loop. You take a small step, test against reality, update your understanding, and take the next step. The more frequent that loop is, the more efficient you are, but also the closer you stay to the path you need to be on.
\n I used to work on a large frontend application where every change caused the whole app to reload. Then I had to navigate back through the application to the exact state to see the result of my change. That was a terrible feedback loop. It was clunky and slow and took focus away from the task at hand.
\n Coding agents need to train on process artefacts. Artefacts that show the software engineering process. The thinking, exploration and testing that goes into producing good software. It is like when your math teacher was forever nagging you to show your work. That's what coding agents need to see.
\n For example, let's say I'm implementing a feature that uses an unfamiliar API. I don't read the documentation and assume I have everything I need. Trusting documentation to that extent will bite you very fast. I sneak up on it. First I'll make sure I can authenticate, then I'll make a request and check the output, and so on. The code I'm writing to explore the API may not make it into the final code. Hell, I might use a different language altogether.
\n Another example is when I'm trying to work out the shape of a change, I'll start in pseudocode. First, I write a function signature and a few high-level comments. Then I make another pass, adding more detail to those comments. I call functions that do not exist yet. I use libraries I haven't imported yet. I change the signature when I notice a missing input. Sometimes I realise I am on the wrong track, delete the whole thing, and find a simpler path. Each pass adds detail and fills the solution in.
\n The last example I'll give is test-driven development. Red, green, refactor. Make the tests fail, then make the tests pass, then refactor if necessary. Keeping each step small, but meaningful. Each iteration narrows the system's behaviour. However, if you only look at the final artefact, it looks like code with a test suite. That misses the sequence of constraints and decisions that shaped the implementation.
\n Have a go at teaching a coding agent test-driven development. It is funny, and a little painful. When I tried, I had to keep it on a short leash, otherwise it would try to do too much in a single pass. I started telling it to be maliciously compliant in making the test pass. Do the absolute minimum, and only write the code that the test forced it to write. But then it started adding targeted conditional blocks that returned the expected answer. After a few loops, it would decide it was time to refactor and then smuggle the real implementation in. I can't blame the model too much for struggling with TDD. I struggle not to jump ahead too.
\ The next question is whether this is solvable with a skill, a prompt, or an agent workflow. Does the process need training? When I tried to steer the agent into TDD, I felt like I was pushing against its default behaviour. It was an uphill battle, and I don't think I won. It followed the instruction but not the discipline.
\n Skills and workflows can help. I have had some success getting agents to do TDD by giving them large example transcripts. But the size of those examples is revealing. An Advent of Code exercise done with TDD produced a transcript that was around 30k tokens, and that is one example of one process. That's a big chunk of context before you even get started.
\n We can't teach every software engineering process through a skill-stuffed with examples. At some point, the process itself has to become part of the training data. That means capturing more than the final pull request. We need high-quality training data showing the software engineering process.
\n On the surface, coding agents have already learned to produce impressive solutions. If you scratch a little deeper, though, the code will give you nightmares. The next step for coding agents is to follow good software engineering practices.
This content originally appeared on HackerNoon and was authored by Ryan
Ryan | Sciencx (2026-06-23T10:50:49+00:00) Claude Is Not a Software Engineer. Retrieved from https://www.scien.cx/2026/06/23/claude-is-not-a-software-engineer/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.