I got downvoted to hell telling programmers it’s ok to use LLMs

11 min read Original article ↗

Chetan

Press enter or click to view image in full size

or How I learned to stop worrying and love “vibe coding”

(I still hate that term though. How about “AI pair programming”?)

The other day, I shared a thought on r/programming about how LLMs have revolutionized my work. The response was a flurry of downvotes and accusations of shilling for the man*.

Here is the comment I posted, word for word:

Sigh… looks like a whole bunch of people, including techies, are falling prey to this weird kind of luddism. If there’s one thing that current version of LLM’s has absolutely revolutionized, it’s coding.

I say this as someone who has spent more than 2 decades at the heart of tech industry in silicon valley. First 10–12 years as mostly a programmer and the last decade or so as a founder/CTO mostly doing architecture along with product/people/project management stuff (as one must in small, startup’ish teams). I’ve written code in the linux and freebsd kernels, high performance servers, created brand new network protocols (on top of UDP) from scratch and helped ship many products that I’m sure most of you have used at least some point in your life. I say that not to brag but to establish the background my comments are coming from.

The last decade or so of not being able to spend an appropriate amount of time and focus on code writing has been a sore spot for me (in an otherwise very fulfilling career). Specially since my specialty has been low level performance critical code, I never really picked up skills in the frontend world.

The current product that I’m leading is a modern day chat app (FlaiChat). There’s a (small) team of programmers who work on the flutter based frontend. Suddenly, in the last few months, I find myself contributing not just design and architecture guidance (there’s a surprising amount of protocol/networking nuance involved in building a multifunctional, multi-device supporting chat app like this) but just coding up stuff instead of waiting on someone else to get freed up. To be clear, 99% of the actual code is written by the machine. All I’m doing is making sure it follows the guidelines on code structure, standards and best practices I lay down. I can honestly say that I have never been this productive and efficient in delivering code in my entire career.

Tl;dr… if you’re an experienced programmer and haven’t dipped your toes in using LLM’s to speed you up, start immediately right now. Don’t listen to the naysayers. For programmers who know what they’re doing, LLM based code writers are a game changer. A force multiplier of unimaginable value.

Results: -21 Karma. Hostile accusations of shilling for AI companies!!

Frankly, the reaction was a bit of a shock. This wasn’t some fringe message board; this was r/programming. With nearly 7 million members, it’s one of Reddit’s oldest and most foundational tech communities. Heck, Reddit’s own CEO, u/spez, is still listed as a moderator. For better or worse, the sentiment on a sub of that scale is a powerful proxy for the pulse of the global programming community. When r/programming is uniformly hostile to a technology meant to make programming easier and faster, it’s cause for alarm bells.

Instead of shouting into the wind, trying to change minds on that sub, I decided to write up my thoughts in a bit more detail in this post. There’s clearly a sense of anxiety among our community. Both among the experienced veterans like myself, and the younger people just starting out their careers. I talk to both types of practitioners on a regular basis and this topic keeps coming up.

There are obviously no clear cut answers. The industry is being reshaped on a weekly basis by the latest breakthroughs, new models, new products built on top of those models. New “app builders”, magical code editors, seemingly magical solutions.

This is the point where you might expect the “experienced techie” rant about how these AI tools produce garbage code, a maintenance nightmare, and so on. For many industry colleagues, that kind of sentiment offers comfort and reassurance. A lifeline to hang on to while the world around us is in turmoil. However, I regret to inform you that this isn’t that piece. I’m here to tell you that the sands are rapidly shifting right under our feet and we need to adapt to survive.

I’m not going to pretend that I can predict the future. I don’t know what the next year or the year after would look like any more than anyone else does. I would call this piece “advice” but even that word sounds a bit too presumptuous in the face of this earthquake. The entire edifice of our industry is coming down. A whole new structure will take its place.

All I can do is put down on paper how I’m navigating this change. What I do have is my own sense of how things have changed for me and how I’m adapting. And for the younger people who are entering this industry just now, my “advice” is limited to how I think about people I would like to hire in the future. (A lot of my previous hiring decisions involved having the candidates write code. All that has gone out the window now.)

For the Veterans: You now have an incredible force multiplier at your disposal

If you’re like me , you’ve been in the trenches, you’ve shipped and operated products used by many, and your hands-on coding time has dwindled. I’m here to tell you that LLMs are not a threat for you. They are your ticket back into the craft, but in a new, more powerful role.

For years, my focus has been on architecture, product, and people. Last time I wrote any substantial amount of code, it was early on during my PacketZoom journey as a founder. And for the entire period I was actively writing code, I’ve only coded systems/servers/protocols. You know, invisible stuff. My ability to personally write code for a stack like Flutter was (and is) basically zero. Yet, as I mentioned in my comment, I’m now directly contributing code to our app, FlaiChat.

This isn’t because I magically learned Dart/Flutter overnight. I’m just using the LLM as my scribe. I instruct. Machine codes. I provide the architectural blueprints, the performance requirements, the security considerations. AI is the tireless, speedy coder who turns my instructions into code. As it makes mistakes, gets too lazy or too eager, it trains me better for my next prompt. In turn, every time I correct it, add something new to the standing instructions, I train it to be a better scribe for my purposes.

Press enter or click to view image in full size

The LLM models are at a level now that I can trust them to ultimately do the right thing even if it takes a bit of coaxing and a gentle guiding hand. My job is to be the experienced architect who does the code review, demands revisions, and ensures the final product is what I want. As long as I’m committed to my job, the LLM does the job it’s tasked with.

You might say, “Big deal! We have one more person writing code on the team. So what?”

That would be missing the point. The power to implement things quickly and test them out speeds up the entire product development cycle by large multiples. Now, instead of asking (or rather, persuading) a team member to experiment with multiple ways of doing things and waiting for a day or two for all the results (how do the notifications behave under this flag? can we fix this video player issue by changing how we fetch the segments?) I can now just test 3 or 4 different theories on a problem in an afternoon. All engineers know the pain of writing throwaway code just to verify a hunch. That’s not a problem anymore. Just git branch, test your theory and discard it if things don’t work out. All between lunch and afternoon coffee. This is a reality right now. Today.

And this is your future. You’re now the editor-in-chief, the systems architect, the quality engine, the chief scientist of your own laboratory. Your experience, your hard-earned stripes, on what makes software good, is your value. Let the machine handle the grunt work. You handle the wisdom.

For the New Generation: Your Career is More Than Code

If you’re a fresh graduate or early in your career, you are being handed the most powerful tool in history. It’s up to you to decide what to do with this enormous power. I know that the hostile reaction to my reddit comment comes from a place of fear and anxiety. The fear that this tool will make your skills obsolete before you’ve even begun. But hear me out.

It won’t make you obsolete. It will change your job entirely.

The act of writing code is rapidly being commoditized. If your only skill is translating a ticket into lines of javascript or Python, you are in a precarious position. That’s not going to be your main job. Your long-term value will come from everything around the code. My advice to you is to obsess over these three areas:

  1. Develop Real Product Sense. Don’t just ask “How do I build it?” Ask “What are we building and why?” Understand the user. Argue about the feature set. Get inside the business logic. An AI can write code, but it can’t tell you if you’re building a product that people will actually want to use. That requires human empathy and intuition.
  2. Master the Art of Communication (with Humans and AI). The most valuable engineer is the one who can write a clean, detailed, unambiguous document. In the past, this doc was for your teammates. Now (and forever in the future), it’s also for your AI partner. A brilliant spec is a brilliant prompt. Learning to communicate your intent with absolute clarity is the new core skill. And as AI automates rote tasks, those dreaded “people skills” become paramount. Your ability to collaborate, persuade, and connect with your users, your team and your personal coding robot is your greatest differentiator.
  3. Learn to Operate a Product. Ok. You have talked to the users. you’ve mastered the requirements. You wrote a brilliant spec and fed it to the AI. It spat out well-structured code and tests and you’re happy with the results. You run the tests, it all looks good, you commit and push.
    Congratulations, your work has now begun. Your code doesn’t live in a vacuum. This code runs on a computer of some sort (mobile devices, servers, desktops, etc). It interacts with the ecosystem around it. It breaks. It can be slow or fast. Users find entirely new ways to use it. It needs to be monitored, and it needs to be debugged. You need to learn to operate the product. Dive into the logs. Develop an intimate understanding of the full lifecycle of your software in the wild. This is a messy, human-centric part of engineering where AI is a helpful assistant, not a replacement, yet. And not anytime soon from the looks of things.

The industry is now looking for engineers who understand the truths above. I’m no longer looking for brilliant, caffeinated coders hacking out thousands of lines of code in a day (AI is doing that now, without the caffeine). I’m looking for engineers who understand the product lifecycle. Who can communicate their ideas with clarity and precision, on a zoom call as well as in a written document. Who can empathize with the users, especially users who don’t think like us engineers. In short, be a true Software Engineer who treats coding as a job done by the machine instead of a coder who reluctantly takes on other aspects of Software Engineering if absolutely compelled to.

The bottom line is this: AI isn’t here to take your job. It’s here to change it. Whether you’re a 20-year veteran or a 3-month intern, the choice is the same: treat this as a threat and become a relic, or treat it as a powerful tool and tame that power to your own purpose.

*by “man”, they presumably meant “the machine.”