We do not interview for this nor care about it, despite using agentic and code complete tooling heavily. It's not a deep technical skill like C++ that requires years of hands-on experience. Spend a few weeks getting comfortable with Claude Code and you're probably at about parity with most devs.
That seems like sort of a red flag to me to have that as a job requirement.
This has been my thought all along, not sure why I don't see it more. I'm not scared about being left behind, none of the tooling looks crazy enough that a few weeks of dedicated learning wouldn't catch me up.
The framing of "is vibe coding a job requirement" conflates two things: the skill of coding-by-prompting, and the skill of knowing what you need to build.
The second one is genuinely underrated. Knowing your problem well enough to describe a working solution, the inputs, the logic, the outputs, who uses it, is hard to automate. Generating the actual app from that description is increasingly not.
We've been using Lyzr Architect (architect.new) for this; you describe the agentic app you want in plain English, it generates a full-stack React frontend + multi-agent backend and deploys a live URL. The "vibe coding" is more like a product spec conversation than an IDE session. The people who are best at it aren't coders, they're people who understand their problem deeply.
You're describing two different jobs though, "what you need to build" is supposed to be done by the army of "product managers/owners" or whatever they're called, rather than letting the programmer do that, and the product managers/owners whole reason for existing is figuring out what to build, what not to build and how the thing should work.
If you end up having engineers do the work of product people, you'd end up with the typical "engineered mess" that might be very fast, and lots of complicated abstractions so 80% of the codebase can be reused, but no user can make sense of it.
Add in LLMs that tend to never push back on adding/changing things, and you wend up with deep technical debt really quickly.
I admit that vibe coding was kind of a clickbaity way to frame this, but I couldn't think of a better way to describe it. That might just underscore my ignorance in this domain.
One problem I personally have here is that I write code as a way to reason through and think about a problem. It's hard for me to grasp the best solution in a space until I try some things out first.
I don't think vibe coding is becoming mandatory, but writing software using AI assistance is. I find Salvatore Sanfilippo's distinction between vibe coding and 'automatic programming' useful. [0]
To be perfectly honest, I wouldn't work at a firm that requires vibe-coding. The hype train in tech is honestly nauseating, and the so-called productivity boost neither shows up in the data nor in qualitative elements (like shovelware on GitHub or firms moving faster).
Vibe coding seems like a religion more than anything to me: engineers go and use techniques for prompting but rarely actually test those techniques relative to other ones. There is especially no evidence that vibe coding is a skill: the people most effective with these tools are people who would've been most effective without them (i.e. it relies on experience and domain knowledge).
If I were currently actively hiring and I wanted to capture skills that likely will translate well to an AI-augmented work strategy, I would focus on "code review" in the interview. I've only seen a handful of truly great, rigorous code reviewers in my career, but AI makes code review supremely important. Unfortunately, most of the real world "agentic coding" I've seen is light in review (lots of LGTMs!).
I think that firms are going to eventually collapse under their own weight unless models continue improving at the velocity slop is merged into main.
I will also note that I do use these tools, mainly as a search engine, and I do so in hiccups (I will use the tools for a month and then completely abstain for 1-2 months). I am worried about undermining my own cognitive fitness by overreliance on these tools.
We won’t hire anybody moving forward who doesn’t have hands-on agentic programming experience. We’re in the traditionally slower moving GovTech space. I have to imagine this is now a common expectation in many sectors.
Teams where I work can use Claude Code, Codex, Cursor, and Copilot CLI. Internally, it seems like Claude Code and Codex are the more popular tools being used by most software teams.
If you’re new to these tools, I highly recommend trying to build something with them during your free time. This space has evolved rapidly the past few months. Anthropic is offering a special spring break promotion where you can double the limits on weeknights and weekends for any of its subscription plans until the end of March.
> We won’t hire anybody moving forward who doesn’t have hands-on agentic programming experience.
This doesn't make a lot of sense to me even as someone who uses agentic programming.
I would understand not hiring people who are against the idea of agentic programming, but I'd take a skilled programmer (especially one who is good at code review and debugging) who never touched agentic/LLM programming (but knows they will be expected to use it) over someone with less overall programming experience (but some agentic programming experience) every single time.
I think people vastly oversell using agents as some sort of skill in its own right when the reality is that a skilled developer can pick up how to use the flows and tools on the timescale of hours/days.
I suspect it’s not about agentic coding being a special skill, and more about why a competent programmer wouldn’t have tried it by this point, and whether that is a sign of ideological objections that could cause friction with the team. Not saying I agree with that thinking, but I definitely see why a hiring manager could think that way.
I can't get into that hiring manager's head. It shouldn't matter, if the candidate can deliver business value. That's what you are hiring them for. You're not hiring them to burn LLM tokens, you're hiring them to create business value. Why would you care if he does it by hand-coding, using an LLM, or chanting magic spells at the computer?
Don't shoot the messenger, I'm just telling you how some hiring managers might think, not endorsing the opinion and it's definitely not something I consider in my hiring.
I will say it's a little weird to frame it as "every fad" though. Do you really not see any net new or lasting utility for software engineering in AI tools? If not then more power to you, but software engineering being a fast-moving field where there are (fair or unfair) expectations to keep up is nothing new.
I certainly keep an eye on these developments, but I think the jury is still out on how useful/beneficial they actually are in practice. Generating more code in less time is not a useful measure of productivity for me.
Agree the jury is still out, but "More code in less time" is a shallow strawman. The better question is what is it good at and what is it not good at, and what are the ways to best leverage those capabilities. I've seen enough use cases from enough engineers now that I firmly believe anyone saying "nope never useful" is sticking their head in the sand.
On the contrary. That's the only kind of competent software engineer in 2026. Competent engineers don't hand things off to the tool that generates terrible code really quickly.
Many companies cannot take advantage of it. Not everyone is making toy CRUD web applications to help consumers purchase things they don't want. Some people are making safety critical applications, and many more are making highly sensitive applications.
At my job, we just got agents. Because we had to self-host them in our new data center. Our product isn't the kind that can be used with Claude or Gemini, like, legally.
So you just said that you couldn’t use coding agents because you are doing “very important things”, while you clutch your pearls about what other people are doing but your company is in fact using coding agents…
Right. Using Claude Code & friends is not some esoteric skill that needs years in the trenches to learn which magical incantations to utter.
You prompt it. That's it. Yes, there are better and worse ways of prompting; yes, there are techniques and SKILLs and MCP servers for maximizing usability, and yes, there are right ways to vibe code and wrong ways to vibe code. But it's not hard. At all.
And the last person I want to work with is the expert vibe coder who doesn't know the fundamentals well enough to have coded the same thing by hand.
Yeah, will they take someone who has two months of hands-on with Claude Code, just not someone with zero? Come on, I'll take a great programmer with zero who knows they need to use it over a mediocre programmer who's been doing it since Claude Code released and I expect to be better off for doing so within 2 weeks.
Random question but what are some issues your facing with these ? I am just curious because everyone in my org uses them but act like it doesn't bring them any productivity gains probably they are scared to admit that it's actually been super helpful otherwise they are out of a job.
> Random question but what are some issues your facing with these ?
I’ve seen some folks who are quite productive with these tools, but there is a lot more slop too. On my team on same the code base you see two different team members producing vastly different results.
If you're technically competent, as in you can program pretty well, you can pick up agentic programming fast. Like, in a week, max. And I don't mean be okay-enough. I mean be just as good as people who have been agentic coding this whole time.
And, at the end of the day, a person who can program will be better at agentic coding after a couple days than someone who cannot program who has been agentic coding for a year.
Agentic coding is just not all that complicated. It's a deep rabbit hole, sure, but figuring out how to prompt an AI is not that complicated. The harness can be, the skills might be, the subagent architecture maybe. But your organization should be standardizing that stuff. I would hope to God. Catching someone up to speed is very quick.
But, if you hire good engineers, you will be have a competently engineered product. That has always been the case and will continue to be the case. If you hire sales people and product managers, it will not. Again, that's always been the case.
The distinction between coding-by-prompting and knowing what to build is the right one, but I'd push it further.
The problem with vibe coding isn't the coding part — it's that people are trying to think through their product while they're building it. That's always been a bad idea. AI just makes the consequences arrive faster.
Good product thinking happens before you touch any tool. What problem are you actually solving? For whom? What does success look like? What are you not building? These questions don't get easier with LLMs — if anything, because you can generate plausible-looking output so quickly, it's easier than ever to convince yourself you've answered them when you haven't.
The vibe coding mess isn't an AI problem. It's a 'skipped the thinking' problem that AI has made cheap enough to do at scale.
So many companies and products were built on a pivot. Why try to imagine the exact problem, user, success, etc. when you can build in seconds (or more reasonably days) and then find the right users' problems to rebuild around from actual users?
It might feel like kicking the can down the road. But it's a much more informed decision when users churn or they don't. And you can reach that decision point just about as quickly as a long thinking/planning phase.
Thinking while building is bad when paying multiple high-dollar humans for months per rebuild. It's arguably better when a full redesign costs you $10.57.
Depending on your standards, seems like a potential indicator of companies to avoid?
Personally I still believe that despite AI being moderately useful and getting better over time, it's mostly only feasible for boilerplate work. I do wonder about these people claiming to produce millions of lines of code per day with AI, like what are you actually building? If it's then Nth CRUD app then yeah, I see why... Chances are in the grand scheme of things, we don't really need that company to exist.
In roles that require more technical/novel work, AI just doesn't make the cut in my experience. Either it totally falls over or produces such bad results that it'd be quicker for a skilled dev to make it manually from scratch. I'd hope these types of companies are not hiring based on AI usage.
When doing more technical / novel work you can’y vibe code it but you can still use ai tools to make things faster. Having Claude implement small chunks with strict direction and oversight is underrated in my opinion. Or just using it to search the codebase (where is the code that does x), implement tests, and do code review are all helpful. There is a lot of e-peen measuring around vibe coding but I think it’s really not the must useful workflow, it’s just chasing a dream.
Sure! I went through my Claude history and pulled out some of the most recent ones (anonymized a bit). I had it write code when it was rote / boilerplate work to save time, and other than that I used it more to discuss the code rather than write it for me. In between these, I was writing code myself.
Writing code:
- can you remove this <zustand store> and move the state here into <a new slice in a different zustand store>
- Can you update the unit tests for the working copy changes that need test updates / created (it wrote a bunch of tests which were satisfactory, I just deleted some redundant ones)
- I removed this <TypeName> type can the usages in this file be safety replaced with <OtherType>? (it analyzed the type differences, confirmed it was safe, and made the replacement, though an IDE could have done the replacement too)
- Can you fix this type error (it built a type guard function to address it, which is boilerplate code)
- is there a way to add the output here not just the input (it found a way to plumb some context through the codebase that I needed, pretty rote)
Other stuff I did in this time:
- can you review the code in commit <hash> (been doing this a lot)
- Seems my changes in this branch has broken <feature>. can you add logging to help me diagnose what is now wrong, and also analyze the git history to maybe get some theories on what maybe broke it (this can save a lot of time, digging through git history manually can be time consuming)
- This file doesn't work as expected anymore given that we've implemented <feature>. Can you investigate (another good time save, it's good at digging through a bunch of changes quickly)
Oh definitely seems like it. In Australia, at least, I am seeing job ads from recruiters with titles like "AI Engineer" or asking for "LLM-assisted development" or "agentic development" and so on.
I noticed that some of these roles come from businesses that recently had layoffs and were now asking their staff to "do more with less" so not exactly places people would be eager to work at, unless they have to.
I don't know if this is the new norm but this craziness is not helped by the increase in the number of "AI influencers" pushing the hype. Unfortunately, I've been seeing this on HN a lot recently.
The old copy/paste from StackOverflow was essentially vibe coding, it just took a bit more effort. I saw plenty of people Google their way to code that technically worked, without having any idea how or why.
If someone has been doing that for 10 years and learning nothing, that would be a huge red flag. One that will likely become more common has LLM usage increases.
Vibe coding is definitely the future. The real issue is that the industry is not ready to fully embrace it yet. My suggestion is to keep working on traditional software engineering for now, but use vibe coding to build your own side projects. One day, that will give you the power to start your own business. Believe me!
I realise that this is not always practical. But generally I refuse to engage or negotiate about the way I work. Especially if you have a lot of experience, you have to push back when people want to drag you in the mud and wrestle about which tools you use.
A good company will not try to micro manage you as an Engineer in that way.
I think recruiters would like to see what candidates will do when get some free time. It is not really a lifestyle. It is a short amount of time. Maybe couple of weekends, before they get some other work or get laid off.
E.g., Nobody wants to continue working with someone who create sound effects, movie player, operating system, etc.
This is personal. I wouldnt like to work with someone who is creating sound effects or rap songs etc. Every sound is some piece of pain. Doing html-web stuff is more useful. Internet is a good thing. Noone knows how the internet works still. Sound-movie makes it understanding even more difficult. It is the click sound of browser originally.
Well the rap and audio plugins are created by some people. It's ok, but I am not ok with it. Having a musician career on Spotify is a lie. It is only vibe draggingdrop or code. I prefer my coworkers doing html-programming work kind of vibe coding.
Its a valuable tool that I'd argue everyone is still figuring out how to do it well and the best practices keep changing rapidly. Even more so than everyone was figuring out how to do software well in the first place. Almost all of the best practices are made up, not validated, and kind of magical thinking.
I couldn't imagine wanting to hire someone who doesn't use LLMs for coding unless they are bringing something very special to the table. It accelerates many coding tasks significantly. But you have to know the limitations to use them efficiently and that only comes with experience.
I don't understand why anyone would want to work for a firm that will not allow their employees to do their entire job properly, but will instead insist that they delegate a large portion of it via natural language of all things to some stochastic parrot from hell and hope after enough iterations of this that it will all somehow turn out okay. This sounds like a complete nightmare! To be frank, this entire situation is absurd and honestly sours me on the entire field.
Even just using them for prototyping is a big gain. While they do have monetary cost to run, they massively reduce the time cost of experimenting.
They can also waste a lot of time if you end up over-reliant on them, but that's where experience with LLMs comes in. The nature of them means it's not an exact science, but you get a feel for how to best apply them.
In the same way that typing is a job requirement. It's just how you interface with the code now.
A decent company wouldn't necessarily look for someone who can type faster or commit 100x more code like the vibers do, but look into how you understand the code.
Everything is a skill, depending on what the company values. Early on I used to do work for temp agencies, and they'd care about the ability to use (even on a rudimentary level) Microsoft Word, Excel, and how fast you could type. I'm sure you wouldn't care about anything like that, but it's about the same level of complexity as interacting with codex/claude today.
Assume that the people falling over themselves to issue apocalyptic proclamations in response to such a question are... likely not representative. (And may not even be software engineers.)
But man, I'm sure glad I left FAANG when I did. All this hysterical squawking over AI sounds utterly insufferable. If Claude was forced upon me at my job I would have likely crashed out at some point.
Building software with llm is easier than you imagine. I'd be surprised if you just don't pick it up. No need to lie, just open codex or claude and give it a try.
I'd say that a this point, if your job involves computers and you aren't at least familiar with how you can leverage AI tools, you're basically admitting that you really enjoy the art of working with one hand tied behind your back.
That's not vibe coding. Imagine if you were hiring a chef and a candidate came in who'd never used a stove. Sure, technically there are other ways to heat food, but it would be a bit odd.
I think AI assisted coding is a new job requirement, and I think the more I do it the more I’m convinced it’s going to wreck productivity. And it’s not because these tools aren’t as good as people say they are, it’s because they’re too good.
Everyone talking about vibe coding all your dependencies and the problem is that the people who are good with these tools and do get 50% or greater productivity benefits won’t be able to empathize with the people who are bad with these tools and create all the slop.
I think AI encourages people to take side quests to solve easy problems and not focus on hard problems.
That without domain expertise problems will compound themselves. But I dunno, I agree that they’re here to stay.
I'm already seeing people becoming enamored and proud of output quantity over quality. There were always people off focusing on tangents and low value efforts. Now they can drown an entire team or org in low effort(or low valu) slop.
It'll require stronger and more frequent push back to keep under control.
There is a big difference between vibe coding and using an LLM to assist with coding. Vide coding is just accepting what ever slop it outputs and saying LGTM. You are not going to get quality code that way. You need to review what it does. I often find that it uses outdated libraries and deprecated functions.
Some ways an LLM can assist with coding:
I recently needed to refactor a bunch of code. Claude was very helpful this and it completed in about 5 minutes what would have taken me a couple of hours by hand.
Also they are very handy when using new frameworks and libraries. As we all know documentation for open source projects is often lacking. Just yesterday I ran into this. I pointed Claude at the projects GitHub repo and had the answers to my questions in just a couple of minutes. Manually I would have been spending a hour or two reading the code to figure out what I needed.
They are very handy when debugging. Get a weird hours that makes no sense. Instead of banging your head against the wall for a few hours, an LLM can help you find the problem much quicker.
I feel like people genuinely don't understand what vibe coding means.
Just cause you're using an LLM doesn't mean you're "vibe coding".
I regularly use LLMs at work, but I don't "vibe-code", which is where you're just saying garbage to the model and blindly clicking accept on whatever is spit out from it.
I design, think about architecture, write out all of my thoughts, expected example inputs, expected example outputs, etc. I write out pretty extensive prompts that capture all of that, and then request for an improved prompt. I review that improved prompt to make sure it aligns with the requirements I've gathered.
I read the output like I'm doing a deep code review, and if I don't understand some code I make sure to figure it out before moving forward. I make sure that the change set is within the scope of the problem I'm trying to solve.
Excluding the pieces that augment the workflow, this is all the same stuff you would normally do. You're an engineer solving problems and that domain you do it in happens to involve software and computers.
Writing out code has always been a means to an end. The productivity gains if you actually give LLMs a shot and learn to use the tools are real. So yes, pretty soon it's going to become expected from most places that you use the tools. The same way you've been expected to use a specific language, framework, or any other tool that greatly improves productivity.
At my company, we ask everyone in the hiring process about how they have used any kind of agentic coding tools.
We're not concerned about hiring for the 'skill' of using these things, but more as a culture check - we are a very AI-forward company, and we are looking for people who are excited to incorporate AI into their workflow. The best evidence for such excitement is when they have already adopted these tools.
Among the team, the expectation is that most code is being produced with AI, but there is no micromanager checking how much everyone is using the AI coding tools.
If we're talking about the ability code via prompting, then I would think so. However, I don't think its a skill that a reasonable competent dev can't pick up in a couple of weeks.
But yet again, if you've never touched any form of agentic coding in 2026 that probably says something about your character.
The accountability asymmetry feels like the real problem. The person prompting claims completion; the reviewer absorbs the cleanup. That gap exists because there's no record of what the agent actually decided — just the output, not the sequence that produced it. If you had a trace of tool calls and decision points, at least you'd know where the slop came from and who should own it. Right now review is just guessing backwards.
Here’s another question. Has anyone been able to get an agent to produce reliable high quality code?
My first experience with it was a year ago and the tests it produced were so horrendously hard to maintain that I kinda gave up, but I imagine that things have gotten a lot better in the last year.
Agentic AI-assisted coding is an intrinsic part of the job now. Companies would be leaving lots of money on the table if they didn't take advantage of the 10x/50x/100x productivity gains. If you don't have the skills, learn. Shape up or ship out.
It depends on the task. There are certain tasks which are too tedious, time-consuming, and error-prone to be valuable for humans to perform, and couldn't be automated effectively until LLMs came along. Eric Raymond has cited a shortening of some tasks from weeks to hours. Andreas Kling managed to lift the JS runtime for his browser Ladybird to Rust from C++ in a couple of weeks, some 25,000 lines of code.
The productivity gains are real, and in some cases they are enormous. It is actively, profoundly stupid to pass on them. You need to learn how to work with AI.
Oh for sure, there are _many_ things we defer or value too much for the time they'd have taken otherwise.
But my point is, those are, by definition, lower value. Check back in a big company how much their revenue growth is (which is ultimately the only metric that's hard to game), then the situation changes.
Otherwise, im sure diff per person per day went up 10x. Output in the sense I am talking about is different.
We do not interview for this nor care about it, despite using agentic and code complete tooling heavily. It's not a deep technical skill like C++ that requires years of hands-on experience. Spend a few weeks getting comfortable with Claude Code and you're probably at about parity with most devs. That seems like sort of a red flag to me to have that as a job requirement.
This has been my thought all along, not sure why I don't see it more. I'm not scared about being left behind, none of the tooling looks crazy enough that a few weeks of dedicated learning wouldn't catch me up.
The framing of "is vibe coding a job requirement" conflates two things: the skill of coding-by-prompting, and the skill of knowing what you need to build. The second one is genuinely underrated. Knowing your problem well enough to describe a working solution, the inputs, the logic, the outputs, who uses it, is hard to automate. Generating the actual app from that description is increasingly not. We've been using Lyzr Architect (architect.new) for this; you describe the agentic app you want in plain English, it generates a full-stack React frontend + multi-agent backend and deploys a live URL. The "vibe coding" is more like a product spec conversation than an IDE session. The people who are best at it aren't coders, they're people who understand their problem deeply.
You're describing two different jobs though, "what you need to build" is supposed to be done by the army of "product managers/owners" or whatever they're called, rather than letting the programmer do that, and the product managers/owners whole reason for existing is figuring out what to build, what not to build and how the thing should work.
If you end up having engineers do the work of product people, you'd end up with the typical "engineered mess" that might be very fast, and lots of complicated abstractions so 80% of the codebase can be reused, but no user can make sense of it.
Add in LLMs that tend to never push back on adding/changing things, and you wend up with deep technical debt really quickly.
Edit: Ugh, apparently you wrote your comment just to push your platform (https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...) which is so trite, apparently HN is for people to push ads about their projects now...
I admit that vibe coding was kind of a clickbaity way to frame this, but I couldn't think of a better way to describe it. That might just underscore my ignorance in this domain.
One problem I personally have here is that I write code as a way to reason through and think about a problem. It's hard for me to grasp the best solution in a space until I try some things out first.
> + multi-agent backend
Does that mean you need AI subscriptions just to run your backend? That explodes costs even more than opaque cloud pricing. Sweet!
I don't think vibe coding is becoming mandatory, but writing software using AI assistance is. I find Salvatore Sanfilippo's distinction between vibe coding and 'automatic programming' useful. [0]
[0] https://antirez.com/news/159
To be perfectly honest, I wouldn't work at a firm that requires vibe-coding. The hype train in tech is honestly nauseating, and the so-called productivity boost neither shows up in the data nor in qualitative elements (like shovelware on GitHub or firms moving faster).
Vibe coding seems like a religion more than anything to me: engineers go and use techniques for prompting but rarely actually test those techniques relative to other ones. There is especially no evidence that vibe coding is a skill: the people most effective with these tools are people who would've been most effective without them (i.e. it relies on experience and domain knowledge).
If I were currently actively hiring and I wanted to capture skills that likely will translate well to an AI-augmented work strategy, I would focus on "code review" in the interview. I've only seen a handful of truly great, rigorous code reviewers in my career, but AI makes code review supremely important. Unfortunately, most of the real world "agentic coding" I've seen is light in review (lots of LGTMs!).
I think that firms are going to eventually collapse under their own weight unless models continue improving at the velocity slop is merged into main.
I will also note that I do use these tools, mainly as a search engine, and I do so in hiccups (I will use the tools for a month and then completely abstain for 1-2 months). I am worried about undermining my own cognitive fitness by overreliance on these tools.
We won’t hire anybody moving forward who doesn’t have hands-on agentic programming experience. We’re in the traditionally slower moving GovTech space. I have to imagine this is now a common expectation in many sectors.
Teams where I work can use Claude Code, Codex, Cursor, and Copilot CLI. Internally, it seems like Claude Code and Codex are the more popular tools being used by most software teams.
If you’re new to these tools, I highly recommend trying to build something with them during your free time. This space has evolved rapidly the past few months. Anthropic is offering a special spring break promotion where you can double the limits on weeknights and weekends for any of its subscription plans until the end of March.
> We won’t hire anybody moving forward who doesn’t have hands-on agentic programming experience.
This doesn't make a lot of sense to me even as someone who uses agentic programming.
I would understand not hiring people who are against the idea of agentic programming, but I'd take a skilled programmer (especially one who is good at code review and debugging) who never touched agentic/LLM programming (but knows they will be expected to use it) over someone with less overall programming experience (but some agentic programming experience) every single time.
I think people vastly oversell using agents as some sort of skill in its own right when the reality is that a skilled developer can pick up how to use the flows and tools on the timescale of hours/days.
I suspect it’s not about agentic coding being a special skill, and more about why a competent programmer wouldn’t have tried it by this point, and whether that is a sign of ideological objections that could cause friction with the team. Not saying I agree with that thinking, but I definitely see why a hiring manager could think that way.
I can't get into that hiring manager's head. It shouldn't matter, if the candidate can deliver business value. That's what you are hiring them for. You're not hiring them to burn LLM tokens, you're hiring them to create business value. Why would you care if he does it by hand-coding, using an LLM, or chanting magic spells at the computer?
I was only granted permission to use it a few weeks ago and haven’t had time to set it up yet
> why a competent programmer wouldn’t have tried it by this point
What does one have to do with the other? Since when is following every fad a prerequisite for competence?
Don't shoot the messenger, I'm just telling you how some hiring managers might think, not endorsing the opinion and it's definitely not something I consider in my hiring.
I will say it's a little weird to frame it as "every fad" though. Do you really not see any net new or lasting utility for software engineering in AI tools? If not then more power to you, but software engineering being a fast-moving field where there are (fair or unfair) expectations to keep up is nothing new.
I certainly keep an eye on these developments, but I think the jury is still out on how useful/beneficial they actually are in practice. Generating more code in less time is not a useful measure of productivity for me.
Agree the jury is still out, but "More code in less time" is a shallow strawman. The better question is what is it good at and what is it not good at, and what are the ways to best leverage those capabilities. I've seen enough use cases from enough engineers now that I firmly believe anyone saying "nope never useful" is sticking their head in the sand.
If you aren't taking advantage of it, you are not a competent software engineer in 2026.
On the contrary. That's the only kind of competent software engineer in 2026. Competent engineers don't hand things off to the tool that generates terrible code really quickly.
Many companies cannot take advantage of it. Not everyone is making toy CRUD web applications to help consumers purchase things they don't want. Some people are making safety critical applications, and many more are making highly sensitive applications.
At my job, we just got agents. Because we had to self-host them in our new data center. Our product isn't the kind that can be used with Claude or Gemini, like, legally.
So you just said that you couldn’t use coding agents because you are doing “very important things”, while you clutch your pearls about what other people are doing but your company is in fact using coding agents…
Claude has been a big boost to my sense of competency. I get to point out so many poor solutions in slop PRs now
Right. Using Claude Code & friends is not some esoteric skill that needs years in the trenches to learn which magical incantations to utter.
You prompt it. That's it. Yes, there are better and worse ways of prompting; yes, there are techniques and SKILLs and MCP servers for maximizing usability, and yes, there are right ways to vibe code and wrong ways to vibe code. But it's not hard. At all.
And the last person I want to work with is the expert vibe coder who doesn't know the fundamentals well enough to have coded the same thing by hand.
Yeah, will they take someone who has two months of hands-on with Claude Code, just not someone with zero? Come on, I'll take a great programmer with zero who knows they need to use it over a mediocre programmer who's been doing it since Claude Code released and I expect to be better off for doing so within 2 weeks.
Random question but what are some issues your facing with these ? I am just curious because everyone in my org uses them but act like it doesn't bring them any productivity gains probably they are scared to admit that it's actually been super helpful otherwise they are out of a job.
> Random question but what are some issues your facing with these ?
I’ve seen some folks who are quite productive with these tools, but there is a lot more slop too. On my team on same the code base you see two different team members producing vastly different results.
> On my team on same the code base you see two different team members producing vastly different results.
And if they use LLMs to assist, does the same thing happen?
If you're technically competent, as in you can program pretty well, you can pick up agentic programming fast. Like, in a week, max. And I don't mean be okay-enough. I mean be just as good as people who have been agentic coding this whole time.
And, at the end of the day, a person who can program will be better at agentic coding after a couple days than someone who cannot program who has been agentic coding for a year.
Agentic coding is just not all that complicated. It's a deep rabbit hole, sure, but figuring out how to prompt an AI is not that complicated. The harness can be, the skills might be, the subagent architecture maybe. But your organization should be standardizing that stuff. I would hope to God. Catching someone up to speed is very quick.
But, if you hire good engineers, you will be have a competently engineered product. That has always been the case and will continue to be the case. If you hire sales people and product managers, it will not. Again, that's always been the case.
The distinction between coding-by-prompting and knowing what to build is the right one, but I'd push it further.
The problem with vibe coding isn't the coding part — it's that people are trying to think through their product while they're building it. That's always been a bad idea. AI just makes the consequences arrive faster.
Good product thinking happens before you touch any tool. What problem are you actually solving? For whom? What does success look like? What are you not building? These questions don't get easier with LLMs — if anything, because you can generate plausible-looking output so quickly, it's easier than ever to convince yourself you've answered them when you haven't.
The vibe coding mess isn't an AI problem. It's a 'skipped the thinking' problem that AI has made cheap enough to do at scale.
Thinking first just isn't cost-effective anymore.
So many companies and products were built on a pivot. Why try to imagine the exact problem, user, success, etc. when you can build in seconds (or more reasonably days) and then find the right users' problems to rebuild around from actual users?
It might feel like kicking the can down the road. But it's a much more informed decision when users churn or they don't. And you can reach that decision point just about as quickly as a long thinking/planning phase.
Thinking while building is bad when paying multiple high-dollar humans for months per rebuild. It's arguably better when a full redesign costs you $10.57.
Depending on your standards, seems like a potential indicator of companies to avoid?
Personally I still believe that despite AI being moderately useful and getting better over time, it's mostly only feasible for boilerplate work. I do wonder about these people claiming to produce millions of lines of code per day with AI, like what are you actually building? If it's then Nth CRUD app then yeah, I see why... Chances are in the grand scheme of things, we don't really need that company to exist.
In roles that require more technical/novel work, AI just doesn't make the cut in my experience. Either it totally falls over or produces such bad results that it'd be quicker for a skilled dev to make it manually from scratch. I'd hope these types of companies are not hiring based on AI usage.
When doing more technical / novel work you can’y vibe code it but you can still use ai tools to make things faster. Having Claude implement small chunks with strict direction and oversight is underrated in my opinion. Or just using it to search the codebase (where is the code that does x), implement tests, and do code review are all helpful. There is a lot of e-peen measuring around vibe coding but I think it’s really not the must useful workflow, it’s just chasing a dream.
Out of curiosity, can you elaborate on the size and nature of the "small chunks"? I'm very curious for examples!
Sure! I went through my Claude history and pulled out some of the most recent ones (anonymized a bit). I had it write code when it was rote / boilerplate work to save time, and other than that I used it more to discuss the code rather than write it for me. In between these, I was writing code myself.
Writing code:
- can you remove this <zustand store> and move the state here into <a new slice in a different zustand store>
- Can you update the unit tests for the working copy changes that need test updates / created (it wrote a bunch of tests which were satisfactory, I just deleted some redundant ones)
- I removed this <TypeName> type can the usages in this file be safety replaced with <OtherType>? (it analyzed the type differences, confirmed it was safe, and made the replacement, though an IDE could have done the replacement too)
- Can you fix this type error (it built a type guard function to address it, which is boilerplate code)
- is there a way to add the output here not just the input (it found a way to plumb some context through the codebase that I needed, pretty rote)
Other stuff I did in this time:
- can you review the code in commit <hash> (been doing this a lot)
- Seems my changes in this branch has broken <feature>. can you add logging to help me diagnose what is now wrong, and also analyze the git history to maybe get some theories on what maybe broke it (this can save a lot of time, digging through git history manually can be time consuming)
- This file doesn't work as expected anymore given that we've implemented <feature>. Can you investigate (another good time save, it's good at digging through a bunch of changes quickly)
Hope this was of interest to you!
Oh definitely seems like it. In Australia, at least, I am seeing job ads from recruiters with titles like "AI Engineer" or asking for "LLM-assisted development" or "agentic development" and so on.
I noticed that some of these roles come from businesses that recently had layoffs and were now asking their staff to "do more with less" so not exactly places people would be eager to work at, unless they have to.
I don't know if this is the new norm but this craziness is not helped by the increase in the number of "AI influencers" pushing the hype. Unfortunately, I've been seeing this on HN a lot recently.
In fact, they want 10 years of vibe coding experience
The old copy/paste from StackOverflow was essentially vibe coding, it just took a bit more effort. I saw plenty of people Google their way to code that technically worked, without having any idea how or why.
If someone has been doing that for 10 years and learning nothing, that would be a huge red flag. One that will likely become more common has LLM usage increases.
They want people who not get scared of getting their hands dirty. There is something like perfectionism trap. It is very difficult to manage that.
hey 10 years for a junior position your going to need like 25 years for a senior level position.
Vibe coding is definitely the future. The real issue is that the industry is not ready to fully embrace it yet. My suggestion is to keep working on traditional software engineering for now, but use vibe coding to build your own side projects. One day, that will give you the power to start your own business. Believe me!
I realise that this is not always practical. But generally I refuse to engage or negotiate about the way I work. Especially if you have a lot of experience, you have to push back when people want to drag you in the mud and wrestle about which tools you use.
A good company will not try to micro manage you as an Engineer in that way.
I think recruiters would like to see what candidates will do when get some free time. It is not really a lifestyle. It is a short amount of time. Maybe couple of weekends, before they get some other work or get laid off.
E.g., Nobody wants to continue working with someone who create sound effects, movie player, operating system, etc.
> E.g., Nobody wants to continue working with someone who create sound effects, movie player, operating system, etc.
What do you mean by this?
This is personal. I wouldnt like to work with someone who is creating sound effects or rap songs etc. Every sound is some piece of pain. Doing html-web stuff is more useful. Internet is a good thing. Noone knows how the internet works still. Sound-movie makes it understanding even more difficult. It is the click sound of browser originally.
So when you bring this up with your coworkers, do they tell you just what to do with or where to put your value judgments of their hobbies?
Well the rap and audio plugins are created by some people. It's ok, but I am not ok with it. Having a musician career on Spotify is a lie. It is only vibe draggingdrop or code. I prefer my coworkers doing html-programming work kind of vibe coding.
Its a valuable tool that I'd argue everyone is still figuring out how to do it well and the best practices keep changing rapidly. Even more so than everyone was figuring out how to do software well in the first place. Almost all of the best practices are made up, not validated, and kind of magical thinking.
I couldn't imagine wanting to hire someone who doesn't use LLMs for coding unless they are bringing something very special to the table. It accelerates many coding tasks significantly. But you have to know the limitations to use them efficiently and that only comes with experience.
I don't understand why anyone would want to work for a firm that will not allow their employees to do their entire job properly, but will instead insist that they delegate a large portion of it via natural language of all things to some stochastic parrot from hell and hope after enough iterations of this that it will all somehow turn out okay. This sounds like a complete nightmare! To be frank, this entire situation is absurd and honestly sours me on the entire field.
Even just using them for prototyping is a big gain. While they do have monetary cost to run, they massively reduce the time cost of experimenting.
They can also waste a lot of time if you end up over-reliant on them, but that's where experience with LLMs comes in. The nature of them means it's not an exact science, but you get a feel for how to best apply them.
In the same way that typing is a job requirement. It's just how you interface with the code now.
A decent company wouldn't necessarily look for someone who can type faster or commit 100x more code like the vibers do, but look into how you understand the code.
Jesus Christ. Imagine reading these comments even just a year ago.
Don’t know/care about coding with AI? You’re unhireable now. Grim.
HN has a disproportionate quantity of 23yo founders trying to vibe-code the "Stripe for pickleball gyms" or whatever. Don't fret about it
It's not a skill. Seriously. It's pretty simple to get started, just open codex/claude, and give it a shot.
Everything is a skill, depending on what the company values. Early on I used to do work for temp agencies, and they'd care about the ability to use (even on a rudimentary level) Microsoft Word, Excel, and how fast you could type. I'm sure you wouldn't care about anything like that, but it's about the same level of complexity as interacting with codex/claude today.
Assume that the people falling over themselves to issue apocalyptic proclamations in response to such a question are... likely not representative. (And may not even be software engineers.)
But man, I'm sure glad I left FAANG when I did. All this hysterical squawking over AI sounds utterly insufferable. If Claude was forced upon me at my job I would have likely crashed out at some point.
Building software with llm is easier than you imagine. I'd be surprised if you just don't pick it up. No need to lie, just open codex or claude and give it a try.
dead internet theory is really taking grip
I'd say that a this point, if your job involves computers and you aren't at least familiar with how you can leverage AI tools, you're basically admitting that you really enjoy the art of working with one hand tied behind your back.
That's not vibe coding. Imagine if you were hiring a chef and a candidate came in who'd never used a stove. Sure, technically there are other ways to heat food, but it would be a bit odd.
lol what. This is more like a chef who reheats tv dinners and sometimes taste them in case theres mold
Bizarre perspective. Imagine if you were hiring a chef and you found out they mostly do not go in the kitchen?
I think AI assisted coding is a new job requirement, and I think the more I do it the more I’m convinced it’s going to wreck productivity. And it’s not because these tools aren’t as good as people say they are, it’s because they’re too good.
Everyone talking about vibe coding all your dependencies and the problem is that the people who are good with these tools and do get 50% or greater productivity benefits won’t be able to empathize with the people who are bad with these tools and create all the slop.
I think AI encourages people to take side quests to solve easy problems and not focus on hard problems.
That without domain expertise problems will compound themselves. But I dunno, I agree that they’re here to stay.
I'm already seeing people becoming enamored and proud of output quantity over quality. There were always people off focusing on tangents and low value efforts. Now they can drown an entire team or org in low effort(or low valu) slop.
It'll require stronger and more frequent push back to keep under control.
There is a big difference between vibe coding and using an LLM to assist with coding. Vide coding is just accepting what ever slop it outputs and saying LGTM. You are not going to get quality code that way. You need to review what it does. I often find that it uses outdated libraries and deprecated functions.
Some ways an LLM can assist with coding: I recently needed to refactor a bunch of code. Claude was very helpful this and it completed in about 5 minutes what would have taken me a couple of hours by hand.
Also they are very handy when using new frameworks and libraries. As we all know documentation for open source projects is often lacking. Just yesterday I ran into this. I pointed Claude at the projects GitHub repo and had the answers to my questions in just a couple of minutes. Manually I would have been spending a hour or two reading the code to figure out what I needed.
They are very handy when debugging. Get a weird hours that makes no sense. Instead of banging your head against the wall for a few hours, an LLM can help you find the problem much quicker.
I have seen it for a number of positions, but it seems ridiculous.
I feel like people genuinely don't understand what vibe coding means.
Just cause you're using an LLM doesn't mean you're "vibe coding".
I regularly use LLMs at work, but I don't "vibe-code", which is where you're just saying garbage to the model and blindly clicking accept on whatever is spit out from it.
I design, think about architecture, write out all of my thoughts, expected example inputs, expected example outputs, etc. I write out pretty extensive prompts that capture all of that, and then request for an improved prompt. I review that improved prompt to make sure it aligns with the requirements I've gathered.
I read the output like I'm doing a deep code review, and if I don't understand some code I make sure to figure it out before moving forward. I make sure that the change set is within the scope of the problem I'm trying to solve.
Excluding the pieces that augment the workflow, this is all the same stuff you would normally do. You're an engineer solving problems and that domain you do it in happens to involve software and computers.
Writing out code has always been a means to an end. The productivity gains if you actually give LLMs a shot and learn to use the tools are real. So yes, pretty soon it's going to become expected from most places that you use the tools. The same way you've been expected to use a specific language, framework, or any other tool that greatly improves productivity.
At my company, we ask everyone in the hiring process about how they have used any kind of agentic coding tools.
We're not concerned about hiring for the 'skill' of using these things, but more as a culture check - we are a very AI-forward company, and we are looking for people who are excited to incorporate AI into their workflow. The best evidence for such excitement is when they have already adopted these tools.
Among the team, the expectation is that most code is being produced with AI, but there is no micromanager checking how much everyone is using the AI coding tools.
If we're talking about the ability code via prompting, then I would think so. However, I don't think its a skill that a reasonable competent dev can't pick up in a couple of weeks.
But yet again, if you've never touched any form of agentic coding in 2026 that probably says something about your character.
The accountability asymmetry feels like the real problem. The person prompting claims completion; the reviewer absorbs the cleanup. That gap exists because there's no record of what the agent actually decided — just the output, not the sequence that produced it. If you had a trace of tool calls and decision points, at least you'd know where the slop came from and who should own it. Right now review is just guessing backwards.
Here’s another question. Has anyone been able to get an agent to produce reliable high quality code?
My first experience with it was a year ago and the tests it produced were so horrendously hard to maintain that I kinda gave up, but I imagine that things have gotten a lot better in the last year.
Agentic AI-assisted coding is an intrinsic part of the job now. Companies would be leaving lots of money on the table if they didn't take advantage of the 10x/50x/100x productivity gains. If you don't have the skills, learn. Shape up or ship out.
There's no 100x productivity gain. No company shipped their products 100x faster except their very first versions.
It depends on the task. There are certain tasks which are too tedious, time-consuming, and error-prone to be valuable for humans to perform, and couldn't be automated effectively until LLMs came along. Eric Raymond has cited a shortening of some tasks from weeks to hours. Andreas Kling managed to lift the JS runtime for his browser Ladybird to Rust from C++ in a couple of weeks, some 25,000 lines of code.
The productivity gains are real, and in some cases they are enormous. It is actively, profoundly stupid to pass on them. You need to learn how to work with AI.
Oh for sure, there are _many_ things we defer or value too much for the time they'd have taken otherwise.
But my point is, those are, by definition, lower value. Check back in a big company how much their revenue growth is (which is ultimately the only metric that's hard to game), then the situation changes.
Otherwise, im sure diff per person per day went up 10x. Output in the sense I am talking about is different.