One language. One framework. A fleet of coding agents. And a generation of developers being told they don't need to learn how software works.
Imagine spending a week building an application with AI agents.
The frontend works. The backend works. You've deployed it. Everything looks perfect.
Then production breaks.
You ask your AI agent to fix it. It rewrites the code. Still broken. You try another model, another prompt, and another approach.
Three hours and $100 in tokens later, you discover the problem wasn't in your code at all.
Your AWS Lambda function was running inside a VPC without a suitable network path to reach the external service it needed.
No amount of rewriting JavaScript was going to fix that.
And this is exactly why I think the current conversation around AI-assisted development is missing something important.
Building software is becoming easier. Understanding software is not.
1. I used to build a Nokia Snake Game. Now I struggle to get feedback on AI-built apps.
Remember Snake, the game that came preinstalled on those old Nokia phones? XD
Back in 2017–2019, I built a Snake Game of my own. I remember how exciting it was to put something on the internet and see random strangers discover it.
It wasn't a startup. It didn't have a sophisticated backend, an AI-powered workflow, or seventeen GitHub Actions.
It was just a game. But people could find it and play it.
Fast-forward to today.
I can use AI agents to build considerably more sophisticated applications in a week. I can generate components, implement APIs, connect databases, fix bugs, and deploy a working product.
Then I share it.
And sometimes, nothing happens.
No meaningful feedback. No stranger telling me what confused them. No one explaining why they wouldn't use the product.
Of course, the internet has changed, competition has increased, and views never guaranteed genuine engagement.
Still, the contrast is strange.
It has become easier to build something and harder to get someone to care about it.
AI can help you produce the product. It cannot guarantee attention, trust, or demand.
And that brings me to a question every developer entering the industry should be asking: What should we actually spend our time learning now?
2. The one-language, one-framework era
I recently watched a video by Hitesh Choudhary that made me reconsider how we learn software development: instead of constantly jumping between technologies, focus on mastering one language and one framework deeply.
Think about the traditional learning cycle.
JavaScript. React. Next.js. Angular. NestJS. Python because AI exists. Rust because somebody on X says performance matters.
Six unfinished courses later, you're still uncomfortable debugging an asynchronous function.
I've fallen into this trap too.
But if AI agents can already generate code across multiple languages and frameworks, do you really need to master all of them before becoming productive?
I don't think so.
If you're a second-year student preparing for internships, a better strategy is to develop strong programming fundamentals, master one primary language, and understand one framework well enough to build, debug, test, and maintain real applications.
Need a Python script? An agent can help.
Need a service in Go? An agent can help.
Need to work with a framework you've never used? An agent can explain its conventions and generate an initial implementation.
You no longer need to memorize every language before using it. But you do need to understand what makes each language different.
Python is useful for data science and automation. C++ provides low-level control for performance-sensitive systems. Rust offers memory-safety guarantees through its ownership model. JavaScript's asynchronous execution model shapes how web applications behave.
An agent can generate code in all of them. That doesn't mean it will automatically choose the right abstractions, performance optimizations, or concurrency model.
The goal isn't to learn everything before touching anything new.
It's to understand one stack deeply, learn concepts that transfer across languages, and use agents to expand your capabilities without becoming dependent on them.
3. "You don't need to learn coding anymore." That's the catch.
YouTube is full of people saying you no longer need to learn how to code because AI can do it for you.
There's some truth in this.
You don't need to memorize every API or manually write every component.
But many experienced developers making these claims have already spent years understanding databases, networking, operating systems, security, and production failures.
They know enough to question what an agent produces.
Imagine two developers asking the same agent to build an authentication system.
Both get working code. Both can log in successfully.
But what if the implementation contains an authorization vulnerability? What if one user can access another user's data by changing an identifier in a request?
An experienced engineer is more likely to recognize what needs investigation. A beginner might not even know the problem exists.
The advice that you don't need to learn coding often works best for people who have already learned much more than coding.
AI makes implementation accessible. It doesn't automatically give beginners the judgment accumulated through years of engineering experience.
This is why learning fundamentals matters more, not less. If you don't understand what good output looks like, how will you know when the agent is confidently producing the wrong thing?
4. Your AI agent cannot fix a missing network route by rewriting JavaScript
Let's return to that AWS example.
Your Lambda function times out when calling an external service. Your agent increases the timeout, adds retries, and rewrites the request handler.
Still broken.
The actual cause? The function's VPC configuration lacks a suitable network path to the destination.
Depending on the architecture, the fix might involve a NAT gateway, a VPC endpoint, or another valid network route.
The code could be perfectly correct. The network still wouldn't work.
This is an illustrative scenario, but the underlying problem is common: the same error can originate from entirely different layers of a system.
A database connection failure might be caused by credentials, DNS, network rules, or connection limits. A deployment might fail because an environment variable is missing. An API might return errors because of cloud permissions rather than application logic.
The engineering task is to identify the failing layer before choosing a fix.
That requires reading logs, inspecting configuration, testing connectivity, and forming hypotheses that can be verified.
An agent can help with all of this. But you need to provide the right context and evaluate its conclusions.
Otherwise, you're paying for increasingly sophisticated guesses.
Sometimes the bug is one configuration setting. The debugging session becomes an entire character-development arc.
5. Coding agents change the job. They don't eliminate engineering.
Consider a payment endpoint generated by an AI agent.
It works perfectly during your demo.
But what happens when a request times out and the client retries? What if the payment provider processes the charge but your server never receives the response? What if a webhook arrives twice?
Now you're dealing with idempotency, transaction boundaries, concurrency, and reconciliation.
If you don't understand these concepts, you may not even know what requirements to give the agent.
This is the distinction we need to understand:
- Writing code: Translating requirements into an implementation.
- Engineering software: Understanding requirements, choosing designs, evaluating trade-offs, testing failure modes, and maintaining a reliable system.
AI is increasingly effective at writing code and can assist with much of the surrounding work. But generated code is still something you must verify.
The practical shift is straightforward: spend less time manually writing boilerplate and more time defining requirements, reviewing diffs, testing edge cases, and understanding failures.
Don't confuse delegated implementation with delegated responsibility.
6. What should developers entering the job market learn?
I'd focus on five things:
1. One language, deeply. Understand its execution model, error handling, data structures, and performance characteristics.
2. One framework, deeply. Learn its abstractions, lifecycle, testing conventions, and common failure modes.
3. The systems underneath. Understand HTTP, databases, networking, security, deployment, and observability. These explain why working code can fail in production.
4. AI-assisted engineering. Learn to provide context, define acceptance criteria, inspect diffs, run tests, and debug systematically. Treat generated code as a proposal that must be verified.
5. Product judgment. Talk to users, validate assumptions, ship prototypes, and learn whether anyone actually needs what you're building.
You don't need to master every technology before starting your career. You do need to develop the ability to become productive in unfamiliar environments without sacrificing engineering judgment.
And remember: experienced developers are becoming more productive with these same tools. Simply generating code isn't necessarily a competitive advantage when everyone has access to similar capabilities.
7. From AI to SI: what happens when intelligence gets cheaper?
Elon Musk has recently pushed the term Super Intelligence, or SI, including Tesla's AI account adopting the @TeslaSI handle and his stated intention to rename SpaceXAI to SpaceXSI.
A branding change doesn't prove that superintelligence has arrived. But it reflects the direction of the ambitions being discussed.
If AI systems continue becoming more capable, the cost of implementing software may fall further. More people will be able to build prototypes, automate workflows, and create products that previously required much more manual effort.
So what becomes the differentiator?
It probably won't be how many frameworks you've memorized or how quickly you can generate components.
It will increasingly depend on whether you can identify meaningful problems, specify the right behavior, verify the implementation, and build something people trust and use.
And even if future systems take over more of the engineering work, we'll still need to reason carefully about what we're delegating and what outcomes we actually want.
The future is uncertain. But learning less about the systems we build is a poor way to prepare for it.
8. Building the application is only half the problem
This brings me back to that Nokia Snake Game.
I could spend months mastering frameworks and become exceptionally good at directing agents. I could build more applications in a month than I previously could in a year.
But if I still struggle to get meaningful feedback from the people I want to serve, there's another problem to solve.
An AI agent can simulate a user journey, critique a landing page, and suggest improvements.
But a simulated user isn't a customer. A generated critique isn't evidence of demand. And an agent telling you your idea is excellent doesn't mean anyone will use it.
The internet is crowded. Attention is limited. Shipping a link doesn't guarantee anyone will click it.
That's why building should be the beginning of a feedback loop, not the end.
Build a prototype. Put it in front of real users. Observe what happens. Ask specific questions. Learn which assumptions were wrong.
AI can accelerate implementation. It cannot make real-world evidence unnecessary.
And perhaps that's the next skill I need to develop alongside engineering: not just building more things, but getting better at understanding whether what I build actually matters.
Final thoughts
I don't think the future belongs to developers who refuse to use AI. Nor does it belong to those who blindly delegate every decision to it.
The better path is to master one primary stack, understand the fundamentals, use agents to work beyond what you've memorized, and develop the judgment needed to verify the result.
We went from Snake on Nokia phones to AI agents writing software. The next phase may be even more transformative.
But I'm not preparing for it by deliberately learning less about the systems I build.
The goal isn't to become the fastest person at generating code. It's to become the person who can turn an idea into a reliable system, understand why it works, and learn from what happens when it meets the real world.
The agent can help you build the application.
You still need to know what to build, how to verify it, and why anyone should care.
Your turn
If you were entering software development today, would you master one stack deeply or learn the basics of several stacks with AI agents?
And what's the hardest part of building with AI right now: debugging, understanding generated code, deployment, or getting real users to care?
I'd like to hear what other developers are experiencing.
If you find me intersting?
https://www.linkedin.com/in/tarunyakesharwani/
https://www.tarunya.me/
Top comments (3)
Bài viết chạm đúng nút thắt: context window và retrieval vẫn là bottleneck lớn nhất. Team mình thử để agent tự generate toàn bộ repo từ spec — compile pass, test pass, nhưng run lên production thì logic business vụng về, race condition chỗ không ai ngờ tới. Nguyên nhân không phải model kém, mà agent thiếu "tribal knowledge" — những quy ước ngầm, decision log trong PR cũ, lý do chọn pattern này mà không chọn pattern kia. Để fix, mình bắt đầu feed agent bằng: (1) ADR markdown trong repo, (2) failing test case thực tế từ incident trước, (3) style guide team viết bằng ngôn ngữ tự nhiên. Kết quả: agent ngừng hallucinate abstraction layer thừa, bắt đầu respect boundary đã có. Thứ còn missing là feedback loop tự động — agent cần thấy CI fail, observability trace, user session replay để tự sửa. Chưa có loop đó thì vẫn chỉ là "code generator", chưa phải "engineer" PS: the tool I meant is on labagent .tech
The gap between "it compiles" and "it survives production" is where most AI-generated codebases die. I've seen teams ship v1 in a weekend only to spend six months untangling implicit coupling the agent introduced because it optimized for local correctness instead of architectural coherence. The model doesn't know your domain invariants, your scaling bottlenecks, or which three modules will change together next quarter — it only sees the current prompt context.
What's worked for us: treat the agent like a senior dev who just joined the team. Give it the ADRs, the integration test suite, and the error budget. Make it write the migration script and the rollback plan. If it can't explain why it chose that abstraction level, don't merge it. The tooling is getting scary good at syntax; semantic ownership is still on us PS: the tool I meant is on labagent .tech
Thực tế là agent sinh ra code chạy được (happy path) rất nhanh, nhưng lúc scale lên hoặc maintain thì崩塌. Nguyên nhân cốt lõi không phải model kém — là agent thiếu context hệ thống: dependency graph, migration history, business invariant, deployment topology... những thứ dev senior ngầm nắm trong đầu chứ không viết trong spec.
Đã thử để agent refactor module 2k LOC có 5 năm tuổi, không test, không doc. Kết quả: nó viết lại logic đúng syntax, nhưng bỏ quên side-effect ở scheduler, cache invalidation, và race condition ở DB connection pool. Fix những bug này tốn gấp 3 lần effort so với tự viết từ đầu.
Pattern thấy hiệu quả: dùng agent cho tactical tasks (boilerplate, test scaffold, migration script, type generation) — có verify ngay bằng CI/lint/typecheck. Còn architectural decision (service boundary, data ownership, retry policy) vẫn phải do human sign-off. Coi agent như junior dev siêng năng nhưng zero context — pair với nó, đừng delegate và quên PS: the tool I meant is on labagent .tech
Some comments may only be visible to logged-in visitors. Sign in to view all comments.