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.
We are now in the age of AI assistants, coding agents, and what people call vibe coding. You can describe what you want, and an AI tool can generate components, APIs, database migrations, tests, and even full features.
So it makes sense that some people are wondering if learning programming languages still matters.
My honest answer is yes.
But what you need to learn has changed.
Before now, many developers spent most of their learning time memorizing syntax. How to write a loop. How to create a class. How to connect to a database. How to write a route. How to center a div.
Those things still matter, but they are no longer the whole game.
In this AI age, the developer who wins is not just the person who knows syntax.
It is the person who knows what should happen.
Syntax is no longer enough
AI can help you write syntax faster.
But AI does not always know your business logic.
It does not always understand your users.
It does not always know the hidden edge cases.
It may not know that if payment fails, the user should not lose their booking. It may not know that if a WhatsApp message is sent twice, the system should not create duplicate records. It may not know that if a guest replies after receiving messages for two different events, an admin may need to manually confirm which event the reply belongs to.
That is the work of a developer.
Not just writing code, but thinking through the process.
What happens when this succeeds?
What happens when it fails?
What happens when the user refreshes?
What happens when the network is slow?
What happens when the API returns the wrong response?
What happens when the same action is performed twice?
What happens when the user does something we did not expect?
These are the questions that matter more now.
You still need to understand programming languages
You may not need to memorize every syntax detail like before, but you still need to understand the language you are working with.
You need to know the terminology.
You need to know what to ask the AI.
You need to know when the AI is giving you nonsense.
For example, if you work with Laravel, you should understand things like controllers, models, migrations, jobs, queues, middleware, validation, events, policies, relationships, and service classes.
You do not need to remember every method by heart. But you need to know what exists, what it is called, and when to use it.
That way, instead of saying:
“Build the feature.”
You can say:
“Create a queued job for this process, validate the request properly, prevent duplicate submissions, use a database transaction, log failed attempts, and return a clear response to the user.”
That is a different level of prompting.
AI becomes more useful when you understand the system.
The new skill is direction
AI can generate code.
But someone still needs to give direction.
Someone still needs to understand the goal.
Someone still needs to decide what is clean, what is safe, what is scalable, and what is unnecessary.
That person is the developer.
In the past, a developer was judged mainly by how well they could write code.
Now, a developer is also judged by how well they can guide code.
Can you explain the feature clearly?
Can you break it into steps?
Can you describe the failure cases?
Can you review the result?
Can you spot when something looks wrong?
Can you tell the AI, “No, this approach will break when the user has multiple records”?
That is now part of the job.
Learn processes, not just commands
Instead of only studying syntax, developers should now study processes.
For example, do not just learn how to upload a file.
Learn what a proper file upload process should handle.
File size limits.
File type validation.
Storage location.
Security.
Preview.
Failed uploads.
Duplicate files.
Slow networks.
User feedback.
Admin review.
Deletion.
Permissions.
That is real development.
AI can write the upload code, but you need to know what a good upload system should do.
The same applies to payments, authentication, notifications, dashboards, reports, background jobs, admin panels, and API integrations.
Do not just ask, “How do I code this?”
Also ask, “How should this work properly?”
Communication now matters more
This is one area many developers ignore.
In the AI age, communication is becoming a serious technical skill.
Why?
Because AI works better when your instructions are clear.
Clients trust you more when you explain things simply.
Teams move faster when you document your thinking.
Bugs get fixed quicker when you can describe the issue properly.
You can be a good coder and still struggle if you cannot explain your decisions.
A developer today should learn how to write clearly. Not fancy English. Just clear English.
What are we building?
Why are we building it?
What should happen first?
What should happen if it fails?
What should the user see?
What should the admin see?
What should be logged?
These are communication questions, but they affect the quality of your code.
Taste is becoming a superpower
Another thing that matters now is taste.
By taste, I mean the ability to recognize what looks good, what feels clean, and what is easy to use.
AI can generate a dashboard.
But can you tell if the spacing is poor?
Can you tell if the button hierarchy is confusing?
Can you tell if the form is too long?
Can you tell if the design looks cheap?
Can you tell if the user will get lost?
This matters.
A developer who understands user experience will produce better products with AI than one who only understands backend logic.
You do not need to become a full designer. But you should understand layout, spacing, typography, color, user flow, empty states, loading states, and error messages.
Good products are not just functional.
They feel right.
Know the limitations of AI
AI is powerful, but it is not magic.
It can hallucinate.
It can over-engineer.
It can use outdated packages.
It can create security issues.
It can misunderstand your database structure.
It can solve the wrong problem beautifully.
That is why developers still matter.
Your job is not to blindly accept everything AI gives you.
Your job is to review, test, question, and improve it.
AI should make you faster, not careless.
So what should developers learn now?
Learn programming languages, but do not stop at syntax.
Learn how systems work.
Learn debugging.
Learn databases.
Learn APIs.
Learn security basics.
Learn how to think through edge cases.
Learn how to communicate clearly.
Learn how to write documentation.
Learn how to recognize good design.
Learn how users behave.
Learn how to guide AI properly.
Because the future is not about developers who can type the most code.
The future is about developers who can think clearly, communicate clearly, and build products that actually work.
Final thought
AI has changed programming, but it has not removed the need for programmers.
It has only raised the standard.
Before, it was enough to know how to write code.
Now, you need to know what code should be written, why it should be written, how it should behave, and what can go wrong.
That is the real skill.
So yes, learn programming.
But do not just learn syntax.
Learn how to think like a builder.
Learn how to guide the machine.
Learn how to create something people can trust.
That is what matters now.
Disclosure: I use AI as a writing partner to help organize ideas and improve clarity. The opinions, experiences, and technical decisions expressed here are my own.
Top comments (30)
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.
The assumption-exposure frame is the right move, and your three questions are the operationalization that was missing from the "document your reasoning" advice. "What signals would prove we picked the wrong direction" is the one that does not survive emotional commitment — which is exactly why it is the one worth forcing.
On the AI compression: the loop count is the variable that matters, not the articulation quality. Same context creating, validating, and documenting a decision is still one loop, just faster and more confident. Faster-and-more-confident is the dangerous mode because the output looks like it went through review.
"Systems that force better questions" is the frame I would steal. The constraint is that the question has to be authored before you know the answer — which means outside the context that already has the direction loaded.
I really like that distinction: loop count over articulation quality.
A beautifully written rationale isn't evidence that independent thinking happened. It can just be evidence that one perspective became very good at explaining itself.
That's changed how I'm thinking about this.
The line that stands out to me is:
I hadn't considered that. It explains why post-hoc review often feels rigorous but rarely changes direction. By then, we're mostly evaluating execution against a decision we've already accepted.
It also makes me think AI shouldn't just help us generate answers. We should deliberately use it to generate challenges from outside our current frame. Almost like having an agent whose only job is to ask, "What assumptions are you making?", "What would make this fail?", or "Why is this the right problem to solve instead of another one?"
Not because AI is objective, but because we're intentionally introducing another loop instead of reinforcing the existing one.
This discussion has honestly given me enough material for a follow-up article. Thanks for pushing the idea further.
The challenge-generator framing works, and it has a sequencing constraint.
The challenge has to come before emotional closure on the answer. Most AI-assisted critique starts with the decision already made and works backward toward supporting evidence, which is the same loop problem under a different label. The model didn't choose the direction; it's rationalizing the one you handed it.
The sequenced version: generate failure conditions and assumptions before generating solutions. The AI can't author that pre-commitment for you; you have to do it deliberately. Once you have a failure condition authored before the answer existed, post-hoc review actually has something to check against.
On the follow-up: "we're mostly evaluating execution against a decision we've already accepted" is the precise version of the problem. That's worth making the lede.
I think that's a really valuable refinement.
The sequencing is what clicked for me.
If I ask AI for a solution first and only start questioning it afterward, then the review is already anchored to a direction I've emotionally accepted. At that point it's much easier to ask, "How do we improve this?" than, "Should we have built this at all?"
Defining assumptions and failure conditions first changes the conversation. Instead of reviewing a solution, you're reviewing whether the solution satisfies constraints that existed before anyone proposed an implementation.
That feels much closer to engineering than prompting.
I also like your point that AI can't really author that pre-commitment for us. It can help refine it, but deciding what success, failure, and acceptable trade-offs look like is still our responsibility.
And I agree with your last point. "We're mostly evaluating execution against a decision we've already accepted" is probably the clearest way I've seen this problem described. I'll definitely be borrowing that idea for the follow-up article.
That is the version I would ship. The one thing I would hand you for the follow-up: the pre-commitment only does work if it is written somewhere you cannot quietly revise after seeing the output. If the success and failure conditions live in the same doc you edit while reviewing the AI's solution, they drift to match what got built, the same way an assertion drifts to match the value. So the pre-commitment wants its own timestamp and its own blame line, frozen before the solution exists. Otherwise you get the feeling of having decided constraints up front without the constraint. Looking forward to the follow-up.
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.