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.
> The vast majority of people are not going to bother, regardless of how low the bar to entry is, because time is not free.
You need a certain amount of thinking capacity at the user end to be able to understand, plan and envision a semi-complex functional software, regardless of who will produce it.
But those people who doesn't slop their app them self seem to let their llms install appslop from github en masse. At least that's what I conclude after looking at some recent 50k+ star repositories.
I tried building an obsidian clone. God it was hard. Had to spell every little thing. I suppose that's because Obsidian source code was not in the training set
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.
It's also worth pointing out how many businesses have always had a dev team that can rapidly prototype regardless of AI usage.
They tend to be the largest businesses (outside of SV) that employ the majority of people in the USA. They are also the least likely to really use AI for much other than copilot in MS Teams.
I have spent the better part of the last decade of my career being approached by executives asking me how to optimize or automate away services that I felt had reached a local optimum. Each time this was the case I would gently express that our options were to commodify, by offering a kind of template, the service or optimize the process and way we gathered information from clients. Without fail, they hated the latter option. It was hard to do, and it implied that any number of people needed to do a lot better at their job in seemingly abstract ways. No, they’d always go for the template, then be dissatisfied by the fact that it’s, well, a template! Finally, they’d go back to begging me for alternatives.
This feels like them doubling down yet again. It’s like looking at your personal finances and trying to optimize it by canceling Netflix instead of acknowledging that you eat out 7 days a week.
Spot on. Generative AI is an amplifier of your current trajectory, and a good side effect of that is that it exposes inefficient internal processes. As a company, it will be increasingly hard to go for the naïve and easy solution (the template) when the blockers are clearly visible.
One of my mantras is:
Automate governance first, creation second. Streamline code reviews and compliance before content generation, or you'll drown in manual oversight.
And this is not what people want to hear, because generating content is easy and automating governance (code reviews, build the domain knowledge into skills and automated processes) is a _real_ and hard engineering problem.
Thank you for your reply.
Yes, we could all work a bit more effectively cross-team. It's missing the point to focus on the "what" and the "doing" instead of the "why" and the "planning".
If there are some people who need AI training wheels to help plan, I think that strongly signals some kind of dysfunction. They are rehearsing how to talk to another team? Sounds unprofessional and inexperienced.
LLMs actually raise the bar and resulting demand for experienced workers. Most programmers with more than about 5 years are not the bottleneck. It's all the auxiliary people that are supposed to be coordinating, but don't know their ass from their elbow.
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.
It’s fascinating to me how polished these things can look now. Years ago I recall reading a story of some consultant or new team member remarking how strange it is to start at a company, be given a tour of the codebases, and eventually find some awkward aspect of the architecture no one could really explain the reason for that had slipped under the radar for years. This feels like that but multiplied by a thousand.
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.
TFA responds to exactly this: the state that accumulated in those 3-5 years is what cannot be thrown away.
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.
OK, I'll bite. What, in your opinion is happening? What should we be doing instead?
HA! I'm of the belief that it is impossible to predict other than it's going to keep improving.
If you read this essay, you see quickly that his implicit assumption is that this is now the way things will remain. It is literally insane, given what we are seeing.
> What should we be doing instead?
I have no idea. No one does. This is a runaway train.
I guess being out of control is so intolerable to some people that their minds will not accept it.
Those who have knowledge, don't predict. Those who predict, don't have knowledge.
— Lao Tzu
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.
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.
Product design also becomes more important. You can build a new UX every day but your userbase can only handle a new UX or two every year, so creating and validating good ideas and strategies becomes more valuable.
According to doomers, the userbase will be AI too.
Or just entrepreneurs - people willing to take a risk to build something, and effort to promote / sell / hustle. They have always done well as a group, and now they are likely to shine even more.
(I am empathically not one of those so times are getting even more interesting for me :)