# The Changing Craft of Writing Code in the Age of AI

> How much of writing code have AI tools taken over, and what is left for the developer? A reflection on the shifting craft.

- Published: 2025-11-02
- Category: Journal
- Tags: Araçlar
- Reading time: 3 min read
- Source: https://www.muhammetsafak.com.tr/en/blog/the-changing-craft-of-writing-code-in-the-age-of-ai/
- Language: en-US
- Author: Muhammet Şafak

---
It has been roughly three years since [I first tried an AI coding tool](/en/blog/using-chatgpt-for-the-first-time-as-a-developer/). Back then it was curiosity; today it is an ordinary part of daily work. That span has been long enough to move past the question "do these tools actually work?" and ask something more real: which *part* of writing code have they taken over, and what remains for the developer?

## What has been taken over: production

One thing is clear: the physical production of code has gotten cheaper. Scaffolding a function, writing out a familiar pattern, filling in the repetitive parts of a test — these used to take time; now they do not. I have been doing this job for seventeen years, and I always knew that typing speed was never the real bottleneck. That is now even more obvious.

If a developer's value was "writing code fast," that value has eroded. But for me, it was never there to begin with.

## What remains: judgment

What has not changed — and has actually grown more important — is reasoning. The tool proposes a solution; [deciding whether that solution is the *right* solution](/en/blog/taking-ais-impact-on-coding-seriously/) is still the developer's job. That decision demands three distinct skills:

- **Framing the problem correctly.** The tool answers the question you ask; if you ask the wrong question, you get a flawless but useless answer. The real work is in framing the question right.
- **Auditing the output.** Generated code can be confidently wrong. Reading it, understanding it, stress-testing edge cases — this skill is more critical now than ever before.
- **Seeing the whole.** The tool solves the piece in front of it; seeing how that piece fits into the rest of the system is still a human responsibility.

## The shifting craft

So the craft has not disappeared — it has shifted. In the past, mastery meant fluently translating a solution from thought into code. Now mastery means evaluating a solution, quickly rejecting the bad ones, and fitting the good ones into the larger whole. Less "writing," more "judging."

There is a danger here: reasoning atrophies when it goes unused. If a junior developer hands off all production to the tool, they may never build the foundation needed to audit the output. That is why I still dig into an unfamiliar topic myself before asking the tool. I use it as an accelerator, not a replacement.

## Where the tool looks safest may be where it is most wrong

There is a pattern I have noticed in recent months: the more confident the tool looks, the more carefully I need to watch. Common patterns — a REST endpoint, form validation, a database query — it writes solidly. But if the problem has something distinctive about it, the tool produces a "standard" solution without noticing, and the standard solution answers a question you never asked.

Last month, a suggested currency-conversion function managed decimal precision with float arithmetic. It would have worked fine on small amounts; on large amounts, rounding errors would accumulate and produce incorrect results. The tool had written it in a way that looked safe; catching it required prior experience in that domain.

This points to something essential for keeping the relationship with the tool healthy: maintaining critical distance. No matter how good the tool becomes, validating its output remains the developer's non-negotiable responsibility. "The tool wrote it, so it must be correct" is the mindset that neutralizes years of experience faster than anything else.

## Conclusion

AI has not ended the act of writing code — it has made the *valuable part* of writing code more visible. That part has always been judgment: deciding what to build, why to build it, and whether it has been built correctly. As production gets cheaper, judgment gets more expensive. That is exactly where I intend to keep investing as a developer.