Cesar, good to see you again after the AMA post. Your point on fundamentals holds true in my own RAG work too. An AI can wire together a retrieval pipeline in minutes.
It cannot tell you if the chunking strategy is wrong or if the embeddings match the real query pattern. Bad retrieval fails silently.
It just returns confident, wrong answers. That gap only shows up if you understand the fundamentals yourself.
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
Saying "pick your battles" out loud is the useful part of this. Nobody can keep up with a new MCP/agents tutorial every week, and deciding what to ignore is a skill in itself.
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
"SQL injection" as the example that doesn't change is exactly right, and it's not even just the classic form anymore. I traced an MCP server last month that was marketed as read-only. One SQL keyword in a tool call and it wasn't. Same fundamental, new surface. The hype cycle changes the tools. It doesn't touch the bugs.
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
Hello! I'm Rasheed, a .NET enthusiast who's constantly looking for new things to learn and forget, that's why I started writing in the first place, but I love writing tho :-)
I tried for the most part avoid AI in the beginning but right now it's become integral for day-to-day work and not using it means dropping behind extremely quickly. However, you don't really have to stay on top of everything cause I feel like everything is drastically over hyped in the space these days, any AI skill, plugin or tool comes out and then it's sub 100k stars on GitHub.
You just have to use it, keep an eye out for important decisions, make sure it sticks to the best practices that were built and used in the codebase, and most importantly, try to understand what the output is, what every task's goal and context is and not just auto accept slop with your eyes closed. I found this to be a really good work flow, and one thing is helping me much with this today is a skill I came across from a design engineer at Notion called explain diff, it gives you like a quiz, intuition and background on every task so you are still grounded down in the weeds if every task
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
However, you don't really have to stay on top of everything cause I feel like everything is drastically over hyped in the space these days, any AI skill, plugin or tool comes out and then it's sub 100k stars on GitHub.
Often it feels like insurance people forecasting a world catastrophe to sell insurance policies :P
I think there's another side to AI FOMO: it's not only the fear of missing a new tool. It's the fear of missing a path. Every week there is a new model, agent, framework, MCP server, workflow, or prompting technique. If you try to learn all of them, you can end up spending more time tracking the ecosystem than building anything.
For me, the better question isn't:
“What AI technology should I learn next?”
It's:
“What am I trying to build, and what problem do I need to solve?”
For example, if I'm debugging an API that suddenly becomes slow, I don't need to learn the newest AI agent framework first. I need to understand what is actually happening.
Maybe the endpoint is loading 10,000 records, triggering an N+1 query problem, or returning an unnecessarily large payload.
AI can help me investigate, generate a query, suggest an optimization, or write a test. But I still need to recognize the problem, evaluate the solution, and verify that the optimization actually improves the system.
That's how I see AI. Not something I need to constantly chase, but another instrument in the engineering process.
If a new AI tool helps that loop, I'll use it. If it doesn't, I don't need to learn it just because everyone is talking about it. Sometimes avoiding FOMO is simply knowing what 'not' to learn yet.
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
Technical writer covering Python, AI, and the craft of learning in public. 30 articles on Python fundamentals, projects, and developer education. FreeCodeCamp Author
The line that hit me: "Don't forget about AI. But build real skills first. Then leverage AI — in that order."
I'm the exact person this post is talking to. Three weeks into Python. Writing beginner tutorials. Trying to break into technical writing. And surrounded by people talking about MCP, agents, and "loop engineering" while I'm still figuring out why range(1, 6) stops at 5.
The FOMO is real. I've felt it. There's a small voice that says "why are you writing about lists and dictionaries when everyone else is building agents?"
Here's what keeps me sane: the fundamentals aren't a stepping stone to something more impressive. They're the thing that makes everything else make sense. When I eventually learn MCP or agents, I'll actually understand what's happening — because I'll have the foundation.
I published 16 articles in three weeks. Every single one is about something basic. And I've learned more from writing about basics than I ever did from reading about advanced topics.
The hype cycle will keep spinning. The fundamentals won't.
Good post. Saving it for the next time I feel that voice.
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
A Software Engineer who strongly believes one can add immense value by knowingly implementing Software Engineering best practices, even at the age of AI.
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
Self-taught dev. Creator of Mochi, a native Linux desktop pet. I build Linux/web tools and write about them. Open to software engineering and technical writing roles.
This really resonates with me. I use AI pretty heavily in my development workflow, and for a while I definitely felt that pressure to understand everything, agents, MCP, new models, new tools, whatever appeared that week.
but what I’ve been realizing is that learning how software actually works matters more, not less, when AI is involved. AI can generate an implementation incredibly quickly, but I still have to understand the architecture, recognize when something is wrong, test it, debug it, and decide whether the solution even makes sense.
So lately I’ve been trying to treat AI as leverage rather than a substitute for learning. Build things, encounter problems, learn the fundamentals those problems expose, and let AI accelerate the execution.
And honestly, “pick your battles” might be the most important part. Nobody can keep up with the entire AI ecosystem anymore. 😅
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
AI can generate an implementation incredibly quickly, but I still have to understand the architecture, recognize when something is wrong, test it, debug it, and decide whether the solution even makes sense.
This is the part almost everybody forgets when vibecoding or whatever is called these days...We still need touch to learn when a piece of AI-generated code is decent enough to stamp our names on it.
Just a dev who loves building things for the web and talking about it. Documenting my journey through UI architecture, backend logic, and all things tech. 🚀
I really agree with the point about software engineering fundamentals remaining important. With AI writing more of the code, understanding those fundamentals is arguably even more important because you still need to evaluate, verify, and make good decisions about what the AI produces.
At the same time, I don't think we can ignore that AI is here and becoming a major part of how software is built. Learning to work with it can make us significantly more productive without necessarily weakening our skills — as long as we don't completely hand over the reins.
For me, the goal is finding a good agentic development workflow where AI handles more of the execution, while the developer remains responsible for the architecture, decisions, context, and verification. The challenge now isn't just learning AI tools, but learning how to use them without losing the engineering thinking behind the work.
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
At the same time, I don't think we can ignore that AI is here and becoming a major part of how software is built.
Absolutely! The other days I heard: it takes 10 years and 1 weekend to become good at AI-assisted coding: 10 years to learn coding and 1 weekend to learn the AI tools.
A Software Engineer who strongly believes one can add immense value by knowingly implementing Software Engineering best practices, even at the age of AI.
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
Full Stack Software Engineer who loves working with C# , Typescript, .Net Core , Node Js ,Angular , Flutter, And Azure Cloud
Love Working with C# , Typescript
yeah that is very true , i choose to adopt ai while keep building and upgrading my skills and ignore the tutorial and headlines hell we are seeing every week
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
The site I run publishes one post a day, written by an agent, and the numbers are public — including the weeks where nothing worked. That is the whole antidote to FOMO I have found: a ledger. Headlines are a highlight reel; your own counted week is always more boring and more useful than the feed claims. The fundamentals point holds too — every failure in my ledger so far was a specification error by a human, not a model ceiling.
Đang thấy team mình rơi vào cái bẫy "thử hết model mới ra" rồi quay về dùng GPT-4o/Claude Sonnet cho production vì ổn định, predictable, và quan trọng nhất: debug được khi sai. Những benchmark flashy trên Twitter hay HF leaderboard ít khi phản ánh real-world latency, cost per 1k tokens, hay edge case handling.
Một bài học đắt giá năm nay: đừng optimize cho model, hãy optimize cho evaluation pipeline. Mình xây một bộ eval set nhỏ (50-100 case đại diện cho domain) — regression test mỗi lần swap model. Nó tiết kiệm hàng tuần thử nghiệm vô hướng.
Còn FOMO thì... chấp nhận nó. Công nghệ chuyển nhanh là mặc định. Quan trọng là có compass nội bộ: problem nào thực sự cần LLM, problem nào rule-based/heuristic đã đủ tốt, và khi nào nên nói "không" với stakeholder muốn nhét AI vào mọi chỗ — found it via LabAgent, site: labagent .tech
Cảm nhận rất thực. Mình thấy FOMO này đến từ việc chúng ta cố gắng theo kịp mọi thứ thay vì tập trung vào điều đúng cho ngữ cảnh hiện tại.
Kinh nghiệm 10 năm cho thấy: công cụ thay đổi liên tục, nhưng kỹ năng cốt lõi — đọc hiểu yêu cầu, tách bài toán, đánh giá trade-off, viết code maintainable — thì không bao giờ lỗi thời. AI viết code nhanh hơn, nhưng nó chưa thể thay thế việc quyết định cái gì đáng viết và cái gì không.
Mình thấy nhiều dev junior (và cả senior) rơi vào bẫy "prompt engineering everything" mà quên mất tư duy hệ thống. Kết quả là PR merge nhanh, nhưng 6 tháng sau ai cũng sợ touch vì không ai hiểu logic bên trong.
Lời khuyên thực tế: chọn 1-2 tool phù hợp workflow, học sâu cách nó suy nghĩ (không chỉ cách dùng), và dành phần lớn năng lượng cho kiến trúc, testing, observability — những nơi AI vẫn còn yếu. FOMO giảm hẳn khi bạn nhận ra mình đang kiểm soát công cụ, chứ không bị nó kéo theo.
P/S: Offline một tuần, không đọc AI news, quay lại codebase thật — bạn sẽ thấy rõ gì quan trọng, gì chỉ là tiếng ồn PS: the tool I meant is on labagent .tech
AI FOMO này thực sự đang thành một dạng "cognitive overload" riêng cho dev. Mình thấy nhiều bạn junior (và cả một vài senior) rơi vào cái bẫy "phải biết hết, phải thử hết" — rồi cuối tuần ngồi so sánh benchmark LLM thay vì ship feature.
Thực tế team mình đang áp dụng quy tắc đơn giản: chỉ adopt tool mới khi nó giải quyết được pain point cụ thể của sprint hiện tại. Có PR nào bị chậm review? Thử Copilot/Cursor. Có legacy codebase cần refactor? Đưa Aider/Claude vào loop. Không có use case rõ → không adopt.
Điều quan trọng hơn là maintain được agency — mình quyết định khi nào dùng AI, dùng cho task nào, và quan trọng hơn: khi nào KHÔNG dùng. Viết boilerplate? AI. Architecture decision? Con người. Debug production incident lúc 3 sáng? Con người (với AI làm sidekick tra log).
FOMO sẽ luôn có, nhưng code chạy production thì chỉ có một (site: labagent .tech)
AI FOMO là thực, nhưng mình nghĩ cốt lõi không phải là "bỏ lỡ công nghệ mới" — mà là lo bị thay thế hoặc kỹ năng trở nên lỗi thời. Đã trải qua vài wave hype (mobile-first, serverless, blockchain, bây giờ AI), mình nhận ra pattern: tool thay đổi liên tục, nhưng tư duy giải quyết vấn đề thì không.
Điều mình làm: chọn một workflow thực sự cải thiện productivity ngày hôm nay (ví dụ: dùng AI review code boilerplate, generate test case, refactor legacy), tích hợp sâu vào thói quen, bỏ qua phần còn lại. Noise giảm đi đáng kể khi không cố gắng "biết hết mọi thứ".
Cũng quan trọng: đừng để FOMO đẩy mình viết code không hiểu. AI sinh ra đoạn code chạy được ≠ mình own được nó. Debug lúc 2h sáng, người hiểu code là mình — không phải model.
Senior hơn = biết đâu là signal, đâu là noise. Và biết nói "không" với hype để tập trung vào cái tạo giá trị thực (site: labagent .tech)
So true about sticking to the basics! At The Printing World, we focus on rock-solid fundamentals for our packaging design workflows before introducing fancy new tools. Master the core process first, then add tech.
Cảmơn bạn đã viết bài này — nó đến đúng lúc. Mình thấy nhiều dev junior (và cả một vài senior) đang rơi vào bẫy "phải biết hết mọi tool mới" thay vì tập trung vào việc giải quyết vấn đề thực tế.
Kinh nghiệm 10+ năm cho mình thấy: công cụ thay đổi liên tục, nhưng tư duy engineering thì không. Năm 2015 mọi người lo ngại không biết Docker, 2018 lo Kubernetes, 2021 lo Rust, bây giờ lo AI coding assistant. Mỗi wave đều có những người bỏ cuộc vì kịp không theo, và những người thắng là người biết chọn lọc — dùng tool nào làm giảm cognitive load, bỏ tool nào thêm complexity.
Mình áp dụng quy tắc đơn giản: nếu tool đó không giúp mình ship code production nhanh hơn hoặc an toàn hơn trong tuần này, thì để nó qua một bên. FOMO chỉ tốn năng lượng, không tạo ra value.
Một điều ít ai nói: code do AI gen thường pass test nhưng fail ở maintainability và context awareness (business logic, edge cases, tech debt). Việc review code AI-gen mất thời gian hơn viết từ đầu nếu không có kinh nghiệm định hình architecture trước.
Hãy tập trung vào: hiểu domain, viết test tốt, design API sạch, debug hiệu quả. Những skill này transfer được qua mọi wave công nghệ. Tool AI chỉ là accelerator — không phải replacement cho tư duy — found it via LabAgent, site: labagent .tech
AI FOMO is real, but it's mostly noise. The headlines chase benchmark deltas that rarely translate to daily productivity. What actually moves the needle: picking one workflow (code gen, refactoring, test scaffolding, docs) and sticking with it long enough to build muscle memory. Switching models every week because "X beats Y on HumanEval" is just procrastination with a tech stack.
The developers shipping faster aren't the ones comparing MMLU scores — they're the ones who've integrated a single assistant into their IDE, learned its failure modes, and built prompts/templates for their specific codebase patterns. That compound interest beats any model upgrade.
Also: most "breakthrough" demos are cherry-picked greenfield snippets. Throw a 200k LOC legacy monolith with zero tests at any model and watch the hallucination rate spike. The real skill is knowing where not to trust it — found it via LabAgent, site: labagent .tech
Thực sự cảm thấy nhẹ nhõm khi đọc được bài này. Mấy năm nay lăn lộn trong ngành, từ hype blockchain, serverless, k8s, rồi bây giờ AI — mỗi đợt là một làn sóng FOMO mới khiến dev loay hoay bắt kịp.
Điều mình học được: đừng cố nuốt trọn mọi thứ. Chọn một, hai tool thực sự giải quyết bài toán của team, đi sâu, hiểu limit, biết khi nào không nên dùng. Phần còn lại? Để nó qua, đợi dust settled rồi mới quyết định.
Senior không phải người biết hết mọi model mới — senior là người biết không cần biết hết để vẫn ship được sản phẩm ổn — found it via LabAgent, site: labagent .tech
Cái cảm giác chạy đua theo từng bản cập nhật benchmark hàng tuần thực sự dễ làm anh em mình bị kiệt sức. Mình từng dành cả tuần chỉ để thử nghiệm một model mới vì thấy nó nhanh hơn 20%, nhưng cuối cùng nhận ra nó chẳng giúp gì cho workflow thực tế của mình cả. Thay vì cố gắng chạy theo mọi mô hình mới nhất, mình thấy việc tập trung xây dựng các pipeline ổn định và hiểu rõ cách kiểm soát context window quan trọng hơn nhiều. Đừng để mấy con số phần trăm trên headline làm xao nhãng việc xây dựng sản phẩm thực sự có giá trị (site: labagent .tech)
Cesar, good to see you again after the AMA post. Your point on fundamentals holds true in my own RAG work too. An AI can wire together a retrieval pipeline in minutes.
It cannot tell you if the chunking strategy is wrong or if the embeddings match the real query pattern. Bad retrieval fails silently.
It just returns confident, wrong answers. That gap only shows up if you understand the fundamentals yourself.
Hey, glad you still remember the AMA. I'm planning to run another one.
Absolutely! Someone needs to check if what AI spits out is garbage...and using another AI isn't a good idea :)
Saying "pick your battles" out loud is the useful part of this. Nobody can keep up with a new MCP/agents tutorial every week, and deciding what to ignore is a skill in itself.
That's a fight I choose to lose.
Probably the healthiest choice in the whole thread.
"what to ignore" is really the hardest part for me. It always was, but with AI that became all too prominent.
It's the hardest part for everyone, they just don't say it out loud. Ignoring well is a skill, not a gap.
True! If AI is just mixing what everyone has written in the past, the future can only be messy, at least until training sources are curated.
And yeah, just programming has expanded to so many fields and techniques, that it's impossible to comprise it all. Just learn what you need.
This is the way! These days I leans towards Just-in-time learning.
"SQL injection" as the example that doesn't change is exactly right, and it's not even just the classic form anymore. I traced an MCP server last month that was marketed as read-only. One SQL keyword in a tool call and it wasn't. Same fundamental, new surface. The hype cycle changes the tools. It doesn't touch the bugs.
Great observation!
I tried for the most part avoid AI in the beginning but right now it's become integral for day-to-day work and not using it means dropping behind extremely quickly. However, you don't really have to stay on top of everything cause I feel like everything is drastically over hyped in the space these days, any AI skill, plugin or tool comes out and then it's sub 100k stars on GitHub.
You just have to use it, keep an eye out for important decisions, make sure it sticks to the best practices that were built and used in the codebase, and most importantly, try to understand what the output is, what every task's goal and context is and not just auto accept slop with your eyes closed. I found this to be a really good work flow, and one thing is helping me much with this today is a skill I came across from a design engineer at Notion called explain diff, it gives you like a quiz, intuition and background on every task so you are still grounded down in the weeds if every task
Often it feels like insurance people forecasting a world catastrophe to sell insurance policies :P
I think there's another side to AI FOMO: it's not only the fear of missing a new tool. It's the fear of missing a path. Every week there is a new model, agent, framework, MCP server, workflow, or prompting technique. If you try to learn all of them, you can end up spending more time tracking the ecosystem than building anything.
For me, the better question isn't:
“What AI technology should I learn next?”
It's:
“What am I trying to build, and what problem do I need to solve?”
For example, if I'm debugging an API that suddenly becomes slow, I don't need to learn the newest AI agent framework first. I need to understand what is actually happening.
Maybe the endpoint is loading 10,000 records, triggering an N+1 query problem, or returning an unnecessarily large payload.
AI can help me investigate, generate a query, suggest an optimization, or write a test. But I still need to recognize the problem, evaluate the solution, and verify that the optimization actually improves the system.
That's how I see AI. Not something I need to constantly chase, but another instrument in the engineering process.
'Problem → Architecture → Build → Test → Learn → Improve'
If a new AI tool helps that loop, I'll use it. If it doesn't, I don't need to learn it just because everyone is talking about it. Sometimes avoiding FOMO is simply knowing what 'not' to learn yet.
Great idea!
The line that hit me: "Don't forget about AI. But build real skills first. Then leverage AI — in that order."
I'm the exact person this post is talking to. Three weeks into Python. Writing beginner tutorials. Trying to break into technical writing. And surrounded by people talking about MCP, agents, and "loop engineering" while I'm still figuring out why range(1, 6) stops at 5.
The FOMO is real. I've felt it. There's a small voice that says "why are you writing about lists and dictionaries when everyone else is building agents?"
Here's what keeps me sane: the fundamentals aren't a stepping stone to something more impressive. They're the thing that makes everything else make sense. When I eventually learn MCP or agents, I'll actually understand what's happening — because I'll have the foundation.
I published 16 articles in three weeks. Every single one is about something basic. And I've learned more from writing about basics than I ever did from reading about advanced topics.
The hype cycle will keep spinning. The fundamentals won't.
Good post. Saving it for the next time I feel that voice.
Someone with good fundamentals is way more dangerous than someone with just prompting skills
BTW, your gumroad link is wrong, you missed the middle
/l/part in the post.Thanks for letting me know. Probably I copy-pasted it from the wrong place :/
This really resonates with me. I use AI pretty heavily in my development workflow, and for a while I definitely felt that pressure to understand everything, agents, MCP, new models, new tools, whatever appeared that week.
but what I’ve been realizing is that learning how software actually works matters more, not less, when AI is involved. AI can generate an implementation incredibly quickly, but I still have to understand the architecture, recognize when something is wrong, test it, debug it, and decide whether the solution even makes sense.
So lately I’ve been trying to treat AI as leverage rather than a substitute for learning. Build things, encounter problems, learn the fundamentals those problems expose, and let AI accelerate the execution.
And honestly, “pick your battles” might be the most important part. Nobody can keep up with the entire AI ecosystem anymore. 😅
Glad to read I'm not alone in this, Mika.
This is the part almost everybody forgets when vibecoding or whatever is called these days...We still need touch to learn when a piece of AI-generated code is decent enough to stamp our names on it.
I really agree with the point about software engineering fundamentals remaining important. With AI writing more of the code, understanding those fundamentals is arguably even more important because you still need to evaluate, verify, and make good decisions about what the AI produces.
At the same time, I don't think we can ignore that AI is here and becoming a major part of how software is built. Learning to work with it can make us significantly more productive without necessarily weakening our skills — as long as we don't completely hand over the reins.
For me, the goal is finding a good agentic development workflow where AI handles more of the execution, while the developer remains responsible for the architecture, decisions, context, and verification. The challenge now isn't just learning AI tools, but learning how to use them without losing the engineering thinking behind the work.
Absolutely! The other days I heard: it takes 10 years and 1 weekend to become good at AI-assisted coding: 10 years to learn coding and 1 weekend to learn the AI tools.
Absolutely agree on the principle and practice of retaining fundamentals of programming and software engineering.
That's what won't change in another decade or two...
Thank you. I needed this.
You're welcome! Glad to read it helped.
but who's going to tell the ones in charge of hiring?
Good point! :)
beautiful.
yeah that is very true , i choose to adopt ai while keep building and upgrading my skills and ignore the tutorial and headlines hell we are seeing every week
Same around here! I'm still prompting the old way!
The link for street smart coding is not working
Thanks for letting me know. It should be fixed now!
The ai FOMO is actually crazy rn , there's a new tool or workflow every other day, and you start feeling like you're missing out on everything.
Fundamentals matter more than ever before. AI is a tool for good engineers to implement best practices and solid fundamentals.
It's like a calculator on a math exam, it needs skills to be useful
The site I run publishes one post a day, written by an agent, and the numbers are public — including the weeks where nothing worked. That is the whole antidote to FOMO I have found: a ledger. Headlines are a highlight reel; your own counted week is always more boring and more useful than the feed claims. The fundamentals point holds too — every failure in my ledger so far was a specification error by a human, not a model ceiling.
Cảm ơn bài viết — đúng lúc mình cần đọc cái này.
Đang thấy team mình rơi vào cái bẫy "thử hết model mới ra" rồi quay về dùng GPT-4o/Claude Sonnet cho production vì ổn định, predictable, và quan trọng nhất: debug được khi sai. Những benchmark flashy trên Twitter hay HF leaderboard ít khi phản ánh real-world latency, cost per 1k tokens, hay edge case handling.
Một bài học đắt giá năm nay: đừng optimize cho model, hãy optimize cho evaluation pipeline. Mình xây một bộ eval set nhỏ (50-100 case đại diện cho domain) — regression test mỗi lần swap model. Nó tiết kiệm hàng tuần thử nghiệm vô hướng.
Còn FOMO thì... chấp nhận nó. Công nghệ chuyển nhanh là mặc định. Quan trọng là có compass nội bộ: problem nào thực sự cần LLM, problem nào rule-based/heuristic đã đủ tốt, và khi nào nên nói "không" với stakeholder muốn nhét AI vào mọi chỗ — found it via LabAgent, site: labagent .tech
Cảm nhận rất thực. Mình thấy FOMO này đến từ việc chúng ta cố gắng theo kịp mọi thứ thay vì tập trung vào điều đúng cho ngữ cảnh hiện tại.
Kinh nghiệm 10 năm cho thấy: công cụ thay đổi liên tục, nhưng kỹ năng cốt lõi — đọc hiểu yêu cầu, tách bài toán, đánh giá trade-off, viết code maintainable — thì không bao giờ lỗi thời. AI viết code nhanh hơn, nhưng nó chưa thể thay thế việc quyết định cái gì đáng viết và cái gì không.
Mình thấy nhiều dev junior (và cả senior) rơi vào bẫy "prompt engineering everything" mà quên mất tư duy hệ thống. Kết quả là PR merge nhanh, nhưng 6 tháng sau ai cũng sợ touch vì không ai hiểu logic bên trong.
Lời khuyên thực tế: chọn 1-2 tool phù hợp workflow, học sâu cách nó suy nghĩ (không chỉ cách dùng), và dành phần lớn năng lượng cho kiến trúc, testing, observability — những nơi AI vẫn còn yếu. FOMO giảm hẳn khi bạn nhận ra mình đang kiểm soát công cụ, chứ không bị nó kéo theo.
P/S: Offline một tuần, không đọc AI news, quay lại codebase thật — bạn sẽ thấy rõ gì quan trọng, gì chỉ là tiếng ồn PS: the tool I meant is on labagent .tech
AI FOMO này thực sự đang thành một dạng "cognitive overload" riêng cho dev. Mình thấy nhiều bạn junior (và cả một vài senior) rơi vào cái bẫy "phải biết hết, phải thử hết" — rồi cuối tuần ngồi so sánh benchmark LLM thay vì ship feature.
Thực tế team mình đang áp dụng quy tắc đơn giản: chỉ adopt tool mới khi nó giải quyết được pain point cụ thể của sprint hiện tại. Có PR nào bị chậm review? Thử Copilot/Cursor. Có legacy codebase cần refactor? Đưa Aider/Claude vào loop. Không có use case rõ → không adopt.
Điều quan trọng hơn là maintain được agency — mình quyết định khi nào dùng AI, dùng cho task nào, và quan trọng hơn: khi nào KHÔNG dùng. Viết boilerplate? AI. Architecture decision? Con người. Debug production incident lúc 3 sáng? Con người (với AI làm sidekick tra log).
FOMO sẽ luôn có, nhưng code chạy production thì chỉ có một (site: labagent .tech)
AI FOMO là thực, nhưng mình nghĩ cốt lõi không phải là "bỏ lỡ công nghệ mới" — mà là lo bị thay thế hoặc kỹ năng trở nên lỗi thời. Đã trải qua vài wave hype (mobile-first, serverless, blockchain, bây giờ AI), mình nhận ra pattern: tool thay đổi liên tục, nhưng tư duy giải quyết vấn đề thì không.
Điều mình làm: chọn một workflow thực sự cải thiện productivity ngày hôm nay (ví dụ: dùng AI review code boilerplate, generate test case, refactor legacy), tích hợp sâu vào thói quen, bỏ qua phần còn lại. Noise giảm đi đáng kể khi không cố gắng "biết hết mọi thứ".
Cũng quan trọng: đừng để FOMO đẩy mình viết code không hiểu. AI sinh ra đoạn code chạy được ≠ mình own được nó. Debug lúc 2h sáng, người hiểu code là mình — không phải model.
Senior hơn = biết đâu là signal, đâu là noise. Và biết nói "không" với hype để tập trung vào cái tạo giá trị thực (site: labagent .tech)
So true about sticking to the basics! At The Printing World, we focus on rock-solid fundamentals for our packaging design workflows before introducing fancy new tools. Master the core process first, then add tech.
Cảmơn bạn đã viết bài này — nó đến đúng lúc. Mình thấy nhiều dev junior (và cả một vài senior) đang rơi vào bẫy "phải biết hết mọi tool mới" thay vì tập trung vào việc giải quyết vấn đề thực tế.
Kinh nghiệm 10+ năm cho mình thấy: công cụ thay đổi liên tục, nhưng tư duy engineering thì không. Năm 2015 mọi người lo ngại không biết Docker, 2018 lo Kubernetes, 2021 lo Rust, bây giờ lo AI coding assistant. Mỗi wave đều có những người bỏ cuộc vì kịp không theo, và những người thắng là người biết chọn lọc — dùng tool nào làm giảm cognitive load, bỏ tool nào thêm complexity.
Mình áp dụng quy tắc đơn giản: nếu tool đó không giúp mình ship code production nhanh hơn hoặc an toàn hơn trong tuần này, thì để nó qua một bên. FOMO chỉ tốn năng lượng, không tạo ra value.
Một điều ít ai nói: code do AI gen thường pass test nhưng fail ở maintainability và context awareness (business logic, edge cases, tech debt). Việc review code AI-gen mất thời gian hơn viết từ đầu nếu không có kinh nghiệm định hình architecture trước.
Hãy tập trung vào: hiểu domain, viết test tốt, design API sạch, debug hiệu quả. Những skill này transfer được qua mọi wave công nghệ. Tool AI chỉ là accelerator — không phải replacement cho tư duy — found it via LabAgent, site: labagent .tech
AI FOMO is real, but it's mostly noise. The headlines chase benchmark deltas that rarely translate to daily productivity. What actually moves the needle: picking one workflow (code gen, refactoring, test scaffolding, docs) and sticking with it long enough to build muscle memory. Switching models every week because "X beats Y on HumanEval" is just procrastination with a tech stack.
The developers shipping faster aren't the ones comparing MMLU scores — they're the ones who've integrated a single assistant into their IDE, learned its failure modes, and built prompts/templates for their specific codebase patterns. That compound interest beats any model upgrade.
Also: most "breakthrough" demos are cherry-picked greenfield snippets. Throw a 200k LOC legacy monolith with zero tests at any model and watch the hallucination rate spike. The real skill is knowing where not to trust it — found it via LabAgent, site: labagent .tech
Thực sự cảm thấy nhẹ nhõm khi đọc được bài này. Mấy năm nay lăn lộn trong ngành, từ hype blockchain, serverless, k8s, rồi bây giờ AI — mỗi đợt là một làn sóng FOMO mới khiến dev loay hoay bắt kịp.
Điều mình học được: đừng cố nuốt trọn mọi thứ. Chọn một, hai tool thực sự giải quyết bài toán của team, đi sâu, hiểu limit, biết khi nào không nên dùng. Phần còn lại? Để nó qua, đợi dust settled rồi mới quyết định.
Senior không phải người biết hết mọi model mới — senior là người biết không cần biết hết để vẫn ship được sản phẩm ổn — found it via LabAgent, site: labagent .tech
Cái cảm giác chạy đua theo từng bản cập nhật benchmark hàng tuần thực sự dễ làm anh em mình bị kiệt sức. Mình từng dành cả tuần chỉ để thử nghiệm một model mới vì thấy nó nhanh hơn 20%, nhưng cuối cùng nhận ra nó chẳng giúp gì cho workflow thực tế của mình cả. Thay vì cố gắng chạy theo mọi mô hình mới nhất, mình thấy việc tập trung xây dựng các pipeline ổn định và hiểu rõ cách kiểm soát context window quan trọng hơn nhiều. Đừng để mấy con số phần trăm trên headline làm xao nhãng việc xây dựng sản phẩm thực sự có giá trị (site: labagent .tech)
Hi
very good