--- title: "When AI Writes Code Faster, Is Programming Still a Creative Craft?" url: https://www.thinnd.site/en/reflections/are-developers-still-creative-when-ai-writes-faster/ language: en author: "Nhu Duy Thin (Thinnd)" published: 2026-10-29 updated: 2026-10-29 section: "Reflections" tags: ["reflection", "creativity", "craft", "AI", "programming", "career"] summary: "Yes, but the creative part moves. When writing code gets cheap, the hard-to-replace work is finding a problem worth solving, choosing a direction and accepting trade-offs, verifying results, and caring for the system and the people around it. The risk is real: if you hand over all the writing you may lose the ability to judge what AI produces (a small Anthropic trial found the AI group scored about 50% on a quiz against about 67% for those who wrote by hand). To keep the craft, sketch your own idea first, read as a grader, practice deleting, and make small things for fun." license: "Cite with the author name and the canonical URL above." --- # When AI Writes Code Faster, Is Programming Still a Creative Craft? > This is a **reflection**: I argue and ask questions, it is not a research report. I mark which parts are figures I cite and which are my own opinion. > > Many figures are self-reported surveys or published by vendors, so read them with care. The carpenter is my own comparison, to make things easy to picture. --- ## Quick summary - My short answer: **still creative, but the creative part moves**, from "typing code" to "choosing the work, choosing the direction and answering for the result". - I split a developer's work into **five layers**: finding the problem, shaping the solution, writing code, verifying, caring. AI is taking over the third layer most strongly. - When producing options is cheap, **what becomes precious is taste and the ability to choose**, not typing speed. - There is a **real risk**: handing over all the writing may cost you the ability to judge what AI makes. A small trial shows signs of it. - You can **keep the craft on purpose** with a few small habits, and one question to measure yourself each week. --- ## Hard words, plain meaning | Term | Plain meaning | |---|---| | **Craft** | The skill of making something good with your own hands and attention, built through practice. | | **Taste** | The ability to tell what is good from what is merely acceptable, among many options. | | **Trade-off** | Choosing one thing means losing on another, for example faster but harder to maintain. | | **Flow** | Being absorbed in work without interruption. | | **Deskilling** | Doing less of something and gradually losing the ability to do it. | | **Self-reported** | Numbers from what people say they feel, not directly measured. | --- ## 1. The picture: a carpenter and a power saw Imagine a carpenter's workshop long ago. Every plank is cut by hand. Then the power saw arrives. Does carpentry die? I think not, but it **moves where skill sits**. The carpenter spends less effort cutting and more on design, on joints, on finishing. At the same time something truly disappears: **the feel of the hands while sawing**, and for some people that was the joy of the craft. This picture helps me ask the question precisely. Do not ask "will AI take creativity", ask: **where is skill moving to, and what am I losing at the same time?** The picture also has limits: a power saw does not "decide" what table to make, while AI can propose the design too. So do not apply it mechanically. --- ## 2. Five layers of a developer's work When we say "writing code" we often lump many jobs into one. I separate five layers: | Layer | Work | How far AI helps today (my opinion) | |---|---|---| | **1. Finding the problem** | Understanding what users need, which problem is worth solving | Helps summarize and suggest questions. Deciding which problem is worth it, little | | **2. Shaping the solution** | Design, choosing trade-offs, deciding what to drop | Proposes options. Answering for the choice, no | | **3. Writing code** | Turning the design into a program | **Strongest**, especially repetitive and well-defined parts | | **4. Verifying** | Reading, testing, debugging, knowing when it is "right" | Can assist, but tends toward overconfidence | | **5. Caring** | Maintenance, working with people, long-term responsibility | Helps with small chores | This table is **my opinion**, not a measurement. But it shows one thing: when layer three gets cheap, **the other four do not vanish, they become more important**. --- ## 3. Taste and selection become precious When writing one option takes a week, you only have a few to choose from. When AI writes one in minutes, you can have ten. Then the scarce thing is **the ability to look at ten and recognize which deserves to stay**. To me this is the most creative part of the craft, and it needs **taste**, which only comes from having made things, broken them and fixed them. An old story illustrates it: in early 1982, an engineer at Apple, as the story goes, replaced a piece of graphics code with a simpler algorithm, about six times faster and about 2,000 lines shorter, and wrote minus 2000 lines on a productivity report. The anecdote is retold through several sources, so do not treat each detail as exact, but it reminds us that **creativity in code often lies in taking away**, all the more true when producing code is nearly free. The post [Do not measure productivity by lines of code](https://www.thinnd.site/en/product-thinking/dont-measure-productivity-by-lines-of-code/) goes into it. --- ## 4. What the figures say about enjoyment and how the work feels There are a few pieces of data, and they **do not point the same way**. - **Enjoyment and focus (GitHub, self-reported).** GitHub's research on Copilot found 87% of users said the tool helped preserve mental effort on repetitive tasks and 73% said it helped them stay in flow. A group of 60 to 75% said they felt more fulfilled and less frustrated when coding. This is a self-reported survey by the toolmaker itself, not a direct measurement. - **What makes developers satisfied (Stack Overflow 2025).** According to summaries of the survey, the top factors are autonomy and trust, competitive pay and solving real problems, while AI integration ranks low. The share of "happy" developers rose slightly from last year (24% versus 20%) but is still low. I rely on summaries and have not read each question of the original survey. - **Worry about jobs.** Also per the summaries, 64% of developers do not see AI as a threat to their jobs, down from 68% a year earlier. Read together, I take away one cautious idea: **AI may remove some drudgery, but many people's joy in the work comes from autonomy and solving real problems**, and those sit in layers 1, 2 and 5. If AI only trims layer three without giving you more autonomy in the others, enjoyment may not rise. --- ## 5. The risk: losing the ability to judge what you no longer do This is the part I worry about most. **To choose well, you must have made things.** Someone who has never debugged on their own struggles to notice when AI debugs wrongly. Anthropic published (January 2026) a randomized trial of 52 programmers, mostly early-career, learning an unfamiliar Python library. The AI group scored about 50% on a knowledge quiz and the hand-coding group about 67%, with the largest gap on debugging questions. The sample is small (26 per group), and I have read the summary, not the full paper. Another study, by METR (July 2025), with 16 experienced developers doing 246 real tasks, found them **about 19% slower** with early-2025 AI tools even though they believed they were about 20% faster. The tools have changed a lot since, but it is a reminder that **how well we feel we are doing and how well we are doing can differ**. Beyond these are two worries I have no data to assert, so I offer them as **hypotheses**: (1) if everyone accepts the first option AI gives, products may slowly resemble each other; (2) if learning the craft skips the "make it yourself" part, the next generation may lack people with enough taste to review. --- ## 6. The bigger picture: AI as an amplifier Google's DORA 2025 report reaches a conclusion that fits this story: AI is mainly **an amplifier**. It strengthens the strengths of good organizations and exposes the weaknesses of disorderly ones. According to the report, big returns come not from the tools alone but from the quality of platforms, the clarity of workflows and team alignment. (I rely on summaries and have not read the whole report.) Applied to the craft: AI may also **amplify how you practice your craft**. People with taste and a habit of verifying will go faster. People without may produce many things that look fine without knowing which ones are broken. --- ## 7. Five habits for keeping the craft *These are my suggestions, not tested on many people.* 1. **Sketch the idea before asking.** Spend 15 minutes drawing or writing your own design. Then compare it with what AI proposes. 2. **Read as a grader.** Do not just run it. Ask "why this way, what is missing, who will maintain it". 3. **Practice deleting.** Each week find a piece of code you can remove or simplify. Creativity often lies in having less. 4. **Keep a stretch of time without AI.** To train your hands, and to know what you can still do. 5. **Make small things for fun.** A small tool for yourself, not for a KPI. Joy in the craft needs feeding. If you are new to the field, the [12-month plan for freshers](https://www.thinnd.site/en/journeys/fresher-ai-era-12-month-plan/) makes the write-first habit concrete. And [Why you should not trust AI blindly](https://www.thinnd.site/en/engineering/why-not-to-trust-ai-blindly/) explains why verifying matters. --- ## 8. One question to measure yourself each week > **This week, how many decisions did I make that AI could not have made for me?** By decisions I mean choices someone answers for: which problem to do first, which feature to drop, which trade-off to accept, which request to say "no" to. If the number keeps falling, you may be sliding from a creative craft into a job of reviewing and clicking "accept". If it rises, AI may be freeing you for the more interesting parts. --- ## 9. A balanced view - **This is a reflection, not a conclusion.** The five layers and the habits are my opinion. - **The data is thin and mixed.** Most is self-reported or vendor-published, research samples are small, and tools change very fast. - **Some people will truly lose something.** For some, the joy is writing code line by line. If that part shrinks, the regret is legitimate, and I do not want to brush it aside with "the craft just moves". - **The carpenter picture has limits.** AI is not only a hand tool, it can also propose the design. - **I do not know the future.** AI may get good at layers 1 and 2 as well. Then the question must be asked again. --- ## 10. Conclusion Developers are still in a creative craft when AI writes code faster, **if they keep hold of their creative part**: choosing the problem, shaping the solution, verifying with taste and answering for the result. The risk is that you slide into being the one who clicks accept. A power saw did not take carpentry away, but a carpenter who no longer trains their hands will struggle to design something worth making. A small step today: this week, before asking AI for a task, write three lines on how you would do it. Then compare. --- ## References - [GitHub: Research, quantifying GitHub Copilot's impact on developer productivity and happiness](https://github.blog/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/) - [Stack Overflow Developer Survey 2025, AI section](https://survey.stackoverflow.co/2025/ai) - [Anthropic: AI assistance and coding skills (January 2026)](https://www.anthropic.com/research/AI-assistance-coding-skills) - [Simon Willison on the METR productivity study](https://simonwillison.net/2025/Jul/12/ai-open-source-productivity/) - [DORA 2025: State of AI-assisted Software Development](https://research.google/pubs/dora-2025-state-of-ai-assisted-software-development-report/) - [Negative 2000 Lines Of Code, folklore.org](https://www.folklore.org/Negative_2000_Lines_Of_Code.html) - Related posts in this blog: [Do not measure productivity by lines of code](https://www.thinnd.site/en/product-thinking/dont-measure-productivity-by-lines-of-code/), [Fresher in the AI era: a 12-month plan to become a junior](https://www.thinnd.site/en/journeys/fresher-ai-era-12-month-plan/), [Why you should not trust AI blindly](https://www.thinnd.site/en/engineering/why-not-to-trust-ai-blindly/)