标签：#career

Back-of-the-envelope estimation for system design interviews Most people don't fail capacity math because the arithmetic is hard. They fail because they do it silently, produce a number they can't defend, and then never use it again for the rest of the interview. The math itself is trivial. The method is what's worth learning. Why interviewers ask Capacity estimation isn't a numeracy test. It's checking two things: Can you tell whether a design is physically possible before you commit to it? Do you know which constraint actually binds — storage, read throughput, write throughput, or bandwidth? A candidate who estimates 30,000 reads/sec and 200 writes/sec has learned something that changes the design. A candidate who computes petabytes of storage and then never mentions it again has just performed arithmetic. Round aggressively Precision is a trap. You're not producing a capacity plan; you're finding the order of magnitude. The single most useful substitution: 1 day = 86,400 seconds ≈ 10^5 seconds That's a 16% error and it makes every subsequent division doable in your head. Nobody will challenge it. Everyone will notice if you spend forty seconds long-dividing by 86,400. A few more worth having ready: 1 million requests/day ≈ 12/sec — round to 10 1 KB × 1 million = 1 GB 1 KB × 1 billion = 1 TB Peak traffic ≈ 2–3× average Replicated storage ≈ 3× raw ## Work in one direction Users → requests → QPS → storage → bandwidth. Don't jump around. Say each assumption out loud and label it as an assumption, so the interviewer can correct you early rather than watch you build on sand. A worked example Say we're designing a social feed. Given: 100M daily active users. Assumptions (stated, not smuggled in): Each user posts 0.2 times/day Each user reads their feed 10 times/day A post averages 1 KB including metadata A feed page shows 20 posts Writes 100M × 0.2 = 20M posts/day 20M / 10^5 = 200 writes/sec Peak (3×) = 600 writes/sec Reads 100M × 10 = 1B feed loads/day 1B / 10^5 = 10,0

If you've been anywhere near AI job postings lately, you've seen the title: Forward-Deployed Engineer. Sometimes it's "Deployment Engineer" or "Solutions Engineer" or "Applied AI Engineer." Sarvam is hiring more than a hundred of them. Palantir built a large part of its business on them. OpenAI, Anthropic, and a long tail of AI startups are all competing for the same people. And yet, if you ask five engineers what an FDE is , you'll get five different answers. Let's fix that. The one-sentence definition A Forward-Deployed Engineer is an engineer who is deployed forward — to the customer — to take a powerful but generic product and make it solve that specific customer's real problem. The word "forward" is borrowed from the military sense: you're not back at HQ, you're out in the field where the actual work happens. For an FDE, "the field" is the customer's environment — their data, their workflows, their constraints, their stakeholders. Think of it as part engineer, part consultant, part founder-in-the-field. You build, but you build for someone specific, sitting right next to you . Why AI companies need this role so badly right now Here's the thing about modern AI products: they're incredibly powerful and incredibly generic . A foundation model or an AI platform can do a thousand things — but an enterprise customer doesn't want a thousand things. They want their one problem solved, with their data, inside their systems, respecting their compliance rules. That gap — between "powerful generic product" and "solves my specific problem" — is exactly where deals are won and lost. And it's too custom, too messy, and too high-stakes to solve with documentation alone. So AI companies send an engineer to close the gap in person. That engineer is the FDE. One strong FDE can be the difference between a seven-figure enterprise contract signing or walking away. That's why the role is: High-leverage — your work directly moves revenue Well-paid — companies pay up for people who can

We've been testing a new project this week. The project's origin story is a mess. Upper management...

Before I hand this over, I want to tell you where I'm actually standing right now. I'm looking at the biggest mountain yet: building our hospital's own ERP and EMR — the systems that run the business side and the medical records side of the whole place. That's usually the job of specialized companies, and it's tangled up with outside regulators too. Nobody knows how long it'll take. I'm assuming at least three years. Honestly, it feels overwhelming. The size of the fear hasn't changed. My grip on it has. Here's the strange part. That overwhelmed feeling isn't unfamiliar at all. A year ago, staring at a blank screen and not knowing what code even was, I felt exactly this lost. What's different isn't the size of the fear. It's that I now know what to do with it. Get curious, look it up. Look it up, a direction shows up. See a direction, find a method, and just start. Fail, and you've learned something. Succeed, and you move to the next thing. That loop is the only thing that ever carried me anywhere , and it's the same loop I'm running at the foot of this much bigger mountain. Right now the wall isn't technical The thing I don't know isn't code. It's other departments. I moved from the treatment room to the planning office not long ago, and I still don't really know how the other departments do their work. You can't automate what you don't understand. So before anything else, I'm doing the one thing that actually comes first: listening. Hearing what people in the field actually need, what's grinding on them, and figuring out the shape of a fix together, one conversation at a time. I've noticed something before, more than once: problems that look completely different from the outside — counting a stack of forms, tracking down misplaced supplies, sorting a pile of ID cards — usually reduce to the exact same shape underneath. Make the pile of things findable. I suspect the same pattern is waiting inside every other department too. I just haven't looked yet. That's how I

Every day, I see discussions about how AI assistants and Copilot are changing software development. And honestly? I agree. AI is helping us save time, automate repetitive work, and learn faster than ever before. But recently, I've noticed something that concerns me. Some interviewers, managers, and even developers are starting to treat AI-generated answers as the "correct" answers. That's where I think we're making a mistake. 🤔 Does Copilot Know Your Responsibilities? We've all seen responses like: "With 10 years of experience, you should know this." But who decides that? Does Copilot know: The projects you've worked on? The systems you've built? The challenges you've solved? The responsibilities you've carried for the last 10 years? The answer is simple: No. Two developers can have 10 years of experience and possess completely different skill sets. One may be an expert in distributed systems. Another may specialize in frontend architecture. A third may have spent years building enterprise applications. Meanwhile, a developer with only 5 years of experience may know a modern technology that none of them have ever needed. Does that make anyone less capable? Absolutely not. It simply means their journeys were different. 🚨 Experience Is Not a Checklist Let's take a different example. Suppose someone has spent 10 years mastering Figma and has become an exceptional designer. Does that automatically mean they should be an expert in Photoshop, Illustrator, CorelDRAW, Sketch, and every other design tool? Of course not. Their expertise reflects the work they've done and the problems they've solved. The same applies to software engineering. Experience is about depth, not knowing everything. ⚠️ The Risk of Over-Relying on AI Don't get me wrong. I use AI. Most developers I know use AI. And it saves hours of effort. But there's a difference between: ✅ Taking help from AI and ❌ Letting AI think for you When every answer, every opinion, and every decision comes from AI, something

Como eu mostro que estou contribuindo? Posso colocar no meu LinkedIn? E no meu currículo, como faço? Foi a partir dessas dúvidas que eu elaborei esse guia pra você que quer contribuir do seu jeito e mostrar às empresas e às pessoas, de forma clara e estratégica, o que você está fazendo. Vamos lá? 👇 Por que eu deveria mostrar no LinkedIn? LinkedIn é a porta de entrada para o mundo corporativo no Brasil e no mundo. É por meio dele que você mostra "trabalho". E tem mais: não é só experiência remunerada que conta como evidência de que você tem conhecimento e prática, mas também tudo o que você constrói de forma voluntária , seja tirando dúvida de alguém, participando de um projeto open-source ou escrevendo sobre o que aprendeu. Recrutador não lê currículo pensando só em carteira assinada. Lê pensando em capacidade . Você contribui com algo para a comunidade e quer colocar isso no seu perfil. Existem 3 formas que você pode usar, e elas podem ser usadas todas juntas ou só uma. Escolha aquela que fizer mais sentido pro seu perfil ou busque por outras pessoas que você admira dentro da comunidade e veja como elas colocaram no próprio perfil. 1. Seção de Experiência Use como experiência sempre que estiver contribuindo de forma profissional pra uma área que você busca. Se você participa de contribuições no GitHub, seja através de código, documentação ou outra forma, use como experiência. Pessoas que também estão ajudando na moderação ou administração (community managers) podem destacar as responsabilidades ou resultados das suas ações por aqui. Exemplo de como preencher no LinkedIn: Cargo: [cargo que você faz] Open Source Empresa: [Nome do projeto/organização] Tipo de emprego: Meio período (ou Voluntário) Local: Remoto, Brasil Descrição: - Contribuí com [X] pull requests na documentação do projeto [Nome], focando em clareza para novos contribuidores. - Revisei issues abertas e sugeri melhorias de acessibilidade em componentes de UI usando [ferramenta/stack]. - Participei de re

Everyone is arguing about AI ROI right now. Boards want a number. Consultants are selling frameworks. And the headlines look brutal: an MIT report claimed 95% of enterprise GenAI pilots showed no measurable return, and a Forbes piece this January says 56% of CEOs see zero ROI from AI. So AI is a bust, right? Here is the thing. Ask any of those same companies to turn off email for a week. Just try it. Nobody ever ran a six month ROI study on email. Nobody had to. It became the way work happens, and the return stopped being a line item because it was everywhere. I think AI is following the same path, and the data backs it up. The gap between the pilot and the person That same MIT report has a stat that got way less coverage than the 95% number: 90% of employees regularly use personal AI tools for work, while only 40% of companies have an official LLM subscription. Workers adopted it at more than twice the rate of their own employers. The report even found that 70% of workers prefer AI over a colleague for quick stuff like drafting emails and basic analysis. So the official pilot fails its KPI review while the people inside the building are quietly using AI multiple times a day. That is not a failed technology. That is a measurement problem. Worth noting: the 95% figure itself has been heavily criticized. It came from 52 interviews and a narrow definition of success. I would not build a strategy on that number in either direction. Why the ROI is invisible The value seems to be landing in the same place email's value landed: the unglamorous middle of the workday. Drafting the reply. Summarizing the thread. Turning messy notes into something you can send. None of that shows up as a new revenue line. It shows up as an hour you got back and immediately spent on something else. You cannot easily measure that, but you can feel it. Take the tools away from a developer who has been using them for a year and watch what happens. People cannot imagine working without it anymore.

Your resume tells people what you’ve done. Your GitHub shows what you’ve built. But your personal website tells people who you are. When I started learning web development, I believed that a good resume and a few GitHub repositories were enough. Like many students, I spent countless hours building projects, solving coding problems, and learning new technologies. Every new project felt like a milestone, yet all of them remained scattered across different platforms. A recruiter would have to open my resume, visit my GitHub, search for my LinkedIn profile, and perhaps never even discover the articles I had written or the experiments I had built. That made me realise something important. Developers need a place on the internet that they truly own. Not another profile. Not another social media account. A place that represents their identity, work, and journey. That’s what a personal website becomes. More Than Just a Portfolio Many people hear the words personal website and immediately think of a portfolio with a few screenshots and a contact form. A great developer website goes much further. It answers questions before anyone has to ask them. Who are you? What technologies do you enjoy working with? What problems have you solved? What kind of developer are you becoming? What have you learned recently? How can someone reach you? Instead of forcing visitors to jump across five different platforms, everything exists in one carefully designed experience. Your Name Deserves a Home Every developer works hard to build projects. Very few work equally hard to build their own identity. When someone searches your name, what should they find? Ideally, the very first result should be something you completely control. A website with your own domain isn’t just another webpage. It’s your digital home. Unlike social platforms, algorithms cannot redesign your identity overnight. You decide what visitors see first. You decide which projects matter. You decide how your story is told. Resume

I've spent my career helping people build software. This is a series of letters about what happens when the tools for building change faster than the principles behind building. Each one is a reminder that while the technology changes quickly, the questions that matter often stay the same. -- Dear past Jenna, The thing that drew you to tech in the first place, that it's always changing, is the thing that will keep you here. Tools change (sometimes for the better and sometimes not) almost weekly. People who never consider themselves technical, much less a developer, will build apps in an afternoon with this new programming language called English. Products will go from idea to deployed before you finish your first cup of coffee (you have a toddler now, so you rarely get the full cup before it goes cold anyways). "I don't know how to code" or "I'm not technical" is no longer a barrier to building. And that's exciting, given you've focused nearly your entire career helping others build software. But we can't confuse the ability to build with the wisdom to build. One of the most valuable habits you've developed over the last two decades is asking a simple question: "Should we build it?" For most of your career, "Can we build it?" was a hard question. Time, budget, complexity, maybe the tech wasn't there yet. But those constraints were usually temporary. With enough people, time, and money, just about anything is possible. But the real questions were always: Should we build this? Is this the best use of our time? Does this solve a problem our customers actually need solved, or does it create new problems? What are we choosing not to build? Those questions haven't changed, but the environment around them has. Today, almost anyone can build software. Between tools like Lovable, Bolt, Replit, Claude Code, Codex, and whatever's next, the barrier to building software is lower than it's ever been. Now the question "Can we build it?" is too easy to answer. It's almost always ye

A practical roadmap for students who want to build real AWS skills, create an impressive portfolio, and prepare for cloud engineering careers. Introduction Every year, thousands of students begin learning AWS. They watch training videos, collect certificates, complete online courses, and share digital badges on social media. Yet when internship interviews or entry-level cloud engineering opportunities arrive, many struggle to answer a simple question: "What have you actually built on AWS?" The cloud industry rewards practical experience, not passive learning. AWS itself focuses beginner learning on hands-on experience with foundational services such as Amazon S3, Amazon EC2, Amazon VPC, Amazon RDS, and cloud security because these services power most real-world cloud environments. If you're a student aiming for a career in Cloud Engineering, DevOps, Site Reliability Engineering (SRE), Solutions Architecture, or Platform Engineering, this article provides a practical roadmap that can help you become job-ready. Why Students Should Learn AWS Cloud computing has become the backbone of modern technology. Companies of every size use cloud platforms to: Host applications Store data Deploy AI workloads Build scalable systems Reduce infrastructure costs Improve reliability As a result, companies continue to hire professionals with cloud skills across software engineering, cybersecurity, DevOps, networking, and data engineering domains. AWS offers dedicated learning paths, hands-on labs, certification tracks, and career-focused programs specifically designed to help learners develop these skills. The key question is not: "Which AWS service should I memorize?" The better question is: "Can I design, deploy, secure, and troubleshoot cloud solutions?" The 5 AWS Projects Every Student Should Build Instead of completing another course, build these five projects. Project 1: Host a Static Website Using Amazon S3 What You'll Learn Cloud Storage Static Website Hosting Bucket Policies O

Every day, the internet quietly convinces us that we're running out of time. A 19-year-old launches...

Something happened in 2026 that should be on every engineer's radar, especially if you work in finance, healthcare, government, or anywhere regulated. The US government labeled an American AI company a national security supply-chain risk. That had never happened before. Whatever you think of the politics, the professional lesson underneath it is big, so let me walk through it plainly. What actually happened The Department of Defense terminated a contract with Anthropic worth an estimated $200 million. The breakdown wasn't about price or performance. It was about how the military could use the AI. Anthropic's CEO, Dario Amodei, objected to a clause that allowed the military "any lawful use" of the model. Anthropic wanted the contract to explicitly rule out things like domestic mass surveillance and autonomous weapons, and refused to sign without those limits. The government wanted fewer restrictions. When talks broke down, the Secretary of War, Pete Hegseth, formally designated Anthropic a "Supply-Chain Risk to National Security." That label is normally reserved for foreign adversaries and hostile telecom vendors, think of how the US treated Huawei. This was the first time it had ever been applied to an American company, and reportedly the first time it was used because a company wouldn't agree to certain contract terms. OpenAI then stepped in to take the Pentagon work Anthropic had walked away from. There's a legal coda worth noting for accuracy. In March 2026, a federal judge granted a preliminary injunction against the government, writing that the designation looked like retaliation for Anthropic drawing public scrutiny, which she framed as a First Amendment problem. So the label is being contested in court, not settled fact. Why this matters beyond the headlines Strip away the politics and this is a case study in something every regulated team deals with: what happens when your AI vendor's policies collide with your requirements. Anthropic drew a hard line on use

DISCLAIMER: This post was written entirely by me! I used AI for a little research, spelling, grammar, and comprehension checks. This post was originally shared on Hackernoon Entertain me for a moment, let's appreciate where we are today by understanding where we've been… or at least, where I've been. I remember when I first learned to code. I was bad, like really bad. But I was so curious! It all started by writing some VBA in an MS Access Database to create an IT Inventory app in the late 90s. Then I learned JavaScript, ASP (without the .Net), then C#, .Net ( I still have my .Net for Dummies book, see below) , jQuery, Python, Java, Angular, ReactJS, and Python again (yeah, had to relearn that one for some reason), and I'm sure there are others in there I forgot about. Learning to write code was rewarding! There were those days I'd spend hours on a bug, only to realize I didn't initialize the variable or forgot a semicolon. I learned .Net over a weekend thanks to the above book. I never became an artist of the craft, like some of my colleagues have (you know who you are: Josh, Kevin, and many others), but I knew how to build anything. I loved that ability: I could build anything. Pure joy! If you haven't had the joy of learning to code, do your best to learn it, because you can't prompt your way to being a Senior Engineer . As I progressed in my career, I became an architect and senior lead. I started off by leading a single engineering team, and now I support large programs and teams. All the while, I never let go of hands-on-code. I still love coding for work and my myriad of side projects. Then, a few years ago, this GenAI thing showed up. Put me in that group of: oh-no-there-goes-my-joy. Joy, yes, not my job. I love my job because I get to do what I love. I loved the dramatic rollercoasters: architecting a perfect solution, realizing it's wrong, getting to write every line of code, chasing impossible bugs, panicking with deadlines, late nights chasing hot fixes,

Why Your WeChat Mini-Program Work Is Actually Relevant US data engineering interviews prioritize hands-on experience with data pipelines, SQL, and scalable storage. WeChat mini-programs, though often seen as front-end tools, generate and process substantial backend data. If you designed the logic behind user actions, session management, or real-time updates, you already have transferable skills. The key is to stop describing the mini-program as a "feature" and start describing it as a "data system." Recruiters don't care about WeChat's UI components; they care about how you moved, transformed, and stored data. The Core Translation: From Mini-Program to Data Engineering When rewriting your resume, map each mini-program task to a standard data engineering function: User interaction logic → Event-driven data pipeline (e.g., Kafka, AWS Kinesis, or custom queues) WeChat cloud functions → Serverless compute (e.g., AWS Lambda, Azure Functions) Database reads/writes via WeChat API → NoSQL or relational database operations (e.g., MongoDB, MySQL, DynamoDB) Session tracking or analytics → ETL pipeline extracting user behavior data into a warehouse Do not use WeChat-specific terms like "wx.request" or "Mini Program SDK" without explaining the data they handled. Replace them with equivalent English terms. A Quick Side-by-Side Translation Table WeChat Term US Data Engineering Equivalent WeChat Cloud Database Managed NoSQL database (like MongoDB Atlas) Mini Program Backend with Cloud Functions Serverless data processing (AWS Lambda) User login & session management Authentication pipeline with token storage Real-time message push Event-driven notification system Reshaping Your Bullet Points: Before and After Generic bullet points kill your chances. Here is a concrete rewrite that turns a typical WeChat mini-program description into a data engineering achievement. Before (Chinese-English hybrid, vague): "Developed a WeChat mini-program for e-commerce with 50k users. Used wx.request

It's Monday morning. You open your laptop. Coffee sits beside you. LinkedIn is open in one tab. A job portal is open in another. Your inbox is empty. Before lunch, you've already applied for five jobs. Tomorrow, you'll probably do it all again. This is why people say, "Finding a job is a full-time job." But once you're living it, you realize it isn't just a saying—it's a reality. Unlike a regular job, there's no salary, no weekends off, no annual leave, and no guarantee that today's effort will lead to tomorrow's opportunity. More Than Just Clicking "Apply" From the outside, job hunting looks simple. Upload a resume. Click Apply . Repeat. In reality, every application is a small project. The resume is tailored to match the job description. A cover letter is rewritten. LinkedIn is updated. The company is researched. Interview questions are reviewed. Sometimes a portfolio is improved before clicking Submit . What looks like a two-minute application often takes thirty minutes—or more. Multiply that by dozens of applications, and job hunting quickly becomes a full-time commitment. The Numbers Nobody Sees Fifty applications. Ten automated acknowledgements. Three interview invitations. One final-round rejection. And then... The cycle begins again. Many applications never receive a response. Some positions are filled internally. Others are paused, redefined, or quietly removed. From the candidate's perspective, every unanswered application feels the same—another day without clarity. The system doesn't tell you if you were close. It only tells you if you made it. _ Waiting Becomes Part of the Process After clicking Apply , another phase begins. Waiting becomes part of the routine. Refreshing email. Checking LinkedIn. Looking for missed calls. Hoping today's notification finally brings good news. A rejection can be disappointing. But uncertainty is often harder. At least a rejection provides an answer. Uncertainty leaves people creating their own. The Work Doesn't Stop After

Artificial intelligence is changing the way websites are planned, built, managed, and improved. WordPress developers now have access to tools that can help with coding, content creation, customer support, automation, analytics, and search engine optimization. However, using an AI plugin does not automatically make someone an AI-ready developer. A genuinely AI-ready WordPress developer understands how to combine technical experience, business thinking, automation, and human judgment. The goal is not to add AI everywhere. The goal is to use it where it solves a real problem. AI Should Solve a Clear Business Problem Many businesses make the mistake of choosing an AI tool before deciding what they actually need. A better approach starts with a practical challenge. For example, a company may want to: Respond to customer questions more quickly Organize website enquiries Improve WooCommerce product recommendations Automate repetitive administrative work Connect website forms with a CRM Generate content drafts Analyze customer behaviour Improve internal support processes An experienced developer will first study the workflow, the expected result, the available data, and the possible risks. Only after that should a suitable plugin, API, automation platform, or custom solution be selected. This approach prevents businesses from spending money on features that look impressive but provide little value. AI-Generated Code Still Needs Human Review AI coding tools can produce functions, snippets, plugin ideas, and debugging suggestions within seconds. That speed is useful, especially when a developer is working with repetitive tasks or unfamiliar code. The danger is that AI-generated code may look correct while containing hidden problems. It can include: Outdated WordPress functions Weak security practices Plugin compatibility issues Poor database queries Unnecessary scripts Incorrect assumptions Performance problems That is why generated code should never be added directly to a li

Imagine your AI assistant just produced 200 lines of code. Legally, you may not own a single line of...

24 hours. That's how long a contract lasted before someone pulled it because I was running Windows,...

Try asking this in your next team meeting: "Who on our team is the best at using AI?" There will probably be a moment of silence. Someone thinks of the person who uses the tools the most. Someone thinks of the person who's good with prompts. Someone thinks of whoever recently produced something impressive-looking with AI. But none of these answers feels convincing. There's a gut sense that something is off — and yet nobody knows what the right criterion would be. Nearly every company is standing in front of this wall right now. AI competence is rising to the top of hiring and performance criteria, and there's no yardstick to measure it with. This essay proposes one. The short answer is a set of five axes I call ABCD2. But before that, we need to fix the question itself. The very idea of "good at using AI" is wrong The title of this essay says "good at AI" — but that phrasing is itself the trap. The word "using" carries a hidden frame: AI is a tool, and the person is a user. It puts AI on the same shelf as Excel and Photoshop — something you get skilled at operating. On top of that frame, evaluation naturally becomes a measure of tool proficiency. How many features do you know? How fluently do you operate it? But AI is not a hammer. AI is an engine that judges and executes. It's less like a tool and more like a junior colleague you can delegate work to. And once you think of a junior colleague, the frame flips. Behind every junior who performs well, there is invariably a senior who makes them perform well — someone who explains the context of the work, lays out the criteria for judgment, makes it safe to ask about ambiguities, and verifies the output. That senior isn't "using" the junior. They are making the junior do the work well . AI is exactly the same. The person who truly gets the most out of AI is not the person who is good at using AI, but the person who helps AI do the work well. And what do they help with? Two things, broadly. One is knowledge building — pr

I don’t log in to my LinkedIn account anymore, haven’t done so in years. “AI first this, AI driven that,” alright, alright, I get it! You guys absolutely love AI, and I can’t stand the fact that after almost 5(!!!) years, people still talk about it like it’s the best thing since chicken nuggets. Back when LLMs have started showing somewhat positive results when it came to generating less-than-average code, I came to a devastating conclusion: My friends and colleagues might not actually enjoy coding at all. Maybe they just didn’t enjoy coding the way I do—but either way, I was extremely sad and actively burnt out to find that everybody around me jumped on the prompting bandwagon without giving it much of a critical second thought. I could argue that it was partially because of their employers, but it was definitely because they chose and wanted to. They pressed me “It’s the future, aob2f, we don’t need to write code anymore.” “I just tell Claude to do it, and it’s done.” “I don’t write a single line of code anymore, don’t be left behind.” Some even outrageously claimed “Yeah I reviewed Claude’s 40k lines PR in two days, it was good.” I was baffled. Was I in this sick, absent-minded Truman show spinoff? Were these the same smart, even genius individuals that have built and driven the world’s innovation in the past 30 years with their own hands and minds? It got to a point where I started doubting myself. Maybe it’s really that good? I genuinely gave it a thought. Eventually, I reluctantly gave in and tried vibe coding for the first time… You see, up until then I exclusively used AI as a sophisticated search engine. I asked a technical question—got an answer. More than 50% of the times it was inaccurate or a full-on hallucination, and then I validated the result through trial and error. Admittedly it was better than blindly googling niche bugs and finding nothing but a lonely and vague question from 8 years ago on Stack Overflow. But matter of fact—vibe coding was a mi