The Developer as Guide, Editor, and Owner
You’re reading part 2 of a three-part essay. I believe it has never been more exciting to be a software developer than it is right now — and this series explores why.
I usually agree with and admire the work of Nassim Nicholas Taleb. I am not sure Taleb had software development in mind for this quote: “VERDICT ON ChatGPT. It is ONLY useable if you know the subject very, very well. It makes embarrassing mistakes that only a connoisseur can detect.”^3 But this is exactly how I feel about the use of AI for software development.
The reality is that: most software developers do not write rocket-science code. We write a lot of boilerplate and repetitive code, which AI can produce faster than we can — so let it do that. That lets me spend more time with the business, so I can better understand the domain, concerns, and requirements.
If AI can write most of the code, what is my role then? LLMs make money by generating tokens. I often find that the generated code can be simplified, so some yak-shaving is required to get high-quality code.
From time to time, I hear the argument that code agents produce code of higher quality than humans. But LLMs are trained on code with errors, flaws, and technical debt — so how can they be so much better than humans when it is humans that instruct them?
When working with AI, I often generate a plan together with it before the agent executes the plan and writes code. This makes me a guide. I consider most code generated by AI to be a first draft, which makes me an editor.
Looking ahead, my future role remains uncertain, but I find the pilot-autopilot analogy compelling: it requires years of training to become a pilot, and yet most planes are flown by autopilots.
Vibe coding. I have mixed feelings about this concept — perhaps I’m comfortable with it for fast prototyping and exploring new ideas, but not beyond that. The key question is: who owns the code, you or the AI agent? I prefer to be responsible for the code. Currently, I work in an environment where I would not be comfortable having an agent own complex enterprise business logic encoded in software. In that scenario, I would be trading speed for deep knowledge (not to be confused with mere information). Code agents still sometimes get confused and give up. Would I be able to fix a critical bug in a larger codebase that I’ve never seen before? Maybe. For now, I’m not ready to take that bet.
And the reason isn’t just risk management — it’s that programming is more than producing code. It’s about building and maintaining understanding.
Disclaimer: I wrote the text and Gemini Nano Banana generated the background image.
3: https://x.com/nntaleb/status/1759234709949710753
Edit page on GitHub. Please help me to improve the blog by fixing mistakes on GitHub. This link will take you directly to this page in our GitHub repository.
There are more posts on the front page.
Content of this blog by Carsten Jørgensen is licensed under a Creative Commons Attribution 4.0 International License.