upvote
While I agree with your sentiment, very strongly actually, there has always been a tension between what I'll call "engineering teams" and "product teams". The engineering teams want the long-term platform stability, performance, etc. The product teams want to push that new feature out, quick! The overall business needs both (types of thinking and doing) to survive, of course, but not all leadership sees the world through the lens engineering team lens. I'd argue most actually lean the other way, which is understandable though unfortunate. I'd also posit that since these product teams are often "closer to the business", those people typically win favor with the real decision makers.

These new tools only exacerbate this issue.

reply
This tension is why I refer to myself as a product engineer. Teams where non-technical product managers (ie. your "product team") become feature factories that eventually drown in their own tech debt. Teams where navel-gazing engineering managers (ie. your "engineering team") have too much power end up with premature platformization, and beautiful architecture diagrams while user needs go unmet.

The key is to understand that computers exist to serve human needs, and the less code / UI / hoops to solve a problem the better, and to think end-to-end. If you are able to do that, most systems built by committee have a lot of low-hanging fruit that can be improved without much sacrifice. In practice, political realities and operational concerns may come in the way, but I firmly believe this is the only way to successfully operate as an engineer, and it will only become more important in the age of AI.

reply
And I feel that stuff like agile is now even more important than before. Now it’s role should be more about protecting customers from bad changes and following whole processes through where you actually measure the impact. It’s just too easy to do those 100k lines changes to products because it’s some vice presidents pet project.
reply
deleted
reply
If you build your platform well, then you can execute fast, but also safe.

I push "money and data are sacred"; if we lose either of those, someone cries. Build the platform slow and fast. Governance, scaling etc sits here.

Provide reference APIs and let the product team one shot whatever they want and need, build fast and experimental, but your platform enforces constraints.

Best of both worlds (though feels like we're back in backend vs frontend development)

reply
>If you build your platform well, then you can execute fast, but also safe.

this is extremely true, but it seems less and less like anyone wants to invest in a solid platform and just wants to jump to executing fast and unsafe. and then pretends that ai can definitely do both when the experience is quite a bit different.

reply
I have seen at least one example develop in real time. You typically spent years building before you had a platform, then lack the enthusiasm from senior leadership to invest the next 12-18 months with no new features and hard to quantify - maybe no - returns. Then you get displaced by newcomers who are "platform native"; what this really means is their engineering misteps haven't been discovered yet, or even if they guessed correctly the world has turned and made their previously correct solution now a failing one. And now we have something called "AI-native" that is going to solve this once and for all with some sort of magic, and you can't lead these companies unless you truly believe in the magic.
reply
“ You typically spent years building before you had a platform, then lack the enthusiasm from senior leadership to invest the next 12-18 months with no new features and hard to quantify - maybe no - returns.” —> this is failure from the team and especially people who should do product management job on that team.
reply
I'm lucky I guess, I feel like the product team is on "my side" with respect to building a resilient system. They understand that bad architecture shows up as a fragmented and friction-full UX.

The demand for new features come from sales and executive people who want to check more boxes on a customer's checklist.

reply
Ultimately your paycheck exists through deals that involve those boxes on checklists. It doesn't simply materialize out of thin air. If there are no deals, it doesn't matter how robust and elegant the architecture is.
reply
Features don’t usually come from product teams. They come from above: some Head Of, VP Of, and the like. Those people only ask, they know very little about execution. They want their wishes come true in a timely manner
reply
They have been vibecoding via a harness of human LLMs this whole time.
reply
I think this is the key to some of this debate.

Management/Product/Product Engineer - When you are responsible for getting the work done then you look for any and every option to speed it up.

Owner/Platform/Senior Engineer - When you are responsible for ensuring it works and can be maintained then you have to pay attention to how to build it, aka the trade offs

reply
Well support teams are even closer to the customer than product and I think they would advocate for perf/stability over more features.
reply
How would that change when support teams themselves are replaced by LLM agents
reply
Any evidence that this can be done without terrible self-harm to the business?
reply
I've spent most of the past two weeks trying to get my AI to stop writing so goddamned much code. It's great that I can, say, completely switch between two databases, but I wish the AIs would develop a concept of energy spend or something and spend maybe a moment checking whether something is already implemented in the code base before blasting out 2000 new lines defining a new database access layer, and also rewriting random code it shouldn't be touching for some task hundreds of lines at a time just because it can. I don't care how easy it is to write some tests that sort of kind of cover it hopefully maybe... no new code is as tested as the stuff that has been doing it in the field for years already.

Just because it has the power doesn't mean it should be used.

I'm not asking for everything to be some sort of beautiful code whose concision would lead Knuth to tears. I'm just asking that you not slather dozens of existing functions with three new parameters and dozens of lines of code each that basically do nothing, to cover a use case that I accidentally vaguely alluded to, if you read my prompt a certain way, but isn't really what I was interested in.

reply
Totally agree but I suspect that our desires are in contrast with ai companies profits
reply
Right. There IS a way to convince ai to write less code.. but it obviously spends 10x tokens, whether it’s LLMs as judge and automated review or just write 10 solutions and keep 1. Partly ai companies like it this way but partly it’s unintentional consequences that happen to work in their favor.

Training for good taste in architecture actually causes premature optimization at high effort allowance, but at the same time, it is combined with an inability to even recognize / exploit that later if it should ever become actually useful. Dial the effort down, and it skips the reasonable abstraction and nothing is dry, factoring is insane.

Goldilocks for simple stuff barely works with frontier models after they are out of their comfort zone for topic or line limits.. you kind of just have to decide whether it’s worth it anyway. In practice.. constant supervision for high quality code, or such high quality system design that the code quality is less of a down side.

reply
One thing I've spotted several times throughout this year: the larger volume of code leads to exactly the sort of problems it always has. It just happens real fast now, with fewer people. Problems that used to take years to erupt now manifest before an MVP ships, but people just sweep it all under the rug in the name of moving fast.
reply
The rate at which software is produced has never been higher, nor has the rate at which it is thrown away for being broken and useless. It’s not at all obvious to me that if you control for both of those rate changes that the amount of useful software with a lifespan measured in years created per developer (ie, the software that actually has long term value) has actually changed all that much.
reply
I drastically improved the reliability of an internal IoT device so it can tolerate all kinds of abuse (abrupt power loss during update, unreliable SD card, bootstrapping over network when the SD card is missing/damaged, fail-safe updates, recovery in a network isolated environment). This is the first release that I really leaned into AI, having been pretty skeptical before.

I think AI has been a net positive and has been used responsibly at my work. It can be used to make existing products better and more secure. You just won't naturally hear about that. There's some challenges like emerging social mores but overall good.

reply
> I think AI has been a net positive and has been used responsibly at my work. It can be used to make existing products better and more secure. You just won't naturally hear about that. There's some challenges like emerging social mores but overall good.

It always works best when layering on top of good human code. The thing is, you start to run out of that as you lean in. Tricky.

reply
Heh, you should look at the reply I left for your sibling comment. I think it is just a regression to the mean of all open source software upon which the models were trained. Sometimes the mean is an improvement.

Hell, if the Dunning–Kruger effect is to be believed, it would be bold me to assume I am capable of good human code. Maybe the average is the best I'll ever get.

reply
> The thing is, you start to run out of that as you lean in. Tricky.

I think it depends how you lean in. I generated a few thousand lines of Rust code today. It was actually pretty high quality. On my initial review, I only identified one change I wanted to make.

Most functions were pretty short and well factored. I wonder if using Rust as a target helps, because (1) the training data doesn't include all the terrible Javascript and Python etc. found on the internet, and (2) Rust and many of its libraries encourage good architecture - code factored into traits, functional pipelines, a powerful type system, etc.

LLMs trained on bad code for mediocre languages naturally write corresponding quality code.

A big part of it still boils down to prompting - what you're asking it to do and how much freedom you give them. If you let them make all the architectural decisions, you're likely to end up with issues.

reply
> It can be used to make existing products better and more secure. You just won't naturally hear about that.

Why? I keep asking for examples of LLM being used to make code more simple and elegant (which I would say is adjacent to making software better, if not more secure), and never get a reply, not a single one. I'm not claiming it doesn't exist, I know it must exist. If only via a lots of careful massaging of system prompts and harnesses, even if it takes too much effort to be worth it, I would like to see it.

Of course people can't share internal examples, but this is all over the world for many months now, where are the open source examples? Not "something new someone couldn't have done before", but someone making their precious even neater (while also adding things to it, but not primarily). Put differently, can LLM delete code, can they curate it well, can they not write weird comments nobody wants or needs, that sound like echoes of the user prompts and responses to them, but just explain tricky parts of the code, like a human would?

Also, IMO a VERY useful thing to learn about a tool or a chemical or whatever is, "what happens if I keep applying it to the same small thing over and over?" -- because that's the level of scientist I never evolved past, the kind of stuff you do as a kid -- , whereas a lot of this seems to be more about how it feels to apply it here and there until it looks good, and then move on and never look back. Which really isn't much at all, especially given we're such a short time in. I mean, how useful were mugs made of lead? Are people aware of the (in hindsight) insane things that were done with x-rays as those were invented, before the potential for harm was known? I bet they had a great time playing with that stuff, for a while.

What if in 5 years it turns out that a few years ago, LLM got into this habit of implementing certain things in a certain way because it seemed the best to "them" (the training, whatever), but there's a security issue with that -- what do you do? You can only let more agents loose, and hope they don't miss anything, because you cannot even do something like "patch PHP" (which is not my thought, Casey Muratori mentioned that in on of those podcast things).

Fully leaning into LLM doing as much of the coding and understanding as can be handed off to them seems insane to me, I don't mean this to offend though. It just does, like suggesting we go to Mars, because everything is better there, and to do that, we have to blow up Earth. Or saying to magically be able to fly from now on, we need to saw off the branch we're sitting on. Even if I thought life on Mars was the future or that we could fly, if we just thought of it the right way, this isn't a way forward IMO.

reply
> LLM being used to make code more simple and elegant

Simple and elegant generally doesn't come from the LLM. It comes from me saying no to the LLM. I've discarded many branches that didn't feel like they were going the right way. Hell, I aggressively do that with my own code also. I rarely commit the first thing that works.

> where are the open source examples?

My general impression of open source is that it is, in part, a market driven by good software engineering. There's certainly below average code, but that tends to get mocked out of existence before it grows too much. Proprietary code that doesn't have a strong forcing function used to be able to hide poor engineering principles.

I think AI generated code is a regression to the mean, and the mean can be an improvement sometimes. I inherited this project. It was not originally written with AI. A lot of hard work and good engineering went into the hardware/firmware. The IoT software connecting it to our intranet, less so. Some examples that I'm fixing/fixed: ignoring HTTPS certificates, RCE by design, in-place file updating JSON files, a hand-rolled (but ineffective) fair mutex, busy waiting for a device to appear, and worst of all, no tests. None of these are hard to avoid, and even the small AI models would have come up with a better implementation.

This doesn't seem unique to my project either. I think a lot of software is just silently getting closer to the average of all open source code upon which the models were trained. I don't think I want things like SQLite to get closer to the average.

> Fully leaning into LLM doing as much of the coding and understanding as can be handed off to them seems insane to me, I don't mean this to offend though.

I think you might be reading too much into what I said. When I say "fully lean into", it's probably less than you're thinking of. I still feel that I understand what was written and can stake my reputation/career on it.

reply
You want them to make code more simple and elegant by themselves, no other direction? "Make this code simple and elegant, no mistakes, no hallucinations"? I don't think that's realistic at the moment.

But with suitable direction, they can definitely improve codebases - especially a typical enterprise codebase, which, if you don't like LLM code, you would hate with a passion. (I can only assume you've never seen such code otherwise your perspective would be different.)

> Fully leaning into LLM doing as much of the coding and understanding as can be handed off to them seems insane to me, I don't mean this to offend though.

I essentially agree, but there's a huge spectrum before you get to that point, and lots of ways to use it effectively that doesn't create tech debt.

reply
> You want them to make code more simple and elegant by themselves, no other direction?

No, he wants a project where AI is used as a major help, but the result tend towards good code, i.e readable and well abstracted. Even if the cost is high, just an example where you can extract the best practices of using AI coding.

reply
You are responding to someone that just today generated thousands of lines of code, claims to have reviewed it all, thought it was good and only wanted one minor change. Surely they have an example of the good code it produces.
reply
> claims to have reviewed it all

I specifically wrote an "initial review".

The code in question was split into modules, the largest of which was about 500 lines. Overall, the quality was higher than a lot of unaided human code that I've reviewed.

That code is greenfield code, so doesn't fit what was being requested above. But here's an example that illustrates the point I mentioned about functional pipelines:

    cmd_kw("spatial_context")
        .or(cmd_kw("spatial"))
        .padded_by(ws())
        .then_ignore(just('(').padded_by(ws()))
        .then(group.separated_by(just('|').padded_by(ws())).at_least(1))
        .then_ignore(just(')').padded_by(ws()))
        .map(|((), groups)| Statement::SpatialContext(groups))
        .labelled("spatial_context command")
        .boxed()
This particular fragment is parsing input using the Chumsky parser combinator library. That imposes a structure that has to be followed. It's all heavily type-driven, which means that it's naturally structured as type cases, where each case handler is pretty small. The longest one in this code is around 20 lines, but most are more like 5 lines or so.

As a result, the modules, functions, and case handlers naturally follow the single responsibility principle. This makes it easy to review. Again, this goes to the points I made in my other comment - if you give a model a good type schema, have it use good libraries in a good language, so that it has a well-structured framework in which to operate, you're likely to get good results.

Perhaps a simpler way to describe it is the old saying, "garbage in, garbage out". If you're vibe coding, say, PHP you're much less likely to get the same quality results.

reply
As we all know, LOC as a metric has been around for ages, usually pushed by managers who don't understand development wanting some indicator that you are working hard.

It's no surprise that the same people are now using the same metric against LLMs except this time the LLM isn't telling them it's a daft measurement.

reply
We used to understand that code was harder to read than it is to write. It follows, directly, that better engineering discipline means shipping LESS code. Less to support, less to understand, means a product that is easier to maintain and extend.

Now, token calculators spew out code at a pace no human can match, which completely removes the barrier of effort - which was one of the largest natural counters to shipping massive amounts of slop.

I'll be impressed by a coding model when it writes less code than a human, and spends more time refactoring than it does just adding new layers. Until then, this vibecoding is just madness.

reply
You have to get the agent to refactor it doesnt spontaneously do it.
reply
Idk imo code is and has always been a liability. Like the toilet paper bear says "less is more"
reply
1. The issue is that most people and organizations do not care about maintenance. Maintenance doesn’t get you the promotion, accolades, or immediate quarterly revenue because great maintenance tends to be invisible.

2. This is exacerbated by the lack of loyalty people have towards their organizations because their orgs don’t value or reward loyalty. That’s because leadership doesnt care about the long term view because of item #1. Hence, everyone is only doing short 1 - 4 year stints in order to get meaningful raises

3. The exceptions in the private sector are businesses that not publicly traded.

4. Even then, very few people care about quality that no one else can see

reply
I think you are overcorrecting. LOC is highly correlated with productive output. I’m willing to bet on it.
reply
agree 100%

it really isn't a flex ppl think it is when they're burning tokens churning agents that are working for "hours" doing work

we don't need to read or write code anymore, but we do need to write (as humans) the instructions for agents.

having ADRs, product specs, acceptance criteria, etc. that are properly maintained leads to agents working for just a few minutes and pumping out reliable code.

the more vague the work for agents, the more randomness and inefficiency there will be. that leads to bugs, constantly re-writing code, etc.

imo ofc, i'm not yet running a billion dollar company so maybe i'm wrong.

reply
Can you please point me to any project based around spec-driven development with agents which has worked well long-term, ideally one that isn't another agentic devleopment tool?
reply
i would second this. at $company they are jumping head-first into this and its not going well at all...
reply