16 ms·

Software development jobs must be very diverse if even this anti-vibe-coding guy thinks AI coding definitely makes developers more productive. In my work, the

Software development jobs must be very diverse if even this anti-vibe-coding guy thinks AI coding definitely makes developers more productive. In my work, the bigger bottleneck to productivity is that very few people can correctly articulate requirements. I work in backend, API development, which is completely different from fullstack development with backend development. If you ask PMs about backend requirements, they will dodge you, and if you ask front-end or web developers, they are waiting for you to provide them the API. The hardest part is understanding the requirements. It's not because of illiteracy. It's because software development is a lot more than coding and requires critical thinking to discover the requirements.

mavamaarten 10mo ago
Yup. I would never be able to give my Jira tickets to an LLM because they're too damn vague or incomplete. Getting the requirements first needs 4 rounds of lobbying with all stakeholders.
- bjacobso 10mo ago
  Claude Code et al. asks clarifying questions in plan mode before implementing. This will eventually extend to jira comments
  - fooker 10mo ago
    What do you mean by eventually? this already exists.
  - swatcoder 10mo ago
    You think the business line stakeholder is going to patiently hang out in JIRA, engaging with an overly cheerful robot that keeps "missing the point" and being "intentionally obtuse" with its "irrelevant questions"? This is how most non-technical stakeholders feel when you probe for consistent, thorough requirements and a key professional skill for many more senior developers and consultants is in mastering the soft skills that keep them attentive and sufficiently helpful. Those skills are not generic sycophancy, but involve personal attunement to the stakeholder, patience (exercising and engendering), and cycling the right balance between persistence and de-escalation. Or do you just mean there will be some PM who acts as proxy between for the stakeholder on the ticket, but still needs to get them onto the phone and into meetings so the answers can be secured? Because in the real world, the prior is outlandish and the latter doesn't gain much.
    - a_wild_dandan 10mo ago
      Businesses do whatever’s cheap. AI labs will continue making their models smarter, more persuasive. Maybe the SWE profession will thrive/transform/get massacred. We don’t know.
- colechristensen 10mo ago
  A significant part of my LLM workflow involves having the LLM write and update tickets for me. It can make a vague ticket precise and that can be an easy platform to have discussions with stakeholders.
  - somebehemoth 10mo ago
    I like this use of LLM because I assume both the developer and ticket owner will review the text and agree to its contents. The LLM could help ensure the ticket is thorough and its meaning is understood by all parties. One downside is verbosity, but the humans in the loop can edit mercilessly. Without human review, these tickets would have all the downsides of vibe coding. Thank you for sharing this workflow. I have low tolerance for LLM written text, but this seems like a really good use case.
  - SoftTalker 10mo ago
    Wait until you learn that the people on the other side of your ticket updates are also using LLMs to respond. It's LLMs talking to LLMs now.
    - colechristensen 10mo ago
      The desired result is coming to a documented agreement on an interaction, not some exercise in argument that has to happen between humans. I find having an LLM create tickets for itself to implement to be an effective tool that I rarely have to provide feedback for at all. This seems like greybeards complaining that people who don't write assembly by hand.
      - Yeask 10mo ago
        Who has ever complained that kids don't write assembly by hand? Stop being outraged for things that are only real on your mind.
        colechristensen 10mo ago
- mrweasel 10mo ago
  We had a client who'd create incredibly detailed Jira tickets. Their lead developer (also their only developer) would write exactly how he'd want us to implement a given feature, and what the expected output would be. The guy is also a complete tool. I'd point out that what he described wasn't actually what they needed, and that there functionality was ... strange and didn't actually do anything useful. We'd be told to just do as we where being told, seeing as they where the ones paying the bills. Sometimes we'd read between the lines, and just deliver what was actually needed, then we'd be told just do as we where told next time, and they'd then use the code we wrote anyway. At some point we got tired of the complaining and just did exactly as the tasks described, complete with tests that showed that everything worked as specified. Then we where told that our deliveries didn't work, because that wasn't what they'd asked for, but couldn't tell us where we misunderstood the Jira task. Plus the tests showed that the code functioned as specified. Even if the Jira tasks are in a state where it seems like you could feed them directly to an LLM, there's no context (or incorrect context) and how is a chatbot to know that the author of the task is a moron?
  - ForOldHack 10mo ago
    "The guy is also a complete tool." - Who says Hackers news is not filled with humor?
  - SchemaLoad 10mo ago
    Every time I've received overly detailed JIRA tickets like this it's always been significantly more of a headache than the vague ones from product people. You end up with someone with enough tech knowledge to have an opinion, but separated enough from the work that their opinions don't quite work.
    - jordwest 10mo ago
      Same, I think there's an idealistic belief in people who write those tickets that something can be perfectly specified upfront. Maybe for the most mundane, repetitive tasks that's true. But I'd argue that the code is the full specification, so if you're going to fully specify it you might as well just write the code and then you'll actually have to be confronted with your mistaken assumptions.
- threethirtytwo 10mo ago
  Who says an LLM can’t be taught or given a system prompt that enables them to do this? Agentic AI can now do 20 rounds of lobbying with all stake holders as long as it’s over something like slack.
jcelerier 10mo ago
To be honest I've never worked in an environment that seemed too complex. On my side my primary blocker is writing code. I have an unending list of features, protocols, experiments, etc. to implement, and so far the main limit was the time necessary to actually write the damn code.
- f1shy 10mo ago
  I don’t want to imply this is your case, because of course I’ve no idea how you work. But I’ve seen way too often, the reason for so many separate features is: A) as stated by parent comment, the ones doing req. mngmt. Are doing a poor job of abstracting the requirements, and what could be done as one feature suddenly turns in 25. B) in a similar manner as A, all solutions imply writing more and more code, and never refactor and abstract parts away.
  - mckn1ght 10mo ago
    My guess would be that the long list is maybe not self contained features (although still can be, I know I have more feature ideas than I can deliver in the next couple years myself), but behaviors or requirements of one or a handful of product feature areas. When you start getting down into the weeds, there can be tons and tons of little details around state maintenance, accessibility, edge cases, failure modes, alternate operation modes etc. That all combines to make lots of code that is highly interconnected, so you need to write even more code to test it. Sometimes much more than even the target implementations code.
  - deleted 10mo ago
    [deleted]
- swatcoder 10mo ago
  That sounds like papier mache more than bridge building, forever pasting more code on as ideas and time permit without the foresight to engineer or architect towards some cohesive long-term vision. Most software products built that way seem to move fast at first but become monstrous abominations over time. If those are the only places you keep finding yourself in, be careful!
legitster 10mo ago
Convince your PMs to use an LLM to help "breadboard" their requirements. It's a really good use case. They can ask their dumb questions they are afraid to and an LLM will do a decent job of parsing their ideas, asking questions, and putting together a halfway decent set of requirements.
- gitremote 10mo ago
  PMs wouldn't be able to ask the right questions. They have zero experience with developer experience (DevEx) and they only have experience with user experience (UX).
  - tmp10423288442 10mo ago
    You can hope that an LLM might have some instructions related to DevEx in its prompt at least. There's no way to completely fix stupid, anymore than you can convince a naive vibecoder that just vibing a new Linux-compatible kernel written entirely in Zig is a feasible project.
- Scarblac 10mo ago
  How does the LLM get all the required knowledge about the domain and the product to ask relevant questions?
  - sh4rks 10mo ago
    Give it access to the codebase and a text file with all relevant business knowledge.
    - wiml 10mo ago
      Man ... if there were a text file with "all relevant business knowledge" in any job I've ever worked, it would have been revolutionary. I'd say 25% of my work-hours are just going around to stakeholders and getting them to say what some of their unstated assumptions and requirements are.
giancarlostoro 10mo ago
I have done both strict back-end, strict front-end, full stack, QA automation and some devops as well, I worked in an all Linux shop where we were encouraged by great senior devs to always strive for better software all around. I think you're right, it mostly depends on your mindset and how much you expose yourself to the craft. I can tackle obscure front-end things sometimes better than back-end issues despite hating front-end but knowing enough to be dangerous. (My first job in tech really had me doing everything imaginable) I find the LLMs boost my productivity because I've always had a sort of architectural mindset, I love looking up projects that solve specific problems and keeping them on the back of my mind, turns out I was building myself up for instructing LLMs on how to build me software, and it takes several months worth of effort and spits it out in a few hours. Speaking of vibe coding in archaic languages, I'm using LLMs to understand old Shockwave Lingo to translate it to a more modern language, so I can rebuild a legacy game in a modern language. Maybe once I spin up my blog again I'll start documenting that fun journey.
- burnt-resistor 10mo ago
  Hehe. In the "someone should make a website"™ department: using a crap tons of legacy protocols and plugins semi-interoperable with modern while offering legacy browsers loaded with legacy plugins something usable to test with, i.e., - SSL 2.0-TLS 1.1, HTTP/0.9-HTTP/1.1, ftp, WAIS, gopher, finger, telnet, rwho, TinyFugue MUD, UUCP email, SHOUTcast streaming some public domain radio whatever - <blink>, <marquee>, <object>, XHTML, SGML - Java <applet>, Java Web Start - MSJVM/J++, ActiveX, Silverlight - Flash, Shockwave (of course), Adobe Air - (Cosmo) VRML - Joke ActiveX control or toolbar that turns a Win 9x/NT-XP box into a "real" ProgressBar95. ;) (Gov't mandated PSA: Run vintage {good,bad}ness with care.)
  - lawlessone 10mo ago
    why even write webpages or apps anymore just prompt an LLM everytime a user makes a request and write the page to send to the user :D
    - giancarlostoro 10mo ago
shortrounddev2 10mo ago
I write a library which is used by customers to implement integrations with our platform. The #1 thing I think about is not > How do I express this code in Typescript? it's > What is the best way to express this idea in a way that won't confuse or anger our users? Where in the library should I put this new idea? Upstream of X? Downstream of Y? How do I make it flexible so they can choose how to integrate this? Or maybe I don't want to make it flexible - maybe I want to force them to use this new format? > Plus making sure that whatever changes I make are non-breaking, which means that if I update some function with new parameters, they need to be made optional, so now I need to remember, downstream, that this particular argument may or may not be `undefined` because I don't want to break implementations from customers who just upgraded the most recent minor or patch version The majority of the problems I solve are philosophical, not linguistic
doug_durham 10mo ago
I don't think the author would disagree with you. Ad you point out coding is just one part of software development. I understand his point to be that the coding portion of the job is going to be very different going forward. A skilled developer is still going to need to understand frameworks and tradeoffs so that they can turn requirements into a potential solution. It just they might not be coding up the implementation.
tshaddox 10mo ago
I like my requirements articulated so clearly and unambiguously that an extremely dumb electronic logic machine can follow every aspect of the requirements and implement them "perfectly" (limited only by the physical reliability of the machine).
- deepsun 10mo ago
  Aka "coding". I see what you mean ;)
epolanski 10mo ago
If AI doesn't make you more productive you're using it wrong, end of story. Even if you don't let it author or write a single line of code, from collecting information, inspecting code, reviewing requirements, reviewing PRs, finding bugs, hell even researching information online, there's so many things it does well and fast that if you're not leveraging it, you're either in denial or have ai skill issues period.
- mdavidn 10mo ago
  It sounds like you're the one in denial? AI makes some things faster, like working in a language I don't know very well. It makes other things slower, like working in a language I already know very well. In both cases, writing code is a small percentage of the total development effort.
  - epolanski 10mo ago
    No I'm not, I'm just sick of these edgy takes where AI does not improve productivity when it obviously does. Even if you limit your AI experience to finding information online through deep research it's such a time saver and productivity booster that makes a lot of difference. The list of things it can do for you is massive, even if you don't have it write a single line of code. Yet the counter argument is like "bu..but..my colleague is pushing slop and it's not good at writing code for me", come on, then use it at things it's good at, not things you don't find it satisfactory.
    - lunar_mycroft 10mo ago
      It "obviously" does based on what, exactly? For most devs (and it appears you, based on your comments) the answer is "their own subjective impressions", but that METR study (https://arxiv.org/pdf/2507.09089 https://arxiv.org/pdf/2507.09089) should have completely killed any illusions that that is a reliable metric (note: this argument works regardless of how much LLMs have improved since the study period, because it's about how accurate dev's impressions are, not how good the LLMs actually were).
omnicognate 10mo ago
> Software development jobs must be very diverse if even this anti-vibe-coding guy thinks AI coding definitely makes developers more productive. As a Professor of English who teaches programming to humanities students, the writer has had an extremely interesting and unusual academic career [1]. He sounds awesome, but I think it's fair to suggest he may not have much experience of large scale commercial software development or be particularly well placed to predict what will or will not work in that environment. (Not that he necessarily claims to, but it's implicit in strong predictions about what the "future of programming" will be.) [1] https://stephenramsay.net/about/ https://stephenramsay.net/about/
- godelski 10mo ago
  Hard to say but to back his claim that he was programming since the 90's his CV shows he was working on stuff that's clearly more than your basic undergraduate skill level since the early 2000's. I'd be willing to bet he has more years under his belt than most HN users. I mean I'm considered old here, in my mid 30's, and this guy has been programming most my life. Though that doesn't explicitly imply experience, or more specifically experience in what. That said, I think people really under appreciate how diverse programmers actually are. I started in physics and came over when I went to grad school. While I wouldn't expect a physicist to do super well on leetcode problems I've seen those same people write incredible code that's optimized for HPC systems and they're really good at tracing bottlenecks (it's a skill that translates from physics really really well). Hell, the best programmer I've ever met got that way because he was doing his PhD in mechanical engineering. He's practically the leading expert in data streaming for HPC systems and gained this skill because he needed more performance for his other work. There's a lot of different types of programmers out there but I think it's too easy to think the field is narrow.
  - AceJohnny2 10mo ago
    > I mean I'm considered old here, in my mid 30's sigh
    - jjgreen 10mo ago
threethirtytwo 10mo ago
You can vibe ask the requirements. Not even kidding.
yieldcrv 10mo ago
and in reality, all the separate roles should be deprecated we vibe requirements to our ticket tracker with an api key, vibe code ticket effort, and manage the state of the tickets via our commits and pull requests and deployments just teach the guy the product manager is shielding you from not to micromanage and all the frictions are gone in this same year I've worked at an organization that didn't allow AI use at all, and by Q2, Co-Pilot was somehow solving their data security concerns (gigglesnort) in a different organization none of those restrictions are there and the productivity boost is through an order of magnitude greater
al_borland 10mo ago
I don’t mind the coding, it’s the requirements gathering and status meetings I want AI to automate away. Those are the parts I don’t like and where we’d see the biggest productivity gains. They are also the hardest to solve for, because so much of it is subjective. It also often involves decisions from leadership which can come with a lot of personal bias and occasionally some ego.
- Vegenoid 10mo ago
  This is like the reverse centaur form of coding. The machine tells you what to make, and the human types the code to do the thing.
  - al_borland 10mo ago
    Well, when put like that it sounds pretty bad too. I was thinking more that the human would tell the machine want to make. The machine would help flesh out the idea into actual requirements, and make any decisions the humans are too afraid or indecisive to make. Then the coding can start.
luckydata 10mo ago
Sounds like you work with inexperienced PMs that are not doing their job, did you try having a serious conversation about this pattern with them? I'm pretty sure some communication would go a long way towards getting you on a better collaboration groove.
- gitremote 10mo ago
  I've been doing API development for over ten years and worked at different companies. Most PMs are not technical and it's the development team's job figure out the technical specifications for APIs we build. If you press the PMs, they will ask the engineering/development manager for the written technical requirements, and if the manager is not technical, they will assign it to the developers/engineers. Technical requirements for an API are really a system design question.
  - luckydata 10mo ago
    The technical design is definitely the job of the technical team for the most part, but the business requirements should be squarely on the pm. The list of use cases, how the API feels, the performance etc... All of that the business owner should be able to describe to you to ensure it does the job it needs and is fit for the market.
burnte 10mo ago
"the bigger bottleneck to productivity is that very few people can correctly articulate requirements." I've found the same way. I just published an AI AUP for my company and most of it is teaching folks HOW to use AI.
sureglymop 10mo ago
Also that requirements engineering in general isn't being done correctly. I'm the last guy to be enthused about any "ritualistic" seeming businessy processes. Just let me code... However, some things do need actually well defined adhered to processes where all parties are aware of and agreeing with the protocol.
keeda 10mo ago
This feels like addressing a point TFA did not make. TFA talks mostly about vibe-coding speeding up coding, whereas your comment is about software development as a whole. As you point out, coding is just one aspect of engineering and we must be clear about what "productivity" we are talking about. Sure, there are the overhypers who talk about software engineers getting entirely replaced, but I get the sense those are not people who've ever done software development in their lives. And I have not seen any credible person claiming that engineering as whole can be done by AI. On the other hand, the most grounded comments about AI-assisted programming everywhere are about the code, and maybe some architecture and design aspects. I personally, along with many other commenters here and actual large-scale studies, have found that AI does significantly boost coding productivity. So yes, actual software engineering is much more than coding. But note that even if coding is, say, only 25% of engineering (there are actually studies about this), putting a significant dent in that is still a huge boost to overall productivity.
pron 10mo ago
The thing is that some imagined AI that can reliably produce reliable software will also likely be able to be smart enough to come up with the requirements on its own. If vibe coding is that capable, then even vibe coding itself is redundant. In other words, vibe coding cannot possibly be "the future", because the moment vibe coding can do all that, vibe coding doesn't need to exist. The converse is that if vibe coding is the future, that means we assume there are things the AI cannot do well (such as come up with requirements), at which point it's also likely it cannot actually vibe code that well. The general problem is that once we start talking about imagined AI capabilities, both the capabilities and the constraints become arbitrary. If we imagine an AI that does X but not Y, we could just as easily imagine an AI that does both X and Y.
- whimsicalism 10mo ago
  I agree with the first part which is basically 'being able to do a software engineers full job' is basically ASI/AGI complete. But I think it is certainly possible that we reach a point/plateau where everything is just 'english -> code' compilation but that 'vibe coding' compilation step is really really good.
  - pron 10mo ago
    It's possible, but I don't see any reason to assume that it's more likely that machines will be able to code as well as working programmers yet not be able to come up with requirements or even ideas as well as working PMs. In fact, why not the opposite? I think that currently LLMs are better at writing general prose, offering advice etc.., than they are at writing code. They are better at knowing what people generally want than they are at solving complex logic puzzle that require many deduction steps. Once we're reduced to imagining what AI can and cannot do, we can imagine pretty much any capability or restriction we like. We can imagine something is possible, and we can just as well choose to imagine it's not possible. We're now in the realm of, literally, science fiction.
    - whimsicalism 10mo ago
      > It's possible, but I don't see any reason to assume that it's more likely that machines will be able to code as well as working programmers yet not be able to come up with requirements or even ideas as well as working PMs. Ideation at the working PM level, sure. I meant more hard technical ideation - ie. what gets us from 'not working humanoid robot' to 'humanoid robot' or 'what do we need to do to get a detection of a higgs boson', etc. etc. I think it is possible to imagine a world where 'english -> code' (for reasonably specific english) is solved but not that level of ideation. If that level of ideation is solved, then we have ASI.
ljm 10mo ago
I constantly run into issues where features are planned and broken down outside-in, and it always makes perfect sense if you consider it in terms of the pure user interface and behaviour. It completely breaks down when you consider the API, or the backend, is a cross-cutting concern across many of those tidy looking tasks and cannot map to them 1:1 without creating an absolute mess. Trying to insert myself, or the right backend people, into the process, is more challenging now than it used to be, and a bad API can make or break the user experience as the UI gets tangled in the web of spaghetti. It hobbles the effectiveness of whatever you could get an LLM to do because you’re already starting on the backfoot, requirements-wise.
ozim 10mo ago
Unfortunately a lot of it is also because of illiteracy. Lots of people hide the fact that they struggle with reading and a lot of people hide or try to hide the fact they don’t understand something.
wouldbecouldbe 10mo ago
The solo projects I do are 10x, the team projects I do maybe 2-3x in productivity. I think in big companies it's much much less. Highest gains are def in full stack frameworks (like nextjs), with Database ORM, and building large features in one go, not having to go back & forth with stakeholders or collegues.
MetaWhirledPeas 10mo ago
> very few people can correctly articulate requirements This is the new programming. Programming and requirements are both a form of semantics. One conveys meaning to a computer at a lower level, the other conveys it to a human at a higher level. Well now we need to convey it at a higher level to an LLM so it can take care of the lower-level translation. I wonder if the LLM will eventually skip the programming part and just start moving bits around in response to requirements?
- lisbbb 10mo ago
  My solution as a consultant was to build some artifact that we could use as a starting point. Otherwise, you're sitting around spinning your wheels and billing big $ and the pressure is mounting. Building something at least allows you to demonstrate you are working on their behalf with the promise that it will be refined or completely changed as needed. It's very hard when you don't get people who can send down requirements, but that was like 100% of the places I worked. I very seldom ran into people who could articulate what they needed until I stepped up, showed them something they could sort of stand on, and then go from there. Mythical Man Month had it all--build one to throw away.
  - MetaWhirledPeas 10mo ago
    > I very seldom ran into people who could articulate what they needed The people with the needs and ideas are often so divorced from the "how" that they don't even bother trying to nail down the details. I think in their mind they are delegating that to the specialists. This question of who writes the requirements is so ubiquitous you would think we'd have better solutions for it. I know some people solve it with processes like BDD but personally I think we'd be better off if we just had clearer role definitions. For example, in a waterfall project the requirements usually land in the lap of the Business Analyst. Well when you look at Business Analyst roles you see they are expected to do a lot more than documenting requirements, so it's viewed as acceptable when they are somewhat bad at it. They also spend most of their time with the business so they are unaware of the limitations of the team who is expected to implement the changes. For another example look at Scrum. It talks a lot about good requirements in the form of user stories, but it stops short of assigning this responsibility to any one of the formal roles, presumably making it a team activity or expecting it to be organic. When we want someone to write code we hire a programmer, and writing code is what they are expected to do. Where is the role that is strictly requirements and nothing else? Considering how often I hear complaints about bad requirements, it seems overdue that we establish one.
alfalfasprout 10mo ago
This is one reason I think spec driven development is never really going to work the way people claim it should. It's MUCH harder to write a truly correct, comprehensive, and useful spec than the code in many cases.
asimeqi 10mo ago
AI is making coding so cheap, you can now program a few versions of the API and choose what works better.
jama211 10mo ago
This is like saying the typewriter won’t make a newspaper company more productive because the biggest bottlenecks are the research and review processes rather than the typing. It’s absolutely true, but it was still worth it to go up to typewriters, and the fact that people were spending less effort and time on the handwriting part helps all aspects of energy levels etc across their job.
antirez 10mo ago
This means your difficulty is not programming per se, but that you are working on a very suboptimal industry / company / system. With all due respect, you use programming at work, but true programming is the act of creating a system that you or your team designed and want to make alive. Confusing the reality of writing code for a living in some company with what Programming with capitalized P is, produces a lot of misunderstanding.
freetonik 10mo ago
>In my work, the bigger bottleneck to productivity is that very few people can correctly articulate requirements. Agreed. In addition, on the other side of the pipeline, code reviews are another bottleneck. We could have more MRs in review thanks to AI, but we can't really move at the speed of LLM's outputs unless we blindly trust it (or trust another AI to do the reviews, at which point what are we doing here at all...)
sputr 10mo ago
Yeah, the hardest part is understanding the requirements. But it then still takes hours and hours and hours to actually build the damn thing. Except that now it still takes me the same time to understand the requirements ... and then the coding takes 1/2 or 1/3 of the time. The coding also always takes 1/3 of the effort so I leave my job less burned out. Context: web app development agency. I really don't understand this "if it does not replace me 100% it's not making me more productive" mentality. Yeah, it's not a perfect replacement for a senior developer ... but it is like putting the senior developer on a bike and pretending that it's not making them go any faster because they are still using their legs.
theptip 10mo ago
> very few people can correctly articulate requirements The observation from Lean is that the faster you can build a prototype, the faster you can validate the real/unspoken/unclear requirements. This applies for backends too. A lot of the “enterprise-y” patterns like BFFs, hexagonal, and so on, will make it really easy to compose new APIs from your building blocks. We don’t do this now because it’s too expensive to write all the boilerplate involved. But one BFF microservice per customer would be totally feasible for a sales engineer to vibe code, in the right architecture.
btbuildem 10mo ago
> the bigger bottleneck to productivity is that very few people can correctly articulate requirements. One could argue that "vibe coding" forces you (eventually) to think in terms of requirements. There's a range of approaches, from "nitpick over every line written by AI" to "yolo this entire thing", but one thing they have in common is they all accelerate failure if the specs are not there. You very quickly find out you don't know where you're going. I see this in my work as well, the biggest bottleneck is squeezing coherent, well-defined requirements out of PMs. It's easy to get a vision board, endless stacks of slides about priorities and direction, even great big nests of AWS / Azure thingnames masquerading as architecture diagrams. But actual "this is the functionality we want to implement and here are the key characteristics of it" detail? Absolutely scarce.
paulddraper 10mo ago
Sounds like the bottleneck is good PMs then. Which is what vibe coders are.....
mlinhares 10mo ago
Is there anyone doing dev work that operates in an environment where people can clearly articulate what they want? I've never worked in a place like that in 20 years doing software.
BizarroLand 10mo ago
The only class I've ever failed was a c++ class where the instructor was so terrible at explaining the tasks that I literally could not figure out what he wanted. I had to retake it with the same instructor but by some luck I was able to take it online, where I would spend the majority of the time trying to decipher what he was asking me to do. Ultimately I found that the actual ask was being given as a 3 second aside in a 50 minute lecture. Once I figured out his quirk I was able to isolate the ask and code it up, ended with an A+ in the class on the second take. I would like to say that I learned a lot about programming from that teacher, but what I actually learned is what you're saying. Smart, educated, capable people are broken when it comes to clearly communicating their needs to other people just slightly outside of their domain. If you can learn the skill of figuring out what the hell they're asking for and delivering that, that one skill will be more valuable to you in your career than competency itself.
lxgr 10mo ago
In my work, the bigger bottleneck to productivity is that very few people can correctly articulate requirements. [...] software development is a lot more than coding and requires critical thinking to discover the requirements. Very well said. More often than not, the job isn't to translate the product requirements into compiling/correctly executing computer code, but rather to reveal the hidden contradictions in a seemingly straightforward natural-language feature specification. Once these are ironed out, the translation into code quite often does become a somewhat mechanical exercise, at least in my line of work. We're basically the lawyers the person finding the magic lamp should have consulted with before opening their mouth while facing the genie ;)
kalasoo 10mo ago
> In my work, the bigger bottleneck to productivity is that very few people can correctly articulate requirements. Totally agree. I’ve tried to explain this in many places: AI coding (and creative tools in general) will ultimately remain tools. Only people who can clearly and thoughtfully articulate requirements will be able to fully leverage them. Another hot take: the “one-person company.” Headcount isn’t the key variable. With AI, the real constraint is how well you can understand a problem and clearly define a solution. - If a problem can be clearly defined and fully understood by one person, then one person is enough to solve it. - If a problem is more complex and requires two fundamentally different areas of expertise, then it will likely take two capable people to solve it—no more, no less.
seg_lol 10mo ago
AI coding allows me to simulate that system, cross reference it with what the document says wrt what the customer wants and figure out holes in the spec. Having to code something to find the hole in the definition, the spec, the problem, the anything was a necessary step in building a sound working system. That is no longer the case.
Breza 9mo ago
I really wonder if we're going to see a reversion to old school project management, with a PMBOK's worth of detailed project documents for every major initiative instead of the modern Agile/Scrum/Kanban approach that seems to work better for human devs. If you can get everyone to agree on the minutia of, for example, the Stakeholder Management Plan, up front then the LLM actually has a chance of developing a decent program that has the features everyone wants. Then again, if humans could agree on all the project minutia at the outset, we never would have developed the other systems.

mavamaarten 10mo ago

Yup. I would never be able to give my Jira tickets to an LLM because they're too damn vague or incomplete. Getting the requirements first needs 4 rounds of lobbying with all stakeholders.

bjacobso 10mo ago
Claude Code et al. asks clarifying questions in plan mode before implementing. This will eventually extend to jira comments
- fooker 10mo ago
  What do you mean by eventually? this already exists.
- swatcoder 10mo ago
  You think the business line stakeholder is going to patiently hang out in JIRA, engaging with an overly cheerful robot that keeps "missing the point" and being "intentionally obtuse" with its "irrelevant questions"? This is how most non-technical stakeholders feel when you probe for consistent, thorough requirements and a key professional skill for many more senior developers and consultants is in mastering the soft skills that keep them attentive and sufficiently helpful. Those skills are not generic sycophancy, but involve personal attunement to the stakeholder, patience (exercising and engendering), and cycling the right balance between persistence and de-escalation. Or do you just mean there will be some PM who acts as proxy between for the stakeholder on the ticket, but still needs to get them onto the phone and into meetings so the answers can be secured? Because in the real world, the prior is outlandish and the latter doesn't gain much.
  - a_wild_dandan 10mo ago
    Businesses do whatever’s cheap. AI labs will continue making their models smarter, more persuasive. Maybe the SWE profession will thrive/transform/get massacred. We don’t know.
colechristensen 10mo ago
A significant part of my LLM workflow involves having the LLM write and update tickets for me. It can make a vague ticket precise and that can be an easy platform to have discussions with stakeholders.
- somebehemoth 10mo ago
  I like this use of LLM because I assume both the developer and ticket owner will review the text and agree to its contents. The LLM could help ensure the ticket is thorough and its meaning is understood by all parties. One downside is verbosity, but the humans in the loop can edit mercilessly. Without human review, these tickets would have all the downsides of vibe coding. Thank you for sharing this workflow. I have low tolerance for LLM written text, but this seems like a really good use case.
- SoftTalker 10mo ago
  Wait until you learn that the people on the other side of your ticket updates are also using LLMs to respond. It's LLMs talking to LLMs now.
  - colechristensen 10mo ago
    The desired result is coming to a documented agreement on an interaction, not some exercise in argument that has to happen between humans. I find having an LLM create tickets for itself to implement to be an effective tool that I rarely have to provide feedback for at all. This seems like greybeards complaining that people who don't write assembly by hand.
    - Yeask 10mo ago
      Who has ever complained that kids don't write assembly by hand? Stop being outraged for things that are only real on your mind.
      - colechristensen 10mo ago
mrweasel 10mo ago
We had a client who'd create incredibly detailed Jira tickets. Their lead developer (also their only developer) would write exactly how he'd want us to implement a given feature, and what the expected output would be. The guy is also a complete tool. I'd point out that what he described wasn't actually what they needed, and that there functionality was ... strange and didn't actually do anything useful. We'd be told to just do as we where being told, seeing as they where the ones paying the bills. Sometimes we'd read between the lines, and just deliver what was actually needed, then we'd be told just do as we where told next time, and they'd then use the code we wrote anyway. At some point we got tired of the complaining and just did exactly as the tasks described, complete with tests that showed that everything worked as specified. Then we where told that our deliveries didn't work, because that wasn't what they'd asked for, but couldn't tell us where we misunderstood the Jira task. Plus the tests showed that the code functioned as specified. Even if the Jira tasks are in a state where it seems like you could feed them directly to an LLM, there's no context (or incorrect context) and how is a chatbot to know that the author of the task is a moron?
- ForOldHack 10mo ago
  "The guy is also a complete tool." - Who says Hackers news is not filled with humor?
- SchemaLoad 10mo ago
  Every time I've received overly detailed JIRA tickets like this it's always been significantly more of a headache than the vague ones from product people. You end up with someone with enough tech knowledge to have an opinion, but separated enough from the work that their opinions don't quite work.
  - jordwest 10mo ago
    Same, I think there's an idealistic belief in people who write those tickets that something can be perfectly specified upfront. Maybe for the most mundane, repetitive tasks that's true. But I'd argue that the code is the full specification, so if you're going to fully specify it you might as well just write the code and then you'll actually have to be confronted with your mistaken assumptions.
threethirtytwo 10mo ago
Who says an LLM can’t be taught or given a system prompt that enables them to do this? Agentic AI can now do 20 rounds of lobbying with all stake holders as long as it’s over something like slack.

jcelerier 10mo ago

To be honest I've never worked in an environment that seemed too complex. On my side my primary blocker is writing code. I have an unending list of features, protocols, experiments, etc. to implement, and so far the main limit was the time necessary to actually write the damn code.

f1shy 10mo ago
I don’t want to imply this is your case, because of course I’ve no idea how you work. But I’ve seen way too often, the reason for so many separate features is: A) as stated by parent comment, the ones doing req. mngmt. Are doing a poor job of abstracting the requirements, and what could be done as one feature suddenly turns in 25. B) in a similar manner as A, all solutions imply writing more and more code, and never refactor and abstract parts away.
- mckn1ght 10mo ago
  My guess would be that the long list is maybe not self contained features (although still can be, I know I have more feature ideas than I can deliver in the next couple years myself), but behaviors or requirements of one or a handful of product feature areas. When you start getting down into the weeds, there can be tons and tons of little details around state maintenance, accessibility, edge cases, failure modes, alternate operation modes etc. That all combines to make lots of code that is highly interconnected, so you need to write even more code to test it. Sometimes much more than even the target implementations code.
- deleted 10mo ago
  [deleted]
swatcoder 10mo ago
That sounds like papier mache more than bridge building, forever pasting more code on as ideas and time permit without the foresight to engineer or architect towards some cohesive long-term vision. Most software products built that way seem to move fast at first but become monstrous abominations over time. If those are the only places you keep finding yourself in, be careful!

legitster 10mo ago

Convince your PMs to use an LLM to help "breadboard" their requirements. It's a really good use case. They can ask their dumb questions they are afraid to and an LLM will do a decent job of parsing their ideas, asking questions, and putting together a halfway decent set of requirements.

gitremote 10mo ago
PMs wouldn't be able to ask the right questions. They have zero experience with developer experience (DevEx) and they only have experience with user experience (UX).
- tmp10423288442 10mo ago
  You can hope that an LLM might have some instructions related to DevEx in its prompt at least. There's no way to completely fix stupid, anymore than you can convince a naive vibecoder that just vibing a new Linux-compatible kernel written entirely in Zig is a feasible project.
Scarblac 10mo ago
How does the LLM get all the required knowledge about the domain and the product to ask relevant questions?
- sh4rks 10mo ago
  Give it access to the codebase and a text file with all relevant business knowledge.
  - wiml 10mo ago
    Man ... if there were a text file with "all relevant business knowledge" in any job I've ever worked, it would have been revolutionary. I'd say 25% of my work-hours are just going around to stakeholders and getting them to say what some of their unstated assumptions and requirements are.

giancarlostoro 10mo ago

I have done both strict back-end, strict front-end, full stack, QA automation and some devops as well, I worked in an all Linux shop where we were encouraged by great senior devs to always strive for better software all around. I think you're right, it mostly depends on your mindset and how much you expose yourself to the craft. I can tackle obscure front-end things sometimes better than back-end issues despite hating front-end but knowing enough to be dangerous. (My first job in tech really had me doing everything imaginable) I find the LLMs boost my productivity because I've always had a sort of architectural mindset, I love looking up projects that solve specific problems and keeping them on the back of my mind, turns out I was building myself up for instructing LLMs on how to build me software, and it takes several months worth of effort and spits it out in a few hours. Speaking of vibe coding in archaic languages, I'm using LLMs to understand old Shockwave Lingo to translate it to a more modern language, so I can rebuild a legacy game in a modern language. Maybe once I spin up my blog again I'll start documenting that fun journey.

burnt-resistor 10mo ago
Hehe. In the "someone should make a website"™ department: using a crap tons of legacy protocols and plugins semi-interoperable with modern while offering legacy browsers loaded with legacy plugins something usable to test with, i.e., - SSL 2.0-TLS 1.1, HTTP/0.9-HTTP/1.1, ftp, WAIS, gopher, finger, telnet, rwho, TinyFugue MUD, UUCP email, SHOUTcast streaming some public domain radio whatever - <blink>, <marquee>, <object>, XHTML, SGML - Java <applet>, Java Web Start - MSJVM/J++, ActiveX, Silverlight - Flash, Shockwave (of course), Adobe Air - (Cosmo) VRML - Joke ActiveX control or toolbar that turns a Win 9x/NT-XP box into a "real" ProgressBar95. ;) (Gov't mandated PSA: Run vintage {good,bad}ness with care.)
- lawlessone 10mo ago
  why even write webpages or apps anymore just prompt an LLM everytime a user makes a request and write the page to send to the user :D
  - giancarlostoro 10mo ago

shortrounddev2 10mo ago

I write a library which is used by customers to implement integrations with our platform. The #1 thing I think about is not > How do I express this code in Typescript? it's > What is the best way to express this idea in a way that won't confuse or anger our users? Where in the library should I put this new idea? Upstream of X? Downstream of Y? How do I make it flexible so they can choose how to integrate this? Or maybe I don't want to make it flexible - maybe I want to force them to use this new format? > Plus making sure that whatever changes I make are non-breaking, which means that if I update some function with new parameters, they need to be made optional, so now I need to remember, downstream, that this particular argument may or may not be `undefined` because I don't want to break implementations from customers who just upgraded the most recent minor or patch version The majority of the problems I solve are philosophical, not linguistic

doug_durham 10mo ago

I don't think the author would disagree with you. Ad you point out coding is just one part of software development. I understand his point to be that the coding portion of the job is going to be very different going forward. A skilled developer is still going to need to understand frameworks and tradeoffs so that they can turn requirements into a potential solution. It just they might not be coding up the implementation.

tshaddox 10mo ago

I like my requirements articulated so clearly and unambiguously that an extremely dumb electronic logic machine can follow every aspect of the requirements and implement them "perfectly" (limited only by the physical reliability of the machine).

deepsun 10mo ago
Aka "coding". I see what you mean ;)

epolanski 10mo ago

If AI doesn't make you more productive you're using it wrong, end of story. Even if you don't let it author or write a single line of code, from collecting information, inspecting code, reviewing requirements, reviewing PRs, finding bugs, hell even researching information online, there's so many things it does well and fast that if you're not leveraging it, you're either in denial or have ai skill issues period.

mdavidn 10mo ago
It sounds like you're the one in denial? AI makes some things faster, like working in a language I don't know very well. It makes other things slower, like working in a language I already know very well. In both cases, writing code is a small percentage of the total development effort.
- epolanski 10mo ago
  No I'm not, I'm just sick of these edgy takes where AI does not improve productivity when it obviously does. Even if you limit your AI experience to finding information online through deep research it's such a time saver and productivity booster that makes a lot of difference. The list of things it can do for you is massive, even if you don't have it write a single line of code. Yet the counter argument is like "bu..but..my colleague is pushing slop and it's not good at writing code for me", come on, then use it at things it's good at, not things you don't find it satisfactory.
  - lunar_mycroft 10mo ago
    It "obviously" does based on what, exactly? For most devs (and it appears you, based on your comments) the answer is "their own subjective impressions", but that METR study (https://arxiv.org/pdf/2507.09089 https://arxiv.org/pdf/2507.09089) should have completely killed any illusions that that is a reliable metric (note: this argument works regardless of how much LLMs have improved since the study period, because it's about how accurate dev's impressions are, not how good the LLMs actually were).

omnicognate 10mo ago

> Software development jobs must be very diverse if even this anti-vibe-coding guy thinks AI coding definitely makes developers more productive. As a Professor of English who teaches programming to humanities students, the writer has had an extremely interesting and unusual academic career [1]. He sounds awesome, but I think it's fair to suggest he may not have much experience of large scale commercial software development or be particularly well placed to predict what will or will not work in that environment. (Not that he necessarily claims to, but it's implicit in strong predictions about what the "future of programming" will be.) [1] https://stephenramsay.net/about/ https://stephenramsay.net/about/

godelski 10mo ago
Hard to say but to back his claim that he was programming since the 90's his CV shows he was working on stuff that's clearly more than your basic undergraduate skill level since the early 2000's. I'd be willing to bet he has more years under his belt than most HN users. I mean I'm considered old here, in my mid 30's, and this guy has been programming most my life. Though that doesn't explicitly imply experience, or more specifically experience in what. That said, I think people really under appreciate how diverse programmers actually are. I started in physics and came over when I went to grad school. While I wouldn't expect a physicist to do super well on leetcode problems I've seen those same people write incredible code that's optimized for HPC systems and they're really good at tracing bottlenecks (it's a skill that translates from physics really really well). Hell, the best programmer I've ever met got that way because he was doing his PhD in mechanical engineering. He's practically the leading expert in data streaming for HPC systems and gained this skill because he needed more performance for his other work. There's a lot of different types of programmers out there but I think it's too easy to think the field is narrow.
- AceJohnny2 10mo ago
  > I mean I'm considered old here, in my mid 30's sigh
  - jjgreen 10mo ago

threethirtytwo 10mo ago

You can vibe ask the requirements. Not even kidding.

yieldcrv 10mo ago

and in reality, all the separate roles should be deprecated we vibe requirements to our ticket tracker with an api key, vibe code ticket effort, and manage the state of the tickets via our commits and pull requests and deployments just teach the guy the product manager is shielding you from not to micromanage and all the frictions are gone in this same year I've worked at an organization that didn't allow AI use at all, and by Q2, Co-Pilot was somehow solving their data security concerns (gigglesnort) in a different organization none of those restrictions are there and the productivity boost is through an order of magnitude greater

al_borland 10mo ago

I don’t mind the coding, it’s the requirements gathering and status meetings I want AI to automate away. Those are the parts I don’t like and where we’d see the biggest productivity gains. They are also the hardest to solve for, because so much of it is subjective. It also often involves decisions from leadership which can come with a lot of personal bias and occasionally some ego.

Vegenoid 10mo ago
This is like the reverse centaur form of coding. The machine tells you what to make, and the human types the code to do the thing.
- al_borland 10mo ago
  Well, when put like that it sounds pretty bad too. I was thinking more that the human would tell the machine want to make. The machine would help flesh out the idea into actual requirements, and make any decisions the humans are too afraid or indecisive to make. Then the coding can start.

luckydata 10mo ago

Sounds like you work with inexperienced PMs that are not doing their job, did you try having a serious conversation about this pattern with them? I'm pretty sure some communication would go a long way towards getting you on a better collaboration groove.

gitremote 10mo ago
I've been doing API development for over ten years and worked at different companies. Most PMs are not technical and it's the development team's job figure out the technical specifications for APIs we build. If you press the PMs, they will ask the engineering/development manager for the written technical requirements, and if the manager is not technical, they will assign it to the developers/engineers. Technical requirements for an API are really a system design question.
- luckydata 10mo ago
  The technical design is definitely the job of the technical team for the most part, but the business requirements should be squarely on the pm. The list of use cases, how the API feels, the performance etc... All of that the business owner should be able to describe to you to ensure it does the job it needs and is fit for the market.

burnte 10mo ago

"the bigger bottleneck to productivity is that very few people can correctly articulate requirements." I've found the same way. I just published an AI AUP for my company and most of it is teaching folks HOW to use AI.

sureglymop 10mo ago

Also that requirements engineering in general isn't being done correctly. I'm the last guy to be enthused about any "ritualistic" seeming businessy processes. Just let me code... However, some things do need actually well defined adhered to processes where all parties are aware of and agreeing with the protocol.

keeda 10mo ago

This feels like addressing a point TFA did not make. TFA talks mostly about vibe-coding speeding up coding, whereas your comment is about software development as a whole. As you point out, coding is just one aspect of engineering and we must be clear about what "productivity" we are talking about. Sure, there are the overhypers who talk about software engineers getting entirely replaced, but I get the sense those are not people who've ever done software development in their lives. And I have not seen any credible person claiming that engineering as whole can be done by AI. On the other hand, the most grounded comments about AI-assisted programming everywhere are about the code, and maybe some architecture and design aspects. I personally, along with many other commenters here and actual large-scale studies, have found that AI does significantly boost coding productivity. So yes, actual software engineering is much more than coding. But note that even if coding is, say, only 25% of engineering (there are actually studies about this), putting a significant dent in that is still a huge boost to overall productivity.

pron 10mo ago

The thing is that some imagined AI that can reliably produce reliable software will also likely be able to be smart enough to come up with the requirements on its own. If vibe coding is that capable, then even vibe coding itself is redundant. In other words, vibe coding cannot possibly be "the future", because the moment vibe coding can do all that, vibe coding doesn't need to exist. The converse is that if vibe coding is the future, that means we assume there are things the AI cannot do well (such as come up with requirements), at which point it's also likely it cannot actually vibe code that well. The general problem is that once we start talking about imagined AI capabilities, both the capabilities and the constraints become arbitrary. If we imagine an AI that does X but not Y, we could just as easily imagine an AI that does both X and Y.

whimsicalism 10mo ago
I agree with the first part which is basically 'being able to do a software engineers full job' is basically ASI/AGI complete. But I think it is certainly possible that we reach a point/plateau where everything is just 'english -> code' compilation but that 'vibe coding' compilation step is really really good.
- pron 10mo ago
  It's possible, but I don't see any reason to assume that it's more likely that machines will be able to code as well as working programmers yet not be able to come up with requirements or even ideas as well as working PMs. In fact, why not the opposite? I think that currently LLMs are better at writing general prose, offering advice etc.., than they are at writing code. They are better at knowing what people generally want than they are at solving complex logic puzzle that require many deduction steps. Once we're reduced to imagining what AI can and cannot do, we can imagine pretty much any capability or restriction we like. We can imagine something is possible, and we can just as well choose to imagine it's not possible. We're now in the realm of, literally, science fiction.
  - whimsicalism 10mo ago
    > It's possible, but I don't see any reason to assume that it's more likely that machines will be able to code as well as working programmers yet not be able to come up with requirements or even ideas as well as working PMs. Ideation at the working PM level, sure. I meant more hard technical ideation - ie. what gets us from 'not working humanoid robot' to 'humanoid robot' or 'what do we need to do to get a detection of a higgs boson', etc. etc. I think it is possible to imagine a world where 'english -> code' (for reasonably specific english) is solved but not that level of ideation. If that level of ideation is solved, then we have ASI.

ljm 10mo ago

I constantly run into issues where features are planned and broken down outside-in, and it always makes perfect sense if you consider it in terms of the pure user interface and behaviour. It completely breaks down when you consider the API, or the backend, is a cross-cutting concern across many of those tidy looking tasks and cannot map to them 1:1 without creating an absolute mess. Trying to insert myself, or the right backend people, into the process, is more challenging now than it used to be, and a bad API can make or break the user experience as the UI gets tangled in the web of spaghetti. It hobbles the effectiveness of whatever you could get an LLM to do because you’re already starting on the backfoot, requirements-wise.

ozim 10mo ago

Unfortunately a lot of it is also because of illiteracy. Lots of people hide the fact that they struggle with reading and a lot of people hide or try to hide the fact they don’t understand something.

wouldbecouldbe 10mo ago

The solo projects I do are 10x, the team projects I do maybe 2-3x in productivity. I think in big companies it's much much less. Highest gains are def in full stack frameworks (like nextjs), with Database ORM, and building large features in one go, not having to go back & forth with stakeholders or collegues.

MetaWhirledPeas 10mo ago

> very few people can correctly articulate requirements This is the new programming. Programming and requirements are both a form of semantics. One conveys meaning to a computer at a lower level, the other conveys it to a human at a higher level. Well now we need to convey it at a higher level to an LLM so it can take care of the lower-level translation. I wonder if the LLM will eventually skip the programming part and just start moving bits around in response to requirements?

lisbbb 10mo ago
My solution as a consultant was to build some artifact that we could use as a starting point. Otherwise, you're sitting around spinning your wheels and billing big $ and the pressure is mounting. Building something at least allows you to demonstrate you are working on their behalf with the promise that it will be refined or completely changed as needed. It's very hard when you don't get people who can send down requirements, but that was like 100% of the places I worked. I very seldom ran into people who could articulate what they needed until I stepped up, showed them something they could sort of stand on, and then go from there. Mythical Man Month had it all--build one to throw away.
- MetaWhirledPeas 10mo ago
  > I very seldom ran into people who could articulate what they needed The people with the needs and ideas are often so divorced from the "how" that they don't even bother trying to nail down the details. I think in their mind they are delegating that to the specialists. This question of who writes the requirements is so ubiquitous you would think we'd have better solutions for it. I know some people solve it with processes like BDD but personally I think we'd be better off if we just had clearer role definitions. For example, in a waterfall project the requirements usually land in the lap of the Business Analyst. Well when you look at Business Analyst roles you see they are expected to do a lot more than documenting requirements, so it's viewed as acceptable when they are somewhat bad at it. They also spend most of their time with the business so they are unaware of the limitations of the team who is expected to implement the changes. For another example look at Scrum. It talks a lot about good requirements in the form of user stories, but it stops short of assigning this responsibility to any one of the formal roles, presumably making it a team activity or expecting it to be organic. When we want someone to write code we hire a programmer, and writing code is what they are expected to do. Where is the role that is strictly requirements and nothing else? Considering how often I hear complaints about bad requirements, it seems overdue that we establish one.

alfalfasprout 10mo ago

This is one reason I think spec driven development is never really going to work the way people claim it should. It's MUCH harder to write a truly correct, comprehensive, and useful spec than the code in many cases.

asimeqi 10mo ago

AI is making coding so cheap, you can now program a few versions of the API and choose what works better.

jama211 10mo ago

This is like saying the typewriter won’t make a newspaper company more productive because the biggest bottlenecks are the research and review processes rather than the typing. It’s absolutely true, but it was still worth it to go up to typewriters, and the fact that people were spending less effort and time on the handwriting part helps all aspects of energy levels etc across their job.

antirez 10mo ago

This means your difficulty is not programming per se, but that you are working on a very suboptimal industry / company / system. With all due respect, you use programming at work, but true programming is the act of creating a system that you or your team designed and want to make alive. Confusing the reality of writing code for a living in some company with what Programming with capitalized P is, produces a lot of misunderstanding.

freetonik 10mo ago

>In my work, the bigger bottleneck to productivity is that very few people can correctly articulate requirements. Agreed. In addition, on the other side of the pipeline, code reviews are another bottleneck. We could have more MRs in review thanks to AI, but we can't really move at the speed of LLM's outputs unless we blindly trust it (or trust another AI to do the reviews, at which point what are we doing here at all...)

sputr 10mo ago

Yeah, the hardest part is understanding the requirements. But it then still takes hours and hours and hours to actually build the damn thing. Except that now it still takes me the same time to understand the requirements ... and then the coding takes 1/2 or 1/3 of the time. The coding also always takes 1/3 of the effort so I leave my job less burned out. Context: web app development agency. I really don't understand this "if it does not replace me 100% it's not making me more productive" mentality. Yeah, it's not a perfect replacement for a senior developer ... but it is like putting the senior developer on a bike and pretending that it's not making them go any faster because they are still using their legs.

theptip 10mo ago

> very few people can correctly articulate requirements The observation from Lean is that the faster you can build a prototype, the faster you can validate the real/unspoken/unclear requirements. This applies for backends too. A lot of the “enterprise-y” patterns like BFFs, hexagonal, and so on, will make it really easy to compose new APIs from your building blocks. We don’t do this now because it’s too expensive to write all the boilerplate involved. But one BFF microservice per customer would be totally feasible for a sales engineer to vibe code, in the right architecture.

btbuildem 10mo ago

> the bigger bottleneck to productivity is that very few people can correctly articulate requirements. One could argue that "vibe coding" forces you (eventually) to think in terms of requirements. There's a range of approaches, from "nitpick over every line written by AI" to "yolo this entire thing", but one thing they have in common is they all accelerate failure if the specs are not there. You very quickly find out you don't know where you're going. I see this in my work as well, the biggest bottleneck is squeezing coherent, well-defined requirements out of PMs. It's easy to get a vision board, endless stacks of slides about priorities and direction, even great big nests of AWS / Azure thingnames masquerading as architecture diagrams. But actual "this is the functionality we want to implement and here are the key characteristics of it" detail? Absolutely scarce.

paulddraper 10mo ago

Sounds like the bottleneck is good PMs then. Which is what vibe coders are.....

mlinhares 10mo ago

Is there anyone doing dev work that operates in an environment where people can clearly articulate what they want? I've never worked in a place like that in 20 years doing software.

BizarroLand 10mo ago

The only class I've ever failed was a c++ class where the instructor was so terrible at explaining the tasks that I literally could not figure out what he wanted. I had to retake it with the same instructor but by some luck I was able to take it online, where I would spend the majority of the time trying to decipher what he was asking me to do. Ultimately I found that the actual ask was being given as a 3 second aside in a 50 minute lecture. Once I figured out his quirk I was able to isolate the ask and code it up, ended with an A+ in the class on the second take. I would like to say that I learned a lot about programming from that teacher, but what I actually learned is what you're saying. Smart, educated, capable people are broken when it comes to clearly communicating their needs to other people just slightly outside of their domain. If you can learn the skill of figuring out what the hell they're asking for and delivering that, that one skill will be more valuable to you in your career than competency itself.

lxgr 10mo ago

In my work, the bigger bottleneck to productivity is that very few people can correctly articulate requirements. [...] software development is a lot more than coding and requires critical thinking to discover the requirements. Very well said. More often than not, the job isn't to translate the product requirements into compiling/correctly executing computer code, but rather to reveal the hidden contradictions in a seemingly straightforward natural-language feature specification. Once these are ironed out, the translation into code quite often does become a somewhat mechanical exercise, at least in my line of work. We're basically the lawyers the person finding the magic lamp should have consulted with before opening their mouth while facing the genie ;)

kalasoo 10mo ago

> In my work, the bigger bottleneck to productivity is that very few people can correctly articulate requirements. Totally agree. I’ve tried to explain this in many places: AI coding (and creative tools in general) will ultimately remain tools. Only people who can clearly and thoughtfully articulate requirements will be able to fully leverage them. Another hot take: the “one-person company.” Headcount isn’t the key variable. With AI, the real constraint is how well you can understand a problem and clearly define a solution. - If a problem can be clearly defined and fully understood by one person, then one person is enough to solve it. - If a problem is more complex and requires two fundamentally different areas of expertise, then it will likely take two capable people to solve it—no more, no less.

seg_lol 10mo ago

AI coding allows me to simulate that system, cross reference it with what the document says wrt what the customer wants and figure out holes in the spec. Having to code something to find the hole in the definition, the spec, the problem, the anything was a necessary step in building a sound working system. That is no longer the case.

Breza 9mo ago

I really wonder if we're going to see a reversion to old school project management, with a PMBOK's worth of detailed project documents for every major initiative instead of the modern Agile/Scrum/Kanban approach that seems to work better for human devs. If you can get everyone to agree on the minutia of, for example, the Stakeholder Management Plan, up front then the LLM actually has a chance of developing a decent program that has the features everyone wants. Then again, if humans could agree on all the project minutia at the outset, we never would have developed the other systems.