A lot of developers are quietly asking the same question now:
“If AI can write code, do I still need to learn programming?”
It is a fair question...
For further actions, you may consider blocking this person and/or reporting abuse
The "AI can solve the wrong problem beautifully" line is the one worth pulling out, because it names a failure mode that's invisible to syntax review, and that's the actual shift in what developers have to catch.
The "taste as superpower" section reads honest, and I'd push one floor under it: how do you know your taste is calibrated rather than just your taste? Self-trained intuition plus AI output produces the same single-party authorship problem the post is warning about elsewhere: the agent generates something, the developer judges it good or bad, both pieces come from the same loop. Without external authors of the judgment (a peer who hasn't seen the design yet, a customer with skin in the outcome, a public timestamp the work has to survive against), "taste" becomes "I think this looks good, and I'm the one who decides what good means."
The "review, test, question, and improve" framing is the operator-side audit discipline this domain doesn't have shared vocabulary for yet, and the absence of a name is part of why it's hard to teach. Naming it is half the work.
This is such a good point, especially the part about taste needing calibration.
I completely agree. Maybe I should have expanded that section more because “taste” should not mean “I personally like this.” That can easily become another echo chamber where the AI generates, I approve, and we both miss the actual user problem.
Real taste probably comes from exposure and feedback loops. Seeing great products, understanding why certain decisions work, getting feedback from other developers, watching real users struggle or succeed with what you built, and allowing your assumptions to be challenged.
And I love your point about “AI can solve the wrong problem beautifully.” That’s exactly the scary part. The output can look professional, the code can look clean, the UI can look polished, but the direction can still be completely wrong.
I think this review layer you mentioned is going to become one of the biggest skills developers need. We have names for writing code, testing code, reviewing code, but we don’t really have a mature vocabulary yet for auditing AI collaboration itself.
Maybe that becomes one of the next important engineering disciplines.
The vocabulary gap is the real tell. Code review, QA, threat modeling. They all assume the problem definition is already locked. What you're describing is one level up: catching misaligned problem statements before they get beautifully executed.
That is a different discipline. Most engineering orgs haven't felt the failure mode at scale yet, so they haven't named it. The output looked right. The code was clean. The user still didn't want it.
Your point about taste is worth sharpening. Feedback loops calibrate taste, but only if they feed back on decisions, not just outcomes. Watching users struggle tells you the output was wrong. Reconstructing why the direction was chosen is what actually trains the muscle.
What you're circling is closer to architectural review than code review. Except the artifact being reviewed is the problem statement, not the implementation. And most teams don't even write that artifact down.
Exactly. I think you captured something I didn’t fully put into words in the article.
We have spent years building processes around validating the implementation, but not enough around validating the thinking that produced the implementation.
And AI makes that gap much more obvious because execution is becoming cheaper and faster. You can go from idea to working feature so quickly now that the dangerous part is no longer just “can we build it?” but “should this be built this way?”
I really like the point about feedback loops needing to feed back on decisions, not just outcomes. It is easy to look at a failed feature and say “users didn’t like it.” The harder and more valuable question is “what assumptions made us believe this was the right solution?”
Maybe that is the missing artifact in AI-assisted development. Not just documenting the architecture and the code, but documenting the reasoning behind decisions.
Because if AI can help us produce faster, we probably need to become much better at questioning what we are producing.
The reasoning artifact is real, and it has a harder constraint than most people expect.
Documenting why you made a decision is useful. But if the same person who made the decision is also the one who writes it down, you've captured their rationalization, not their reasoning. The artifact looks like a second view. It isn't one.
The version that actually works has to be written in a form someone outside the original context can challenge. Not just "here is why we chose this," but "here is what would have to be true for this to be wrong." That second sentence is the part that gets skipped.
AI speeds up the execution side. If it's also doing the documentation, you're compressing two loops that need to stay separate. You get a polished record of a decision made in one perspective, reviewed in the same perspective. Which is close to no review at all.
This is a really important distinction.
I think the line between documenting reasoning and documenting justification is where a lot of this breaks.
A decision document that only says “we chose this because...” can easily become a polished explanation of a decision we were already emotionally committed to.
The more useful version is probably closer to exposing assumptions:
That gives someone else something to challenge.
And your point about AI compressing both loops is interesting. Using AI to help organize thoughts is useful, but if the same context creates the decision, validates the decision, and documents the decision, we haven't really introduced a different perspective.
Maybe the skill developers need to build is not just prompting AI to produce better answers, but learning how to create systems that force better questions.
Because faster execution without better questioning just means we can confidently build the wrong thing faster.
Yeah it's a shift in emphasis, but if you don't learn the basics then how are you supposed to guide the AI agent and check its output, pretty obvious that it's still important ...
P.S. what is it with the writing style of many articles on dev.to nowadays? Apparently it's no longer in vogue to write paragraphs of multiple sentences expressing a certain thought - instead what I see a lot is this staccato style, with short sentences, each sitting on a line of their own - sort of like a bullet list without the bullets ...
Not saying that the contents are bad because of it, or the argumentation less valid, it's just something I noticed recently ... impact of AI assistance on writing?
I think we're actually saying the same thing though.
My goal wasn't to argue that developers shouldn't learn the basics. Quite the opposite. I think a solid understanding of at least one language is even more valuable now because it allows you to guide AI instead of just accepting whatever it generates.
The point I was trying to make is that the emphasis has shifted. Just a few years ago, spending weeks memorizing syntax was a much bigger part of becoming a developer. Today, AI can help with syntax, but it can't replace understanding how systems work, how to debug, how to reason about edge cases, or how to decide whether the generated solution is actually the right one.
As for the writing style, that's a fair observation. I'd say AI has probably influenced it to some extent. That said, I also intentionally prefer this style because it's easier to scan. A lot of people read dev.to on their phones or during short breaks, so shorter paragraphs help reduce visual fatigue and make it easier to follow the ideas. That said, I do enjoy longer-form writing too. Different formats suit different audiences, and it's good to have both.
Thanks for your comment.
Completely agree on all accounts, points well made - the writing style is just something I noticed lately, I thought that maybe it was an AI thing, but I see your point and I agree that it's easy to read!
Yes definitely everyone must know every basic knowledge of coding and proper command on one programming language because when a bug occur in the code your ai will solve it but you did not know any changes it makes in that code or in that file so yeah i strongly vote one must learn coding now as well.
I agree. Understanding at least one programming language well is still very important.
One thing I'd add is that it's no longer just about knowing the syntax. It's about understanding how the language works, how to debug it, and how to reason about the code AI generates.
When AI fixes a bug, you should be able to answer questions like:
That's the shift I was trying to highlight in the article. AI can write and even fix code, but developers still need the understanding to review it, challenge it, and guide it in the right direction.
So yes, I still think learning programming is essential. The focus has simply moved from memorizing syntax to understanding systems and making good engineering decisions.
I think when a dancer has to publish an article, whether dancers should learn how to dance is kind of late rome-ish.
Lol, I get the analogy.
To be fair, I wasn't arguing that developers shouldn't learn programming. My answer throughout the article is actually "yes, absolutely."
The question I was trying to explore was what developers should focus on learning now that AI can handle much more of the mechanical coding. My conclusion was that programming is still essential, but skills like system design, debugging, reasoning through edge cases, communication, and product thinking have become even more valuable.
So I don't think dancing has gone away. I just think the choreography has changed lol.
If programming was learnable, and under control, then this would be shorter.
Imo LLMs just made techbros realize - of course in a non self-introspecting way, not like actually thinking about that 'omg I've been a llm to QAs for decades' manner - that coming up with spec and testing is harder than writing new entries to the CVE list / eyeballing 2 unit tests / pushing out a new JS framework each minute.
I'm not saying QA is better, because ISTQB lost touch with reality and it is mainly about money and participation trophies, and we know how much power QA has against ROI-concerns etc.
All in all: For me, this profession is Dr. Seuss' Once-ler. Started out with good intentions, but became well... left-pad.
I think there's a lot of truth in that.
One thing AI has done is expose where the real complexity was hiding. Writing code has always been only one part of software engineering. Understanding the problem, defining good requirements, making trade-offs, and validating that we've built the right thing have always been harder. They were just easier to overlook when implementation itself consumed so much time.
Now that implementation is becoming cheaper, those other skills are much harder to ignore.
Whether that's a good or bad shift for the industry is probably a discussion in itself.
Thanks for your comment.
I think PR, Lobby, Legal team will become the most important jobs in the future.
Since you cannot control quality anymore, you need to make that EULA airtight etc.
I mean after circa 100 years or something, we still don't have good tooling for invariant checking.
On the other hand, we now handle rocket emojis. On IPv4. While banks are running COBOL.
This kind of sets the bar for my expectations about the future.
But, that's just me.
That's an interesting perspective, and I can definitely see why you would think that.
I do think legal, governance, and risk management will become even more important as AI lowers the cost of producing software. The easier it becomes to ship code, the more valuable accountability becomes.
That said, I'm hopeful we'll also see better engineering practices emerge alongside it. AI has made implementation faster, but it has also exposed weaknesses in how we define requirements, validate assumptions, and review decisions. My hope is that we respond by improving those disciplines rather than relying solely on contracts to manage the risk.
Strong framing. I agree that AI raises the leverage bar rather than eliminating the need for real engineering judgment. The examples around duplicate actions, failed payments, and ambiguous user flows are exactly where product thinking matters more than raw syntax recall. From a founder/operator perspective, the developers who stand out now are the ones who can turn messy intent into reliable systems: good constraints, idempotency, observability, and clear failure handling. AI is great at acceleration, but it still needs someone who understands what the system should do when reality gets weird. Good reminder that direction is becoming just as important as implementation.
Thank you! I really like how you framed it.
You captured what I was trying to get at. AI can help us generate implementations much faster, but it doesn't remove the need to think through constraints, edge cases, observability, or what happens when things don't go as planned.
I also like your point about reality getting weird. That's where good engineering usually shows itself. It's the unexpected retries, duplicate requests, partial failures, and ambiguous user behavior that separate a feature that demos well from one that's reliable in production.
Really appreciate you adding that perspective.
Thanks for your comment.
Thank you,I really love that you are offering your knowledg
Thank you! I really appreciate that.
I'm still learning myself, but if sharing what I've learned helps even one developer think differently or grow a little faster, then it's worth writing these articles.
Thanks for reading!
even before AI, learning syntax was not enough. What do you mean? Who would get a job just by learning syntax? LMAO
Fair point. I definitely wasn't trying to say syntax alone was ever enough to become a professional developer.
What I meant is that learning syntax used to occupy a much larger part of a developer's journey because you had to write almost everything yourself. Today, AI can help generate a lot of that syntax, so the value has shifted even more toward understanding systems, architecture, debugging, trade-offs, and problem-solving.
So yes, those higher level skills have always mattered. My argument is simply that AI has made them even more important because generating code is becoming easier, while judging whether that code is correct and appropriate is becoming the real differentiator.
Hey, this article appears to have been generated with the assistance of ChatGPT or possibly some other AI tool.
We allow our community members to use AI assistance when writing articles as long as they abide by our guidelines. Please review the guidelines and edit your post to add a disclaimer.
Failure to follow these guidelines could result in DEV admin lowering the score of your post, making it less visible to the rest of the community. Or, if upon review we find this post to be particularly harmful, we may decide to unpublish it completely.
We hope you understand and take care to follow our guidelines going forward!
Appreciate the reminder! The article is updated now.