6 ms·

100% We're already seeing this at the enterprise level. Companies have dictates from leadership that "if you're writing code manually, you're doing it wrong."

• javcasas 1mo ago
  My job improved significantly since I managed to get into their (managers) thick skulls to tell Claude to not be verbose. I'm tired of 1200-word tickets for "put the totals in the automated emails".
• ben_w 1mo ago
  > That sounds great until you realize that "hey Claude, read this Jira ticket and implement the feature in this code base" isn't really worth $200K/year. Nor even €50k/year. Two things are true: 1) The coding part of my career is over. LLMs are capable of doing everything I've ever been paid to *write*. 2) My actual job also included non-coding work: Does this attempted solution even work at all? Is this solving the right problem? Even if it's a valid solution to the right problem, is it the best solution given the time constraints? That last one, "given the time constraints", is a place where my experience is still useful. The AI is as lazy (or as optimised for fast wins) as the humans whose examples it was trained upon; but an LLM costs so little that the answer is always "do it right" rather than "do it fast". A lot of people don't know what "do it right" even looks like, having only ever known e.g. websites that take 5 seconds to load because of all the adverts and analytics, and never the world where machines with 1% of the CPU and no GPU at all could fit a fully playable first person shooter in the same memory footprint as that page. At least, I hope this "is a place where my experience is still useful"; I may just be telling myself a nice story, same as all the other people through history who have found themselves obsoleted when the automation came for them.
  • enraged_camel 1mo ago
    FWIW: The highest paid devs I know excel at 2, and aren't even that good at 1.
    • finaard 1mo ago
      I guess that somewhat describes me - and guess what, that also transfers to "should we even throw AI at that specific problem, or are there other solutions?". Early curiousity in figuring out the limits of LLMs now is turning into revenue by customers with problems that didn't exist a few years ago at all - which currently is quite an exciting field to work in as a lot of things just don't have pre-established solutions yet. It's a similar level of excitement as when we started doing devops stuff before devops even was a thing (which has been one of our main things for a very long time now).
    • wnmurphy 1mo ago
      Complement: I know many devs who are exceptional at 1 (writing code), and 2 (contextual thinking) never even occurs to them. They will happily implement whatever they are told, without ever thinking to ask "why am I being asked to implement this?" or "is this actually solving the problem?"
  • tayo42 1mo ago
    Ai can work through all of those questions in number 2 and design around it. I was just doing that yesterday designing a game demo lol
    • matsemann 1mo ago
      Works for a demo, but quickly stagnates. Future models may of course push the limits further, but right now it quickly goes sideways without someone knowledgeable at the helm.
      • tayo42 1mo ago
        You don't design things with never ending details though. If your developing a feature there's a limited scope to it. If your designing the direction of a large project you're working with higher level concepts. The point is that AI is aware of constraints and can manage a round it. You've got to keep in mind the size of a typical software project and plan. Most people aren't writing a kernel. They're writing some backend tool and need a project that fits into a couple of quarters with a handful of people at most involved.
• sandeepkd 1mo ago
  I think there are two parts to it 1. Execution of engineering task - Companies happen to focus on this mostly and this is the metric to measure easily. Using LLM tools gives a impression of improvement on this area which is what everyone is chasing 2. Growth of the Engineer - This is the one which was always a side product of company culture, individuals interest, work being done, time being spent to understand, learn from failures. A job being executed perfectly for the first time itself does not gives the opportunity for learning, no memories/experiences are built up mind of the person executing the job after a while. The second part is the one which is under appreciated in current scheme of things since it was a by product. There is a concept of muscle memory which pretty much applies to everything.
• doctoboggan 1mo ago
  > That sounds great until you realize that "hey Claude, read this Jira ticket and implement the feature in this code base" isn't really worth $200K/year. When you factor in overhead and benefits, many companies were regularly paying that much for someone (many someones) to "read this Jira ticket and implement the feature". We are currently in the "centaur" phase where a human-AI combination produces the best output, but I think some people are betting on the fact that the AI only product will eventually outperform the centaur. And with the cost of tokens falling thanks to fierce competition from the Chinese open weight models, it's definitely possible that those that bet on AI early will reap payoffs in lower expenditures for more output. Honestly not sure which side I land on that bet but I definitely can't rule it out.
  • svachalek 1mo ago
    We've gone through this with chess, and the days when a human can do anything to help AI there are long past; the human can only drag it down. It seems to me to be a form of the bitter lesson. I expect this will happen in every field where we don't add guardrails to require humans in the network. I have a hard time seeing regulation happening around this in the US but vanity may also serve, will CEOs be satisfied ruling armies of virtual assistants, or do they need big buildings full of human thralls?
    • LPisGood 1mo ago
      At some point the whims of the CEOs don’t win. The shareholders demand more growth.
      • dotancohen 1mo ago
        Demand from whom, if not the CEO?
        • emodendroket 1mo ago
          The board, presumably
        • 1mo ago
• risyachka 1mo ago
  Maybe some day, not in the short term. I've seen output of bad developers using Fable and after that I sleep safe. A bad or below average dev with AI will run your product and company into the ground in a matter of weeks.
  • switchbak 1mo ago
    It's like a tool that has caused a fan out of both good and bad outcomes. Good: you can refactor your codebase at will, throw out legacy cruft by the megabyte, improve build/CI time, and simplify ruthlessly. Not to mention kick out new features in simple and consistent ways that align with what a user actually wants. Or you could add megabytes of vibe coded crap, solutions that add a ton of mass but don't actually solve the problem at hand (seriously!), implement abstractions that are logically inconsistent with the rest of the system, etc. Both of these are happening right now, and I think the latter is happening at a rate far higher than the former. But our fundamental dynamics are still at play - the ball of mud is still a ball of mud, even if AI lets you make it 100x bigger. The problem just gets more entrenched. Eventually AI will learn how to simplify code, understand coupling, etc - and hopefully it will just iron out problems as it goes. I think we're a long way away from that. But this is uncharted territory, and I don't think anyone really knows. I certainly don't hear anyone focusing on that as a target of optimization however. My hope is that we'll see a number of companies collapse as they scale - with basically no hope of rescue, and perhaps we can re-learn these lessons yet again. It kind of feels like GitHub might be the first example of this.
    • oceanplexian 1mo ago
      > My hope is that we'll see a number of companies collapse as they scale - with basically no hope of rescue If you worked in SV like I did from 2010-2020 you know that the exact opposite of that will happen. I saw hundreds of companies successfully scale out of their garbage stack such as Facebook and PHP. The only thing that matters is the problem you’re solving and the quality of the code is irrelevant.
      • switchbak 1mo ago
• jgilias 1mo ago
  We have a product guy on the team who was in a deeply not technical role before AI who is trying to do the “hey Claude, read this Jira ticket, implement” thing. It doesn’t work for the vast majority of tickets he attempts because he doesn’t have the necessary understanding to even start thinking about if the solution that the autocomplete generates is even remotely workable. And that’s with fancy dev loops and whatnot. The spacer between the keyboard and the chair still matters in my experience.
  • dan_ggggg 1mo ago
    [flagged]
    • mcbuilder 1mo ago
      honestly "product guy" is enough of a slur for most technical folks. What you are saying just sounds nasty.
      • orangedog 1mo ago
        It's a troll account. Stuff like this isn't productive and should get flagged.
  • dd8601fn 1mo ago
    Not everyone has this, but I always felt that a significant percentage of the value I bring is in immediately recognizing what you shouldn’t do. I have a hard enough time explaining why “yet another bespoke application on some unmanaged azure resources” is a bad idea when they have more reasonable alternatives at hand. Now these goofs can (very nearly) press a button and do it anyway, with no comprehension of the consequences. It’s high fives and pats on the back, until I’m cleaning up the mess.
    • chermi 1mo ago
      This lands. Llms are bad precisely at following what not to do. They work best off of positive constraints. I have a design principles + tech preferences doc I force llms "lint" their approach against. It's not perfect but it helps. I call it a bias field, pushes them toward hopefully the happy and harmonious (with the rest of the system) paths. Obviously this is only partial and imperfect enforcement, but if it's applied to everything consistently it naturally encodes some self-consistency and harmony.
• mohamedkoubaa 1mo ago
  Decades ago, enterprises said, "If you're writing assembly you're doing it wrong". That led to a reduction in knowledge of assembly in the average programmer but the people who specialize in it haven't gotten any worse at it. The result was a generation of programmers who make useful software while very few of them understand the machine they program. You could easily make either a positive or negative value judgement about that result.
  • mapontosevenths 1mo ago
    I came here to rephrase the headline as "Punch card expertise is going to collapse from compiler reliance." Yes, it's true... but who cares? We lost that skill because we don't need it anymore. English is becoming a very popular programming language.
    • mohamedkoubaa 1mo ago
      The people who swizzle registers on GPU drivers need that skill, and there's no evidence that they lost it. There's a reason why we use the stack metaphor for a programming ecosystem. You trust the lower layers below the one you work in.
• everdrive 1mo ago
  People are fundamentally short-term thinkers. Just imagine spraying neurotoxins on your lawn. You're "saved" from the "terror" of noticing more than one kind of grass, but of course you're incrementally increased the cancer risk for yourself, your children, and who knows who else. This is just one example; people do this constantly. Plastic fleece puts an untold amount of poison into the environment, but "I need to be warm RIGHT NOW." etc. Or lead paint. "It's only toxic when it breaks down, and that won't be for decades!" Why would programming be any different?
  • mjburgess 1mo ago
    All the issues you mention here have a death horizon: the people engaged in the behaviour will be dead when its effects are most acute. That they engage in it then isnt very mysterious. That doesnt clearly apply here
    • everdrive 1mo ago
      The problem is further away when the next quarter, which for some companies, might as well be in the year 3000.
• kazinator 1mo ago
  Up to now, manual coding has produced mountains of code, faster than humans can un derstand it! Already! The nincompoops at the top think that if mountains of code can appear by snapping your fingers, they will be less of a problem. If the mountain doesn't work, no problem; since it was so cheap to produce, just scrap it and snap you fingers again. The next one will be better. Comparatively evaluating 2, 3, ... mountains of code is harder than trying to understand one.
• hintymad 1mo ago
  Boris: "I don't prompt Claude anymore. I have loops prompting Claude and figuring what to do". Boris: "I haven’t written a line of code by hand in, I think, eight months now… Claude Code, 100% written by Claude Code". Boris: "There’s no manually written code anywhere at the company… All of the SQL is written by models. Everything is just built by the models... Claude instances communicate with each other (e.g., over Slack) in autonomous loops" This does not sound like they review the code either. So, either the frontier labs like Anthropic have figured out something that very few companies could replicate, or they are being incredibly deceptive. I don't know which is true.
  • wry_discontent 1mo ago
    They work on research problems you can define a clear solution criteria for. The kinds of business software I work on don't have those characteristics. If I needed something like a utils library, I think I could easily have Claude write the whole thing and not read the code.
    • throwway120385 1mo ago
      As always, the essential skill in engineering is not providing the right answer it's about asking the right questions.
    • hintymad 1mo ago
      What puzzles me is this: research means that we are exploring something that has not done before, yet using Claude to generate code means slicing and dicing what has been done many times before. So, I'm not sure how to make sense of both at the same time: Anthropic is pushing the boundary of AI, yet all the knowledge and engineering in form of code can be generated from the previous work?
      • wry_discontent 1mo ago
        How I interpreted their thoughts on "loops" and "graphs" etc, is that they 1. have unlimited token allowances, and 2. are working on problems where the solution itself can be described by code. It reminds me of property based testing. I really liked the idea when I heard about it, but most of what I work on does not tend to behave in a way that can be easily described mathematically like that. Maybe I'm just not clever enough to do it.
• pandaman 1mo ago
  Engineers, free from writing thousands of lines of boilerplate, now have more time to review code and be more efficient in that armed with LLMs. E.g. instead of asking a question about the code and waiting for the author to respond, I can ask an LLM and get the answer almost immediately. Or, if I see some strange code being changed, I am always curious why it was there in the first place and, instead of tracing it through git blame over formatting, renaming, and moving files around dirs I can delegate this to an LLM. If I have doubts about it working in some environment I can, again, make an LLM test it out instead of asking the author etc. etc. And no, telling Claude to implement a Jira ticket is not worth $200K/year. Checking if it has not done something stupid and correcting it when it's trying to - is.
• Ancapistani 1mo ago
  > We are indeed producing a shit-ton of code, but the reality is that engineers are pumping out code faster than the humans can understand and (honestly) review it. That sounds great until you realize that "hey Claude, read this Jira ticket and implement the feature in this code base" isn't really worth $200K/year. My argument here is that what is worth $200k+ is the ability to distinguish the changes that must get thorough, critical review from those that need only a couple of specific things verified and those that require no manual review at all. Our jobs have never been to write code. We’ve been saying for decades that LoC isn’t a rational way to measure engineering output, and now we have our chance to structurally change that system before processes re-solidify. In fact, I think the flexibility to adopt new systems and the experience and foresight to choose a path that is better than the status quo without throwing out everything we’ve learned is going to be what sets companies apart and makes individual careers over the next few years. > we have leadership air dropping AI generated manifestos on the product owners and product owners having to use AI to transmute all that shit into 1,500 word Jira tickets that are 10% necessary feature work and 90% LLM boilerplate. There’s an important criticism here IMO - the relationship between “business” and “engineering” is changing drastically. It’s going to be a challenge to set the expectation that just because Marketing was able to vibe-code a prototype in a day, actual implementation may well take weeks or months. Engineering should be considering things like security, scalability, and systems integration that aren’t a concern for Marketing - that’s why we’re being paid! > So now you have software engineers whose job has changed radically to the point that the hardest part about being a software engineer is just filtering through AI generated artifacts from all directions just to try to get a feature out the door. I think it’s an extremely heterogenous landscape right now. Where I work I’m struggling mostly with organization - keeping the (literal) dozens of inbound features that come in every day straight long enough to hook up an agent harness, review, validate, and deploy. At other companies the issues seem to revolve around their Agile-based processes. Or maybe it’s non-technical vibe-coders and their expectations. Or maybe it’s executive leadership flirting with AI psychosis. Everything is in flux. It’s stressful and exciting, and I’m thankful to be around for it, even if I am in my 40s at this point and looking at the core skills I’ve built rapidly become worth exponentially less. It’s a huge opportunity for growth.
  • ElProlactin 1mo ago
• Alex3917 1mo ago
  > the reality is that engineers are pumping out code faster than the humans can understand and (honestly) review it The word "engineering" means doing things using a repeatable process to get predictable results. If you can get predictable results (e.g. guaranteeing the absence of data integrity issues, security issues, anything that will cause downtime, etc.) without looking at the code, you're still doing the work of engineering. Your job as an engineer is to choose high-value problems to work on, solve them in the correct way, and guarantee that the functional and non-functional requirements are met. If you no longer need to read the code to guarantee that it has the right set of ilities, then I'm not sure that's obviously a bad thing, as long as the ilities you're enforcing result in a codebase that is sustainably secure and maintainable over the long term.
  • unknownfuture 1mo ago
    > as long as the ilities you're enforcing result in a codebase that is sustainably secure and maintainable over the long term. Perfect example of begging the question. Vibe coding works great as long as vibe coding works great. Personally, I'd love to see how you enforce security and long-term maintainability without looking at the code cuz we need to add that to our build pipelines ASAP.
• giancarlostoro 1mo ago
  Mythical man month should still apply for AI coding. If you look at the code you're shipping, and you can't quickly edit it by hand, or fix a bug with it, you will be in trouble if the models are down, and your website is down at the same unfortunate time.
  • oh_no 1mo ago
    1. I think LLMs will end up pretty dramatically shrinking MTTR, a lot of that will be tooling to proactively resolve problems as soon as they start, but a lot of it is that agents are very good at finding and fixing problems by correlating data, something humans can do but I think we're going to be slower at 2. "The models are down" doesn't seem like a very realistic problem unless you have a single provider/set of endpoints. I do not recommend this setup but I guess if you have a single point of failure that is a risk.
    • Kinrany 1mo ago
      They may very well shrink MTTR and increase deploy frequency at the cost of all other metrics
  • confidantlake 1mo ago
    If the models are down you are probably in the same situation as when aws is down. A collective shrug, everyone is down, no one will take the blame individually.
• Gigachad 1mo ago
  >the hardest part about being a software engineer is just filtering through AI generated artifacts This is so real. Jira tickets used to include a paragraph about what the change or feature needed is, a screenshot from figma for what it should look like and that's it. Now I get tickets from the product manager that contain a whole novel waffling on about specific variables in the codebase that need to be changed which I have to wade through to work out what the prompt was that explains the actual product change desired.
• throwatdem12311 1mo ago
  Imagine hiring a carpenter and then telling him if he’s using a tablesaw instead of a hammer he’s doing it wrong. He would call you a moron. He might even just fire you as a customer if you annoyed him enough.
• peab 1mo ago
  Would you say the same thing about people not knowing assembly after compilers came out?