12 ms·

Cleaning up after AI rockstar developers

• milkers 4mo ago
  This is why I like a bit of 'wet-kiss'es while working on projects.
• skydhash 4mo ago
  I’ve cleaned up after outsourced code and it has a different flavor to AI rockstar code. In the former, you can see that the developer only care about the current ticket. After every merge, it’s a flurry of bug fixes, because they always break something unrelated. And that’s due to bad design, you will see a lot of copy pasted code and unused code. As for the AI code, the most defining elements are unneeded complexity and low understanding of the abstraction involved. When you need a 10 lines functions, the AI will happily write an entire module because that’s how a fully implemented domain is like. But it’s not part of the requirements. As for the low understanding, you will see strange code, which are not fully antipattern, but are definitely not needed as it solves issue that the platform/library/framework doesn’t have or already have a solution for.
• deleted 4mo ago
  [deleted]
• elzbardico 4mo ago
  Please write a manual on how to cleanup after AI rockstar managers who think they can code. Much needed right now as I slept only two hours since yesterday after solving a SEV-0 and having to wake up after a 2 hour nap, so I could be now cleaning up the fallout before business hours. I am not a AI-denier, I am actually thankful I have AI right now to multiply my force, but frankly, people STILL need to review that fucking code, and the people who review the fucking code STILL need to be good enough to be able to write it themselves if they needed. Whoever says otherwise is either an AI investor, a linkedin influencer or a complete imbecile. --- EDIT Please add a section on how to communicate and write a post mortem where the guilty is completely exhonerated without the blame falling on me as I try to save said manager's face.
  • eithed 4mo ago
    > Please write a manual on how to cleanup after AI rockstar managers who think they can code. Why are you allowing AI rockstar managers to (I assume) push without code review? Why are you cleaning up the fallout? It's not AI issue, it's people issue
    • Sharlin 4mo ago
      Because most people, in most parts of the world, are not allowed to question whatever their superiors do? And, yes, unfortunately are also expected to clean up after said superiors' messes. Of course it's a people issue. AIs just make people issues worse in new and entertaining ways.
    • wccrawford 4mo ago
      100%. You don't "clean up after them." You make them clean up their own mess. You refuse to let a mess into the system in the first place. Same as it ever was. The only difference now is that if you let it happen, it'll happen 100x as fast. When I was mentoring junior devs, I would start by fully reviewing their code. If they had a ton of mistakes more than a few times, I would only review until the first mistake, and then reject it. Repeat, repeat, repeat, until they got the picture that I wasn't going to let mistakes through, and handing me a ton of mistakes was going to waste more of their time than mine. I let the pain be their pain, instead of mine. But good developers, I'd help them by doing a more thorough review and not wasting their time. Good developers were the ones that made an honest effort to follow the requirements to the letter and test their own work. We further emphasized this by having a very simple coding test during the interview, and the only thing we cared about was whether they followed the requirements to the letter. There wasn't a lot left to the imagination, and the requirements were very clear. Anyone who missed them wasn't someone who would do well with us. That very same test will help filter out a lot of AI-braindead candidates that don't check the AI's work as well. Actually, I wish I still had the exact test so I could throw it against an AI and see what happens. I'm a little afraid that it would pass it too easily now. I'm not sure how I'd fix it to prevent them from just using AI.
    • piva00 4mo ago
• ramon156 4mo ago
  I kind of envy people who need to clean up after others. At least you're puzzling. My current job is genuinely just boring. It's tasks that are so simple, a junior could do it. But no, instead they needed a medior. I'm not saying I'm better than this, nor that no medior will pick it up. I just cannot push myself to care about the code this company makes. It's old, dusty and it serves no one of importance. These customers use it because they once bought the tool and do not care enough to switch, because the tool in question is not interesting. I was promised work soon that aligned more with my experience, but I do not foresee these customers to come to a stale company like this. It's not surprising that this company is losing customers, employees, etc. But I have a mortgage to pay. Today I had the conversation about how they might not extend my contract, basically threatening me to take more ownership, do more work, for the same pay. Sadly I have to make it last until I find a new position that is actually interesting. I don't even need a lot of money, I could give a rat's ass about "growing". I just need enough to survive. This might be a very unrelated comment, in which I apologize. I just do not have another vent to post this to.
  • newswasboring 4mo ago
    For a boring codebase how is your company not trying to throw tokens at it? Not saying its the right choice but definitely the trend I am seeing.
    • LtWorf 4mo ago
      Perhaps they don't like slot machines
  • calflegal 4mo ago
    I love this kind of comment. It's so human. Good luck, friend.
  • dkdbejwi383 4mo ago
    At first I thought "medior" was a strange typo for "senior", but on seeing it twice I had to check - apparently it's used in some parts of Europe to mean "mid-level"
• gyanchawdhary 4mo ago
  [flagged]
  • DamonHD 4mo ago
    Hmm, ~30 years ago the compilers that I was using were generating generally fine assembly/machine code. Some of the other tooling was more troublesome: cross platform high performance numerically stable code and C++ static template deduplication paid for a lot of beers around then, and I needed them.
    • gyanchawdhary 4mo ago
      [dead]
  • this_user 4mo ago
    Compilers are deterministic and they actually possess domain knowledge of what they are trying to do. AI models are non-deterministic, have no real domain knowledge due to lack of an underlying world model, and their way of "writing" software is to spew out something that looks like something that they have been trained on, then iterate on it long enough until it has reached the level of being barely runnable.
    • gyanchawdhary 4mo ago
      [flagged]
      • sumeno 4mo ago
        I don't think you know what deterministic means
        • gyanchawdhary 4mo ago
          [flagged]
        • LearnYouALisp 4mo ago
• 349187 4mo ago
  The ironic rockstar comparison is very good. The classic rockstar only cared about "new" technologies and wrote spaghetti code, the new 100x AI rockstar can do more damage. It's a pity that the article ends cautiously with recommending to perhaps adapt AI usage practices. In this climate we are not there yet to publish the unfiltered opinion that generative AI is garbage and should be disposed of. Soon we will be.
• danjc 4mo ago
  As much as it's true that a novice will generally use AI to build a sloppy mess, I've also had success unsloppifying through some careful prompting.
  • nicman23 4mo ago
    or linters
  • Cthulhu_ 4mo ago
    I wish I had current-day AI (and a big credit card) for my previous job, they had a big legacy mess made by a productive but not very good developer, but my job was to rebuild it. If I had AI tooling at the time I'd probably be more inclined to have it both refactor / optimize the existing application, add automated regression tests etc, and use it to extract all of the features and requirements for it for a potential rebuild. But honestly I think if that application was properly designed and factored (instead of nesting JS in HTML in strings in JS or concatenating XML from query results only for it to be converted to JSON taking up 50% of response time) its lifetime could've been extended, especially if it was then containerized into a HHVM or similar php optimizer. But, hindsight.
  • pu_pe 4mo ago
    Absolutely. I really don't think the future will be humans reading and picking apart an AI-generated codebase, there will be tech debt agents or whatever running overnight.
    • SlinkyOnStairs 4mo ago
      I think you misunderstand why tech debt lingers around. It's not a capacity or capability problem. Organisations just don't want to deal with the accountability involved with "touching cold code". Whether it's a human or "AI agent" doesn't change the "It worked in prod, you touched it, you broke it, never touch anything again" dynamic.
      • pu_pe 4mo ago
        That's one dimension of it, but in the context of this thread we are talking about how maintainable a codebase is for other humans. If your codebase is messy you depend on a few key employees and it might be hard to onboard new ones, so there has always been financial incentives to reduce tech debt.
• nbevans 4mo ago
  "I am a rockstar developer and this characterisation is unwarranted" -- thought bubble emoji
• anonzzzies 4mo ago
  I like fixing code made by AIs and others (outsourcing code is similar as someone else said already). Last week we found out some client tried to vibe some departmental tool; the result is some massive crap in nextjs that needs 10GB mem to compile, has 1000s of lint errors, dev logs in git (very noisy ones) and so on. Now we have to fix it: its basically free 10k-50k euros over and over again for this type of work. Very easy if you know what you are doing; impossible if you don't. Keep m coming.
  • DenisM 4mo ago
    In some ways they are giving you a spec and UI mocks to implement.
    • JoelMcCracken 4mo ago
      This is one of the things I keep thinking about. At the very least, these tools make prototyping and idea vetting remarkably cheaper. Then we go back to the old “the prototype works; I’m the boss and I’m telling you to deploy it to production”
      • rzmmm 4mo ago
        Prototyping is widely underappreciated. People think it's waste to throw away stuff but it's more costly to build upon shoddy foundations
        • darkwater 4mo ago
          But... "time to market!", "we won't have cash by the time this gets implemented properly" etc etc are the usual suspects here.
          • conductr 4mo ago
            Sounds like valid issues to me. Pristine software isn’t the objective of most businesses. Leaving as a problem for another day, if we’re lucky that day will come, for many businesses, products, and startups it doesn’t and the shoddy prototype usually isn’t to blame. I feel like SWE’s that make this gripe really need to step back and understand their role and the process for value creation. Because it’s certainly a process, the quality of code/architecture matters little if the low bar of functionality is met. Functionality can be sold to customers or used to test the market. It’s basically the whole MVP thing and the MVP should be a bit jank. If it wasn’t, you spent too much time/effort on it. All said, there’s definitely some approaches to make it less jank from day one. Unfortunately, jankiness is a subjective metric.
• scotty79 4mo ago
  > Building software that lasts Nah. Now everyone can build single purpose, single use, throw away software.
  • Supermancho 4mo ago
    Then reconstitute it later, even if slightly different. Nobody cares because it's small.
• AndrewKemendo 4mo ago
  It’s literally no different than how to clean up old projects over the last 30 years of software engineering I don’t understand why all this stuff is all of a sudden “new.” It feels like we’ve got an entire generation of people who never had to spend their time factoring or doing hard infrastructure work It’s actually pretty baffling how rare it is to find somebody who has consistent experience in refactoring that is under the age of 40
  • hilariously 4mo ago
    That's because the businesses got into the habit of new C level means new project, obviously the old code is bad. I even had a PE buy the company I worked at, put in a new CEO, and his goal was to rewrite the entire code base in a year. I asked him what problems this would solve and never got a straight answer besides "its yucky" and "people told me they dont like it." I have had multiple upper management teams decide that "dealing with this product is too hard, let's start from scratch" as if the new thing wouldn't have the same problems of the old thing, but with less effort put into it. People love to work on new, all the possibilities and none of the bugs!(yet)
    • AndrewKemendo 4mo ago
      I think that’s right I have seen over the past decades this concept of just reusable throw it away code becomes the norm and that’s why also I’m always surprised to look at people complaining about AI development and it’s like yeah it’s just the same as all other development at this point everything‘s just frameworks and throwaway code I’m not even mad at it but it’s just one of those things where people are like “I’ve never dealt with anything like this” But it’s the majority of operational software engineering since more or less forever
      • hilariously 4mo ago
        I think its also the pyramid of age - as you work in this field a lot of people burn out, the field was significantly smaller in the past and has shown huge growth, and the young say "yes sir!" and work nights and weekends on the fucking stupid idea while the older folks push back. So in general most of the people have worked on a bunch of greenfield development, thought of the project 2 years old as aged out entirely, and never thought you might "maintain" something at all.
• robofanatic 4mo ago
  > Half the code was written in a language you didn't understand. The other half was written using libraries you never heard of. > As you waded through the slop, you browsed job postings and fantasized about leaving Just because you didn't understand something or haven't heard about a library, doesn't mean its slop. How do you make sure your definition of "clean code" is not a slop to others?
  • skydhash 4mo ago
    Programming is for humans first. Cleanness and code quality is judged according to that.
  • mrweasel 4mo ago
    I'll avoid trying to guess what the author meant, but I found it rather relatable. Some of these "rockstars" pick weird languages, niche database, esoteric frameworks and whatnot, not because they're needed, but because that's the rockstar thing to do at that moment. And then they leave and you're stuck managing a Cassandra database and a Rust application when everything else around you is MariaDB and Java, and you have to maintain an application in an abandoned JavaScript framework, even though dynamic frontend wasn't a requirement.
  • kaydub 4mo ago
    This is a guy who has 20 years of 1 year of experience. His blog includes his linkedin and github, just give it a look over.
• itake 4mo ago
  This article feels is trying to justify their own inefficiencies (lack of library or language knowledge) instead of taking the time to learn from the rockstar and their technology choices. As I was leaving my last job, I advocated everyone migrate from plain old es6 to typescript, b/c several times broken builds made it to production. Certainly my coworkers may of felt upset that typescript is too verbose and pointless if everyone reaches for the "any" operator. But that doesn't mean the decision to move to Typescript was bad, it just means the company is "old school" and not willing to take the time to adopt modern workflows...
• herrherrmann 4mo ago
  I’m sure the general premise around AI-generated code is accurate. That being said, I’ve definitely had interesting moments where e.g. Claude produced code that matched the pre-existing codebase quite nicely, and slowly started building up its memory of how new pieces fit into the codebase in an idiomatic way. Then again, it started to throw in Tailwind-based CSS classes all of a sudden, because it assumed that Tailwind had been set up (it wasn’t).
• jdw64 4mo ago
  If you're just starting to learn programming, people will tell you that maintainability is important, and they'll mention John Ousterhout's concept of the "tactical tornado" as an anti-pattern. The problem is that this approach implements features quickly but in a way that conflicts with the team's mental model, ultimately ruining the entire codebase. A lot of blog posts initially framed this as a problem. I agreed to some extent. But as I've gained more programming experience, I've come to realize that all programs degrade over time until they are reborn. Eventually, it seems that destructive innovation is necessary for longevity. And sometimes, new patterns emerge from that kind of disruptive feature development. So you could say that AI rockstar developers and AI-driven development are close to being a "tactical tornado" because their codebases are bad, with poor maintainability and reliability. Maintainable development, in my experience as a traveling contract developer, usually refers to code that is well-modularized and well-crafted, making it easy for someone like me to understand the codebase when I come on board. But when I saw the leaked Claude code, frankly, the code quality was disappointing—yet by my standards, it worked very well. So I've changed my mind lately. I think we actually need a new classification of developer types: those who love creating new things but are bad at maintenance, versus those who are conservative, good at maintenance, and build beautiful code. What makes me think not too badly of recent AI-Rockstar(or AI vibe)developers is that as any industry becomes more advanced, it becomes harder for stars to emerge. Work gets divided and specialized, and no single individual can master everything. For example, I'm confident in writing 60,000–90,000 lines of code by combining frameworks based on IoC (Inversion of Control). But I'm weak at large-scale programming like distributed systems or low-level programming. That's the difference in expertise. I'm strong at the macro level but weak at the micro level. You become cognitively optimized for your own domain. vibe coding developers(or AI star developer)since AI is still far from being highly advanced—produce messy code, but they definitely bring a new kind of shock. And when you look at their internal structure, many developers mock them. This reminds me of Undertale. Undertale's code is full of if statements and an enormous number of branches—honestly, it seemed like the developer didn't even know the basics of coding. Yet that game became a historic success. The same goes for programming. Some people make the code components beautiful and efficient, while others focus on delivering what the end consumer wants. So these days, I even think that the more AI developers create bad software using AI, the more new jobs will emerge to maintain that software. Everything always has two sides, it seems. And in a way, maintainability means knowing how that feature fits into the overall shape and UX of the product. With new products, that prediction is often impossible
• maerF0x0 4mo ago
  I've met a handful of people across my life that i'd call truly brilliant. Like, holy heck how in the world is this person this smart? Two things I've noted about really smart people are (usually mutually exclusively) 1) Sometimes they do not realize how smart they are, because it's simple to them, or because they know the subject they assume everyone else, say with a computer science degree, knows and recalls and understands all they do. I've had friends who go off on crypto related maths and I'm like "I passed that class, but know that I do not really know the subject you just talked about" ... And 2) There's the people who it's painfully forefront of mind that they're smarter than most everyone around them. Some of them are jerks, some of them are exhausted by being surrounded by relatively "stupid" (again, relatively...) people. For the latter group i have some sympathy. Imagine walking through life and everything is clear, obvious, easy to process and having to watch humanity make stupid choices over and over and over again when the answers have been long known...
  • Havoc 4mo ago
    And then you’ve got a third problem - that well north of 50% believe themselves to be in that last sentence of yours
    • functionmouse 4mo ago
      It seems that way sometimes but maybe we're just biased as we tend to hang out among intelligentsia
      • Havoc 4mo ago
        Oh we can call that the 4th problem. The bias of the people perceiving the bias
      • booleandilemma 4mo ago
        [dead]
    • TonyStr 4mo ago
      Some people are very good at working with complex abstract ideas, but are terrible at signaling that intelligence to others. And some are fantastic at signaling intelligence and steering conversation toward domains of knowledge that they've studied (many political commentators come to mind), but don't seem to have processed those ideas very deeply.
• SkipperCat 4mo ago
  This isn't a problem with "rockstar" AI devs. This is a problem of management. Who would let someone come in and rebuild the core infra of their business without any planning or review?
• josefritzishere 4mo ago
  AI codes worse than even the most egotistic prima donna. I see future business opportunities in cleaning up the mess being created now.
• red75prime 4mo ago
  Is the "Cleaning up after hundreds of AI rockstars" part a description of an actual experience? I don't feel that it is. I would expect much more swearing if it were the case.
  • tyleo 4mo ago
    It could be but there’s always been so called “10x developers” who just make 10x messes. I think it’s the continuation of an existing phenomenon. https://www.tyleo.com/blog/the-terminal-star https://www.tyleo.com/blog/the-terminal-star
    • albedoa 4mo ago
      This is a confusion that you could not have predicted, but primed by your comment, I expected "terminal star" to refer to a suggested predecessor of the AI rockstar. No, it refers to the animated Claude Code star :P
  • oldandboring 4mo ago
    This was my take as well.
• Goofy_Coyote 4mo ago
  These two sentences hit home: > The flow of data was so hard to follow, it seemed like someone was trying to cover up a murder. > Just getting the code to run on your laptop took a week. I always thought I’m the only one having problem understanding the data flow, or setting up a proper dev environment. Impostor syndrome (and sometimes toxic environments that pushed for “velocity”) didn’t help either. Felt good to know I’m not the one.
  • eqmvii 4mo ago
    > Just getting the code to run on your laptop took a week. This one surprised me. Claude Code in the CLI has made standing up an app and debugging whatever random dependencies or docker BS a dream compared to the before times, when you'd have to learn the architecture while simultaneously troubleshooting whatever isn't working on your machine
    • Lord_Zero 4mo ago
      And in the before times, you learned a lot and walked away with knowledge on the deps needed, connections, .env secrets, and cleaned it all up and documented it so the next dev would have an easier time doing it.
      • fooster 4mo ago
        Yeah, that totally didn't happen the majority of the time.
        • bigstrat2003 4mo ago
          Yes it did. That's how I learned a great many things throughout my career. I'm sure some people didn't pay attention or try to understand what they were doing, and didn't learn. That's on them. But most of us learned a lot that way.
        • bunderbunder 4mo ago
          I think it depends on how “before” we’re talking about. I can remember a time when learning was valued and leaving the camp cleaner than you found it was considered a basic professional standard. But I can also remember a time when Scrum became all the rage and next thing you know we’re all stuck on the sprinting treadmill, management is obsessing over “velocity”, and it’s generally an everyone-for-themself free-for-all to clear the absolute minimum criteria to get the ticket moved to the “done” column in a semi-desperate effort to keep up with your ever-growing backlog of tickets to which you’ve been over committed. Don’t worry about incomprehensible code or flaky designs; taking your time to do it right the first time looks bad on the KPI dashboard but rework does the opposite because you get to count the second (third, fourth, etc.) times the same task needs to be revisited towards your velocity metrics, too. I’m not sure most developers younger than maybe 40 realize just how much worse our line of work has become over the past ~15 years.
• sublimefire 4mo ago
  The post seems to not address the fact that different product phases exist which in turn affect the software. Similarly, teams are different and get assembled for different purposes. There is also a difference if software was created in the past 24 months vs past 10 years. It is very easy to attack decisions made which look messy now, because many reasons. Everything looks obvious in hindsight. And then making it ad-hominem like does not sound smart, it is a clickbait, the issues are usually more complex.
• ChrisMarshallNY 4mo ago
  Oh, yeah. I'm reconciling with the fact, that, if I let AI write a bunch of code, I have to depend on that AI to maintain it. I just spent the last week, hunting down memory issues in the app I'm writing. I had a lot of help from an LLM. It rewrote most of the view controller that implements the map screen. That view controller is now 4,000 lines long (but half of that is comments), but it works extremely well. It took many context resets and rewrites to get here. I would not have done it that way, but then, I probably also wouldn't have fixed the issue. The issue was really in Apple's MapKit, and I needed to do some gymnastics, to keep it from jetsaming my app. It's not particularly good code; but it works. I've made the difficult choice to leave the sloppy view controller in the project, with the option of completely ripping it out, in the future, and replacing it with less "intense" code. It's pretty much "firewalled." It won't be that difficult to do it, assuming I have the bandwidth (and Apple finally fixes the memory hog issue, which seems to have been around for a long time). There's all kinds of options that I could have (and still can) explore, but I feel that this is the best one. But this article is absolutely correct. I think we will have a "slopocalypse," when it comes time to pay the piper for the thousands of vibe-coded applications that are certain to be authored in the next couple of years.
  • magicalhippo 4mo ago
    So far my take has been that there is code that isn't very important, in the sense that if it works it works, it won't be modified or extended much if at all, and it's easy to verify that it works as expected. This type of code I'm happy with letting the AI go wild on. Then there's important code, like business logic, security related stuff and such. For that I'll happily use AI to brainstorm ideas and avenues, do code reviews where I'm prepared for it to be wrong and help with library suggestions etc, but where I want to write the code myself so I understand what's going on. We'll see how it changes, been a wild ride so far.
    • skydhash 4mo ago
      I’ve never seen code that is unimportant. It’s either being used or not. If it’s boilerplate, it can be abstracted away. There are domains that are riskier than others (debug logging vs crypto for auth), but sometimes bugs in a somewhat safe place can lead to some catastrophic issues (you do not have to break a crypto algorithm if the key can be leaked via logging).
• Ithildin 4mo ago
  Like many other critiques along this line, I think the answer is: Yes, for now. For example, in my own code base, I have an agent dedicated to maintaining a sane data model. This agent reviews the plan in advance and again during code review. And then I review the code myself. This seems to be sufficient for my work, at least. YMMV. It was a good post though. I enjoyed the take and the writing.
  • allknowingfrog 4mo ago
    If you're reviewing the code yourself, then I don't think this article is about you.
    • CodingWithJesse 4mo ago
      Exactly right.
• progforlyfe 4mo ago
  This is why I always work at a new company at least 6-12 months before making any major changes. I use that time to get into the flow of how things are being done (even if I think they are not efficient). I may make some suggestions but that's it. Of course, I'll probably never get hired again anywhere so it doesn't matter anymore.
  • sublimefire 4mo ago
    In 6-12 months you could ship a new product or a large feature. This strategy might actually put you on a performance improvement plan instead.
    • hamdingers 4mo ago
      A company/manager that would PIP you during onboarding doesn't understand the craft and does not deserve you.
    • progforlyfe 4mo ago
      That's why I said I'd suggest things. And of course I'd go along with strategic plans. Every company is different -- you'd be surprised at how many shitty [small] companies are out there that are actually profitable and want to keep things the same, refusing to do anything differently.
• zkmon 4mo ago
  Rockstars, AI or not, were 'successful' because they defined how success looks like. They created that perception and called it success. Not many people would bother going beyond the perceptions. They don't know how success or good code looks like. Rockstars gave them the playbook. In reality, sometimes I wonder if there is really anything beyond perceptions.
  • Waterluvian 4mo ago
    Sure there is. Actually getting to the moon.
• LogicFailsMe 4mo ago
  I was such a fool to lean hard into two production engineers to build the infrastructure around the two very profitable projects I built. I could have made so much more money spaghetti coding it all like a 10x boss and then jumped to Anthropic for one of those sweet 9-figure comp deals. Stupid, stupid, stupid me. At least that's my takeaway here.
• Havoc 4mo ago
  One thing I’ve found helps is leaning a bit more towards a modular almost microservice like model with clearly defined interfaces. Gives you a bit better control than a huge unified ball of AI spaghetti code
• laszlojamf 4mo ago
  this resonates with me, but fortunately one difference between LLMs and rockstar developers, is that LLMs will at least _try_ to explain what they are doing, and why something has to be certain why. I've gotten quite a lot of mileage from being a five-year-old with Claude and just asking "why" until I'm satisfied
  • alfredoh07 4mo ago
    [flagged]
• 0-bad-sectors 4mo ago
  I heard this kind of rockstar stories a lot from my friends but I never encountered one in real life. I worked in small and big companies and no one with allowed to use any obscure language or tooling. I count myself lucky.
  • esafak 4mo ago
    You need a CTO to lay down the golden path.
    • Lord_Zero 4mo ago
      .NET 4.8 only, vanilla JS only, MSSQL on-prem only, IIS only, no Azure ever.
      • esafak 4mo ago
        I'll see myself out and return when I locate my "Developers, developers!" T-shirt, but I might find another job first...
• jhack 4mo ago
  Sometimes I wonder if any of this will even matter in a few years. How many of us compile code and then have to clean up the assembly, or even worry about what a compiler generates as long as it's correct?
  • LtWorf 4mo ago
    We are finding out that ram is neither cheap and unlimited.
  • bigstrat2003 4mo ago
    A great many people do that.
• Hasz 4mo ago
  I think this is fine? Code used to be very expensive to generate, now it is cheap. Building glue logic between well-defined, well-documented APIs has never been easier or faster. There is a time and place for throwaway code that quickly automates a task. It is fast food to fine dining -- not everything needs to be a Michelin star experience. However, as always, AI usage is a matter of taste. Including your style rules in the prompt matters. Introduce new paradigms/tools/code into the main codebase because they solve a business problem, not because they are technically interesting. Careful development does not break 7 things to introduce one new feature, etc.
  • nateb2022 4mo ago
    I think an important caveat is that LLMs are prone to writing unnecessary code, i.e. there's almost a superfluity to it, that at the same time makes it less straightforward and more prone to unnecessary side effects, which it does catch and handle, but that again expands code further.
    • freediddy 4mo ago
      Then you add an agent that goes through the code and simplifies it. Before every sprint, you get the agent to simplify whatever it can without losing fidelity. It's really that simple.
      • SlinkyOnStairs 4mo ago
        "Just have a stochastic machine redo the code with no oversight" This is an utterly terrible idea.
        • kaydub 4mo ago
          There's always oversight, that's just something you wrongly assumed.
      • Capricorn2481 4mo ago
        I should probably know better than to interact with a 3 month account called "freediddy", but here we go. > Then you add an agent that goes through the code and simplifies it Can you? I just asked Opus to generate a sum function. def sum(a, b): return a + b Then I asked if it could simplify it further. I would expect it to say this is simple enough, or just use the actual `sum` function, but it did this. add = lambda a, b: a + b That is, at best, a useless but harmless change. If you ask it to simplify something, it will make changes whether it needs to or not. Now imagine we were working with a function that is a couple hundred lines. What changes would it make? The reason something superfluous was written to begin with is because an LLM does not always know what is superfluous. Producing and reading is really cheap for the LLM, so it doesn't have the same considerations we do in writing code. It's more willing to reinvent the wheel or write something that is way more verbose than it needs to be. In practice, asking an LLM to simplify it just means it adds a different superfluous thing. Or it refactors things that didn't need to be refactored (because it can do it quickly). The result is LLM code, even if it's good, tends to bloat a bit. Multiply that across 100 people all vibe coding and not reading the code base, and soon you have an unreadable mess.
• bbminner 4mo ago
  One argument I heard from a college that the experimental llm written code (not production ofc) should be "write only" - you specify the requirements and constraints and let the machine figure it out - you specifically avoid "fixing it" or "cleaning it up" or reviewing the code because it disrupts the state of this discrete optimizer (over code). Not saying that it is right, or that it should be applied in prod, just noting that this is one potential way to go for non-critical code with clear "win conditions".
• rnxrx 4mo ago
  I don’t think the analogy between rock star developers and LLMs bears out here. Like any other tool, AI abides by the basic reality of garbage in/garbage out. If you don’t make sure the LLM has sufficient context then you get what you get. Same point with vague prompts. AI tools are producing code on behalf of a developer. If that developer is fine putting their name on code that they don’t understand, applied to a code base they also don’t fully understand then you have a very human problem. The technology just magnifies this.
• bunderbunder 4mo ago
  The first few sections hit me. I think that I used to be a “rockstar”, until I realized it wasn’t a good thing. Perhaps I could get things done 10x faster than my colleagues. But at some point I realized it wasn’t because I was 10x more productive than a normal person; it was that I worked in a way that made the normal people around me 1/10 as productive. Since then I’ve slowed down. It’s been an overall positive change for my life. Being a team player unfortunately won’t give you the same kind of upward mobility in this crazy industry, but it’s done amazing things for my mental health.
  • jmaw 4mo ago
    I've definitely shot my own foot off in the past by implementing things in a rockstar manner. In my case, it typically involves me over-abstracting something that really doesn't need it. Or building something for use-cases that never actually happen. So I have to try to keep YAGNI and KISS in mind whenever my mind wanders into over-abstraction territory.
    • grebc 4mo ago
      Copy paste is a very, very under appreciated tool when it comes to programming. You can always abstract later, but once you start it’s terribly difficult to reverse.
    • deleted 4mo ago
      [deleted]
• rohanucla 4mo ago
  Nice Blog!
• bogwog 4mo ago
  I realized recently that this all has an unsavory element of ego to it. It doesn't help that LLMs have basically been trained to talk like they're performing in a movie, getting creative with techno-babble that sounds both plausible and exciting. I recently had to review some slop where the LLM was using terms like "event storm" to describe how some callbacks work, or "gating-solve" to describe a simple change to an if statement. Combine that with their sycophantic tendencies, and it really can make you feel like you're a star hacker in a Hollywood movie. It reminds me a little of when Hegseth wrote "we're clean on opsec" in a message thread with confidential military information that he accidentally sent to a journalist. It seems like role playing/fantasy fulfilment for certain personalities. I struggle not to hold some contempt for people like this, who are making life difficult for everyone for their own petty reasons. I can sympathize when it's simple ignorance, but the ego chasing really is inexcusable and needs to be called out more.
  • kaydub 4mo ago
    Funny, the element of ego I'm seeing are the devs that can't accept that LLMs write perfectly good code at a faster pace. It's always "slop" this or "vibe coded" that. Meanwhile I've personally shipped multiple apps and professionally we've done HUGE things in these past 6 months using LLM tools.
    • habinero 4mo ago
      Oh really? Link them.
      • kaydub 4mo ago
        Not sure what I'm going to link to in my professional life, it's all private repos. We have a large microservice architecture in AWS. We've made major changes and the LLMs have helped every step of the way. Migrated our whole auth system from being regional, resulting in customers being limited to specific regions or managing their multiple accounts across regions, to a global authentication with data residency built into accounts so that they login to what looks like a global app now. No more uk.example.com, eu.example.com, ca.example.com and us.example.com. It's now just example.com, but data residency (and currently data processing too, but that's another thing we're working on) stays the same. This isn't some small app, this is the main product at a company with nearly a Billion in ARR. For personal projects, only one thing could I actually show - vaicayo.com This app was originally started pre-llm. I just wanted a centralized place for my wife and I to organize our vacations. I built out the basic crud for that a long time ago and we used it, but then llms got popular. I first integrated it into the app, now I could get it to generate vacation plans completely with the llm. It did okay. Somewhere between 3-6 months after building out llm features claude code released or I became aware of it enough to start using it. I rebuilt the whole thing. So what was once a spring boot app running in AWS ECS with alb + cloudfront (and yeah, some sqs+lambda python processes, s3 buckets for storage, aurora rds for db) is now a super lean apigw + lambda + dynamodb stack with a svelte frontend. I went from paying $20ish a month to $0. I also built a flutter app for android and ios that utilizes the same backend as the frontend webapp with feature parity. It's not really a production app, but it could handle it fine, it's completely cloud native and hands off to operate. And let me be clear about the rebuild, it's not a 1 for 1, I think all that I kept was the domain model. For features, it's mostly just a crud app. You plan your vacation in it. Outside of that there's the ability to take pictures with the phone app that auto-sync (there's a bit of complexity here, the phone app only syncs pics when it's on wifi unless you change settings to allow syncing on cell network, images are cached locally with a ttl, uploads will run in the background and queue up, uploaded images automatically resize/compress and generate thumbnails from an s3 event lambda). The other more complex item is email ingestion, when I get a reservation email I forward it to the app and it automatically processes it (the only place I use an LLM in the app right now). If it can't discern what the email is or which vacation it goes to it goes in a travel inbox so the user can route it to the right vacation and object type. Oh I guess the paywall is a little complex. I don't advertise this thing but I have left user registration open if anybody ever wanted to use it. I did lock the email parsing behind a paywall and I limit photo uploads for free accounts. So frontend, backend apis, flutter app for android and ios all built 100% by llm. For code quality, the frontend is okay, the backend is pretty clean but could use some things split out into domains, and the flutter app has some work to do (recently found a couple code smells). But there's no issues adding features, shipping, etc. I literally finished adding some of the photo syncing features in the flutter app last night. Other than that, I have created 5+ other personal projects that I wouldn't have without an LLM. I've made 2 godot games, a private scribbl.io clone with a few extra features that myself and my coworrkers play as a "happy hour" on fridays, tons of ci/cd build stuff and terraform (using my own personal modules, so I guess that's not 100% llm coded if you consider the modules), and then a couple other simple apps.
• tastyeffectco 4mo ago
  We are always the rockstar of someone else
• freediddy 4mo ago
  > Sometimes there's so much technical debt that it can never be paid off. There is no such thing as technical debt in the age of AI. It's just a series of migrations that take minutes to come up with. I migrated from two disparate databases using AI and it took minutes for it to write the migration code. I had it double-write the data, and then I told the AI to write code to compare between the two databases, and I then tested over the course of a week.. I fixed some small bugs, or more precisely I told the AI to fix the bugs and it did. Then once I was satisfied, I switched it so that the new database was primary and the previous database was secondary. Then I tested to make sure the data was still in sync. Then I switched off the previous database, then I removed all traces of the previous code. It was simple and relatively quick. The thought that there exists technical debt in this age is absurd. One person can do things an entire team used to take in a fraction of the time.
  • cbg0 4mo ago
    > There is no such thing as technical debt in the age of AI. Producing new technical debt quickly doesn't mean there's no more technical debt.
    • LearnYouALisp 4mo ago
      Never mind the huge, untouched, unspoken-of debt to all the people whose work--literary, artistic, software--under various licenses, or without, it (rather THEY, the owners and co-conspirators) are taking and re-using, without attribution, without credit, nor payment of any form. Not even a thanks (because as soon as that is acknowledged it will enter the consciousness and then the question of injustice will dwell--and we can't afford to have people thinking about that).
      • gyanchawdhary 4mo ago
        [flagged]
• sltr 4mo ago
  The job when picking up a codebase made by human or machine always involves reverse-engineering the design intent from code. That's especially hard for LLM-generated code because the path to runtime was so rushed. > It's more expensive to fix code at runtime than at compile time and at compile time than at design time. Unfortunately, AI rushes people to runtime as fast as possible. https://www.slater.dev/2025/09/about-that-gig-fixing-vibe-code-slop/ https://www.slater.dev/2025/09/about-that-gig-fixing-vibe-co...
  • pjc50 4mo ago
    One of the things that annoys me is that we could know what the original intent was, and indeed the preferred form for modification: the prompt! Yet for some reason there's no standard/tradition/expectation that people commit all their prompting. Perhaps I should start trolling people that your software is not truly Open Source if it's not Open Prompt.
• aleph_minus_one 4mo ago
  In my opinion the problem rather is that most managers do not value elegance of the code, and most programmers are either too obedient or too clueless to dissent to management. Also, most team members don't want to understand highly elegant code and its inner beaty. If management and teams would instead value highly elegant code structures over lots of "spewed out" code lines "that (superficially) implement a feature", I would bet that the problem discussed in the article would be much less of an issue.
• erichocean 4mo ago
  > Half the code was written in a language you didn't understand. The other half was written using libraries you never heard of. The author already describes himself as "not a rockstar developer", but if this is the definition of "rockstar" I need to recalibrate. Being able to learn new languages and libraries, to me, is completely normal. (Also: how funny is it to suggest rewriting code you self-admit you can't even read.)
  • rafram 4mo ago
    The point is that developers like this purposefully introduce new languages and frameworks that only they (and maybe not even they) fully understand, so they make themselves harder to replace and ensure that they appear ahead of the curve. (Then they get bored and leave anyway.) It's totally valid to introduce new technologies when the problem calls for them, but doing it in a way that's purely detrimental to the rest of the team is very selfish.
    • CodingWithJesse 4mo ago
      Exactly my point. Learning stuff is fun. But if you're going to introduce new technologies or programming languages into a system, you need to make sure it suits the skills and experience of the rest of the team. Rewriting the company's admin dashboard in Elm, not letting anyone else work on it, and then quitting - that's just cruel. (Elm's cool, but you know what I mean..)
  • kaydub 4mo ago
    Just look at the author's accolades. They are very light. I've never heard of this guy. He's "self employed" The article lacks any real detail and it just a guy patting himself on the back.
  • sumeno 4mo ago
    There's a difference between introducing new things because they are a well thought out appropriate choice and completely ignoring the standards of the company because you want to do resume driven development. I believe the author is talking about the latter.
• dimaaan 4mo ago
  Don't call them rockstars - call them "resume-driven developers." We had one on our team in the past. A bunch of microservices built on an in-house RPC framework he wrote, RabbitMQ, half-baked "monads" in an OOP language, esoteric naming, and no comments (the code should be self-documenting!), no docs. Management adored him. Once we started to grow, the problems started to appear: bad orchestration, uninformative logs full of PII, poor error handling, edge cases that were nearly impossible to fix within the existing abstractions, dependency hell, etc. At that point, he moved on. It took years and many hundreds of pull requests to clean it up.
  • consp 4mo ago
    Or people with not enough time, not enough resources and too much overtime already to kill off any happyness in creating the product.
• Ile09 4mo ago
  [dead]
• rdevilla 4mo ago
  [dead]
• xtajv 4mo ago
  I've said it before, I'll say it again, I'm convinced LLMs will be the thing to convince software engineers to get it together and create a licensing board. Somebody wake me up when the ABET SWE PE is back.
  • tbrownaw 4mo ago
    That makes as much sense as having a licensing board for hammers or socket wrenches or welders.
• kaydub 4mo ago
  This is such a low value article lol I'm not even sure what it's trying to say. It's just someone patting themselves on the back.
  • amphitheatre 4mo ago
    tl;dr: "Slow down and think about what you're doing when using an LLM." Saved you five minutes. I was expecting a lot more, or a worked example, or _something_ to that effect. 90% of the text is the author complaining and defining the problem, then a hand-wavy vague solution is presented in the penultimate paragraph. Barely relevant or useful, really.
    • kaydub 4mo ago
      I mean, go look at the author's linkedin and github. They're a "dev" with 20 years of 1 year of experience. Not a software "engineer" There's a big difference between the two and LLMs are increasing the chasm. The Software devs are crying out because the LLMs can already do their full job. Software engineers are happy because the LLMs are removing a large chunk of the job that's low value. Software dev using an LLM is gonna produce "slop" Software engineer using an LLM is going to have an increase in productivity depending on how they're using the LLM tools.
      • Yokohiii 4mo ago
        There is no universally accepted distinction between developer and engineer. Even if so, dev or engineer, both can be low or high skill. Their job title doesn't tell how sloppy or good their LLM usage will be.
        • kaydub 4mo ago
          This isn't about distinction between literal titles. But continue missing the point.
          • Yokohiii 4mo ago
• galaSerge 4mo ago
  [flagged]
• nrmitchi 4mo ago
  > Craftsmanship will always be in our hands, it's one thing we can never outsource to a machine. I'm right there with you, but this last sentence concerned me a bit. In my most other "industries", craftsmanship is not _dead_, but it's been pushed to the wayside for (significantly) cheaper and more available alternatives. You can still get hand-made leather shoes, but very few want to pay $1000+ for them. You can still get art and paintings that someone poured weeks of work into, but most people buy their wall-art and chachkas at HomeGoods. The main difference is the disposability assumption, and software is _unfortunately_ becoming more and more "disposable"[0], in the same way other products are. This mindset doesn't align well with software that must continue to operate in order to support some process. A disposable countdown app, sure, throw it away, but anything built around long running business processes should not be treated in that way. I have concerns that focusing on software craftsmenship frames the issue as "boutique and bougie and unneccessarily expensive" vs "what I need for my usage", instead of "maintable and trustworthy" vs "disposable". [0] Is that an initiative that benefits large model providers like OpenAI/Anthropic? maybe, but that's not my point here.
  • KronisLV 4mo ago
    > In my most other "industries", craftsmanship is not _dead_, but it's been pushed to the wayside for (significantly) cheaper and more available alternatives. What if for a lot of software projects out there you don't need craftsmanship but you need something closer to real engineering: "This is what a sane PostgreSQL setup and transaction management for your app looks like, this is how you do validations and the ORM layer and logging and interaction with APIs and request queueing, this is how a good front-end page looks like, here's the off-the-shelf component library you use, here's how your process errors and show toast messages and handle redirects without messing around with browser history, here's all the accessibility and mean things you DON'T do (like hijacking scroll, not having contrast, having too many animations etc.)." You don't have a rockstar building a bridge, nor do you usually have craftsmen taking risks on innovative materials and new approaches: most of the time, you just build the damn bridge in ways that have worked for decades and have been proven. Software industry doesn't seem to know what is proven or works, cause it's a moving target. Outside of maybe niches like writing code for airplanes, completely different standards there, not sure if most devs would personally want to work in those conditions, though. Instead on one hand you have orgs and devs that are moving too fast and create a lot of churn without nailing down what works and doesn't, on the other hand you have a lot of people (myself included) that often have to push out slop because tech stacks are a mess and you still have deadlines which don't care about any of that, and largely the state of software development seems like a comparison between Windows 9X, the UI/UX of which was at least partially based on usability studies, and the modern version which... well, you can see for yourself.
• arealaccount 4mo ago
  Okay so "belt and suspenders" is an LLM-ism, it's not just me who recently learned that expression.
  • alt227 4mo ago
    No that expression has been around a long time. In the UK we call it 'Belt and Braces' https://wordhistories.net/2018/12/13/belt-braces/ https://wordhistories.net/2018/12/13/belt-braces/
• balls187 4mo ago
  Opening paragraph is not the profile of a rockstar developer. At least not the rockstars I had the pleasure of working with.
• ifjfkfkfkfj 4mo ago
  [flagged]
• acd 4mo ago
  Code that is written will have to maintained often by someone else than who wrote the code. So if one write code nobody else understands its an eventual maintenence failure. You could optimize for different things. Code understandability by the team, speed, technical brilliance. If you optimize for technical brilliance but nobody else on the team understands the code its still a failure. Seen over engineered code
• nsxwolf 4mo ago
  The photo in the article looks like AI slop but isn't - it was taken in 2019. It took me awhile to convince myself everything in it was real.
• maxothex 4mo ago
  [flagged]
• Imnimo 4mo ago
  >Craftsmanship will always be in our hands, it's one thing we can never outsource to a machine. Current AI coding is certainly very lacking in the craftsmanship department. But it is not obvious to me that that will always be the case. I don't think there's some fundamental reason AI could never produce code that matches or exceeds the craftsmanship of human experts.
  • bigstrat2003 4mo ago
    The fact that LLMs fundamentally do not, and cannot, have understanding or reasoning. I don't think you can produce craftsmanship through sheer volume of throwing stuff at the wall and seeing what sticks.
• OptionOfT 4mo ago
  > You can lead the engineering, and guide the LLM to generate small snippets at a time. Yes, yes you can, but you can't force the LLM user to _understand_ your feedback so that they reduce the burden on you, as the reviewer.
• InfiniteWarlock 4mo ago
  [dead]
• AIGENIZE 4mo ago
  [flagged]
• dktoao 4mo ago
  Story time! I Worked with not just a "rockstar" but what I suspect was a "superstar" for about three years at my last gig. It was a small company with about 3-4 developers at any given time and we worked on an embedded Linux product in a moderately safety-critical industry that had a messy ~25 y/o codebase and a custom, roll-your-own Linux distro on custom hardware. Our "superstar" had been with the company for ~10 years and due to really high turnover I was the most senior of the rest of the staff with 3 years. The manager of the software team claimed to have 10+ years of software development experience on his resume and LinkedIn, but would ask CS 101 questions in our software planning meetings. The basic workflow adopted by our manager was thus: 1. Discover a bug or get a feature request 2. Pass the task to the development team verbally 3. Developers prioritize tasks based on which ones are more likely to be forgotten by management 4. Approx 20% of tasks get completed 5. Repeat step 1 You might think, with our superstar developer, a workflow like this would be possible. Honestly, I saw him do things (pre-AI) that were astonishing. He would work a weekend and add a feature I thought would take 2 weeks. He created a re-write of our main product and demoed a completely new product using the same hardware by himself in about 6 months. He would take feature requests not assigned to him and just do them before the assigned developer was even finished planning the feature. The sales team would come in with a pitch for an insane new feature idea (like add a Farsi version of the UI) on Friday, the rest of the team would attempt to push back on it, then he would check-in a semi-working version of that feature on Monday. For these reasons our manager loved him and would always ask the rest of the development team why we couldn't keep up. It was demoralizing and frustrating. At the same time, as a company, we were mostly unable to get very simple changes out the door. Most of the insane features we added died on the vine before getting to the customer (but the code would remain polluting the codebase). Any bug that was fixed would reveal 2 more serious show-stopping bugs. New software releases were regularly regressed: they would break one of our customer's use cases and because we never created basic functionality like OTA updates, we would fly a tech out with a flash drive to revert all the software. We worked on 3-4 new products an not a single one ever saw the light of day. Our company github was littered with dead, abandoned, duplicated repos. Basically our superstar developer absolutely allowed our non-technical management to commit software development seppuku. His successes were highly visible, but his failures were not: 1. Clobbering other developer's commits because he didn't know how to use git to rebase or merge changes 2. Copy pasting (not forking) entire codebases to work on a new feature that then got so bloated they were impossible to merge 3. Absolutely no documentation of any sort, not even comments. 4. No automated testing of any sort on any of his code even though there was an effort by the rest of the team to do better testing. 5. Refusal to use the common Docker development platform everyone else had standardized on, many times his code only worked on his machine. 6. He wouldn't fix bugs, he would just re-write the core logic of the feature that had the bug and then he wouldn't bother to remove the old logic. 7. Regular, daily code dumps of 1000-2000 LOC that contained new features that were not discussed by the team, sometimes from casual conversations with a sales person, sometimes completely made up by him out of boredom I guess. 8. Our Linux BSP was stuck in Amber because the only copy of it was on his local machine (allegedly). When asked many many times by the rest of the team to get it in our company repo he would check in something that did not compile and was not even remotely close to what was being used on our boards. 9. Instead of adding dependencies where needed he would take a 3rd party library, chop it up and copy-paste it into our code directly (see point 8). 10. Last but not least just general slop code with 15-20 levels of indentation, no modularity, dirty hacks everywhere. I think about him a lot when I think about companies going all in on productivity maxxed vibe coded AI. I think that under better management that restricted his impulses and gave him more structure, he could have been a great asset to the company. Unfortunately when let run wild over the company codebase he was an absolute menace and ultimately led to less actual useful work getting done and an erosion of customer trust. I think this might be the reason we are getting two diametrically opposed experiences with AI: it is either going to destroy your codebase or deliver features at an astounding pace, and I think the difference is the actual technical knowledge of who is managing these projects. My guess is that there are a lot of places with middling or non-technical management pushing AI coding that are going to be in struggle city in a year or so and not understand how they got there. "But AI was making us so productive!".
• anioko1 4mo ago
  This is where determinism is useful to help avoid these. A tool like Archiet does the determinism side of things and generates working solutions, which can then be given to a human or AI to sort out any gaps. This saves time, tokens and the need to clean up after AI rockstar developers. Archiet also ships with the right architecture documentation, without the right architecture or specs-driven documentation, AI rockstars need clean up.
• synapsehire 4mo ago
  [flagged]
• liampulles 4mo ago
  Its never been quicker or cheaper to build something with bad foundational assumptions and principles. Its never been easier to add features whilst not recognizing that it comes with added responsibility. And it will never be too late to hire me for your V2 migration project.
• PeterStuer 4mo ago
  This article feels written by AI. This cascades of short sentences are a giveaway.
  • CodingWithJesse 4mo ago
    100% wasn't. I use Derek Sivers' approach, search "writing a sentence per line", and I try to keep my sentences short intentionally. If you view source on the HTML you can see the line breaks.
• shark1 4mo ago
  Don't worry about losing your job to AI. We will have a lot of mess to clean up.
• OOTW 4mo ago
  [flagged]
• zzyzxd 4mo ago
  IMO that is not a rockstar developer, but a junior developer rocking LLM agents. Completing each individual programming task is easy. Engineering the system in a sustainable way that changes can be traced, understood and reasoned about is difficult. The problem is, as many other comments have pointed out, typically the business doesn't value this.
• deleted 4mo ago
  [deleted]
• socratic_weeb 4mo ago
  Don't bother, they love AI slop here on HN, and will cope hard on the comments
• advertum 4mo ago
  [dead]
• maxothex 4mo ago
  [flagged]
• tracker1 4mo ago
  I kind of resemble the Rockstar portion mentioned... that said, I'm a massive fan and prominently defend KISS/YAGNI over most other principals... Not the there are never abstractions, but IMO, abstractions should make the rest of development easier and not just hide the common points of use/access behind painful boilerplate or interfaces. I know of several projects I've worked on that are alive well over a decade later, and some of which I've heard feedback on even recently. Very little of it excessively negative. It's been an uphill battle though, especially having worked in a lot of C#/.Net shops, where Enterprise Patterns are often adopted when not necessary or prudent. There's also a balance between new tooling and what's working/known already.
• maxothex 4mo ago
  [flagged]