I recently joined a new company. The engineering team in SG is quite lean, with 6 ppl in total, including frontend, backend, and QA.
As a backend engineer, my day-to-day work always revolved around backend logic anyway. However, there is one major twist with this new role: I barely need to write actual code anymore.
The rise of AI Agents has drastically reduced the time I spend on writing technical design(TD) or implementing features. This has allowed me to focus on the most critical part of joining any new team:
to understand business domain.
Incredible Output in Just 14 Days
Before this, I had absolutely zero experience in ad-tech (my current team focuses entirely on ad delivery). Facing an unfamiliar business and system architecture, I heavily relied on LLMs’ strength — semantic analogy — to flatten the learning curve. I was able to quickly pick up industry-specific jargon on our business dashboards, from “channels” and “attribution” to the precise formulas behind various metrics.
Within just 2 weeks, I achieved the following:
- Gained a solid understanding of our core systems
- Delivered 2 technical + 1 business features
- Designed 2 short-term system architectures
- Documented over 10 feasible system optimization proposals
And these are just the pieces actually put into team docs folder. On top of that, AI helped me digest the background of over 30 product requirements in the PM’s backlog, as well as several potential business directions of my team.
A Realistic Comparison: In a traditional onboard,staring at legacy codebase and reading outdated docs, would take me about 1 month to just feel confident when making system changes. Even then, that would be under the assumption that requirements were already clearly defined and the TD were mostly written. Now, AI compressed that entire onboarding cycle down to 2 weeks.
As a tool for picking up new domains, LLMs are phenomenal. However, using them this intensely has also forced me to see their clear limitations.
Why “Grep AI” Misses the Mark?
At the end of the day, an LLM is just a probabilistic model. “Reliability” and “rigor” are traits that are fundamentally difficult for it to possess. (heavily rely on parser coming together)
Lately, I’ve seen a wave of open-source projects and articles claiming that LLMs can completely replace traditional text-searching tools (projects like grepai or various semantic search implementations). These tools use semantic search as their core logic, and their names suggest an ambitious goal to phase out classic utilities like grep or ripgrep.
But if you look closer, this trend reveals a worrying shift: the concept of technical rigor seems to be completely thrown out the window.
People no longer seem to care how or why search errors occur. Traditional tools are reliable because their underlying logic is deterministic and strict; there are no gray areas. On the other hand, RAG (Retrieval-Augmented Generation) relies on ANN (Approximate Nearest Neighbor) similarity matching. At best, it gives you what looks “most similar.” It is still a long way off from being “exactly the same.”
The ultimate irony? Even the most powerful AI Agents on the market today (like Cursor) still rely on traditional grep tools under the hood when searching codebases or local files. This makes projects that claim semantic search will replace grep pretty much useless in real engineering environments. Relying on probability to guess precise code logic is simply bad practice.
GEO: A Hype Without an Entrance Ticket
This same logical skepticism applies to business trends. Recently, my team has been discussing GEO (Generative Engine Optimization). I used my AI assistant to retrieve and summarize the current state of this space. After digesting the information, I shared my view with the team: I am highly skeptical of GEO right now, and I believe traditional SEO (Search Engine Optimization) remains far more important.
My reasoning is straightforward:
- The Black Box Problem: There are too many AI tools out there (ChatGPT, Gemini, Claude, Perplexity, etc.). No one actually knows how these models rank or select their generated outputs. Unlike traditional search engines, there is no public algorithm like PageRank to study or optimize against.
- The Retrieval Foundation: When a user submits a query to an AI engine, the system still relies on mainstream search engines like Google or Bing during its initial retrieval phase.
The logic here is undeniable: If your content cannot be crawled and indexed by traditional search engines first, you don’t even have an entrance ticket to the GEO game. Furthermore, there is currently no concrete evidence showing that adopting the standards like llms.txt can increase citation by LLMs.
Conclusion: A New Way of Working
Despite the obvious flaws of probabilistic models, they have introduced a fascinating paradox: they make writing strict, deterministic tools much easier.
It is a highly effective partnership. AI can take care of roughly 80% of your daily routine work—the tasks that do not require extreme precision. This frees you up to act as the architect, using AI to efficiently generate reliable automation scripts that handle the remaining 20% of critical, high-stakes engineering logic.
In the old era, this level of leverage was unthinkable. It drastically lowers the barrier to enter building internal tools, which boosts an engineer’s automation output.
Returning to the tech workforce and adapting to this new workflow is tiring but rewarding. The workstyle of engineering today feels completely different from a few years ago.
I enjoy this leverage, and I will continue to adapt to this trend while keeping an eye on its limits.
This article is part of my career journal. If you are interested in LLM implementation in backend engineering or ad-tech system architectures, feel free to leave a comment or connect.