You seem like a person who works at a place that doesn't have an AI mandate. That sounds nice. I miss when we had nice things in the world like that. I will never take that for granted again.

Velocity implies direction, AI is just speed sans direction, AI only workflows are just really fast brownian motion centred on training corpus mean for a task. Humans can give it direction, how good that direction is depends on human expertise.

We still need the humans, there are no cases for novel useful work I can think of, or have seen, where humans are no longer required.

As we have seem with offshoring, any company whose main business isn't producing software, isn't coming back in-house, even if the quality for engineering team themselves sucks.

> velocity should never be a first-class concern

Some people have not learned that velocity at small scale without global synchronisation is just thermal agitation.

To the boardroom class, employees are tools as well.

> Speed should only come as a side-effect of quality.

"Slow is smooth, smooth is fast."

- US Navy SEALs

who would have thought :)

The word "lesson" implies that there'll be some learning involved in the process. I got your joke, right?

Nah, that’s the future executives problem, the current executive gets to brag about how their AI integrations cut costs while maintaining an acceptable yet enshittified quality

The article has named sources for its quotes, whereas your comment relies entirely on "almost certainly" which sounds a lot less informed.

> This has nothing to do with LLMs and instead is almost certainly about their MAIVIS and AiTriz pilots

Where does this article say otherwise?

Change engineers to employees and you’re spot on.

I think this may be a US thing. Fords built in Europe are pretty decent. Reliable (compared with most other makes), cheap parts and ubiquitous servicing. I've bought Fords (in the UK) for about the last 20 years and have in the main been very satisfied.

It's impressive all the recall notices I get on my 2020 Escape Hybrid. At this point I joke with my friends that they're love-letters from Ford.

(most of them are for fairly innocuous stuff...)

(As a non American) I remember hearing a joke that goes something like “How do you fix a Chevrolette? Buy a Ford”, but nowadays I guess a bike is a better option

Ebbs and flows with these companies. If you got used to driving in the 70s then the FORD meme was “Fix Or Repair Daily”.

If a company is saying “X is job one” it’s because they suck at X. They sucked at quality. They still suck at quality.

Really? Ford’s quality in the last half of the 1990s was the poster child of cheap, vac-form plastics.

The same Ford whose bean counters caused them decades of reputational damage over skimping on rust protection? Seems like they haven't learned any lessons at all.

Hard to say exactly what went wrong from outside, but a frontier model not being able to implement a simple CRUD feature after 3x8 = 24 hours of work isn't "it can't do this". Let me hazard a guess from what you wrote. The 3-tier spec (design → specs → build details) may be the cause rather than the cure. A big upfront spec has two failure modes the model can't help you with: it can quietly contain contradictions, and it can be ambiguous in ways the model resolves by guessing instead of asking. "Adding clients" is a good example of the trap, even assuming your real spec was more detailed than the comment. "Client" is overloaded — a customer in the domain? An API client? A consumer of a service? And "A clear design requirement was essentially adding clients" is very imprecise: does the model add them, or build a UI so the end user can add them? I know this was just your comment and sorry to sound harsh but if the spec had sentences like that I can definitely see it going off the rails.

Your own conclusion, smaller, concrete units, is the right direction. Except by units I don't mean partitioing the program into smaller units (files, modules). In fact, you should stop thinking about implementation at all. I'm thinking more about the way of asking the LLM to build it. One feature at a time etc. so you can tighten the feedback loop. Then you can early on (in the first hour say): "I also need a way that the user can add/manage clients - basic CRUD" and that small sentence might be enough the model makes it all (UI, API, backend etc.) to enable that and put it in a proper place in the app. A big ambiguous spec defers that discovery to the worst possible moment.

> I haven't managed to really figure out what's the best way

For you, the best way is to break your code down into modules insofar as possible, so that you don't overrun the context window. Opus Max starts forgetting things the minute it begins compressing your conversation -- and multiple compressions can make for gaps in memory.

I find that it's also important to have another model serve as review/critique. I use Opus Max for code and 5.5 Pro for immediate code review. The latter will often pick up on things that might have been missed, and will usually provide good suggestions.

> there were multiple 'please check its all done' separate agent runs/checks

You could ask it to go through the spec point by point and then mark what is done and WHERE/WHY, then it'd point you towards exactly what might be missing.

Why not?

Self-driving cars may have a control agent at the HQ that places car orders as needed.

The dystopian future where no one owns cars is already being laid.

Cars are more and more becoming white goods appliances with the driving experience becoming less and less a priority. Even enthusiast cars now are about raw numbers and need electronics to reign them in to make useable for the average driver on the average road.

The average user probably doesn’t even want to drive and have AI do it for them.

Repairability is becoming less viable as mechanical parts replaced with screens and digital locks. Parts availability is already an issue, only going to get worse especially with the pace of new cars are being churned out from China.

The end will be car as a subscription. We already have it with leasing, and BMW having to pay to use your electric seats.

Not yet perhaps.

The article is not about generative AI at all.

The best people are the least likely to come back, and going through all of that will surely impact productivity.

Just two days ago at work a call of 15+ people spent a non-trivial amount of time recounting the scars of colleagues being laid off, or they themselves having to sign severance papers, only to be saved in the final hours. These events happened 10-15 years ago and they still cost the company time a decade later, not to mention that trust that erodes with these events.

If companies want people to focus on work, those people need to feel secure in their jobs. Laying them off and hiring them back is not job security. It’s a signal that management has no idea what they’re doing. Why would these people follow the leadership of those who can’t even solve the issue of staffing without making a mess of it?

It’s also bad when seemingly competent employees are laid off while incompetent ones stick around. It sends a signal that it doesn’t matter what you do, so why try.

Tune your bot, this is the 3rd time (at least) you've duped this dupe and deleted. You still have this:

https://news.ycombinator.com/item?id=48704222

American tech is basically a sales machine. An ounce of tech will be coated with a ton of selling force. Everything in America is a business, presentation or a talk-show - including government, education, relationships. People do selling and faking to themselves sometimes.

The value of the ai firms isn’t in building a useful tool to increase productivity of your staff by 20%. It’s not an electric drill.

It’s to replace 99% of your staff. In every industry.

Ai will be a useful tool, but either companies like OpenAI are massively overvalued or the economy will completely vanish at a high speed and their valuation will be meaningless.