Hacker News Reader

Comment by loloquwowndueo | Hacker News Reader

> is this going to let me grow the way I need it to in the future

This doesn’t matter in the age of AI - when you get a new requirement just tell the AI to fulfill it and the old requirements (perhaps backed by a decent test suite?) and let it figure out the details, up to and including totally trashing the old implementation and creating an entirely new one from scratch that matches all the requirements.

For performance, give the AI a benchmark and let it figure it out as well. You can create teams of agents each coming up with an implementation and killing the ones that don’t make the cut.

Or so goes the gospel in the age of AI. I’m being totally sarcastic, I don’t believe in AI coding

View on HN

> including totally trashing the old implementation and creating an entirely new one from scratch that matches all the requirements

Let me guess, you've never worked in a real production environment?

When your software supports 8, 9, 10 or more zeroes of revenue, "trash the old and create new" are just about the scariest words you can say. There's people relying on this code that you've never even heard of.

Really good post about why AI is a poor fit in software environments where nobody even knows the full requirements: https://www.linkedin.com/pulse/production-telemetry-spec-sur...

I work on a product that meets your criteria. We can't fix a class of defects because once we ship, customers will depend upon that behavior and changing is very expensive and takes years to deprecate and age out. So we are stuck with what we ship and need to be very careful about what we release.

That's why I find any effort to create specifications... cute. In brownfield software, more often than not, the code _is_ the specification.

But if you start from the beginning with a code base that is always only generated from a spec, presumably as the tools improve you'd be able to grow to a big industrial-grade app that is 100% based on a spec.

The question is how many giant apps out there have yet to be even started vs. how many brownfield apps out there that will outlive all of us.

If the spec covers 100% of the code paths, then yes, you're right. But now spec and code are entirely redundant. Changing the spec or changing the code takes the same effort.

If the spec doesn't specify all the details, then there are gaps for the code to fill. For example, code for a UI is highly specific, down to the last pixel. A spec might say "a dialog with two buttons, labelled OK and cancel". That dialog would look different every time the spec is reimplemented.

Unless of course, there was also a spec for the dialog, that we could refer to in the other spec? That's really just code and reuse.

This might be the "Steve, Don't Eat It!" version of the xkcd workflow comic.

Whatever you ship, steve will eat, and some steves will develop an addiction.

> When your software supports 8, 9, 10 or more zeroes of revenue, "trash the old and create new" are just about the scariest words you can say. There's people relying on this code that you've never even heard of.

Well, now it'll take them 5 minutes to rewrite their code to work around your change.

That will be after it broke, which costs money

Also: no

> Well, now it'll take them 5 minutes to rewrite their code to work around your change

You misunderstand. It will take them 2 years to retrain 5000 people on the new process across hundreds of locations. In some fields, whole new college-level certifications courses will have to be created.

In my specific experience it’s just a few dozen (maybe 100) people doing the manual process on top of our software and it takes weeks for everyone to get used to any significant change.

We still have people using pages that we deprecated a year ago. Nobody can figure out who they are or what they’re missing on the new pages we built

Ask AI about a strategy and tools to build to figure out.

Great now you have a strategy (one less MBA to hire). You still need to do the strategy.

The doing is where most of the time goes. Strategy docs are cheap, my intern can give you 5 of those by tomorrow.

> You misunderstand. It will take them 2 years to retrain 5000 people on the new process across hundreds of locations. In some fields, whole new college-level certifications courses will have to be created.

Replace them by AI.

I’m still being sarcastic.

> Let me guess, you've never worked in a real production environment?

The comment to which you're responding includes a note at the end that the commenter is being sarcastic. Perhaps that wasn't in the comment when you responded to it.

It wasn’t thanks for highlighting. Can be hard to tell online because there’s a lot of people genuinely suggesting everyone should build their own software on the fly

If the amount of code corporations produce goes even 2x there's gonna be a lot of jobs for us to fix every company's JIRA implementation because the c-suite is full of morons.

> Or so goes the gospel in the age of AI. I’m being totally sarcastic, I don’t believe in AI coding

You may think you are being sarcastic, but I guarantee that a significant percentage of developers think that both the following are true:

a) They will never need to write code again, and

b) They are some special snowflake that will still remain employed.

I don't agree with your first point. We are surely writing less code, and it will keep getting less and less. At some point it will reduce to a single run function that will make the universe and everything work and it will be called via a button, and that will be the modern definition of writing code: Click the button. Not a lot of keys with weird alphabet thingies on them.

You are however right on your second point because I'm damn good at clicking buttons.

it isn't gospel, it's perspective. if you care about the code, it's obviously bonkers. if you care about the product... code doesn't matter - it's just a means to an end. there's an intersection of both views in places where code actually is the product - the foundational building blocks of today's computing software infrastructure like kernels, low level libraries, cryptography, etc. - but your typical 'uber for cat pictures' saas business cares about none of this.

If you care about the product, you double-so-much care about code correctness and the alignment with the expectations of the stakeholders.

So you're an auto maker, you say you can care about your product but not care how is built?

If you're building for the cheapest segment of the market, just maybe. Anything else is a hard no imho

Yes? If you’re an auto factory, you might care, but an auto maker cares about minimizing cost and maximizing revenue within the regulatory constraints. Nowhere is there a requirement to care about how the car is built, there are requirements on what the car can and cannot do.

Caring about the requirements on what the car can and cannot do sounds suspiciously like caring about how it's built when you consider how it's built directly impacts what it can and cannot do.

Not al all, it’s what vs how, completely different beasts. How is for engineers to solve, but the business sells the what.

Branding is a thing, you know. Especially if you want to sell the high margin cars.

Reply on news.ycombinator.com