What is the actual “skill” in AI dev?
Posted by GolangLinuxGuru1979@reddit | ExperiencedDevs | View on Reddit | 177 comments
I often hear that same talking points regurgitated time and time again about “if you don’t use AI you will be left behind”. That you need AI skills. Here is my question . What is the elusive AI skill that separates devs who do AI and who don’t?
I am no stranger to AI. I started to study machine learning back in 2016 and have mostly kept up with AI innovations since then. I often read papers on AI as well. So while I’m not data scientist or AI expert, I do know the mechanics of how NLP and GenAI works. And have some base level understanding of the math as well.
But I don’t see how that translate into a “skill”. Feels like to me if a dev doesn’t use AI, they can just really figure it out in a few days. What is the big barrier to entry. If anything AI make it where there aren’t any barriers.
The skill is maybe prompt engineering? I’ve been hearing about the elusive “prompt engineering” skill for the last 3 years. And I have yet to understand the skill gap in “prompting”. Feels like any logical person will just figure out the right prompts given enough time.
This also hasn’t translated to interviews either. I’ve interviewed for a few roles in the last 6 months. And they were some sort of job building an AI wrapper. Yet in these interviews ironically they wanted to make sure I wasn’t using AI during their live coding sessions. And even explicitly stated that using AI would immediately disqualify me. And these are known companies and very very large.
So if AI skills are so important then why aren’t you ever asked to show them in interviews? If there is going to me some huge gap between devs who use AI and those who don’t. Then why don’t companies ever evaluate this in interviews and actively discourage it?
To me the 900 lb gorilla in the room is there is no skill gap. Whatever AI skills you could use are negligible. I can see value in using AI to automate things. But most companies don’t give the average dev access to these APIs directly. You’re only meant to interact with these AI models as a basic user in most scenarios.
AI is a tool. Yes. Like an IDE is a tool. But unless you’re working in some sandbox language where you’re forced into a single IDE (like old school 4GLs) you’re never interviewed on your ability to setup and use an IDE. And your ability to use or not use an IDE rarely has any bearing on how good of a dev you are. I like IDEs but there are devs who don’t use them and I’ve met many who are significantly better than I am.
In either case if AI was amazing its value would sell itself to devs. There are devs who are more productive with it. And some who are more productive who out it. My point is it feels less of a skill and more of a preference. No evidence of it making you any better or worse as a dev . And certainly no evidence that it creates a mythical skill gap amongst developers. And again if it does, then explain the skill gap?
tongboy@reddit
Knowing when an answer is bad and dismissing it.
It takes incredible skill to have enough depth and breath of knowledge to know whether a path is worth going down or dismissing on its face.
Knowing when an ai answer is a bad one will save you wasting the time going down the wrong path instead of saying "try again" or adding some small tweak.
The old saying about calling an expert that solves the problem in 5 minutes but charges you 200 dollars. You aren't paying for their time, you're paying for the 20 years it took to learn how to fix it that fast
kbn_@reddit
This is really the answer. Pretty much every engineer in my company uses AI quite heavily. Some get quantitatively better results out of it than others. And not by a small margin either, it’s really night and day. It is absolutely a differentiated skill.
The ones who are getting the best results have all sorts of things they do, but at the end of the day the most important thing is they were already good at guiding and collaborating with human engineers. When you pair with someone very junior, your job is to be on the lookout for the pitfalls that they’re likely to fall into and short circuit them if possible, either by leading them around ahead of time or catching it as it happens. You also need to have an eye on the big picture of how all of everything needs to fit together, because the AI sure as hell can’t. And at the end of the day, you’re responsible for the quality of code being produced, so you need to review it carefully.
Other things also matter a lot in practice, like pushing agents into a TDD loop (they often skip this step), but the biggest thing, far and away, is just the same skill that makes someone good at collaborating with a very junior flesh and blood engineer. That’s what “AI skills” are, as it turns out.
awkreddit@reddit
This has nothing to do with AI in terms of skill though. In fact it's the opposite: being able to recognise a bad solution because you yourself are able to implement it without the AI doing it. So that's not a new skill for experienced Devs to acquire, just like OP was saying.
Spider_pig448@reddit
Applying it to AI seems like a new skill considering how many experienced devs that don't seem able to do this, for whatever reason
Spider_pig448@reddit
Applying it to AI seems like a new skill considering how many experienced devs that don't seem able to do this, for whatever reason
kbn_@reddit
I think that's fair to some extent, but in my experience it takes a bit of ramp up to figure out how to best apply those core skills. Also the realization that you need to apply those core skills is important. So that can probably be rightly termed a form of knowledge/experience.
I agree it's no where near as vast as what a lot of companies are selling though. If you think about it, if "AI skills" were this giant mountain that everyone needs to climb to remain relevant, then AI itself would be kind of poopy wouldn't it? Like, the whole point of AI is that it is meant to be an powerful accelerant while also remaining extremely accessible to human users. How would that point be satisfied if there were some massive upskilling required to use it correctly?
awkreddit@reddit
So it seems like the skill lies in having realized AI is actually not the magical thing people have been selling management?
kbn_@reddit
Something can be very very useful and valuable without being magical. I think that anyone claiming that you can replace engineers with this stuff is high on their own supply, but people saying it's a giant nothingburger are equally off the mark. But at any rate, I noted in another thread that I work on this stuff and I haven't disclosed conflicts of interest, so I'll refrain from arguing too strenuously. :)
wardrox@reddit
Exactly this! To me it feels a little like a coach teaching an athlete; I have the experience and the "back in my day" hard earned skill gained by doing it manually 100 times, and they have the fitness to move really fast but they don't know the nuances.
kbn_@reddit
Exactly!
Where it differs a bit is, unlike with the coach-athlete or the senior-junior pairing session, the AI has absolutely no qualms about me taking the wheel directly and just hand editing some stuff. Sometimes that's faster! One of the traps I see people get locked into is feeling like they aren't allowed to touch the text, and so then you spin around trying to convince the AI to make a one line change that would have taken you five seconds to just type yourself.
sa1@reddit
The other difference is that the AI learns nothing and will make the same mistakes the next session.
kbn_@reddit
Absolutely true. Sometimes I have to remind myself of this, because my instinct is to try to reinforce good behavior.
As someone who actually works on a lot of this stuff though… I wouldn't try to quash that reinforcement instinct just yet. The field is advancing extremely fast, and this is one of the improvement areas that everyone and their mother is focusing on.
Joseda-hg@reddit
To be fair, if you know bad behaviour is likely adding "Don't do X" is reasonably effective as a stopgap
AchillesDev@reddit
Maybe on poorly developed tools, but actual agents have memory systems that are used for this. Even Claude Desktop has this feature.
thekwoka@reddit
Some nicer agentic tools will even review how you changed it to further inform their context.
Specific_Ocelot_4132@reddit
Do you learn that any better from working with AIs than from general software development experience?
Horror-Tank-4082@reddit
This tbh
You’re supervising a project. You can be a good senior dev / manager, or an idiot, and get the results good and bad managers get without AI.
prisencotech@reddit
> The huge printing presses of a major Chicago newspaper began malfunctioning on the Saturday before Christmas, putting all the revenue for advertising that was to appear in the Sunday paper in jeopardy. None of the technicians could track down the problem. Finally, a frantic call was made to the retired printer who had worked with these presses for over 40 years. “We’ll pay anything; just come in and fix them,” he was told.
> When he arrived, he walked around for a few minutes, surveying the presses; then he approached one of the control panels and opened it. He removed a dime from his pocket, turned a screw 1/4 of a turn, and said, “The presses will now work correctly.” After being profusely thanked, he was told to submit a bill for his work.
> The bill arrived a few days later, for $10,000.00! Not wanting to pay such a huge amount for so little work, the printer was told to please itemize his charges, with the hope that he would reduce the amount once he had to identify his services. The revised bill arrived: $1.00 for turning the screw; $9,999.00 for knowing which screw to turn.
Worldly_Weather5484@reddit
These anecdotes bug me.
My take away is that 40 years ago a printing press was poorly designed.
For the following 40 years nobody addressed the poor design or bothered to pass on the knowledge when they left.
Grey beard hoards knowledge and price gouges when someone is in emergency.
Grey beard is seen as a hero.
Boo.
Worldly_Weather5484@reddit
Pointing out the systemic failure of the newspaper is fair, and I have experienced that sort of organisational neglect a few times.
That being said, having worked with a lot of people with a whole host of different skill levels, I have found the person described in this anecdote to be very rare in the real world, especially in software engineering.
The people that tend to solve these sorts of problems are rarely people who have done one thing so much that they have seen everything and just “know”.
I have also worked on teams and lead teams where knowledge is shared and mentoring occurs, and there is no single failure point that “only one person can solve”.
I have also seen many times where junior or mid level engineers approach things with fresh eyes or new ways of approaching things that not only solves these sorts of problems, but actually improves the system as a whole.
If you have worked somewhere for more than 5 years and cannot effectively communicate a failure point to where anyone in the company can turn the screw(or handle whatever major outage the software causes) you are probably not great at your job.
Anyway, here’s wonderwall.
Temporary_Event_156@reddit
It’s weird that’s what you get from the anecdote. But go off.
PublicFurryAccount@reddit
More like for some reason how to calibrate it clearly wasn’t in the manual.
Araganor@reddit
Grey beard probably tried multiple times to fix the faulty press design 30 years ago but management blocked him every step of the way. "It's working fine, why should we pay you to change it? You just need to add on this new color of ink instead"
SwitchOrganic@reddit
Maybe the poor design was addressed in a newer version and the newspaper never upgraded. Or more realistically, the knowledge was passed or documented somewhere, but people weren't paying attention and can't be assed to read docs.
gelatinouscone@reddit
Meh. Most people eschew that kind of technical knowledge. "Knowledge transfer"... what a joke. Anyone laid off knows how much the management class actually cares about that. And who would address updating the poor design over all those years? Oh that's right, management.
Fuck 'em, and rake 'em over the coals when it's time to collect.
creaturefeature16@reddit
Haha I just posted this anecdote on this sub just a few days ago! One of my favorites.
Temporary_Event_156@reddit
Definitely true, but how are all these newbies supposed to learn this if they’re dumping their entire cognitive load onto these AIs and not personally banging their heads against these problems. They’re at the mercy of AI needed to get better to solve any issues because they’ve spent years relying on it to do half of the thinking for them.
mxldevs@reddit
It's like reading PR's lol
failsafe-author@reddit
Isn’t this the same skill as talking to a recent college grad and listening to their designs and reviewing their code?
HaMMeReD@reddit
It's beyond that, it's also knowing how to break down the work into chunks a AI can digest and act on, and being aware of each model, their strengths and weaknesses, as well as each agent and how to best interact with it.
EasyPain6771@reddit
Yep, it’s the same skill as being a good engineer in general, just more important now because you have a confident sounding coworker putting code of questionable quality in front of you.
budding_gardener_1@reddit
Yep. $1 is for their time, the other $199 is for knowing exactly which button to push.
Normal_Fishing9824@reddit
Don't ask me I still use VI
(Neovim actually which for most things beats the pants off expensive IDEs, and can integrate with AI tools)
MENDACIOUS_RACIST@reddit
Making it worn
ruddet@reddit
Setting your agents up with the context it needs to succeed.
Use AI to generate a readme about your source code, use that read me to help future promps. Provide clear acceptence criteria and context about what you're trying to do.
Theres a skill in using AI properly and it involves doing work before hand before you start prompting.
Then the last skill is in being able to review the quality of the output.
cuixhe@reddit
Yesterday, copilot found one line in a config that was borking an entire build.
The day before, it wrote a suite of fairly tedious unit tests for a utility function I wrote.
Both of those saved me a few hours of work, and offloading that drudgery is awesome. Neither of those took any specific "skill" to use, just me asking 2 or 3 times and correcting a little output.
When I see people "making whole apps" with prompting, they're only actually producing impressive but extremely fragile prototypes -- there's probably some skill in "ordering" an AI to build those, but... like... how many engs do you need cranking out prototypes?
Of course, if you're working directly making wrappers or whatever to expose AI functionality, "prompting" seems to be a skill set, but I don't think that's a skill set every single dev needs.
I don't know, I think we're deep within a hype cycle, though I recognize that the tools are legitimately powerful in some circumstances.
Cube00@reddit
If the utility function has a bug the generated tests based in that defective code will find it?
rodw@reddit
Obviously if you are generating tests based on the "spec" implied by the current implementation code alone you're not really testing anything (but there may be some value in creating a test suite that locks-in the existing behavior in order to detect future accidental charges).
In theory (and certainly to some extent in practice too) the AI-based test generation can be more than that
For a trivial demonstration of this note that you can prompt an AI to write a unit test for a class or function that hasn't even been written yet
Cube00@reddit
Unless I'm misreading this from GP
It's not as obvious as I thought it should be.
cuixhe@reddit
Are you assuming I committed this test suite without even reading it?
It was a simple utility function that required tests for a few different, well-defined, arguments. The llm generated those test cases for me; my output would have been more or less the same but I would have spent 30 minutes typing it. No, I wouldn't trust it for something more complicated where bugs could hide in convincing but wrong code. But I feel relatively confident here.
Cube00@reddit
Given the subtle mistakes LLMs introduce, reading generated tests is not an acceptable risk mitigation when you are misusing the code under test as the authority.
softgripper@reddit
This blanket statement is a bit simplistic and naive imo, especially in the context of discussion about people having varying levels of ability when coaxing AI for help.
Some people can do this have have a shit outcome, while others can do it and excellent results that would stand against any manual critique you can imagine.
It's most certainly not "write me test unit tests, herp derp I'm finished".
It depends a lot on diligence and experience of the user. You have to understand the limitations of AI.
Cube00@reddit
Sorry I don't buy the sales pitch of "excellent results" from a hallucinating large language model that can't even manage to be deterministic when given the same inputs.
stikko@reddit
So the skill is being able to judge when this is an appropriate approach or not.
elprophet@reddit
I believe you on the command line config. I don't think it works 100% of the time, but tossing that in and doing other work while it goes through whatever research is worth the low effort to potential reward.
I don't trust your test suite, because that's the take I had the half dozen times I've tried, only to realize I hadn't actually thought about the tests it wrote, and it turns out they were just as fragile as the full app prototypes. I spent more time rewriting them after the fact when the logic changed or a refactor was needed, than I actually saved in not writing them. I've had much better success in asking the LLM to suggest classes of test cases and specific test data, but then I have to be the one who actually translates that into the suite to decide if the value added is real.
The red flag I've picked up is "it saved me drudgery". If there's an engineering task that is drudgery, the engineer is doing it wrong. If it feels like drudgery to write unit tests, the project needs a better test harness, a more testable architecture, or clearer requirements. If it feels like drudgery to take meeting notes, the meetings aren't providing value or the note taker isn't engaged with the meeting.
Cube00@reddit
In the case of unit tests you can bet that so called ''drudgery" is actually thinking about the problem and all the permutations of "that'll never happen".
I'm confident no AI slop is able to match that.
qGuevon@reddit
Tbh I just love it for the low effort boilerplate, then I can add my own tests for the interesting cases.
hardolaf@reddit
I've used reinforcement learning with a well written cost and reward function set to test things in ways that I never imagined. But generative AI doesn't even come 1% close to that.
eightslipsandagully@reddit
The correcting output is the skill. Think about a completely non-technical person trying to complete that same take - without your experience and knowledge do you think they would have identified those issues?
lawrencek1992@reddit
I do use agents who work WITH me and autonomous agents. But on a legacy repo not some fragile prototype. The folks doing that kind of vibe coding frustrate me. They are part of the reason people think AI can do more than it can (though I admit it’s quite capable), but at the same time they are also the people hiring actual engineers to finish the past 10-20% of their apps.
Spyda-man@reddit
This is exactly what I do. I have a not senior (by title) yet but I have had the pleasure of working daily alongside a principal with over 20 years of experience. They push me constantly to build prototypes from the ground up with tons of technologies. Leveraging copilot for some of this has saved me a ton of time mocking up concepts and ideas, as well as general learning, that I have found to be invaluable. Even if the prototype is fragile, I can dig into the code and start to see where and why and learn design principles and patterns that I should actively avoid. Again, I wind up learning a ton of information while re-configuring things the “right way” since I am afforded the luxury building and failing fast while also being able to ask a litany of questions
It certainly helps learn to build architecture designs / diagrams as well; I ask the models to build guides for me to follow. I think the “skill” is in building personalized learning material. But idk
Meeesh-@reddit
LLMs are good at information retrieval. If you know nothing about what you’re looking for, then it’s not helpful, but if you have an idea and know how to verify, then it can be really helpful.
I think of it like a conceptual fuzzy search. We used to have keyword search where you had to have perfect spelling of everything and then we had fuzzy search where you could use misspelled words or slightly different words with the same meaning. Now with LLMs you can explain the concept at a high level and get some answers.
jhartikainen@reddit
The "AI skills" you hear about are a marketing gimmick to sell you something. A course, consulting, AI applications, or AI as a concept to sell you something else later.
The real AI skills people need right now is not something anyone talks about. I would compare the needed skills to critical thinking / critical reading - these are what you need if you listen to people talk about AI, and if you use any AI based tools.
In other words, you need to be able to tell when someone has no idea what they're talking about or be able to tell if they have some kind of an agenda. Because while AI tools can sometimes be useful, they absolutely will hallucinate and say things that make absolutely no sense. If you can't even suspect this is happening, then I would say you lack "AI skills"
8004612286@reddit
If googling is a skill, why can't prompting be a skill?
Which done correctly btw, is definitely harder than the former. At a minimum, if you're working on a large project you would want the AI to manage a whole bunch of context while you're working.
When you work on more complex tasks, your goal should first be developing a prompt plan.
Have you ever seen those examples where AI fucks up some math question? Well feed it that same question, and tell it to do it step by step, checking in with you every time, and it will get it correct almost every time.
I guarantee 90% of this sub hasn't tried doing anything I mentioned above, but they've already decided they're on the "AI useless" train. Would've thought y'all would get tired of all the copy and pasted AI bad posts by now.
Joseda-hg@reddit
The difference between:
"AI, Build me Twitter" and "AI, We're building Twitter, Use $SQL_Database, Use $Language, Avoid $Common_Pitfalls, Follow $Standard_Practices" "The generated code is prone to X problem, implement this fix" "Implementation of $X is flawed because $Y, do $Z instead"
Is that you still have to know mostly the how's and they why's, and depending on what, do the changes manually, because it will be faster
GolangLinuxGuru1979@reddit (OP)
This is just basic reasoning not a “skill”. The skill is the reasoning and expressing the reasoning . So it’s really just the ability to word things correctly for the LLM. And that still isn’t really a skill. At least not a skill very specific to AI. Again it’s a gap in communicating instructions well which isn’t really going to be a key differentiator amongst devs.
RestitutorInvictus@reddit
I'm not so sure about that, by that logic isn't programming itself basic reasoning. Programming genuinely isn't that complicated (at least in my opinion). The challenge is that you need a mindset of actually being willing to engage with the machine on it's terms to be able to program and you need to be able to push through the challenges that you're likely to run into.
GolangLinuxGuru1979@reddit (OP)
I’m not sure it takes a certain change in mindset. You’re just instructing it to do something. And you’re being very explicit about it. The “leap” is a personal one. If you’re not use to communicating in a detailed way in general . Then obviously limitations in your speech and communication style will translate poorly when trying to prompt an AI.
I am a very detailed communicator by default. I’m excessively long winded and tend to over communicate. So for me talking to an AI is trivial. It doesn’t feel like any special skill.
There are prompting techniques like train of thought. But what it really is just chaining prompts together for a longer and more cohesive prompt. Again doesn’t feel like something you couldn’t pick up in a week or so. And let’s be real most people will nail this in a a day
qGuevon@reddit
I checked our MCP Servers and how they are designed in contrast to regular APIs, that was quite interesting to me and I'm pretty sure that will be a proper skill.
Constant-Listen834@reddit
The fact that people on here don’t understand this is honestly mindblowing to me.
TerriblyRare@reddit
OPs point is how long do you think it would realistically take to figure out the right stuff to prompt for an actual good engineer. Longer or shorter than it would take to learn a new framework or programming language? So we hire people that are smart enough but don't work in our specific framework because we know they will be able to figure it out but won't hire someone that we think doesn't know how to prompt properly yet? Doesn't make sense
8004612286@reddit
It's not about "how long", it's about if they will even try to.
chrisippus@reddit
Yes but. I've seen recently a lot of job posts and hiring of "AI developer" and similar for which I have the same doubts as OP. Under the hood it doesn't look like you need a PhD in AI but more having an idea of how pipelines work. When is someone suitable for such a role?
AchillesDev@reddit
AI developer roles I see are building genAI-based products, so you should be comfortable with how to make API calls, build things to be model-agnostic, how to build evals to track performance, observability (this is often different from other observability), how to build and test guardrails, how to build prompts and keep costs down, etc.
chrisippus@reddit
Does it justify having a new title? I assume at this point "GenAI skills" has to be treated at the same level of "Docker experience".
jhartikainen@reddit
Well for something like that, I would expect the job description to include details on what exactly is is they want. If they are actually looking for someone who can develop LLM, ML, or other kinds of systems, they should be able to describe it in more words than "AI skills".
13-14_Mustang@reddit
Seems like AI should be asking clarifying questions before answering for a more efficient flow. Like you answer as many questions as you want until you hit the executive button.
Constant-Listen834@reddit
This comes down to how you prompt the AI. If you want it to ask clarifying questions, you need to tell it to do so.
Constant-Listen834@reddit
I’ve been using AI heavily at work, and improving at prompting AI is definitely a skill in itself
EmmitSan@reddit
Literally everyone is talking about this, though?
Using your brain and not just rubber stamping AI slop is why you have a job and the boys and girls in marketing/sales/etc still need you around, right?
Turbulent_Tale6497@reddit
The skill is called "prompt engineering" which is basically knowing how to ask the right questions and drill into the answers to actually get the information you need.
In human terms, this is called "interviewing."
dash_bro@reddit
I think it only accelerates learning to the point where you know exactly what bending the rules can do for you, and learn to experiment and implement faster.
The actual AI thinking itself isn't anything new - it's simply accommodating AI processes as black boxes that you can expect certain behavior out of, then developing systems with those as parts of three system. AI development is just being savvy with basic software engineering and a little bit of DevOps/cloud resource management.
The real skill gap is the ability to accelerate and innovate in "thinking", then using AI to only do the lines-of-code grunt work. You retain the critical thinking, systems level arch/design, problem solving abilities etc. You only delegate the actual code writing to it, and nothing else. Being able to do this fast, implement ideas, fail, and iterate -- that's what creates the "gap". This truly gives you the ability to expedite "experience" to the point of knowing what works/doesn't work etc. much earlier than before, saving your org and team lots of time and money.
Companies want you to clear interviews without the help of AI because fundamentally you need the problem solving and the critical thinking aspects still, that's not to be delegated to the AI. As simple as that.
You use your experience and thinking as the primary skill instead of writing lines of code. That, you delegate to the copilot and only refine/correct it, especially if you're starting something from scratch. In an existing project, I find that AI copilot doesn't really do things well since it's missed the whole "why did we do it like this" aspect and is working with microscopic knowledge.
asianpianoman@reddit
My team's dev manager just made ai engagement a requirement for all work this week. Like he's literally mandating that we commit our chat history with the ai agent as proof, no exceptions.
I always try to be fair as possible and to be fair to them, I do believe it comes from a legitimate fear and well-intentioned concern for the team's career growth AND job safety.
But to dictate and micro manage HOW someone gets the job done really doesn't sit right with me. If ai actually starts wiping out dev jobs and this company thinks they can do better with ai than with me then kinda let me accept that risk on my own accord and judgement, ya know?
drumnation@reddit
I agree with most things being said here, without reading every comment, I haven’t seen anybody mention tooling skill. A good ai engineer usually has a stack of mcp servers, some project management tooling, possibly some AI developer tools they crafted themselves. I know this isn’t the skill OP asked about but I do feel like this is one of the things an experienced ai assisted engineer would bring to the table in addition to being able to smell bullshit, quickly be able to lead the ai down a better path.
One other important ai skill I think would be ai leverage. Knowing where AI can be used for maximum leverage. Which tasks are so compatible with AI that you get a massive boost.
GameRoom@reddit
One thing is making a conscious effort to consider using it for a given task. As a programmer who has many years of experience doing things the old fashioned way, I often fall into the habit of just forgetting to ask the AI for help, even when it would have gotten me to an answer faster. For instance, I was writing some unit tests recently, and then after sending them out for review, out of curiosity I asked Gemini to write the tests itself, and while my solution was a bit more concise, the AI one-shotted the problem. If I had just done that from the beginning I could have saved a bit of time.
On the other hand, though, there are also instances where I go for the AI first and in retrospect, I would have been better off doing it myself from the beginning.
rfmh_@reddit
I make and use ai tooling. I find understanding the systems, it's strengths, limitations and understanding what it can and cannot do can go a long way. However I think having enough actual domain knowledge to use the tool correctly for what you're using it for really takes it most of the way. If you don't know the tool you are using, and have domain knowledge in the context you are using it, it's nether going to be accurate or efficient.
PermabearsEatBeets@reddit
Didn’t read the rest of this ramble but to your point of interviews, since when has tech interviewing been in any way an accurate beat to measure skill? They’ve been broken for decades. Leetcode with no googling for a senior engineer who will never ever have to touch dynamic programming quiz questions?
And besides, some companies ARE gauging AI use in interviews
https://www.canva.dev/blog/engineering/yes-you-can-use-ai-in-our-interviews/
Think you’ll see a lot of companies follow suit
crytomaniac2000@reddit
The main skill is exaggerating how productive you are with AI while being vague about the value you are delivering to the business.
Soileau@reddit
The AI “skill” your trying to define has nothing to do with AI.
It’s the same skill as providing feedback during code review.
The skill is having the discernment to know when an approach is wrong, to be able to articulate that clearly, and to be able to provide the right clarity / directional steering to avoid the associated issues that you detect.
It’s experience and communication. That’s the skill.
It seems like most everyone has labeled this context or prompt engineering, but the skill is discernment and the ability to communicate with clarity. They’re not AI specific things. They’re not even necessarily strictly software engineering skills.
kagato87@reddit
I'm still not sold on it's value. Today a lead developer submitter a PR in a language he is not familiar with. It was reviewed and approved by a senior developer and a junior developer.
It... Wasn't great. Apart from the AI "smell" (like overly verbose and pointless comments on top of the overly ), it does a lot of things it doesn't need to do and I was able to pick out a bug by sight. And is full of functions pretending to be class methods, something I know that particular developer would not do in his regular languages.
matthra@reddit
The ability to explain a problem clearly, ask clarifying questions, and a good knowledge of testing.
NowImAllSet@reddit
imho the skill is developing an intuition for prompting, interaction and technical limitations of AI tooling. For example
There's more but that's the top things I can think of right now. All of that isn't something you pick up in a few days, and it's not easy to just teach. It's an intuition that you develop from lots of interactions with these tools.
Middle-Comparison607@reddit
Prompt engineering is just a rebranding of “logic”. You need to structure your prompts in a logical way for the AI to be able to process it correctly.
Lanky-Amphibian1554@reddit
Yep I agree.
If I want buggy code that looks right, I can write it myself, without risking blowing my organization’s private info.
shifty_lifty_doodah@reddit
Just prompting like Google search.
It’s not a hard skill for a good dev.
pinkwar@reddit
I can spawn 5 agents and make them tackle 5 stories in 5 different projects. Go make a brew, come back and review the merge requests.
800808@reddit
I had Gemini 2.5 preview write 3 endpoints for my API yesterday, it created 4 critical code vulnerabilities. That’s real — that’s rare.
It was still useful to have it write the code, but I had to fix how it was handling user sessions and it also created an unauthenticated endpoint to read any user’s info by providing their email address. Like really dumb stuff that a non technical person wouldn’t even notice.
My personal favorite opinion is this will result in a flood of shit code from non technical people, a subsequent flood of companies getting hacked, more demand for real developers to fix the mess.
I also love the all-in-ness of these companies, it’s so short sighted. They really think this toy, and it is a toy, is going to replace probably the most cognitively demanding job in the corporate world? They’ve killed the junior pipeline, this will create a shortage of developers. Going to be very lucrative when the chickens come home to roost if you can just hang on.
And yes AI (in its current stagnant state) is bullshit. No matter what “leash” — karpathy, you put it on, it doesn’t THINK. Thinking is the foundational skill we possess to do this job.
CoochieCoochieKu@reddit
Eh, there are already llm based code security audit tools made for vibe coders. I think your take is missing the point
800808@reddit
Do they work? I assume not unless proven otherwise.
sfbay_swe@reddit
Kent Beck had a relevant tweet on this back in 2023: “The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x.”
AskOk3609@reddit
the problem is that management is banking on the fact that you're not going to be willing to use that leverage in negotiations which saddly will be true for alot of people in this field. Alot of us are going to have to learn to be alot more cutthroat in using that leverage in negotiations.
hardolaf@reddit
My management is banking on me delivering enough new revenue to justify whatever raise I ask for and several new headcount to keep me happy. Just the life of a senior engineer working for competent managers.
ghost_jamm@reddit
I always think of the paper ChatGPT is Bullshit. It argues that LLMs fit the philosophical definition of “bullshit” because they are fundamentally unconcerned with the truth. I think most people either don’t understand this point or maybe vaguely know it but get impressed by the mechanical Turk and don’t care. The fatal flaw in LLMs is that they are not designed to produce truthful output. They don’t and can’t know if their output is accurate. They simply output text that is statistically correct-seeming. I’m not sure what other realm we’d accept “if this tool gives you the right answer, it’s a product of statistical happenstance.”
wardrox@reddit
Time to start a bootcamp but instead of teaching everyone react it's just CS fundamentals tightly packed. Code craft, researching a new codebase or language, and architecture choices.
At least then the juniors have a fighting chance, and aren't hemmed in to one specific framework with no generalized knowledge.
elprophet@reddit
We already see this in the ad agency space, spending more to fix the ad copy from the AI than to retain an agency for the materials in the first place. My initial gut check was that'd be 2028-2030 when we saw that in the engineering side, but 2027 is getting more likely. I don't think it'll happen next year, the execs firing engineers haven't parachuted out yet
creaturefeature16@reddit
What a great comment. Couldn't agree more. We already have a shortage of developers and they've compounded the issue 100 fold.
Competitive-Nail-931@reddit
It’s not ML
shan23@reddit
It’s just speed. I can do stuff that would take 5 days in 1 day. That’s pretty much it
CooperNettees@reddit
the real ai skills are knowing how to offload workloads to gpus, tpus, accelerators; classical or ML.
Strus@reddit
Knowing when to use the coding Agent and which model.
Knowing how to write prompts. What to add to context (files, images, websites with documentation etc.).
Knowing when to stop and either re-adjust prompt or switching to manual Googling/implementation.
Because companies still want to hire experienced Software Engineers that know how to code by hand - because you cannot "vibe code" 100% of your code and you will never be able to do it.
It's the similar reason why you have whiteboard interviews although you don't write code on the whiteboard at a job.
AchillesDev@reddit
It seems like you're jumping between consuming genAI products, knowing how AI in general (not just genAI) works, and building AI applications.
Consuming AI? How to build prompts, how each of the tools work, how to detect bullshit/hallucinations, etc. Highly dependent on the application.
Knowing how it all works? Read books, know linear algebra and calculus, etc.
Building genAI products? Prompting, evals, guardrails, LLMOps/MLOps, agentic dev (tools, memory, etc.).
Forsaken-Promise-269@reddit
Watch this video on Spec driven development with AI
https://youtu.be/8rABwKRsec4?si=Rdh_k_kw-MQqzZCd
thekwoka@reddit
Mostly identifying where AI can solve problems well and where it can't.
MikeFratelli@reddit
AI can often over engineer what could be done with a simple change because it will not always seek all the context it needs before making a modification.
For instance, I want to modify a property where a node in my tree has 'name' = 'guides'. Gippity will create an entire method to traverse that tree rather than look where we may already be doing that.
sfbay_swe@reddit
For context, I work at a FAANG-adjacent public company in a management role, and have a bunch of friends in AI-related startups.
There are two types of AI skills that I’m starting to see more amongst generalist devs (not the ones working on foundational AI).
The first is the ability to successfully integrate AI/LLMs into useful products/features. Given how non-deterministic, unpredictable, and often wrong AI is, this isn’t trivially easy to do, and requires a bit of a paradigm shift in how people think about and architect software. I’m not saying it’s rocket science either, but it’s still something people get better at with practice/experience.
The second one I’m seeing is that people embracing AI tooling are simply becoming a lot more productive than those who aren’t. This doesn’t apply universally: junior/lazy people vibe coding without understanding what’s going on dig themselves into holes. But the more senior engineers who are effectively using AI tooling can move way more quickly than before (much like how engineers using IDEs and modern languages are significantly more productive than those trying to write in machine code).
You can still have cracked engineers who are more productive without AI tooling than those who choose to use them, but as the tooling continues to improve, engineers who avoid AI will fall behind those who use can use it effectively.
fallingfruit@reddit
I have been using AI to help with engineering since chat gpt came out. It speeds me up a lot because it's a great rubber duck, it is very good at searching and explaining codebases im not familiar with, good at explaining architecture options, and also great for searching and solving tedious library or build issues.
The problem is that none of those things I just mentioned are being used for productivity benchmarks. The only thing higher ups seem to give a shit about is how much AI generated code I am stuffing into my codebase. For this, the AI is simply not that great. In a mature enterprise codebase, generating a ton of code is very rarely required. Writing the code, once you actually know what you need to do, simply does not take very much time. This is the case in the vast majority of PRs in my experience.
This probably won't be true of AI generated codebases, but thankfully mine were generated by smart humans.
sfbay_swe@reddit
Yeah, it sounds like a problem with your higher ups. As a manager myself, I'm still holding my team accountable for long-term impact, not short-term code volume, but unfortunately I think the focus on the short-term is probably pretty common.
I'm guessing there will eventually be an "AI hangover" where people start feeling the slowdown in overall productivity/impact from the tech debt created by the AI-generated trash after the initial rush of high-volume code.
sfbay_swe@reddit
And anecdotally, companies are starting to rethink how interviewing should work with more and more engineers being expected to use AI on the job, but this space is just moving too quickly and bigger companies are just slower to move here than startups.
There’s talk at the company I work for of encouraging instead of banning AI use in coding interviews, but this will necessarily require interviews to shift away from leetcode style evaluation on correct + optimal answers to something that gives you better signal on how effective the interviewee will be on the job.
HedgieHunterGME@reddit
They want you to train the ai so it can take your job
Huge-Leek844@reddit
I had a bug that only happened on a few time instants. I couldnt see the pattern. I created a list of parameters and metrics. After a few iterations the LLM found the issue. I provided the domain knowledge and LLM did the rest.
LiveMaI@reddit
I think this is really hard to answer at the moment, since the tools keep changing every month or so. One of the early jokes I heard about AI being able to produce code was "You're telling me that AI will be able to code anything as long as you can give it the exact requirements for your project? Our jobs are safe."
So far, this is still true; all of the LLMs I've worked with can't wait to spit out code and get you an answer, and that's great if you just want to produce a bunch of code as quickly as possible, but (IME) coding is only 20%-30% of the actual work that you do in developing software.
I think the main 'skill' I've used in developing software with AI is really just knowing where its limitations are and how to mitigate those. This is also changing pretty frequently, so I won't make any prediction about what it will look like in the future. For now, I've landed on a good workflow by laying out project coding standards, the development cycle, and an architecture document for an AI agent to use as references while it works on smaller tasks that don't need a lot of context, and I've seen good results from that.
As an aside, giving an agent access to MCP tools that can open/modify issues on github/gitlab has also been a good productivity booster for me because staying organized with that side has always been a weakness of mine. Simply being able to tell it to 'update issue X with the work done in the past three commits' is really great.
lawrencek1992@reddit
Really? There are a ton of skills for engineering with AI. Maybe they are so ingrained in your thought process that you aren’t even thinking of them as skills?
Here’s a list: - Being able to prompt an AI very few times (ideally once) to get the output you want. This is trivial when chatting with an AI but becomes trickier when working with agents. - Understanding how to set up infra for ai engineering. We use Devin and Cursor. I have repo wide rules, set up a whole virtual machine for Devin, have a bunch of Cursor MCPs and internal docs for setup. I also did hacky workaround things to get Devin to work with version control tools it doesn’t natively support. - Understanding how to delegate. There are tasks Cursor can help me with synchronously but which are too much for Devin to do autonomously. - Catching it early when an LLM goes off the rails and cutting it off to save time and money. - Solution architecture and task ordering. I need to be able to architect everything for a project and understand the order things need to get done in. This helps me know which pieces to give to Devin vs do myself and when. Also help me set up a series of sessions where session 1 finishes and initiates session 2, which depends on code from session 1. - Knowing how to support a junior or intern who isn’t that capable when you give them tasks. This is what you need to do for autonomous agents. You need to be able to give examples and explain scope and whatnot. Goes with prompting. - Knowing when writing the prompt will take more time than doing it without AI. I think a lot of people who aren’t thrilled with AI hype resist it and say this is the case most of the time. It’s not. It’s maaaaaybe 50% of the tasks which involve writing code. - Using AI for the related tasks. So I’m talking about getting an AI to review code with you; writ engineering specs; provide estimates; break down specs into tickets which can be assigned to humans or agents; writing tool proposals or internal documents, etc. - Writing documentation. Well-documented code (doc strings, class/function documentation; READMEs; feature descriptions and descriptions of user flows, etc in markdown) is code that AI works better in. Better as in higher quality output and fewer tokens needed to complete a task.
There are probably more but I need to get back to work. I bet a ton of this stuff, OP, are skills you already have but maybe don’t think of as being an ai engineering skill.
MercyEndures@reddit
Prompt engineering has transformed into creating a whole project layout with docs on goals, style, libraries, etc.
metarobert@reddit
I would say something similar, but I'm not really sure it applies to "most people". Maybe some people.
But further, I'd call that learning a skill. And it probably goes much deeper. e.g. I'm finding that starting with a TDD approach is very much more reliable and maintainable for me. I request tests, then the code. When the AI doesn't fully have conversational context any more, there are the tests to read AND to validate changes.
There will definitely be a gap and some/many will fall aside. Predicting what that is will be difficult. Keeping up is about all we can do at this point, and continue to watch for clues as to which direction to movein .
Worldly_Weather5484@reddit
It’s the same skill as systems design, breaking down work, and general best practices. Being able to break down a problem and know how to make atomic changes really helps when using agentic ai. I see fellow engineers struggle with this on a daily basis. These tend to be solid senior ICs that have not necessarily had to lead a team or delegate work before. Now every engineer is essentially a manager that needs to break down manageable tasks for ai.
ILikeBubblyWater@reddit
This sub is the wrong sub to ask, it's full of boomer devs that try to gatekeep the profession and are on a war path with anything AI.
The people that tell you there will be no skill gap are the people that avoid AI and are now in cope mode.
andlewis@reddit
With ai, context is king. Most devs are not using ChatGpt.com for development, they’re using Cursor, Cline, Copilot, etc.
And most AI generated code is garbage. You can significantly improve the output by learning how to provide context, and prompt better. Look in to Cursor rules, or Copilot instructions, etc.
Logical-Idea-1708@reddit
Prompt engineering sounds like good job for law or English grads
DeltaEdge03@reddit
The thing that grinds my gears is that “AI” nowadays refers to neural networks that are implemented in different fashions
However the field of AI is a lot more robust than neural nets. Once you realize this, then you see through the “hype” every company has
It’s cargo culting plan and simple
Mgmt falls for it all the time because uses it! We want to be successful like them, so it must only be their tech stack that’s the difference!
Except it isn’t. It’s a negative net value forcing devs to use AI tools. However, by the time there’s push back and grumbling the execs who hyped it will go to another company to peddle abondonware and/or receive a generous golden parachute, and new AI hype man will replace them until the next programming fad where infinite money is poured into something that only marginally beneficial for the big players
iirc I’ve seen UML, XML, “big data”, “the cloud”, “nosql”, “react only”, “AI” and god knows what else pop up as hype cycles for products that no one asked for
WaterIll4397@reddit
Big data and the cloud turned out to be real. Almost no one uses on prem servers. AI likely will be real too once hallucinations are sufficiently mitigated or if unmitigated you use it for something like an entertainment product where it matters less.
Even for SQL, Ive found Gemini does a good enough debugging that I've told my juniors to go use it for query optimization, it gave the same suggestions I did most of the time.
DeltaEdge03@reddit
I never said that hype cycles are constant, and normally not beneficial for most companies until 5-10 years later after the technology matures
Take your SQL example. “Nosql” was the big thing in late 00s / 10s. So everyone jumped onto MongoDb for all things databases. Then there’s endless moaning from developers at how the query takes root long, joining data isn’t as intuitive, hyper-specific bugs that code needed to work around
So back then it was “hype” that had marginal benefit for most companies. It wasn’t until mid / late 2010s until “nosql” found the use cases its good for
Let’s also not forget bitcoin and all of that universe and NFTs and ICOs are all speculative hype that is only profitable for scammers
DeltaEdge03@reddit
Oh yeah. Web 3.0. Remember that and all the hype?
How’s Web 3.0 going nowadays btw?
vigorthroughrigor@reddit
...Bitcoin just hit $117K. Lol. Not a web3 believer so don't attack me but it's not exactly dead.
AHardCockToSuck@reddit
There is no skill, they want you to use it so they can lay off your friends due to increased productivity
8aller8ruh@reddit
Most people are missing the point here: 1. Accelerate your current workflow to do more of what you already do, this requires integrating AI into custom tooling you built to handle the systems at your company. 2. Increase the scope of your work, Machine Learning can solve a different class of problems that would be cumbersome to solve programmatically. Recommendation, classification, optimization, etc. You no longer need to programmatically choreograph every movement a robot dancer might make, just give a virtual version of the robot a proper reward & avoid local minimums.
Like I made a system that listens to a customer service call & pulls up the internal tool & documentation for what they are asking for which allowed the agent to simply use the tool they needed, we had hundreds of such tools because there was a wide range of requests that customers might make but agents had trouble navigating the menus or knowing about everything that we could do due to high turnover in those positions.
Also pipelining different AI tools to feed into each-other can create a far more valuable output than the sum of its parts…which is really a traditional software engineering ask not some AI/ML skill. Limit what parts of an image can change in a diffusion model to fill in meme templates or maintain consistency in videos via in-painting that your program controls.
DoingItForEli@reddit
I think being familiar with the various avenues a coder can use for interacting with AI, whether it's something like ChatGPT or something built into the IDE. It's also highly valuable to know when the AI generated code isn't a good solution, or when it's a better solution than what you had imagined. It's like being the conductor of a symphony or something. You have to know what you're looking for, and all the ways in which to achieve it.
audentis@reddit
Expressing what you want and don't want very clearly, and adjusting your formulation to your audience. Your audience can be an AI model, but also flesh-and-blood colleagues or other stakeholders.
Systems thinking, letting go of the internals and reasoning about your code and infra on a higher abstraction level. It's effectively low-code if you come to think of it.
iamwil@reddit
In the use of AI, I agree with other posters: it takes taste to distinguish the good responses from the bad. Nuance is a well that goes deep.
When it comes to building AI driven apps, I’d say there’s a skill gap there, mainly around Evals for most engineers.
trashed_culture@reddit
I think you're touching on all the right things. Prompt engineering and using coding assistants are very different use cases. You won't be doing prompt engineering on every project, but as a dev, you will be using new development tools constantly. That's the real meaning of "those who don't use ai...". Basically these are just new tools and if you don't use them, you won't be able do things as quickly.
In my opinion, AI is quickly just becoming a new aspect of how software is designed.
teerre@reddit
In 2016 you couldn't have any "AI skills". That's because there's difference between using llms and building llms. Most of the time people are talking about the former, not the latter (and the latter is obvious)
Even besides actually knowing the domain, there are intrinsic skills one need to effectively use the new chat bots. "Prompt engineering" is a real thing, despite it often being used in a ridiculous way
For example, there's a world of differnce in the output between simply asking a question to the model and asking a question to a specific model, then turning it into a plan, then having another model cross refernce it and then finally having a smaller model do the actual text replacement. You need to know which models to and how to plan you question and answer, that's practical "prompt engineering"
As for interviews, the reason you don't see it in interviews is simply because its too new. This is not from 2016, it's from 2024 at best. I guarantee you that the big companies are at least trying to update their interview pipeline to test precisely this kind of knowledge
Prior_Section_4978@reddit
There is no special skill. Is like saying that devs should now know how to search on Google, otherwise you will be left behind. Bullshit. All those qualities like asking decent questions, splitting a complex problem in smaller easier problems and so on are already well mastered by any decent dev. Devs were always good at that. But they pretend that somehow these are new skills to be mastered.
lordnacho666@reddit
The skill is one you already have. It's knowing, without having written every line of code, where to look for issues and where new features should be connected.
AI simply exercises this skill, because you will be generating a huge amount of code that you've never even read.
The good news is you already use a bunch of libraries and this you have so experience of navigating this kind of thing. Modern dev work is already the kind of thing where you're knitting together a bunch of pieces that you sort of understand, but haven't personally written.
Guisseppi@reddit
Knowing the theory behind tensors ams embeddings is one thing. AI skills is wether you can efectively leverage these to make something useful. Prompt engineering is a bad name, you’re building a system that is capable of retaining context, using memory effectively, etc. Just passing everything to an llm gets expensive really quickly so there’s value in knowing how and when to apply llms on a system.
ImmanuelCohen@reddit
Core skill: To discern whether certain AI would make you deliver fast or not
tomqmasters@reddit
Most of the algorithms themselves come from universities of FAANGs, so the work has a lot more to do with managing the massive amount of training data.
ZuzuTheCunning@reddit
Knowing its pitfalls.
I use LLM tools daily, and I learned most of its frequent biases and hallucinations for my current tech stack. I learned that they some of them change from stack to stack. And some are pretty widespread, like excessive defensive programming, which is prone to introduce silent bugs, excessive mocking and proposing much larger changes than focused ones.
You should also know how to integrate it with static analysis, testing and code quality metrics in general. How to index multiple repositories and documentations. How to pré-configure prompts, both global and project-specific. But all those skills are kinda secondary since most tools are adding features so rapidly, by the time you learned some of these, you'll realize they might be seamlessly baked-in already.
defyingphysics1@reddit
Any tips on handling excessive defensive programming? I don't consider myself an expert coder, and a lot of the time those overly defensive approaches seem legitimate or like proper code written by experienced developers.
bupkizz@reddit
There’s no need to defend against impossible scenarios. Just like you don’t need a moat for your house if you aren’t going to be invaded by Mongols. It’s often checking for impossible conditions which is just LOC that will never run but next time they’re read by a dev the assumption is they are there for a reason… which leads to more code etc.
Also if you have lots of branch conditions you could just miss a ! somewhere and it’s going into the error state frequently when it shouldn’t.
figglefargle@reddit
They also throw off code coverage statistics, unless you can write tests for the impossible conditions.
ZuzuTheCunning@reddit
Think whether an error should explode in your face, or be let go.
An example is environment variable configs - LLMs love setting defaults when those are retrieved, and that's horrendous practice most of the time, because you often NEED to have envs explicitly set for observability's sake. If you forget to configure one in your setup, you want your deployment to crash and not replace the previous system. If, instead, you allow defaults, your system will go up, replace the old one, and you'll have a default config that's probably not visible anywhere. Good luck debugging your system if this is a non-critical failure that leads to intermitent issues, like timeouts, worker load etc.
Nowadays, in my experience, most systems are fairly crash tolerant in the infrastructure level. Playing the catch-em-all antipattern is just setting yourself for silent bugs.
GolangLinuxGuru1979@reddit (OP)
A dev who now their language usually will know if the LLM is producing trash. But that’s not really an AI skill. As a matter of fact it’s the opposite in some ways
ZuzuTheCunning@reddit
Defining what "AI skills" are is not something I'll endulge from a theoretical perspective - AI itself is a bogus term and it only has meaning in the current hypescape. "Knowing how to use AI tools" is probably the best you'll have.
f1datamesh@reddit
Hi!
This is a very highly controversial topic with devs, so I will give you my own 2 cents on it.
First, you need to separate wheat from the chaff. AI has sort of scared people, so it's become a binary - use AI or be left behind. So you have to understand where people are coming from, and believe me (and I speak as a senior person), the fear is very real. Then on top of that, you have people selling their AI tools, and like any salesperson they exaggerate the truth.
What I have found personally is - use AI as a tool, not a solution. And then assess if it helps you out.
Whenever I have to learn a new tool or technology, I ask AI to guide me thru it. Saves me the initial ramp up time. But later on, I am still looking at the docs, and what have you.
When I have to make a simple PoC, I would certainly ask an AI to help me out. But would I use it to just vibe code a fully production application? Hell, no.
Now, does using AI this way puts me ahead of people who don't? I think that's the wrong question to ask. Everyone should use the tool that works for them.
The question I -DO- ask is, does it put ME ahead of MYSELF? As in, am I better off using it than not? I'd say so. But it's because of MY ability to use the tool best suited for the job.
armahillo@reddit
Practically speaking?
It's being a skilled enough dev to be able to discern bullshitting from actual useful code, particularly when a response is a mixture of both.
Pretty much everyone I know that is able to use LLMs gainfully is specifically doing this.
Electrical-Ask847@reddit
launching 20 agents in git worktrees
aidencoder@reddit
When the hype train pulls into the station it'll be fine.
I remember when everyone said if you don't learn React you'll be left behind. I remember when they said if you don't use nosql you'll be left behind. I remember...
bluemage-loves-tacos@reddit
For me, it's understanding that the AI has a limited context, needs a lot of handholding (be specific in prompts, etc), and has features to learn (like making rules and memories to help with style etc).
But yeah, I don't see how it's a huge jump for many people. I feel like some of it is figuring out how to modify your workflow to accommodate the AI style of working as well, so some will take longer than others to get running.
Most of the "get left behind" stuff seems to be CV based. If you don't know how to use it and talk about it in interviews, you may be disregarded as "old" and unable to keep up. I don't agree with that, I just wonder if that's the real threat of not using it.
Shazvox@reddit
Only skill you need is to ask the right question and be smart enough to separate BS from actual good stuff.
pa_dvg@reddit
From a company perspective there's two possible answers here.
Either they are building an LLM enabled product and they want you to be familiar with the suite of tools and technologies that enable a company to do that effectively, with a good user experience, high reliability and a minimum amount of stepping on rakes. This ultimately is just like any other experience based qualification. Have you ever built a product similar to what we're building. If you have, great, you're gonna get higher on the list.
Or they are building a regular product and they want you to be able to scale your engineering impact by leveraging AI. This is more nuanced than you probably think, and I didn't really get it until recently.
So for example, this week I get a request from our marketing team to pull some report or another. This kind of thing comes up a lot and I realize our backoffice app can provide that data if we just add a couple more filter options. So I pull out my phone and start up a cursor background agent to write it. I give it maybe 3 sentences of prompting.
I pull out my phone and look at the pr it made. It did a couple things I didn't care for. I give it a follow up prompt to put the json rendering in jbuilder view templates instead of rendering it in the controller. Another one telling it to use a pundit policy to authorize access and one reminding it to write react testing library specs for the new component and request specs to test the new api.
Now I don't yet have a runtime going for the background agents that will let it run tests in docker like we would locally, so it's just making up all the code based on what it's training on and what else it sees in the repo, but with about 3 minutes of my time it has an at least structurally correct and complete version of the feature.
Next morning I pull down the branch and start up claude code. I let it know that an ai agent made this branch and I want it to work through the tests, linting and stuff like that. It starts going through a process of running tests, making changes, and occasssionally getting stuck and needing more guidance. About halfway through this process I realize that the markeing team won't want to come keep searching for this report to try and do what they want to do with it, they're gonna need an artifact they can put in google sheets or something.
So I make a git worktree for a CSV download, boot up another compose stack and start another instance of claude code. I tell it to allow a CSV to be downloaded from the api endpoint and to give the full result set in such a case and not paginate it. It starts working on enahncing the api while most of my attention is still on guiding the first, more complicated task.
The CSV download gets into a good place first, so I commit those changes and merge it into the main branch. After about 45 minutes I had the whole thing completely tested, following all our authorization rules, and heading out the door for a deploy.
In another world this ask would have been something I would have to put off forever and probably just do a one time pull they would have been back to ask me to redo every few weeks, and instead it's a self service thing I never have to be bothered about again. I can do this all the time for all sorts of things now.
I'm really reshaping all my tooling to take advantage of this now. I have a thor command I can run that will do the whole git worktree to docker setup to claude in one command, so I can spin up a new agent to do something for me anytime.
The combination of background and locally running agents really makes this whole thing work for me. Being able to get an idea 80*% of the way there while I'm sitting by the pool or watching tv is pretty freakin' great, and I can get absolutely tear through our backlog by utilizing concurrent local agents.*
Cosack@reddit
Laundry list I interview candidates for, all immediately applicable on the job and which most devs and DS's don't pass
Depending on the shop, may also be interested in Spark and friends.
Junior-Procedure1429@reddit
You need to be good at engineering and you need the expertise to know when the AI is tripping.
A lot of people don’t know what data to feed and what specifications for it to build, so it comes out with a lot of garbage that usually won’t even compile.
Then you see these lots of complaints online about “AI making sloppy code” or “AI can’t understand my 40 million lines of code project “.
They are using it wrong.
GolangLinuxGuru1979@reddit (OP)
Ok then tell us how to use it right. I hear this all the time, and its so vague. What are the practices or techniques someone would use to tackle a 40 million line code base? I know everything is contextual, but a "skill" can be described in very discrete terms.
Junior-Procedure1429@reddit
There is no one right way to use it. You engineer your solution just like any other program. You just don’t right the boilerplate code yourself.
If you don’t understand your own code, AI sure thing won’t understand it either. It can’t think, it just types code faster than you can. You still have to input the brain, if you have one.
icetlawandorder@reddit
So you have to be a good engineer. That’s not an “AI skill”
abeuscher@reddit
I always assume it means you know:
Prompt engineering is not a thing except in the context of API requests. Using any of the big LLM's through their web interface is not a skill any more than knowing how to use Google is a skill - it is it's just something you can master in < 8 hours.
What I think is really fucked is that I do not think that is the recruiter answer to this question, and I do not think they could provide an intelligible answer. So to me that is where the disconnect exists.
xt-89@reddit
I find that it has less to do with AI-specific skill, and more to do with extensive knowledge on good software engineering principals in general. If you know your stuff, you can be disproportionately more effective by workshopping with the AI if you wish, and otherwise implementing your ideas faster. As a result, you can do complicated but useful things that wouldn't have been practical before AI tools.
starquakegamma@reddit
One of the best uses of AI in code I’ve found is in writing something you’ve written several times in the past. Get the AI to do the typing, verify it looks right, and you’ve saved time on some boring work.
MonochromeDinosaur@reddit
I haven’t seen any AI use case that can replace a truly skilled developer.
I have seen many use cases of grunt work that can be handed off to AI. I still believe this is bad because a good junior could learn from that work instead we’re letting them stagnate without jobs…
Easy-Philosophy-214@reddit
AI skills: being updated on the trends, having used and stitched together OpenAI API calls, knowing what agents are, agentic orchestration. And always knowing more than the AI and knowing your shit. Fundamentals are more important now than a few years ago.
tr14l@reddit
Learning to work with the tools, spot the types of things you need to double check, prompt efficiently etc.
For instance, I don't start making anything with AI until I make a fully fleshed out and approved PRD. Naturally, I use AI to help me write that. For that, I will typically use Claude or chatgpt o3. Once I have that, I tech selection with it down to libraries. Then I do tech and nonfunctional reqs. Whole shebang.
Then, I'll usually use o3 to get mocks from that PRD.
Then I'll take all of that and use it to guide the AI with reference to the PRD, and relevant mocks that we're working on.
It's not as straightforward as "make me and app that apps things"
tom-smykowski-dev@reddit
I think it's a little bit more than using an iDE with AI. Writing prompts maybe is one thing, but it's not all. You can use AI to research faster, find things, braindstorm solutions. So there are several paths where AI can be used. And it requires some usage to learn where it's useful and where not. Also if it comes to prompting: how to structure them, how big features you can safely build with AI, how to incorporate in your workflow so that it's useful and learn when to not use it. Or what to do when AI fails. For example building rules and AI learnings, also incorporating AI in these workflows.
I'd say everything can be built with AI support and without it and everyone is trying to figure out thr best way of work that's actually good for productivity and quality. Also I haven't seen anyone so far try to actually check if someone "has it" because it's hard to test it, because there are no standards of operation. However it's useful to check it and learn where you can apply AI, and where it makes no sense. I run a newsletter wher3 I share my learnings if you're interested
DeProgrammer99@reddit
Knowing that they're better at more common things, knowing they hallucinate, knowing how to minimize that chance, knowing their intelligence degrades with context length, and knowing what info to give them to minimize that. Knowing what sampling parameters are, like temperature, top K, and min P. Knowing that GitHub Copilot is given a bunch of tools that often make it do unnecessary things and is fine-tuned/prompted to want to generate code even if that's not what you asked for. Knowing that any big company is going to enable "block results matching public code" in GitHub Copilot because of some indemnity clause that will never be helpful in reality, resulting in an 80% reduction in useful responses so everyone is just going to go back to web chat interfaces...well, that may just be me being salty.
Just look at this one outdated paper on prompting techniques: https://arxiv.org/html/2406.06608v6
People have said LLMs give better responses when bribed or even when threatened.
galwayygal@reddit
I read in an article that prompt engineering was a skill required for older models that weren’t as great with interpreting less precise prompts. This has changed since gpt 4o. There’s no barrier to entry anymore. There are so many tools, and anyone can write a prompt. IMO the skill is to identify when you can use AI to increase your productivity and also to do your own fact checking before using the code it spits out.
Careful_Ad_9077@reddit
You are grouping three or more different skills.
There's ai/model developement skills, those should be self explanatory and clearly specified in the job description.
There's ai system development on the sense of using ai pieces/API and integrate it into a more complete systems. It's the same as the previous one, it should be clear when is this case.
And the one important in this context. Using ai tools in your development process. Saying that anybody can learn them is like saying that anybody can learn programing (!good luck for the people who can't even understand algebra ). Or close to home, think of all the PMs and business users whom can't write a proper requirement list after years of that being part of their day job.
You are underestimating how long it takes to be able to learn how to write good prompts,me specially with steering being s thing. It's one of the things that seems like it should be easy but it's not. Sure x you can go from trash to useful in one session on e you learn the very basics , but the hole is kiddie pool deep, not just a puddle. There is still weeks maybe even months of practice. Just like other skills that take a few weeks to learn ,in a good market the job will be willing to pay and on a bad market it will be a differentiator.
Other comments already got deep into what kind of skills are needed for effective prompt engineering.
zayelion@reddit
The skill is spotting and fixing or mitigating the mistakes it makes. If intergrating it thats via prompt engineering and context building. If using it to code thats knowing the patterns of mistakes it makes, what libraries its familiar with, what level of context it can and can not handle, reformatting answers, or fixing minor things by hand.
Its close to micromanaging mentorship.
Smart-Emu5581@reddit
AI effectively gives you the ability to instantly hire a motivated and competent intern (the LLM), have him read the entire project, and let him do a day of work in the time it takes you to refill your coffee.
Do you trust what the "intern" produces in that time? What is worth double-checking, and what do you just accept? If he makes a mistake, how do you deal with this? When is it worth talking to the intern to help him solve the task, and when should you as the senior just do it yourself?
These are all very important questions. Before AI, only managers had to ask themselves these questions. Now we all have the ability to spawn pseudo-interns at will, and so learning how to make them productive is an important skill.
false79@reddit
Easily one of the biggest skills is to identify what tasks you can delegate to AI that would require significant manual effort on your part but not so much complexity that an LLM can save you time to do it. There countless mundane tasks that can be handed off which allows you to focus on more important things.
08148694@reddit
Knowing how to write an effective prompt and provide efficient context. A bad prompt will give bad results. Too much context will give bad results. Not enough context will give bad results. The wrong context will give bad results
“Prompt engineering” for lack of a better term is a real skill, and it’s often the difference between someone who gets value out of AI and someone who thinks AI is trash
But it’s not enough, you still need to be able to identify good code and bad code. A pure vibe coder with no strong background in software engineering will probably not be able to produce quality software using AI
Which-World-6533@reddit
There isn't.
You may as well list "Googling" or "searching Stack Overflow".
funbike@reddit
Experience and RTFM.
Like any skill, you read to learn how to use it best and you get good by actually using it.
Read. So read comparision reviews of the tools. Read about prompt engineering. Look for AI coding guides, and even vibe coding guides, that are written by actual programmers that extensively used AI tools. Find out which models do best on coding benchmarks.
Do. Pick a tools based on how actual practitioners feel about them, not raw popularity. Try a several of the best rated tools, until you find one that works best for you. Don't just pick Cursor and never try anything else.
Try the various techniques people suggest and talk about. Don't just give a simple prompt and hope for the best.
cbsudux@reddit
High level Problem solving - execution is cheaper now.
Prompt engineering with the right context (context engineering)
Also being open minded - many devs I know dislike ai coding and say the results suck. But the truth is it's a tool - it's how you use it.
GolangLinuxGuru1979@reddit (OP)
Ok show me an example of a “good prompt” vs a “bad prompt”. And show me how a dev just couldn’t figure this out in a day or two. Is there a real “skill” that if a dev don’t know XYZ then they just can’t be “productive” when it comes to AI?
prisencotech@reddit
I've been saying, the only way to "get good at AI" is to learn the domain of the problem you're solving as deeply as possible.
Everything else is just typing words into a box.
Sensitive-Ear-3896@reddit
Code review, breaking down the application, tight prompts design
Eastern_Interest_908@reddit
There isn't any I use AI tools since copilot beta and I don't feel like I have special AI dev tools skills. That's why "left behind" is stupid argument. Like sure you need to know current tools but you need like a day max to identify them and see their limits.
GoodJobMate@reddit
I guess developing some sort of intuition on what LLMs are good at and what they are bad at and how to prompt them in a way that you increase the likelihood of a helpful response.
To me for example it's about forcing Cursor or whatever tool I'm using to read ALL the context it could possibly need using its read tool, instead of me relying on it asking the right questions or searching. I know that the models - all of them - are designed to be "engaging" first so that we keep using it. That means it's biased towards giving *some* kind of answer instead of gathering all possible context first.
fuka123@reddit
Maybe training models?