"you" lost? Did this guy you're replying to run for office? This whole my team vs your team bullshit is really one of the big problems in our country. No independent thought. Just stick with what news says. Always vote my team. Dumb. Here's a news bulletin for you, everybody lost.
I think people not being able to vote because their right to vote has been taken from them, or their vote was made pointless through gerrymandering, or because of other acts of voter suppression does change elections. The ability for it to change the outcome of a race is why voter suppression happens.
People who don't bother to vote for any reason changes elections. It also makes it very hard to make claims about what the majority of Americans want, since so many didn't make their opinions known
In my experience in Texas, the right-wingers have this system set up where votes that were legally cast can be denied validity by some sort of "citizens election integrity board." I had no issue voting in Travis County but when I moved to a more conservative suburban county address I ran into this. There's a multitude of ways for anti-democratic forces in the US to deny citizens their rights. And it really hardened my opinion of these sorts of people that would do that to me and others. If they say my rights aren't valid how valid are their own, certainly nothing I should respect given their treatment of myself and others. That's why I have no tolerance for the right-wing I've seen their real face.
First you must accept that engineering elegance != market value. Only certain applications and business models need the crème de le crème of engineers.
LLM has been hollowing out the mid and lower end of engineering. But has not eroded highest end. Otherwise all the LLM companies wouldn’t pay for talent, they’d just use their own LLM.
I'm going to give an example of a software with multiple processes.
Humans can imagine scenarios where a process can break. Claude can also do it, but only when the breakage happens from inside the process and if you specify it. It can not identify future issues from a separate process unless you specifically describe that external process, the fact that it could interact with our original process and the ways in which it can interact.
Identifying these are the skills of a developer, you could say you can document all these cases and let the agent do the coding. But here's the kicker, you only get to know these issues once you started coding them by hand. You go through the variables and function calls and suddenly remember a process elsewhere changes or depends on these values.
Unit tests could catch them in a decently architected system, but those tests needs to be defined by the one coding it. Also if the architect himself is using AI, because why not, it's doomed from the start.
So, your point is that programmers identify the unexpected edge cases through the act of taking their time writing the code by hand. From my experience, it takes a proficient developer to actually plan their code around future issues from separate processes.
I think that it's mistaken to think that reasoning while writing the code is at all a good way to truly understand what your code is doing. (Without implying that you shouldn't write it by hand or reason about it.) You need to debug and test it thoroughly either way, and basically be as sceptical of your own output as you'd be of any other person's output.
Thinking that writing the code makes you understand it better can cause more issues than thinking that even if you write the code, you don't really know what it's doing. You are merely typing out the code based on what you think it should be doing, and reasoning against that hypothesis. Of course, you can be better or worse at constructing the correct mental model from the get go, and keep updating it in the right direction while writing the code. But it's a slippery slope, because it can also go the other way around.
A lot of bugs that take unreasonably long for junior-mid level engineers to find, seem to happen because: They trust their own mental model of the code too much without verifying it thoroughly, create a hypothesis for the bug in their own head without verifying it thoroughly, then get lost trying to reason about a made up version of whatever is causing the bug only to come to the conclusion that their original hypothesis was completely wrong.
> From my experience, it takes a proficient developer to actually plan their code around future issues from separate processes.
And it takes even more experience to know when not to spend time on that.
Way too many codebases are optimised to 1M DAU and see like 100 users for the first year. All that time optimising and handling edge cases could've been spent on delivering features that bring in more users and thus more money.
I keep hearing this but I don’t understand. If inelegant code means more bugs that are harder to fix later, that translates into negative business value. You won’t see it right away which is probably where this sentiment is coming from, but it will absolutely catch up to you.
Elegant code isn’t just for looks. It’s code that can still adapt weeks, months, years after it has shipped and created “business value”.
It's a trade-off. The gnarly thing is that you're trading immediate benefits for higher maintenance costs and decreased reliability over time, which makes it a tempting one to keep taking. Sure, there will be negative business value, but later, and right now you can look good by landing the features quicker. It's FAFO with potentially many reporting quarters between the FA and the FO.
This trade-off predates LLMs by decades. I've been fortunate to have a good and fruitful career being the person companies hire when they're running out of road down which to kick the can, so my opinion there may not be universal, mind you.
Sometimes "elegance" just makes shit hard to read.
Write boring code[0], don't go for elegance or cool language features. Be as boring and simple as possible, repeat yourself if it makes the flow clearer than extracting an operation to a common library or function.
This is the code that "adapts" and can be fixed 3 years after the elegant coder has left for another greenfield unicorn where they can use the latest paradigms.
People sometimes conflate inelegance with buggy code, where the market fit and value matter more than code elegance. Bugs still are not acceptable even in your MVP. Actually I think buggy software especially if those bugs destroy user experience, will kill products. It’s not 2010 anymore. There are a lot of less buggy software out there and attention spans are narrower than before.
> I keep hearing this but I don’t understand. If inelegant code means more bugs that are harder to fix later, that translates into negative business value.
That's a rather short-sighted opinion. Ask yourself how "inelegant code" find it's way into a codebase, even with working code review processes.
The answer more often than not is what's typically referred to as tech debt driven development. Meaning, sometimes a hacky solution with glaring failure modes left unaddressed is all it takes to deliver a major feature in a short development cycle. Once the feature is out, it becomes less pressing to pay off that tech debt because the risk was already assumed and the business value was already created.
Later you stumble upon a weird bug in your hacky solution. Is that bug negative business value?
You not only stumble upon a weird bug in your hacky solution that takes engineering weeks to debug, but your interfaces are fragile so feature velocity drops (bugs reproduce and unless you address reproduction rate you end up fixing bugs only) and things are so tightly coupled that every two line change is now multi-week rewrite.
Look at e.g. facebook. That site has not shipped a feature in years and every time they ship something it takes years to make it stable again. A year or so ago facebook recognized that decades of fighting abuse led them nowhere and instead of fixing the technical side they just modified policies to openly allow fake accounts :D Facebook is 99% moltbook bot-to-bot trafic at this point and they cannot do anything about it.
Ironically, this is a good argument against code quality: if you manage to become large enough to become a monopoly, you can afford to fix tech debt later. In reality, there is one unicorn for every ten thousand of startups that crumbled under their own technical debt.
> You not only stumble upon a weird bug in your hacky solution that takes engineering weeks to debug, but your interfaces are fragile so feature velocity drops (bugs reproduce and unless you address reproduction rate you end up fixing bugs only) and things are so tightly coupled that every two line change is now multi-week rewrite.
I don't think you fully grasp the issue you're discussing. Things don't happen in a vacuum, and your hypothetical "fragile interfaces" that you frame as being a problem are more often than not a lauded solution to quickly deliver a major feature.
The calling card of junior developers is looking at a project and complaining it's shit. Competent engineers understand tradeoffs and the importance of creating and managing technical debt.
This has always been true. I just don’t see how AI makes accumulating tech debt more attractive, as the original poster seems to be implying. If anything it seems to make things worse. At least when you write shit code by hand you know it so you can remember to go back to it, keep it in mind as a potential source of bugs. But YOLO from AI and you probably have no idea.
> Competent engineers understand tradeoffs and the importance of creating and managing technical debt.
I would disagree on the engineering point, as this ultimately falls on project management. Yes, engineers should provide professional expertise, but if management decides to yolo then engineers do not have the capacity to remove tech debt, regardless of their competence. Management of technical debt is, at the end of the day, managing short term versus long term velocity.
> Things don't happen in a vacuum, and your hypothetical "fragile interfaces" that you frame as being a problem are more often than not a lauded solution to quickly deliver a major feature.
Nothing I said disagrees with this, however that quick delivery of a major feature has downstream effect: anything that touches said feature is harder / slower / error-prone to implement. The more the team embraces "move fast and break things" the harder the wall it hits. Slower teams tend to be consistently average. Neither is better and this competence in managing technical debt is more often than not coupling/decoupling over fragile/robust interfaces.
This shows in LLM coding assistant use. Drop them in a well structured codebase and they implement features relatively well. Drop them in a bowl of spaghetti and they hurt themselves over confusion. With LLM coding assistants becoming more prevalent this managing of tech debt becomes even more important topic. You just cannot tell the LLM "pls implement well, no tech debt bro" or "yolo this, move fast, make it work 80% of the time".
If my career has taught me anything is that it takes competent engineering to push back against management pushing for every possible shortcut. A worry here is that detachment from the final output will reduce buy-in and produce "bad" code that will eventually grind feature velocity to a halt.
Of course a bug is negative business value. Perhaps the benefit of shipping faster was worth the cost of introducing bugs, but that doesn't make it not a cost.
Because the entire codebase is crap, each user encounters a different bug. So now all your customers are mad, but they’re all mad for different reasons, and support is powerless to do anything about it. The problems pile up but they’re can’t be solved without a competent rewrite. This is a bad place to be.
And at some level of sloppiness you can get load bearing bugs, where there’s an unknown amount of behavior that’s dependent on core logic being dead wrong. Yes, I’ve encountered that one…
Once you gain some professional experience working with software development, you'll understand that that's exactly how it goes.
I think you are failing to understand the "soft" in "software". Changing software is trivial. All software has bugs, but the only ones being worked on are those which are a) deemed worthy of being worked on, b) have customer impact.
> So now all your customers are mad, but they’re all mad for different reasons, and support is powerless to do anything about it.
That's not how it works. You are somehow assuming software isn't maintained. What do you think software developers do for a living?
Nothing I just described was hypothetical. I’ve been the developer on the rewrite crew, the EM determining if there’s anything to salvage, and the client with a list of critical bugs that aren’t getting fixed and ultimately killed the contract.
If you haven’t seen anything reach that level of tech debt with active clients, well, lucky you.
If you can see the future and know no-one will ever encounter it, maybe not. But in the real world you presumably think there's some risk (unless no-one is using this codebase at all - but in that case the whole thing has negative business value, since it's incurring some cost and providing no benefit).
Well, it takes time to assess and adapt, and large organizations need more time than smaller ones. We will see.
In my experience the limiting factor is doing the right choices. I've got a costumer with the usual backlog of features. There are some very important issues in the backlog that stay in the backlog and are never picked for a sprint. We're doing small bug fixes, but the big ones. We're doing new features that are in part useless because of the outstanding bugs that prevent customers from fully using them. AI can make us code faster but nobody is using it to sort issues for importance.
> nobody is using it to sort issues for importance
True, and I'd add the reminder that AI doesn't care. When it makes mistakes it pretends to be sorry.
Simulated emotion is dangerous IMHO, it can lead to undeserved trust. I always tell AI to never say my name, and never use exclamation points or simulated emotion. "Be the cold imperfect calculator that you are."
When it was giving me complements for noticing things it failed to, I had to put a stop to that. Very dangerous. When business decisions or important technical decisions are made by an entity that literally is incapable of caring, but instead pretends to like a sociopath, that's when trouble brews.
LLM has been hollowing out the mid and lower end of engineering. But has not eroded highest end. Otherwise all the LLM companies wouldn’t pay for talent, they’d just use their own LLM.
The talent isn't used for writing code anymore though. They're used for directing, which an LLM isn't very good at since it has limited real world experience, interacting with other humans, and goals.
OpenAI has said they're slowing down hiring drastically because their models are making them that much more productive. Codex itself is being built by Codex. Same with Claude Code.
Source: Trust me, bro. A company selling an AI model telling others their AI model is so good that it's building itself. What could possibly motivate them to say that?
Remember a few years ago when Sam Altman said we had to pause AI development for 6 months because otherwise we would have the singularity and it would end the world? Yeah, about that...
Based on my experience using Claude opus 4.5, it doesn't really even get functionality correct. It'll get scaffolding stuff right if you tell it exactly what you want but as soon as you tell it to do testing and features it ranges from mediocre to worse than useless.
Electricity prices are set by the marginal producer, which in the UK a lot of the time means gas turbines which are expensive to run. Which mainly means that the renewables plants are making money hand over fist, creating a big push to create more. It's only once that percentage grows enough that the price pressure will go downwards in general. (currently the UK is roughly an even split between gas turbines, nuclear/biomass, and renewables). You can already take advantage of the low price of renewables in some cases, though, if you have a flexible tariff and electricity demand (like a water heater, a house battery, or charging an EV), by drawing when the gas turbines are not necessary to meet demand.
The interesting part is that 130 Billion of the savings were in reduced gas prices as it reduced demand, particularly in winter, and freed up gas storage.
And this is depsite an effective ban on constructing onshore wind in England from June 2015, more than half the 2010 to 2023 time period studied.
The exact moment you charge for something, you need payment processing, a bank, a legal entity to hold said processed funds, you have liability, you need some sort of marketing / sales process (even if it's just copy on a website), and the barrier for someone to use your product is suddenly extremely high, simply because it costs something.
Release it for free, no barrier to entry, no legal liability, the entire world can use it instantly. This is why free software spreads and catches on - precisely because it's free.
There is no way to form a business around FOSS without becoming a gatekeeping high-barrier entity. You can release for free then charge extra for consulting or special features, which many have done and continue to experiment with.
But the core reason why FOSS spreads and took over is precisely why it is difficult to fund. No one is going to pay for something when the alternative is free. And the moment you start to charge some free alternative comes along and your prior users spurn you as greedy
The code can become "radioactive" as well when a software library goes paid. It starts phoning home with information about its environment to ensure compliance which is just kinda... icky to most devs. I certainly don't want that bloat in my dependencies.
This is an upfront cost and is possibly a one-time cost per-agreement.
Practically nobody downloads and installs sudo directly from the project website; people install it with their distribution of choice. The agreement could be automated and included in the licensing process. ie: the license gives specific distributions access to the software (either via paid or other agreed-upon terms appropriate to the distribution) and perhaps individual licensing terms for non-commercial entities.
Of course, the bigger ask in this decade is in use for training LLMs. OSS shouldn't be laundered through an LLM (IMHO) for license avoidance. Maybe some projects are OK with that (eg: many BSD licensed works.) There are some that likely aren't.
> The exact moment you charge for something, you need payment processing, a bank, a legal entity to hold said processed funds, you have liability, you need some sort of marketing / sales process (even if it's just copy on a website),
That seems like an area that's ripe for innovation. What does it take to get setup on a platform like Patreon? Seems like something similar ought to be setup for open source/independent development, probably an idealistic nonprofit.
> and the barrier for someone to use your product is suddenly extremely high, simply because it costs something.
All the organizations who really ought to pay are already setup to do all that, and do it all the time.
> But the core reason why FOSS spreads and took over is precisely why it is difficult to fund. No one is going to pay for something when the alternative is free. And the moment you start to charge some free alternative comes along and your prior users spurn you as greedy
What we need is innovation. Maybe a license that has a trip-wire? If not enough money is voluntarily deposited into a tip jar over a certain period of time, the license requires a modest payment from all for-profit organizations of a particular size.
That's up-front, is for the most part free, and incentivizes some payment.
I think you have good arguments, but I wonder if there are alternatives that could work in at least some cases. Like, how Unreal engine's license works. Source-available to game developers, but in theory limited to paying customers, or something along those lines.
Lexapro made me feel like I was randomly being dropped down an elevator shaft for 6 months after I stopped taking it. I’m glad it worked for you, and am not minimizing that, but these medications have a side effects profile a mile long and should be a therapy of last resort in my opinion.
The problem with antidepressants are that while we know, more or less, what they do, we don't know why they work for some and not for others. Escitalopram (Lexapro) was a vast improvement for me over Citalopram. Then it plateaued and a year later, left me anhedonic. Tried an SNRI that would give me brain zaps every day a few hours before my next dose and it was horrendous to quit using. It also messed with my ability to meditate for a long while. Basically, I could put myself in a mental state that would trigger the same kind of painful brain zaps that withdrawal from the SNRI caused.
I can't go so far as to say it saved my life, but I'm part of that cohort of 10% of men who develop postpartum depression. Taking a small dosage of Lexapro had zero side effects for me and helped me deal with not just the anxiety and depression I was experiencing but also a lot of pre-existing anxious behavior that I didn't even realize was abnormal.
Huge quality of life improvement. 10/10 would medicate again.
The problem is not coding (for me). The problem is thinking for a long time about what to code, then the execution is merely the side effect of my thinking. The LLM has helped me execute faster. Is not a silver bullet, and I do review the outputs carefully. But I won’t pretend it hasn’t made me much more productive.
I am old but C is similarly improved by LLM. Build system, boilerplate, syscalls, potential memory leaks. It will be OK when the Linux graybeards die because new people can come up to speed much more quickly
The thing is LLM-assisted C is still memory unsafe and almost certainly has undefined behaviour; the LLM might catch some low hanging fruit memory problems but you can never be confident that it's caught them all. So it doesn't really leave you any better off in the ways that matter.
Technology is just a lever for humanity. Really would like an AI butler, but I guess that's too hard (?). So many things AI could do to make my life better, but instead the world is supposedly over because it can summarize articles, write passable essays, and generate some amount of source code. In truth we haven't even scratched the surface, there is infinite new work to be done, infinite new businesses, infinite existing and new desires to satisfy.
reply