Building quality software with LLMs is still very time-consuming. The vast majority of people are not going to bother, regardless of how low the bar to entry is, because time is not free. That and making software is not interesting to most people, for the same reason assembling electronics is not interesting to most people. It's a niche interest with limited mass appeal. For those two reasons, the software profession will survive AI.

This problem is not new. The new thing is that anyone can understand the core problem they’re trying to solve without involving a dev team by quick ideation and rapid prototyping.

Just as always, it’s then up to the company to prioritize what to focus on - Just like how it’s always been.

* Don't hold onto an idea or prompt output just because you spent time on it.

* Writing code is easy. Maintaining it is hard.

* If it doesn’t save time or generate revenue, it’s just an expense.

* Output does not equal value.

I feel it's more nuanced than this, at least for now.

It's true to say anyone can build software, but that doesn't make the software good and it's not true to say that's specifically reliant on taste.

As an example I am working with an Entrepreneur right now who has no coding experience but have successfully made a product which they have also already sold to a mid sized company.

However without my involvement and knowing the right levers to craft the AI the software just wasn't performing how it needed to despite the latest frontier models trying their hardest to achieve what he was stating.

At least for now there's still a need for experienced devs.

We (my company) have a corporate LoB ‘base’ which has, collected over the odd 40 years, any process you could imagine and using that we just look at large corps to their processes and offer to automate, on departmental level so they don’t need board approval nor IT dep approval to pay for it. SOTA AI can do this in a day or two with our base, almost on its own and we charge just below the departmental budgets for it. We have to send in nasty sarcastic ‘project managers/sales guys’ to the many meetings as of course these middle managers want to be seen as useful so these meetings are objectively useless to us but required misery anyway. They (meatspace meetings) are of course now far more expensive than the (just) tech part, even if you value the framework at some $ licensing and SLA cost.

These corps, and they are mostly multinationals, mostly owned by US, IN or CN owners and literally all their IT deps absolutely stink; stuck on Java or C# from 20 years ago with 0 incentive to improve or learn anything; they heard about AI but don’t use it for anything.

This is gravy train, worth billions in whatever region if you manage to get in at the right level. Not sure it will last as, in my experience, most of these people in those departments can be replaced by a LLM running on an iPhone today and LoB apps are pretty boring if you have one solid consultant who has a few decades knowledge; they must be training LLMs to do just that?

I'm somewhat confused. Its an interesting posting but I'm not sure if I understood exactly where he was going with his "policy as code". He concludes "policy-as-code produce enterprise coherence with no central architecture function" to which I would agree but argue that he misses that today there is a lack of infrastructure / company as code. At least if you want to have an agent being able to solve or at least aware of the problems he begun with. Like the policies define the boundaries of our working environment but doesnt the work itself. This "know how" is mostly implicit for people but invisible to llms and limits the context frame in which the agent operates to its given prompt (and maybe restrained by the policies if they're in the context).

Like if I take his example: "Front-line staff may be skipping mandatory fields because the process adds fifteen minutes of friction to every customer interaction." First it's unclear whats the policy for those fields are when they are mandatory and also can be skipped. Then why are those mandatory if skipping them seems only lower friction with no other consequences? How should a model decide if it should enforce the policy for those fields, code an automation or just make them voluntary?

"Years later the line of business asked for longitudinal reporting, cross-domain aggregation, and planning. The tool integrated with nothing, extended to nothing, had no underlying data platform, could not scale, and had to be rebuilt from scratch."

Any project that takes 2 weeks effort and lasts years (since it doesn't say how many, I read it as 3-5) delivering value is a win. That it needed to be thrown away? That's a couple of people out sick.

Vibe coding is expensive. It eats tokens, which costs your org dearly.

You can't just do what you want - you have to choose and use your brain to decide, with metrics, what's worth doing.

Also, code things yourself. It's free, uses your brain, exercises your skills, and makes you look 10 steps ahead of your AI slopping coworkers.

Keeping features out was important when the complexity burden of that feature would be borne by the entire user base. Restricting features is much less important (or even an anti-pattern) when software is more bespoke, or even has a userbase of just 1.

It seems like the author is pitching topological teams and responsible engineer concepts, sprinkled with decision governance.

None of that is really new, but it’s the chaos of silos, narrow decision frames and lack of detailed understanding by decision makers which probably accentuates the adoption of new concepts.

Microsoft, Google, Apple. I.e walled garden owners.

I love how every one of these "how do we cope now" essays makes the assumption that the progress has now stopped, and what we currently have is what needs to be adapted to.

Humanity really does not want to look at what is happening.

The market decides as it does for everything else.

>When almost anyone can build software, the organizations that win will not be the ones that build the most

It's not possible to A/B test a huge amount of software. The sample size of the real world is not that big.

Market

Taste.

Delusional.

Let me illustrate with a similarly dumb question:

When anyone can buy legal forms from an office supply store or make photocopies from books, why pay for a lawyer and who decides what needs a contract anyway?

That was likely a real question that got some debate in the 20th century only further compounded by the internet by the end of that century. Guess what? We still have lawyers.

I think creative analysts may have a brighter future than programmers. When almost anyone can build software, the real skill shifts from knowing how to build something to understanding what is worth building in the first place. Creativity, judgement, curiosity and the ability to see consequences may become far more valuable than simply being able to write code.