19 ms·

> bad engineers were always a liability This part of the article hits home for me. With AI, "bad" engineers can now amplify their "bad" engineering x10 across

• CuriouslyC 2mo ago
  Ironically, AI mitigates bad developers quite a bit. The architecture/design is coming from above bad devs (in a functional org), and AI tends to write less sloppy code than bad devs, and test/validate it more rigorously.
  • mohamedkoubaa 2mo ago
    Jury is still out here
  • whateveracct 2mo ago
    AI is very good at making the bad dev's PR look plausible and be green in CI. And thus, merged.
  • re-thc 2mo ago
    > AI tends to write less sloppy code than bad devs, and test/validate it more rigorously I've often had it test and benchmark against the wrong things = no test. It also writes over-engineered code. So yes sort, maybe.
  • stackskipton 2mo ago
    Strong disagree. A lot of AI development still requires good engineers to keep tight leash on it so I'm seeing more bad developers create a feature until we need to iterate on said feature and we find AI did such a bad job that it becomes extremely difficult to do so.
  • mjr00 2mo ago
    I don't agree here. Yes Claude is great at following patterns, and for very standard tasks (e.g. "add this HTTP handler" which can copy existing patterns for database transaction management, session management, authentication, etc etc) it does great! The problem is that when you do something that doesn't quite fit int an existing pattern, Claude will optimize for solving the task at hand, producing code that doesn't use a sensible architecture. Doing things like checking user credentials or establishing a database connection deep in domain logic. If you're a good dev, you can totally prompt Claude to not do this and correct itself, that's not an issue. The issue is that bad devs won't even notice this is happening in the first place.
  • jayd16 2mo ago
    Less sloppy in that it's clean and consistent looking but much more sloppy in the AI good looking non-sense way.
    • marssaxman 2mo ago
      Just like compiler-generated machine code, then.
      • jayd16 2mo ago
        no, not like that at all.
  • kube-system 2mo ago
    A bad developer with any current frontier model will happily produce syntactically correct code that is unreadable, in a spaghetti architecture, and write an elaborate test suite that tests all of the wrong things.
  • johnsmith1840 2mo ago
    If those bad engineers are in a very well defined box. Give bad engineers greenfield and watch it implode
  • to11mtm 2mo ago
    It can but you need to be careful. At my org we use Github Copilot as our AI tool for devs, both internally and for vendors (Including a WITCH =/). Where it gets ugly, is that we have a -lot- of WITCH provided code already in our systems, and as a result GHCP winds up often preferring the existing (terrible) patterns. I've done some things to help mitigate at least; Adding instruction/skill/agent files, tossing in some LLM-built .NET analyzers to catch the worst anti-patterns to warn on build and error on CI, and making sure to call out when the vendor people are obviously not even reviewing what the LLM generated for them [0] [0] - Simplest case being, EF Core mappings where the datatypes do not even exist in the target DB...
• OutOfHere 2mo ago
  What is A&D? Shouldn't it have been defined in your comment?
  • Syntaf 2mo ago
    Fair point! I edited my comment, A&D -> Architecture & Design
    • OutOfHere 2mo ago
      What about the video's title?
• ThePhysicist 2mo ago
  Maybe those engineers that don't care about making their solution _good_ are actually the good engineers, have you ever thought about that??? There are exceptions where quality really matters but most software shops build CRUD web apps where it's not really a good characteristic to obsess over the cleanest and most elegant details, instead you need to get the stuff the customer wants done! I for one tend to care less about the minutiae of solutions implemented by AI as long as it gets the job done, I do care about architecture and design decisions and correctness and I have ways to steer and verify these when working with LLMs but I couldn't care less about it writing "good" code. Bad engineers also produce better results with AI at least when they're working in established frameworks, AI doesn't really need a lot of high level architecture input when designing or building a web app with a common stack, so as long as you're not working on something that's completely novel I don't think it will make a strong difference. Maybe designers think the same way about the AI generated web designs I have Claude Code do for me but to be honest I don't care, I just know that before this tool existed it would have taken me weeks or months to come up with a good design and I would have to rely on prefabricated UI libraries and stuff like that or pay a designer tens of thousands of USD to make one for me, now I can get a (for me and my customers) perfectly acceptable and professional design within a few hours. So maybe I'm also a bad designer that amplifies my bad design taste 10x in my company, but the fact is the stuff ships and makes money and the customer is happy! And I can tell you customers or users don't give a shit about how good your code is, they only care if the software works and does what they want!
  • jonnycoder 2mo ago
    This is a great point. I find myself in the middle, where I appreciate and look up to past coworkers who were way better than me at attention-to-detail, but I have a tendency to focus on delivering actual results quickly with maintainable and easy to read code. A lot of engineering teams go into their own world on adhering to best practices with no eye on inefficiencies in the process that causes days of delay because it makes them feel better. I definitely believe in shift-left (findings bugs early saves a lot more time than finding them in production). I believe in balancing fast delivery with quality/process.
  • Syntaf 2mo ago
• hn_throwaway_99 2mo ago
  This is me to a tee. I think I'm a fairly good software engineer, and I loved building software and mentoring more junior engineers who I thought had both ability and a good attitude. I also think I was a pretty pragmatic engineer (I was not an "architecture astronaut"), but I did enjoy the craft of getting into the nitty gritty details of software. The past 5-10 years or so saw me pretty beaten down though with software engineering, and AI was the final nail in the coffin that caused me to leave the profession in later middle age. I thought software as a business had "lost its way" from building great products with attention to detail to "how do we addict as many people as possible as quickly as possible". Think about the degradation in Apple software from say the "it just works" era to now. With respect to AI, I'm not really against it, and I find it extremely valuable in my personal projects. I just feel in a large group/enterprise context that it's replaced a lot of tasks I actually enjoy doing with becoming an editor for what feels like a slightly inebriated junior developer. Or maybe it's better to say a junior developer on a mild amount of meth, because as you say this developer can churn out semi-but-not-fully-working code at an astonishing rate, and then I feel like it's often my job to mop the slop off the floor. Pass, not interested. I feel lucky to have had my career during what I consider the golden age of software engineering, but I'd note I don't think that golden age lasted even a full career of one person.
  • SoftTalker 2mo ago
    In retrospect, the golden age was the pre-internet era. Some rose-colored glasses maybe, but as I remember it: Paying for software was the norm, so it was more clear what the "product" was, and software writers had a direct incentive to write better software. Updates could not be pushed out so you had to be pretty sure your code worked before you shipped it. Having to ship physical media to all your customers for a bug fix was very expensive. Any new release was a big deal, so you had to put some real thought into what features it should contain. Significant amounts of your development time were not spent trying to work around browser bugs, or differences in browsers, or supporting random old browsers that your customers still use for <reasons>. Stack churn was much slower. The feeling of constantly trying to keep up with a treadmill was much less. Users, while often not technology experts, were a much more competent slice of people than the general public who showed up when they got internet service and a computer at home. The only ads were in print in trade magazines or publications like Computer Shopper. Yes, people actually used to buy a magazine that was nothing but ads.
• cautiouscat 2mo ago
  I think this point gets lost on people. A frequent argument I see in favor of vibecoding is: “well there’s also bad engineers”. In other words, bad code is already being written, so who cares if the LLM is wrong sometimes? The issue is that with no reins, the LLM is a fire hose of bad code compared to the garden hose of bad code orgs had before. A good engineer, with a good model and harness will produce great stuff. A bad engineer with a good model and harness will produce something faster, but it will be worse.
  • skydhash 2mo ago
    > A good engineer, with a good model and harness will produce great stuff. A bad engineer with a good model and harness will produce something faster, but it will be worse. A good engineer, without LLM assistance, will still produce great stuff.
    • zinodaur 2mo ago
      Yes, but much more slowly. And if they realize halfway through implementation that there is a better way to do it, but they are under pressure to deliver, they wont have time to rewrite it and will live with the consequences of that decision forever
      • skydhash 2mo ago
        > And if they realize halfway through implementation that there is a better way to do it, but they are under pressure to deliver, they wont have time to rewrite it and will live with the consequences of that decision forever I've never really seen that. What I've seen is the much pragmatic take of marking the source code with a few comments to highlight the problematic areas and then goes on with the implementation. Refactoring can always be done later when the first batch of value has been extracted. There's always tradeoffs to balance and perfection is something you inch towards, not something you get done in one go.
      • sillyfluke 2mo ago
        "Slow is smooth, smooth is fast." ...as Mickey Mouse was fond of telling me as I waiting for the ride at Disney World. Or it was my drill instructor. can't remember which.
• RSHEPP 2mo ago
  This 100%. I just requested a hackathon for performance improvement (might be wasted effort). We are pushing tons of code and now our CPU usage has grown exponentially over the past year because the bad engineers just ship whatever Claude gives them and do not think about the consequences. Our biggest consumer of CPU right now is HTTP connection churn because engineers are creating new clients every request we handle. If the engineers would just think for a second, push back on Claude, even Claude would tell them this is bad. But they don't... Platform engineering is now 10x harder with terrible engineers and unlimited code machines. Don't even get me started on ffmpeg usage, engineers act like the resources are unlimited.
  • ryandrake 2mo ago
    Exactly. For most of my career, bad engineers (or juniors who were earnestly learning) would struggle to even create output that compiled, let alone ran. And it would take them a long time to implement something poorly. So the blast radius from their incompetence would be limited. Today, a bad engineer can churn out ten thousand lines of garbage that actually compiles and runs, before my first cup of coffee. If not on a tight leash, they'll sink the whole codebase or inundate every senior person with garbage code review requests. The blast radius is unlimited!
    • palmotea 2mo ago
      > Today, a bad engineer can churn out ten thousand lines of garbage that actually compiles and runs, before my first cup of coffee. If not on a tight leash, they'll sink the whole codebase or inundate every senior person with garbage code review requests. The blast radius is unlimited! The term for that is "10x AI engineer." Anyone who has anything negative to say about such people is just jealous of their insane productivity and speed.
      • florianherrengt 2mo ago
        [dead]
        • 2mo ago
• _fat_santa 2mo ago
  My team is currently developing our 3rd product this year where 99% of the code is written by an agent. One thing I've definitely noticed is our problem solving hasn't stopped, it just moved up the stack to the "agent layer". A big part of this is ensuring that a "bad" engineers can still write solid code and also investing in systems that make it easier for us to review code. When it comes to writing code, we have this entire library of coding standards that we've moved from one project to another. It describes, sometimes in excruciating detail, exactly how we want our code structured, antipatterns, best practices, etc. On the review side we have invested equally into skills that split up code into readable chunks, take screenshots of any UI changes for quick validation, and a whole battery of tests to ensure that we're not generating slop. If you were to look at just our development process, you would conclude that we're very lazy engineers. We seldom write code by hand, we seldom ask for corrections and our reviews are more of a cursory look at the PR rather than a deep review. But the real work is not in the "development layer", it's now in the "agent layer". Making sure the agent knows how to write solid code so we don't need to write code by hand, making sure it doesn't make dumb mistakes so we don't have to correct it, and structuring our review process in such a way where an engineer only has to take a cursory look at the code. The key difference we noticed between the "old way" and the "new way" is the "new way" is way more scalable and we're able to move way faster than we ever could before.
  • florianherrengt 2mo ago
    What you’ve described solves a different problem. You’ve put a lot of effort into making sure generated code conforms to your standards. That’s all good. But do the people still understand what the system is doing and why? You can have code that perfectly follows every standard and passes every test while gradually building a system nobody has a mental model of. > an engineer only has to take a cursory look at the code If that means you’ve automated away checking syntax and implementation, great. But we already had that before. If it means nobody needs to understand the change anymore, then this is exactly the risk I'm talking about in the article.
• jnpnj 2mo ago
  I've seen a subtler variant of that. Since 2025 winter model improvements, low quality developers can now commit somehow decent stuff more regularly, but as before, they still don't own the solution space independently. LLM output is now larger than what they can envision and cracks will simply happen further away, only to be discovered by someone else later. It's strange everything changes so nothing changes phenomenon.
  • SchemaLoad 2mo ago
    Most vibeslop these days is superficially good in that it has unit tests, compiles, passes the style guide, but it's bad on a macro level in that it makes the system more complicated, ignores the wider design of the app, implements what the prompter asked for and not what the app actually needed, etc. I'm seeing a bad pattern of vibeslop being used to solve the immediate complaint of the user without stepping back and reconsidering things from a product perspective. Just add another conditional statement to make this very specific scenario the user complained about work the way they want.
• fennecfoxy 2mo ago
  I have found this to some degree (even though I work with amazing people day to day). It's much easier for people to pump out absolute garbage, you know the kind of "just get it done fast" slop that management types cry out for. And then they wonder why everything end ups broken, not being maintained etc. And I think the contrast between good and bad code output is much more impactful. Someone can pump out 10x the bad code they used to before, never test it never read through it just push push push baby. And then for good code, sure it's increased my output for slop tasks like repetitive unit tests, but a lot of TLC and review is required for good code and I'd say I've had maybe a 2-3x speed up on a lot of things. But not 10x; you only get that when you don't give a fuck.
  • cindyllm 2mo ago
    [dead]
• renegade-otter 2mo ago
  I think for senior devs, some of us are legitimately jaded, especially if have been facing the same or boring problems. I am just tired of typing and looking up syntax for every line of code. This, however, is a slippery slope, and one has to be mindful of falling into cognitive surrender.
• ok123456 2mo ago
  To everyone complaining about "slop" and "+20000 PRs," what kind of systematic quality assurance, test plans, and tech debt reductions were you doing before the "LLMpocalypse?" Were you only relying on the difficulty of producing "working" from replacement skill/rate "software engineers" and their level of disinterest being the only real circuit breaker?
  • jcranmer 2mo ago
    We had a dedicated QA team and an extensive test base... which we fired to reduce headcount, and we've trimmed back because we don't have the hardware resources to run those tests sufficiently expeditiously.
  • fsnovask 2mo ago
    Secondarily, the business itself is also driving the throughput increases by demanding more volume, but there is no accountability to them for asking for throughput at the expense of quality. They may also deny the engineering time to work on things that would stabilize quality that supports faster delivery because features earn money more directly than developing quality processes. This isn't coming solely from engineers wanting to produce more stuff faster.
  • apsurd 2mo ago
    Trust actually does work that way though, the implicit and collective fuzzy agreement of “having my name on it”. Of course that ambiguity needs enforced automated checks, but reputation and one’s own integrity is not for nothing. Generative AI breaks that agreement. It took me over a year to realize my previous CTO actually didn’t care too much about the system design he shipped . And the expectation was actually to just throw it away, have AI reimplement “what wasn’t working”. Use AI to ship, AI to learn what shipped, and AI to fix what shipped. I quit because of it. Hell is working on other people’s AI code.
    • ok123456 2mo ago
      At different times in recent history, you could have also said: > Hell is working on other people's NoSQL code. > Hell is working on other people's Python slop code. > Hell is working on other people's enterprise Java code. > Hell is working on other people's Windows Forms/GUI Builder code. To quote Jean-Paul Sartre: Hell is other people.
• __turbobrew__ 2mo ago
  The analogy I have heard is that LLMs are a force multiplier, so if you were a 2x engineer before you are now a 10x engineer, and if you were a -2x engineer you are now a -10x engineer.
  • deleted 2mo ago
    [deleted]
• la6479 2mo ago
  But sooner or later for AI to reach its true potential we need to have HOTL ie Human Out of the Loop. Meta prompting or using AI to develop the prompt by coaxing it to ask relevant questions , creating specs and going through multiple loops with LLMs - things like this can be a good start towards the final goal. Final means the over abundance of goods and services like the men of the millenium are suggesting us mere mortals will reach one day,. .. and work will be optional.
  • bobthepanda 2mo ago
    Alternatively, cutting out labor just results in mass poverty except for the moneyed few, and a new era of technofeudalism. It seems pretty clear that the current crop of executives strongly prefer the latter scenario.
  • goatlover 2mo ago
    Pretty big assumptions that we will get a UBI that everyone can live comfortably on, that there will be optional jobs for anyone who wants to work, and even given the first two, that there won't be massive wealth and power accumulation at the top, even more than today.
  • bothers 2mo ago
    > Final means the over abundance of goods and services like the men of the millenium are suggesting us mere mortals will reach one day,. .. and work will be optional. Yeah, that sure sounds like paperclip maximizing hypercapitalists. Real big on sharing, not so big on minding the cost, but they just can't show their love for us all while employee labor still has some value to them. Once that's out of the way and they've taken or mulched everything of value from others, that's... that's when they'll start giving it all back, yeah. I know the sarcasm isn't helpful. But goddamn I can't understand this take, I don't know why people believe people-shaped entities like [your favorite wealthy sociopath's name here] will become society's mommy if given the power, and it's incredibly fscking frustrating. Like people who think once their home and everything is burned to the ground, the fire will rebuild everything, but better.
• perrygeo 2mo ago
  Rather than good or bad engineers, I'd focus on the quality of the idea. Every software engineer has good and bad ideas. Historically, bad ideas were kept in check by the effort it would take to code the implementation. With that barrier nearly gone, there's no friction - a bad idea in the morning gets deployed to prod in the afternoon. No thinking required! So yes, garbage in -> garbage out, but framed in a way that makes it clear what is garbage. The ideas, not the engineer themselves :-) This suggests we need to be doing more designing and planning; introducing that friction intentionally to make sure bad ideas get culled, viable ideas get refined. Critical thinking becomes the bottleneck; the quality of the idea becomes the deciding factor in success.
• torginus 2mo ago
  I think the parallels with AI art are uncanny - nowadays people with zero artistic skill, vision or effort invested are capable of creating stuff that would've previously taken a master artist a solid week of work - doesn't mean any of that is good, but it does mean that the logic of 'if it works and looks good, it's good' is completely broken now.
• swatcoder 2mo ago
  > > bad engineers were always a liability > With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization. Yup, and that's going to be the comeuppance for a decade of aggresive overhiring. There are so many "bad engineers" filling the ranks now that in many teams and divisions there's not even anyone left around who can recognize them as such. This was already manifesting as a rapid decline in software quality and worsening practices, and the amplification effect of AI is mostly going to make everything worse for a while as we wait for all these declining projects to buckle under their weight. If you are a good engineer, it's a good time to work on small teams with other good engineers and rigorous practices. You can be using AI to amplify what you do (and probably should), but you need to be rigorously considering your processes and guarding yourself from seduction by blind-leading-blind hype you see on social media or in iconference talks.
  • ponector 2mo ago
    It's all about the process and the organization. No one is pushing for quality, everyone needs more features. >>a rapid decline in software quality It's hard to expect anything else if budget for QA teams is reallocated to cover llm bills.
• j45 2mo ago
  I'm not sure if it's replacing the middle class of software engineering, but I do feel it's generally true that the static approaches to middle class software engineering are evolving quicker than people are keeping up. Hopefully when there's bad devs, there's a bit less making a mess where someone doesn't know better and as a result some amount of average or general best practices start happening. This can be true not just for software development, but making a mess in anything, including a spreadsheet.
  • lookACamel 2mo ago
    Despite the title this article doesn't seem to be saying anything about the "middle class".
• matchagaucho 2mo ago
  "Okay. I'll create a loop and goal so it doesn't stop until it's checked that everything works." This is where the quality magnification seems to be occurring. Goal-driven loops can make good code great, or bad code worse.
• globalnode 2mo ago
  seems a lot of comments below with disdain for "bad" coworkers. every industry has them, but if theyre objectively bad why not get rid of them? surely some periodic review would do that. how did they get hired in the first place? perhaps hiring managers are the "bad" employees.. or managers that let them go on not performing are "bad". or maybe your expectations arent aligned with reality? who knows? the worlds a complicated place.
• butlike 2mo ago
  Tell me how to paradigm shift careers and I'll get out of your hair and stop shipping uninspired features. But, right now I'm paralyzed with fear in how to make a successful career switch without starting from literally "new grad level." I have wisdom, so it doesn't feel like I should have to start at the bottom rung again. Egotistically, I don't even mind, it's just the salary hit that would be the main issue. Maybe it's not even a paradigm shift (though, I've always wanted to work on film productions). I've sort of lost the passion for being an IC, but how can I make a transition to management without any management experience? Should I just apply for a managerial role and in the cover letter state management is my intended path for growth?
  • burningChrome 2mo ago
    >> Egotistically, I don't even mind, it's just the salary hit that would be the main issue. This is whare I am right now. Even senior positions have dropped 50-60K in range so I've effectively priced myself out of a lateral move because I would be taking a massive hit in salary for the same role I'm doing now. I'm currently at a company that continues to lay people off in lieu of offshore talent and AI. I'm stuck in a weird state of purgatory. >> Should I just apply for a managerial role and in the cover letter state management is my intended path for growth? I know many of my friends in senior dev roles have put their resume in Claude and said they were interested in moving into a management role and had Claude revamp their resume into something that was more management focused. Three of them were hired quite quickly not only based on their dev backgrounds with mentoring, training and light management of junior devs, but having enough emerging AI skills they said helped them close the deal.
    • butlike 2mo ago
      Interesting. Thanks for that last anecdote. I feel you on the weird state of purgatory. I'm confident we'll find a path forward, though. Gotta keep your head up
    • SauciestGNU 2mo ago
      I've decided to take that salary hit. I want to stay an IC and work somewhere that doesn't effectively require a 996 schedule to keep up with openclaw slop for PR count stack ranking purposes. It really depends on your financial situations, but I've seen the human cost of very high compensation jobs on myself and some things are worth more than money.
• vogelke 2mo ago
  This is right on the money. It's not that we have way more bad engineers than before; it's that the damage they do is out of all proportion to their numbers.
• dominotw 2mo ago
  > The most egregious of these cases for me is often long tenured engineers who have lost interest in the craft, creating a dangerous combination of having enough merit to ship but not enough interest to make what they ship _good_. i think i fall into this bucket. our "leaders" and executives have told us they dont care about 'shipping good' . we are simply responding to incentives.
  • florianherrengt 2mo ago
    They’ll care when nothing works, nobody seems able to fix it, building new features takes forever and every change breaks something somewhere else. This was already happening before. But now, a lot more companies that previously might have taken many years to reach an unmaintainable state can now get there in just a few months.
    • a34729t 2mo ago
      My coworkers and I give it 12-24 months before we have a total collapse due to unmaintainable slop and good people leaving. Generally there's a feeling that this will sink a lot of bigger companies.
• mannanj 2mo ago
  Part of the problem is self confidence bias. Everyone things they're the good engineer, while dunning Krueger would say maybe you are the bad engineer. Prove who's good and bad. And you can't really, because there's always tradeoffs you're making as an engineer. The really self confident ones think their tradeoffs win, and maybe they do, though often they don't and these people are just self aggrandizing and stroking their large egos. Are you a better engineer just because you made a big talk and had the confidence to share it with lots of people?
• dzonga 2mo ago
  pretty good presentation. my take is everyone in the industry should read grog-brained developer, & no silver bullet before working as a professional. the other is a mindset change - the best working code is code that's never written as it doesn't have bugs or suffer technical debt. Agentic coding doesn't solve that. Human taste does, which means our job is to reduce the amount of lines we write. agents etc are useful for the filler or bullshit part of our jobs e.g generating tests. but ultimately I think the whole spec-driven development & agents spitting 100000s of lines era will be looked upon as mass psychosis. last thing to give an analogy - you don't carve a David statue by gluing together pieces of marble - but you carve it by cutting pieces of a huge block of marble.
• consp 2mo ago
  > but not enough interest to make what they ship _good_ I'm having the impression business decisions always win, time is always reduced and requirements always changed half-way during a project, having a much greater impact than any bored old engineer.
• indoordin0saur 2mo ago
  Great talk
• swat535 2mo ago
  > The most egregious of these cases for me is often long tenured engineers who have lost interest in the craft, creating a dangerous combination of having enough merit to ship but not enough interest to make what they ship _good_. I wouldn't be so quick to judge the long tenured engineers. They probably realized that moving business forward is more important than writing artisan code. You always have some young hotshot who comes in and wants to rewrite your old boring Java monolith into a micro services disaster for "better architecture". The greybeards learned the life lessons the hard way. The other aspect to consider is this: stay in this industry long enough and it will beat the soul out of you.
  • cactusplant7374 2mo ago
    I agree. Why is everyone so hard on everyone else? Look at the outages Anthropic and OpenAI have had. They aren't hiring stupid people but they can't seem to go a week without major platform instability. And you can't even argue that it's because of high load because all of these engineers have worked at Facebook, Meta, etc. They are seasoned veterans that should be able to build resilient systems.
    • NateEag 2mo ago
      > They aren't hiring stupid people but they can't seem to go a week without major platform instability. All those smart people are probably using genAI to generate their codebases. So far, that does not seem to have resulted in a robust, stable system. Certainly no better than the results the hyperscalers got doing things by hand, and arguably worse.
    • cpgxiii 2mo ago
      Either they believe their own hype and their reliability is a reflection of the real weaknesses of AI coding, or they're complete liars and doing far more traditional SWE than they claim. I think the former case is far more likely and that while they may have hired plenty of senior people from big companies, there's definitely a self-selection for "true believers" in AI coding baked into that hiring process.
• overgard 2mo ago
  I kind of think the whole "Learn to Code" push of the 2010s was one of the worst things that happened to our industry. Call me a gatekeeper if you want but, we ended up with a lot of people that just can't do the job. The problem is our industry mostly doesn't have any sort of reasonable mentorship or apprenticeship culture, so we've always left it to the engineers to teach themselves. Sink or swim. The problem is that worked when the industry was mostly composed of people that were implicitly interested in this stuff, but the people that just got in it for a paycheck don't have that motivation, and we don't have a good culture of getting them up to speed. So now we have seniors that can barely write a function, much less reason about a complex system. I remember people used to debate all the time about if there were "10x" engineers or whatever. A few I'm sure, but I think the real problem is we have a lot of 0.1x engineers or worse.
  • phil21 2mo ago
    Or it’s just the largely self-taught intrinsically curious autodidact developers and engineers have always been 10x and the “average” person in it for the paycheck is really what a 1xer has always actually been. I think the industry highly skewed towards the former back in the 90s (and earlier!) when I first entered it. There certainly were vast differences between the best and the worst, but nothing like the gigantic gulf there is today between say a competent kernel driver developer who can get code mainstreamed into Linux vs. a boot camp style disinterested frontend dev who leet coded and brute forced themselves into a FAANG job. Working closely with other white collar “generic” jobs and the folks who just show up each day and are not interested in the fundamentals at all make me believe this is kind of the baseline for most industries. Most folks are in it for the money and are happy to just be good enough to not be fired. Since most middle management is utterly incompetent at performance management the results tend to not be great for pretty much the entire corporate white collar industries. A stellar manager though really stands out in such situations, but they are so rare many won’t work for or with one their entire career.
    • wwweston 2mo ago
      I also have a suspicion that people’s microdistributions of talents is underappreciated. Some people are good architects and average at algorithms. Some people are unusually good at debugging or QA. Some can spin out whole systems at an impressive speed that may not be a great long term fit for the larger system. And most businesses aren’t managed in a way that’s interested in adapting to the microshapes of personnel.
• UncleOxidant 2mo ago
  > With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization. It's even worse than that. We've got a CEO who has suddenly learned how to vibe code and the stuff he's coming up with is... kind of horrendous. He's coming up with new "products" and proclaiming them the next big thing for us to work on and we're kind of over here scratching our heads asking who would want this? Who would pay for it? I mean, he was able to put together a kind of a cool web app (with 0 web app knowledge) that's supposedly going to let users design thingys with AI, but it just seems like he re-invented a harness/IDE. I suggested that maybe what he wants is a VS Code plugin like Cline or KiloCode... but he hadn't used VS Code.
  • lawn 2mo ago
    It would be funny but sadly our CEO is also vibe coding all days (with AI I have so much free time!), forcing everyone in the company to use his vibe coded product. Oh and he's altering course from the previous "AI only where it makes sense" to "everyone should code, even the sellers" and "AI is not optional, we're an AI first company". Talk about drinking the Kool-Aid...
• FrustratedMonky 2mo ago
  This is great. We now need to talk about the 10xBad engineer.
• WorldMaker 2mo ago
  > With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization. I think the real pain though is that AI also often removes the feedback loop between "good" engineers and "bad" engineers. A lot of "good" engineers started as "bad" engineers that learned, sometimes the hard way and sometimes with patient mentorship, how to be better engineers. Patient mentorship becomes harder as code reviews become less personal. "The Hard Way" becomes harder when the consequences get divorced from actions. For a bad engineer it becomes "Claude broke Production" more often than "I broke Production" and learning mostly ceases. We're starting to recognize how many junior developers AI is replacing, making the pipeline to senior developers harder (if not disappearing), but we also maybe aren't focusing enough on how much we are also losing the pipeline from "bad" to "good" engineers.
• robomartin 2mo ago
  > I am still a firm believer in garbage in -> garbage out, AI is only as good as the abstractions and contracts you put in place for it. Absolutely on point. I just completed the port of a industrial application written in Python using a sophisticated console-based UI to C# and Avalonia UI. This is my second major coding project using Codex. The one salient element of the experience has been that, as I keep saying to anyone who will listen, AI still does not understand anything it is doing. It presents an amazing simulation of it, but, no, it does not. Here's a simple example: The original application had a clean communications protocol implementation. A single file with a class that implemented every single command you could have the industrial controller issue to the hardware. Codex was explicitly told to replicate that in C#. It did, at first, but then it started to duplicate command processor code in the individual functional blocks throughout the application. Which means that, when a bug surfaced, you had to fix it in five different places. Another example: The application has a highly customized table view. Once again, it was told to make that a component to reuse throughout the application. It did, at first, and then weird bugs started to surface that made it clear that it had reimplemented the table control in different areas of the application. If you don't know what you are doing you will probably not pick-up or even care about some of these things. It is easier to whack-a-mole bugs with AI than to worry about code structure, efficiency, maintainability, future-proofing, scalability, etc. I purposely decided not to look or touch a single line of code during this project to see what's possible and where the issues might be. I learned a lot and continue to learn. I think the next step is some sort of an agentic approach, maybe using OpenClaw (or whatever, I don't really know right now) to create a team with coding, supervisory and testing agents. While the project got done significantly faster than it would have without AI (four weeks instead of probably 4 to 6 months), the process was just as intense as coding, just operating at a different level, micromanaging architecture and implementation.
• roncesvalles 2mo ago
  Bad engineers simply don't care about good engineering. They aren't even trying. LLMs have made these engineers super "productive".
• dfee 2mo ago
  > With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization. and > I don't subscribe to the idea that AI generated code is fundamentally bad, just that people lack the right skills today to wrangle agents into writing good code. those people who lack the right skills today – are they the bad engineers you'd mentioned previously?
• BrenBarn 2mo ago
  > With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization. This is why I don't have any patience for the people who say "but AI is so powerful! we can do so much!" It amplifies the bad stuff more than the good stuff, so it's a net negative.
• viccis 2mo ago
  >With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization. I would expand this even further and say that the worst problem for people in the trenches isn't even just that this is happening, it's the it creates a situation where managers are held to some expectations (their team shipping product features) that incentivize not looking too carefully at what their team members are putting out. It makes it really hard to tell a boss "we need to stop and spend a few days reviewing and rewriting because one of my teammates likes to one-shot everything with poorly thought out Claude prompts making multithousand line PRs" when their own bosses are breathing down their neck. It's the same struggle we face to get refactor work prioritized, just at a much more frequent cadence. "It's working so why do we need to spend another sprint on it?"
• Animats 2mo ago
  Why is there no transcript for that video?
• ChrisMarshallNY 2mo ago
  > not enough interest to make what they ship _good_. I know this happens, but don’t really understand it. In my experience, quality hits usually resulted from external pressure (bad managers, trade show-driven schedules, etc.). I always wanted to do better. Now that I’m retired, I take the time to really get Quality right. LLMs have helped (but they need close watching).
• pbronez 2mo ago
  Good talk, thanks for sharing! I’m trying something similar for personal project I’m hacking on. Specifically, I’m spending a lot of time on the first few instances of a pattern that I hope to have the AI scale out for me. My thought is that I can provide an opinionated project structure, feel it out myself, then point the AI to those working examples in the future. Until then, I’m mostly just using ai as fancy autocomplete + domain research.
• joshdavham 2mo ago
  > people lack the right skills today to wrangle agents into writing good code. It's actually this that leaves me feeling optimistic. We're definitely bad at this today, but will we always be bad at this into the foreseeable future? I'd like to think not. I'd like to think that we'll get better at working with agents in the future and eventually develop better practices around this new weird technology once it's better understood.
• bwhiting2356 2mo ago
  [dead]
• andersmurphy 2mo ago
  This is why my theory is LLMs are self defeating in large orgs. Or worse terminal for the organisation. For everyone adding value with LLMs there will be way more destroying value. If you roll a critical failure a mediocre LLM enhanced VP convinces the org to sail aggressively in the wrong direction.
• davidguetta 2mo ago
  Not all industries require good software engineering tho. one good swe out of ten with high authority may be enough in most organisation
• ehnto 2mo ago
  > The most egregious of these cases for me is often long tenured engineers who have lost interest in the craft... Which is an incentive problem, they have likely reached an equilibrium with their company. Genuinely few companies provide any incentive and critically, the space, to ship good code. Because frankly it doesn't matter in the middle grounds. Which is where 90% of developers are. I wish we all had fulfilling edge of our seat projects to work on, that challenged us just right, mattered to our community etc. AI is absolutely poised to disrupt the middle 80% of development because the middle 80% of dev is not that important or hard. It's just a shame for all of us who loved the craft, and didn't mind being in the middle making a living. That's a totally noble place to be, and it could get taken away from many of us.
• gofreddygo 2mo ago
  Bad engineers. Like bad wine, bad pizza and bad exes are impossible to guess till you taste it. Changes you forever. Changed me. You know its bad and good lord! dont bother explain it someone else who will not taste it themselves. There's different kinds of bad too, some justified. The senior that made their way boot licking and being at the right place and time. The junior that just got there. The senior that does not care anymore for being left out of promo two years ago and having to report to the person they despised as being a bad engineer. AI isn't making human behavior better. In any way. Life is too short for all this, keep doing the good stuff, filter in the good, keep the bad out that you can, ignore the rest. Have the self reflection to know when things aren't working out, and when its worth getting out. Build the wisdom to not repeat the same mistakes. Believe that there's a lot of good work to be done in the world and contribute in any way possible.