| ▲ | yodsanklai 13 hours ago |
| I don't think this matters anymore. Software is becoming a black box and agents make it works, as long as you can provide some reasonable spec of what you want to do, and a bit of supervising and directions. Right now, they're not great at following good software engineering principles. They do the job, with verbose code, lots of duplication, abstraction leaks, useless unit tests and so on. Is it an issue? you could think that in the long term it'll be, that AI won't be able to handle the complexity it introduced, but I'm not really worried about it. Most software isn't that big, and agents are getting better by the day. And if you really care about design, it's not too hard to instruct your agent to follow your standards. I wish it wasn't the case and that I could justify my experience and expertise for a few more years, but the facts are there. |
|
| ▲ | softwaredoug 13 hours ago | parent | next [-] |
| The experience still matters. I have had experiences out of my technical depth where I’ve instructed an agent to do something technically nonsensical. The agent tried to do it, creating a mess. Nothing works, I get frustrated, only to realize I have a fundamental misunderstanding of something technical. A similar thing happens when you ask for something, but the complexity for the perfect solution is 10 x the complexity of a simpler, 90% solution. And sometimes you only realize that looking at code (or feeling lots of brittleness) |
| |
| ▲ | ffsm8 13 hours ago | parent [-] | | Fwiw, that's not what the parent was talking about. You're trying to middle road it. He was talking about actually treating it as a black box, so just give the model your expectations and goals it needs to meet, not tell it a rough solution for it to apply in detail. The expectation/goal approach in a ai edited project works better then the middle road since opus5.5 ime. Depending on your project structure, it may not be viable however without large refactorings | | |
| ▲ | lilbigdoot 7 hours ago | parent | next [-] | | For me it's really hard to find a balance with LLMs. Even trying one to add .NET IR codegen to my compiler that already had a working C++, JS, and C# backend for it to use as a reference. It just kept doing really odd stuff and when we got to generics it had done such a bad job with the prior work it struggled to collect the information it needed from .NET to do generic calls correctly, and mid session decided to just make everything reflection based with no notice to me. It had a doc of the AST with notes on what the nodes mean and how different constructs are represented, it's a pretty typical ML family language. Plus a working C# backend to reference. Other times it will one shot things near perfectly that I was expecting to just use as a reference. Demo pages for work I've done its so fast and gets good enough right out the door Every time I've tried to use it to write something small in my compiler? :"( pain. It's the perfect intersection of looks good and covers 90% of cases fine but explodes far away because some subtle invariant is wrong. I can't always think of the invariants up front without writing the code myself | | | |
| ▲ | rsfern 12 hours ago | parent | prev [-] | | Expectations and goals can be technically nonsensical. Agents have gotten really good, but they can’t magically solve intractable problems. If you’re out of your technical depth it can be easy to set unrealistic expectations without realizing it | | |
| ▲ | ffsm8 12 hours ago | parent [-] | | Then you're still middle-roading it from my perspective. Treating it as a black box means you're only specifying what comes out, essentially. But to preempt a "I can't do that in my brownfield distributed monolith I'm maintaining at $dayjob": yes, that's why I said it may not be possible without refactoring. | | |
| ▲ | rsfern 9 hours ago | parent | next [-] | | I think we are talking past each other a bit? I’m curious about GP’s perspective here My point is that you can ask for unrealistic outputs even if you’re treating the system as a black box. This is the classic case of higher level managers asking for infeasible results from their engineering team because they haven’t considered they’re trying to solve the wrong problem. Depends what you’re doing but I don’t think agents tend to push back on badly specified goals unless you’re proactive about it | | |
| ▲ | hugeBirb 4 hours ago | parent | next [-] | | Yeah I think this is the main issue at play. Bad engineers are now 10x bad engineers with the ability to hide behind the mask cause they can output something that looks right, but they don't understand it. You can "make" an agent do ANYTHING. There is no rigor, there is no taste, there is no risk. Anecdotally I have seen this play out IRL. I worked with a 3-month boot-camper that somehow stumbled into a software developer role at a small company. The amount of slop that he was creating was unprecedented. No formal training, no idea of abstraction, letting/making the agent reinvent the wheel for everything. The LLM was doing the whole "you're absolutely right" so he was also under the impression that he was a real engineer doing the "right thing". Concretely he convinced our manager that we need to re-write our web-app in Go because it was so much faster(0 users btw) and safer than python. He had an agent build out this test suite and there was a metric like Go vs Python DB operations, Go being 107x better. Seemed sus, looked into it and he(his agent) removed connection pooling for the python side but for the Go side, 100 concurrent connections, 10 idle and a connection lifespan of 1 hour. His reason for that was that the python code kept crashing every time his agent adding pooling so he had the agent removed it. This sheet got printed as is and distributed to our C-suite to much praise. I know this is a very specific example but I fear this is happening at some level everywhere. Where in the past a bad engineer to this degree would stick out like a sore thumb if they were surrounded by competent people that have rigorous standards. An LLM/AI doesn't have to worry about what happens if things don't work and when it's confirming that YOU are a genius every step of the way. It's going to be a disaster when the reckoning comes. I am not a AI luddite but software engineering is just as much as a culture as it is art and science. Without that backstop I just think that we will see a huge degradation in quality because there is no incentive for LLMs/AI to write "good software". | |
| ▲ | snapcaster 8 hours ago | parent | prev [-] | | Sure theoretically. practically this isn't a real problem for me or anyone else i know |
| |
| ▲ | dwaltrip 8 hours ago | parent | prev [-] | | In the black-box approach, how do you know what is a reasonable task to give it? Just ask the agent about that also? | | |
| ▲ | q4y2u35uk 6 hours ago | parent [-] | | You don't give it tasks. You give it what you want. It decides the tasks, and then executes. Then you give it feedback. "black-box approach" here is just a fancy word for vibe coding. |
|
|
|
|
|
|
| ▲ | mhitza 13 hours ago | parent | prev | next [-] |
| Might be true in your company, your culture, or in Big Tech. For a different perspective, the european peers in my developer network, while never outspoken against their company, like, and redistribute content that circle around the same points. Some have fixed mandates to use AI, in order to use AI, working more to keep the product stable (even outside normal work hours), or complains about the divide between management and developer's perspective on these tools. There is also some consideration about compliance issues and liability when you're stamping commits with your name (luckily for almost all software enginners there is no malpraxis law to punish gross negligence). |
| |
| ▲ | yodsanklai 11 hours ago | parent [-] | | > Might be true in your company, your culture, or in Big Tech. For context, I work in a big tech company with virtually unlimited tokens on the best models, and a lot of tools integrated in our workflows. The culture makes it impossible to go against the wind. Even if you don't want to use AI as much as others, you won't be able to prevent them to do so. |
|
|
| ▲ | megak1d 13 hours ago | parent | prev | next [-] |
| This is what I came to post. For the last 20 years of my career, I have prided myself on keeping a clean codebase, making 'art-not-science' decisions of when and what to abstract, scope boundaries, then implementing them cleanly, specifically to be easily grok'd by other developers. But after building, from scratch, and operating an (essentially) vibe coded software solution (in typically a very engineer led/low level space) over the last 9 months, I am still able to move at super-human speeds in terms of delivering features, investigating and fixing any issues (there aren't many, certainly less than most human teams I've been in) - whether that's because of AI advances or just their innate quality of being able to tackle the dross coding tasks that always got avoided by humans in my past I'm not sure but I'll stick with it until a better approach becomes apparent! I feel my specialist skills (coding, debugging, devops) has been devalued - I can't justify holding those as my value-add proposition any more - but new skills are replacing those (context/AI/agent engineering) in equal measure. |
| |
| ▲ | geertj 13 hours ago | parent | next [-] | | I think I agree with all you said. But I can’t let go of a clean codebase yet. It’s stronger than me. And I’m not sure I should. Or at least not yet, not until the agent can better understand what I actually want. And you’re right, with a bit of direction and further prompting it’s quite easy to get your code in a reasonable shape. So that is what I do now: the agent does all the work but I still whip the output in shape. Mostly my hope is that at some point soon the agents will start writing clean code. But then again, maybe clean code for a galaxy brained agent is not the most optimal code from a all-in token efficiency perspective. | |
| ▲ | skydhash 7 hours ago | parent | prev [-] | | > have prided myself on keeping a clean codebase, making 'art-not-science' decisions of when and what to abstract, scope boundaries, then implementing them cleanly, specifically to be easily grok'd by other developers That’s more of an artist thinking than an engineering thinking, favoriting elegance (cleanness, readability) over practicality. This was not really valuable even though you prided yourself on doing so. It’s like endlessly gushing on the design aspect of the report (the medium) instead of just providing a well-written one (the message). Code is a medium, and being an artist about it can feel good, but the information processing mechanism (the message), is what’s important. If, after using AI, you can’t reason about the mechanism (nothing about code, files,…), you can’t essentially justify anything about what happens in the software. Meaning data given to it has a non-zero chance of giving garbage answer. > but new skills are replacing those (context/AI/agent engineering) in equal measure This is still highlighting surface activities, not anything pertaining to engineering. | | |
|
|
| ▲ | adamddev1 6 hours ago | parent | prev | next [-] |
| You think it doesn't matter because you can get away with making an app that is "good enough" or "works" satisfiably. But what happens when your Node runtime, OS, compilers, or even libraries start regressing to the same lower-quality level? Everything starts collapsing and falling apart. That matters. |
|
| ▲ | utilize1808 12 hours ago | parent | prev | next [-] |
| That's right. I call it "organic software" --- software that behaves like living organisms --- lots of glitches and flaws but are constantly being fixed by AI agents. 99.8% of users never run into catastrophic issues, and for those who do, a dedicated human/agent will handle it manually. |
| |
| ▲ | adamddev1 6 hours ago | parent | next [-] | | That only (sort of) works on the VERY top level - with user-facing apps. No one is going to want "organic software" for their Node runtime, their web browser, or their OS. Some things just need to work, and work efficiently, 99.999999% of the time. | |
| ▲ | catdog 6 hours ago | parent | prev | next [-] | | For some uses cases I think this might even work out well enough if you figure out and apply the right guardrails and boundaries. That's quite a big if though... | |
| ▲ | scott_weber 6 hours ago | parent | prev [-] | | Funny, "organic software" is a mental label I have for how most human written software is produced/functions: software that could not be rebuilt from scratch, because it's construction was highly path dependent and dependent on implicit know-how distributed across irreplaceable individuals; an accumulation of unprincipled designs and patches. |
|
|
| ▲ | hoppp 13 hours ago | parent | prev | next [-] |
| I can write succinct code slowly, agents can write verbose code fast. Depends on use case |
| |
| ▲ | catdog 6 hours ago | parent | next [-] | | You can push the agent to write succinct code by working in small steps, going back and forth. You push the agent in the right direction but also the other way round because it finds a lot of stuff you might have missed, esp. in complex areas. It also oftentimes does quite reasonable things actually. You definitely can use those things to improve both speed and code quality at once. But then your speedup is while quite noticeable not astronomical of course. Also the work isn't easier (apart from less typing), just different. | |
| ▲ | softwaredoug 13 hours ago | parent | prev [-] | | I have a Stackoverflow mode for my agents (essentially a tutor) and sometimes I spend time hand coding but heavily guided by an agent. It helps A LOT to make careful tradeoff when succinct and line by line care matters. |
|
|
| ▲ | vkgcr 13 hours ago | parent | prev | next [-] |
| So you're essentially willingly becoming 100% dependent on AI, while praying that hopefully they'll become good enough to save you from the slopocalypse down the line. Doesn't seem like a good strategy to me. |
| |
| ▲ | hoppp 13 hours ago | parent | next [-] | | It boils down to architecting systems. Using AI is one element for a pipeline that produces code. If you architect well what you generate then it stops being slop and starts behaving like a cohesive system where code is produced automatically. | | |
| ▲ | vkgcr 12 hours ago | parent | next [-] | | I don't think there will ever be a way to "steer" an LLM such that it produces the correct output 100% of the time. You can certainly context engineer your way to better outputs, but you can never reduce to 0 the possibility of the LLM making a mistake, due to inherent limitations of the LLM (perhaps what you ask of it wasn't RL'd during its training), but especially due to the fact that it will often misunderstand requirements and make unjustified assumptions. So, no, you will never be able to produce code automatically. You can and certainly should use AI as a code assistant to write code faster, but the human should always 1) make all important architectural decisions and 2) carefully review the outputted code The human bottleneck is necessary. | | |
| ▲ | hoppp 12 hours ago | parent | next [-] | | Not correct but you can plan in the mistakes.
E.g: I designed a modular monolith where each module is strongly decoupled so an LLM can work on it individually and if it breaks it can be ripped out and replaced without damage to the rest of the system. So the system accounts for mistakes and has protocols for removing bad modules/code. If part of the system go down the rest will remain functional Edit: and yes audits are part of the pipeline | | |
| ▲ | vkgcr 12 hours ago | parent [-] | | Sure but that means accepting the cost of having faulty modules running in production (and there is no guarantee that your LLM could fix a faulty module, perhaps it will just replace it with a module with different bugs. There's no way to know!) This obviously won't fly for "serious" software such as airplane software, but I'm willing to guess that even customers of a low-stakes SaaS would get pissed off if your product regularly turns up new bugs. I think it's easier to just do code reviews... | | |
| ▲ | hoppp 12 hours ago | parent [-] | | There are code reviews. At no point did I write no reviews, that's something you inferred. Both me and LLMs are constantly auditing software. In-fact auditing and QA is mainly what I do now and human audits become much easier when it's scoped to modules. |
|
| |
| ▲ | anal_reactor 11 hours ago | parent | prev [-] | | > I don't think there will ever be a way to "steer" an LLM such that it produces the correct output 100% of the time. You cannot do that with humans either. | | |
| ▲ | EPWN3D 11 hours ago | parent | next [-] | | The difference with humans is that you can incentivize them to try and do the right thing via money. Humans are error-prone and slow, but they don't have an alignment problem, and the types of mistakes they'll make are pretty much understood. There are entire programming languages designed to minimize those types of mistakes. The types of mistakes LLMs will
make are failures of alignment, that is, basically unpredictable. They could fuck up anything. Where a human fucks up by introducing a crash, the LLM fucks up by just not solving the problem you asked it to solve. It will happen less and less as they get better and better, but as the volume of software output keeps growing, it will happen with a consistent defect rate. And we won't be able to catch it prior to shipping, because humans won't be able to review all the code or verify all the tests. I don't think anyone's started taking this seriously yet. | | |
| ▲ | anal_reactor 9 hours ago | parent [-] | | > The difference with humans is that you can incentivize them to try and do the right thing via money. Gen Z has learned that usually, your dedication to work is not tied to the monetary reward. > Where a human fucks up by introducing a crash, the LLM fucks up by just not solving the problem you asked it to solve. Have you ever done a group work project at school? |
| |
| ▲ | bigstrat2003 2 hours ago | parent | prev [-] | | No, but humans are capable of learning and improving. LLMs are not. Humans also make mistakes at a much lower rate than LLMs do. | | |
| ▲ | senordevnyc 23 minutes ago | parent [-] | | Really? Because my LLMs have improved more in the last couple years than any human I’ve met, and while their skills are jagged (like all humans), they routinely exceed the best engineers I’ve worked with once speed and cost are taken into account (as they should be for any true engineering project). |
|
|
| |
| ▲ | insane_dreamer 8 hours ago | parent | prev [-] | | > If you architect well what you generate then it stops being slop the problem is that the "architect well" part is also being left to the LLMs |
| |
| ▲ | snapcaster 8 hours ago | parent | prev | next [-] | | [flagged] | |
| ▲ | greenowl 5 hours ago | parent | prev [-] | | Um, yes? That's exactly the strategy that most companies have adopted by now. Once you go 100% AI code generation, there's no going back. |
|
|
| ▲ | insane_dreamer 8 hours ago | parent | prev | next [-] |
| > Is it an issue? you could think that in the long term it'll be reminds me of all the PHP spaghetti code that would float around because it was "quick and easy" -- eventually that all becomes brittle and someone has to come in and rearchitect it from scratch you may not pay the price, but your successor will but then again, you could say that's your employer's problem, not yours (and you'd be right) the biggest problem is the future, not the present. Presently, we -- you, I, others -- still have the skill and experience to look inside the box and understand it, guide the LLM to make smarter decisions, etc. not only will those skills atrophy in ourselves, but the younger generation won't even develop them in the first place. eventually you have almost no one who understands anything about how things work, they just know how to issue high level commands. It's like if eventually everyone working at CERN just knows how to push the buttons on the LHC but doesn't understand much beyond that. That's where we are heading. |
|
| ▲ | mpalmer 7 hours ago | parent | prev | next [-] |
| Agents are decidedly not getting better at architecture by the day, but soon they'll be the best by default because we'll all be drooling idiots (speaking in terms of technical capability). |
| |
| ▲ | arm32 7 hours ago | parent [-] | | So the agents aren't getting smarter, but rather we're just getting dumber? | | |
| ▲ | mpalmer 7 hours ago | parent [-] | | Both, the former more slowly than the latter. Picture a foolish person falling out of a hot air balloon. "Gosh," they think, plummeting, "the balloon is going upwards SO fast!" | | |
| ▲ | skydhash 6 hours ago | parent [-] | | That reminds me of the usual argument by AI hypers: “it would have taken me days/weeks/years/… to learn and produce something by myself”.
They forget that often what you need to know can be learned quickly, it’s just mastering (solving the general case) that takes a long time. Learning the piano takes years, learning how to play “Happy birthday” can be done in a few minutes. |
|
|
|
|
| ▲ | titzer 13 hours ago | parent | prev | next [-] |
| > Is it an issue? you could think that in the long term it'll be This raises alarm bells. It's a deeply unserious take on software development that I hope doesn't spread (but I know will). YOLO it all. We absolutely will regret the slop AI, as it will become load-bearing (ahem) in short order. There will be critical outages and people will die. |
| |
|
| ▲ | zombot 13 hours ago | parent | prev [-] |
| Meanwhile overlooking all the strategic implications of handing off your production to an external service provider, with built-in total surveillance and industrial espionage. All the software shops are turning into lemmings. Running faster into the abyss is called increased productivity. Full speed ahead! |