You just replaced ns memory accesses by ms API calls. Just the moment people were starting to maybe start thinking about performances again this train-wreck of power wastefulness had to appear.
Build a well architected monolith and be super strict on single purpose and keeping modules separated from each other.
Isn’t the question how to keep likely dependent modules separated from each other in a monolith? You say “single purpose”, but how does that admonition work in the reality of a complex problem domain?
check shikigami.dev - free to use - not a vc baked, indie product
> I also want to be clear that while there are sane and normal people who use these things, they’re mostly drowned out by a crowd of people that oscillate between bootlicking and regurgitating capitalist mythology in a way that makes it hard to trust anybody who spends significant amounts of time using an LLM.
> One thing you’ll notice about the most moistened AI boosters is that they lack much degree of pride in their work. Everything they say must, at some point, compliment the mindless, unprofitable, unreliable tool underneath it — how “incredibly powerful” it is, how it’s “only getting better,” how it’s “only the beginning” of something that’s eaten over a trillion dollars and absorbed the majority of venture capital.
Ed Zitron. The Revenge of the business idiot.
https://www.wheresyoured.at/the-revenge-of-the-business-idio...
That is, the code should be correct but also idiomatic.
Staying on top of work done across many teams is going to be a huge challenge for larger companies and it's going to cause them to organize and hire very differently. Getting this wrong means teams diverge much quicker than they used to and everything gets misaligned much quicker. Some team might launch a product before some other team that was considering to do a similar thing is even aware that is happening. As most engineers might appreciate, the easiest way to tackle complexity is to just work on cohesiveness and coupling. Small teams with few dependencies working on a coherent thing will be much more effective than large orgs with a lot of inter team coupling and no coherent plan.
I'm in my fifties so, I've been around for a while. I currently work in a very small company (3 people) so I'm used to doing things by myself. I also used to work in traditional teams inside large multinationals. Very different game. You spend non trivial amounts of time communicating with people in big organizations. And you basically only get responsibility for a tiny amount of functionality. I had to learn a lot after I left the safety of a big organization. When everything is your problem, you need to skill up in a hurry to deal with all the challenges effectively.
In my current role, I do basically everything vaguely technical. And non technical as well. And it is more than ever since AI coding entered the mix last year. I stopped referring to myself as a backend person. Because I also do UI, devops, websites, IT infrastructure, etc. And a bit of sales, marketing, etc. I'd add management but we're such a small team that I suffer a little from impostor syndrome on that front. But I can do the job if I need to.
I had a whole hiring plan that I developed three years ago that we never executed on. It had all the traditional dev team roles spelled out. That plan is obsolete. These roles will probably never be filled. I need different people though. I need more people like me that can do everything I do when I'm not around and people with complementary skills that are strong where I'm weak. But I have much less need for specialists. I mainly need generalists with attention to detail that can deliver complete working products and systems. I might want a product focused person but not a dedicated product manager. If you can specify it in an issue tracker, you can learn to prompt an AI as well. But I still need a good product plan and roadmap. In the same way, I expect designers to shape UI work directly and not via a separate UI team. I expect them to own the front end experience and drive it. I still need people that are strong in these roles. But not exclusively. Good small teams have less people than all the traditional roles you find in larger traditional teams. That calls for people with overlapping skills that can put on different hats as needed that complement each other.
But I can do this like what, once or twice? Maybe once every release? Then my agents finish "improving performance" and it's Monday 10am. What the fuck I'm supposed to do the rest of the week?
Agents aren't very good at carrying the entire model in their context, so when they reason about a small piece of code, they often come up with something that hurts other parts of the code (especially as the KLOCs pile up). The complexity hasn't been replaced, only moved. And guess what's going to happen when all of these microservices become even more of a moving target than they already are?
AI is capable of improving productivity, but this approach sounds more like a nightmare in the making.
That does not mean we're all going back to artisanally hand-crafting software. That's never going to happen.
Right now you can open Claude Code in your project and prompt it "start a workflow that fans out subagents, each with a narrow scope, to look for {simplifications, correctness by construction opportunities, <insert your goal>} ranked by impact vs confidence, and then collate the findings into result.md". If you have the tokens, do more workflows that find more issues and/or vet and polish the findings already in the file.
I do that every time my weekly usage is about the reset to spend me last tokens.
Maintenance is becoming trivial, and anyone who thinks AI dooms you to an ever growing mudball apparently hasn't considered using AI for anything other than appending more code to the mudball.
The moment you do that, why even bother producing a result.md? Just let the Bot execute on its findings, you realistically won't be able to judge them anyway.
My current theory I might test out is to treat generative AI as generative AI. This means instead of editing things like a microservice in place you version freeze them to bug fixes only and create new versions for new features. This way you can go and update all the places that use the old version to the new version one at a time. As you do you can check that the new version does not break anything while still having an old version to fall back to.
The ripple effects are basically the same as what you'd get in a monolithic codebase. In fact you can still think of a set of microservices as a single codebase, just not centrally maintained anymore. The complexity is moved rather than eliminated. And you'll still have agents (and people) stepping on each other if there's too little coordination.
They still make up some whole product that presumably does something as a whole that you actually care about, and the complexity inherent to that doesn't go away with either approach.
With micro services, that same function call is now a minimum of 200us. And now I have LOC for serialization/deserialization, retries, error handling, etc, bloating my code and making it harder to understand, plus now to do the same integration test I need to understand N different build systems for each component.
In a monolith it's significantly easier to do something that has an unexpected impact somewhere else. For example, changing a shared object a singleton to a clone will give you race conditions all over the place. You just don't have that footgun in micro services.
That is way too close to monkeys on typewriters for comfort.
10 people generating 800 commits a day is completely stupid.
I mean at this stage people don’t even know what they’re building anymore. They’ll burn through their backlog faster than the backlog can be filled.
Or maybe they spend 700 commits fixing the issues generated by the first 100?
This doesn’t make any sense to me
It really does not, honestly.
What’s the point if you’re treating the whole system as a slop bucket?
It will just be computing new geometric states and syncing them to the screen.
Incidentally not having devs save endless copies of their dev tools and languages will save a bunch of electricity; storing and copying that stuff around uses a lot of electricity.
Software engineers who want to be taken as experts in their craft need to understand the chip makers are experts in theirs all the same. They’re not leaving your concerns about correctness, efficiency, and stability unconsidered.
Almost offensive for non-experts in hardware dev to continue to insinuate no one but SaaS devs have any idea how computers work.
> best weapon against complexity spirit demon is magic word: "no"
In counterpoint, I believe small teams can remain small. Small teams can ship simple monoliths with high velocity, commit count, and quality. Service orientation didn’t suddenly become low-cost because of agents; the boundaries between multiple services that version and deploy independently are still tricky beasts to wrangle. And it’s not clear why “running more agents” is inherently desirable or impactful; my small team’s (admittedly anecdotal) experience is that the value quickly saturates.
Only the seniors who know their systems are keeping the lights on today by keeping bs commits out.
Once they burnout and quit, nobody will have a freaking clue what the LLMs have done and why services are down.
But this is also essentially blogspam. The author intentionally includes two screenshots which add absolutely nothing to their point and which are too small to read. When you click the second one, you are not taken to a larger version, you are taken to the frontpage of his company website which features the same screenshot.
A good way I've found, since I do a lot of OSS and have my own libraries, when I find a bug in one of those libraries I can work on the same project on the main window while fixing the library on another window. I normally need to tell the main one "let's skip this for now, I'm fixing the library" meanwhile or similarly.
Have you tried t3 code? It creates a separate worktree per agent, which makes running multiple agents at once much easier.
Microservices are WAY harder to coordinate for deployments. You end up with feature service dependencies, and you are back to the same coordination, but now harder to discover down stream dependencies..
But in truth, all the projects with microservices I have seen in real life had deployment coordination problems, and looked to me like distributed monoliths. So maybe it's a 'no true scotsman' thing. Maybe they are always, or at least most of the time, harder.
Makes it harder to justify using them.
I doubt it. This seems to conflate code modularity with service modularity. Moving complexity from the codebase into operations is counterintuitive to at least the way I use LLMs.
> The more modular your code, the more agents you can run
OK, but why would I want to run more agents? So I can be more productive? What does this productivity lead to? And are we actually being more productive? Take a look at Bun's repo on GitHub which seems to be fully automated. Well over 5000 PRs open.
What's the use? How can we justify these 5000 PRs? Over the past years, software has become considerably more shit. Are these 5000 PRs improving the quality of software?
Is the end-user reaping the rewards? Are they getting better software, cheaper?
The answer to all of those is going to be "no".
And let's take Uber for example. They have many teams, and many more times the services. Has ride hailing become cheaper? No. Has it become more efficient? No.
Nothing is getting better, but at least we're all off worse!
1. LLMs perform best with tight, focused context.
2. Encapsulating specific well-defined functionality into a single service, tool or API inherently limits the amount of code it requires, and hence the context an LLM requires to reason about it. The smaller the codebase, the better an LLM will do with it.
3. Code is already increasingly written by swarms of agents that tend to step on each others' toes, and hence a way of isolating them would be great.
4. Combining the 3 points and taking them to the logical conclusion, we end up with nano-services.
It's basically the Unix philosophy, just scaled up to distributed systems. For all its other issues, the core philosophy worked pretty well for Unix tools, so it should work well for nano-services too.
Currently the "pipes" between these services are network calls, but they need not be. One could imagine an architecture where these components are composed either as direct function calls or remote network calls depending on access patterns and resource requirements for a given instance. Never worked with Elixir but I think that might fit the bill?
Maybe every sufficiently complicated distributed system will end up re-inventing an ad hoc, informally-specified, bug-ridden, slow implementation of half of Elixir.
You will have conflicts during parallel work if people are changing features that are related. You will also get these conflicts with a microservice architecture and hundreds of independent repos, but now it is not a merge conflict because you touched the same syntax, it is a semantic conflict.
And didn't Uber also have a famously slow and convoluted CI pipeline where it took an enormous amount of time and resources to build anything?
- satisfying the needs of parallel agentic development is wholly aligned with the optimal DevSecOps CI/CS/CD WhateverTerm models out there. And that's rad, bc a lot of orgs have a reference frame to map to.
- microservices, monoliths, monorepos, mammoths, whatever.. The code and services can be structured however, so long as the release capabilities are modular and governable/manageable/auditable/flexible/transparent/etc. A killer workflow allows for tight independent releases, but not chaotic, with proper add'l structure/scaffolding to satisfy that list above. Microservices and smaller repos can help with the context window bit initially, but you can rig up and kind of local llm-focused setup to allow for selective context and holistic context (across N repos or N projs within monorepo)
- strategy: use the robots to fix the problems in your PDLC/CICD/ABC so that the robots can help you out more, and keep iterating on that
I think if you want to see delivery speed up focusing on what a team can own is more relevant than if you have merge conflicts.
Who the fuck is writing the requirements in that story?! Setting aside the problem of pushing AI-generated code that nobody has read straight to production, the reason why you're pushing code to production in the first place is to implement a product that is solving a problem for your users. And the problem I have with the hypothethical workflow described above is: How is any product owner supposed to come up with hundreds of feature or improvement requests a week?
The point isn’t to serve customers anymore, it’s to use AI for AI sake because investors want, because they have FOMO.
I’m only half joking. I have seen PMs attempting that and getting fired. The investor thing is 100% true.
It has an overhead but as scaling the amount of people was worth it there was an advantage.
Where did this work: where the interfaces between those groups of people were agreed upon.
A team could call: finance->billTrip(TripObject) via an API and the finance team became independent. The micro services had an API which was documented. They could move from Stripe to SAP to a custom solution internally without bothering the other teams.
Now we have AI.
Those interfaces are still needed. But is there still an advantage to hard separating those interfaces in real micro services, with separate databases for each team, over http or other protocols?
On some point it may. A service which needs to scale unlimited (like RenderThumbnails with hundreds of thousands of call per day) might have that. But if you send out 1000 invoices per day it might not be needed for that at all.
In Rails they have active job for it for example. Same codebase but a scalable worker for longer running jobs.
AI is capable of quickly keeping function calls consistent internally. So a hard coded API is way less useful now for those services which don’t need the scale. An interface could suffice just fine. No human would ever read the finance API anyway.
Keeping consistency in the monolith part is way easier. That is statically testable, quicker testable and there are plenty of tools. All disadvantages on micro services on those calls are just a waste.
One thing where I think hard boundaries are useful is on really blocking AI coding tools. With microservices you are able to physically prevent Claude or others to modify the other interfaces. That way it prevents hallucinations, quick fixes and other workarounds the tools like to do. Just because an AI wants to get sometime done it will sometimes skip corners.
I see that as a current state which will be fixed quite soon. The models and their harnesses will become increasingly better in preventing stupid corner cutting to get the fix out.
When that is done: why would you want more complexity with micro services instead of less?
Instead of we all implementing microservices and other structures we should get the harnesses right to respect interfaces and boundaries.
And in the micro services era we had meetings to sync the API’s between them. So maybe the AI’s should meet about the interfaces, with a good coffee.
Is was successful because I didn't use any sort of LLM assistance.
The out-of-control factor = the number of parallel working agents : the number of human programmers.
1. If the factor > N, you're losing control and there will be no organizational wisdom passed down.
2. If your team can't function with the factor <= N, your architecture is way too complex.
Choose N over your prior. My recommendation is 1.
I have a similar concern, though. To do my job, I need to understand "the thing". I could outsource the understanding process to AI, but then if I'm asked a question by a developer or tester then I'm essentially stumped / useless because I didn't spend the time to understand the thing, I handballed it.
So I then ask the LLM the question I was asked, and pass the answer back (they could have done this themselves though, so where does that leave me? I'm either an AI wrangler, or replaced by someone else who wrangles AI replacing mutliple people in my role). Does my personally understanding the thing actually add value - do the seniors who know their systems add value - in the age of AI/LLM?
Does "LLMs all the way down" solve the problems?
With the existence of hallucinations I lean towards 'no', but again is that solved by adding layer(s) of LLMs to check for hallucinations?
One added value I see in senior knowing how things work is simple - in case of outage or business incidents (caused by incorrect logic produced by LLMs from even worse prompts or incomplete spec) senior can act faster and answer difficult questions live. Now we are going to have bunch of kids looking at „Hallucinating…” and „Crashing the prod…” status bar in CC CLI.
Maybe this is what’s gonna be acceptable and it’s just new world.
Layoffs pushed over the cliff the company. Both due to engineering (content is now trash), and product (lost most of the ad revenue)
Metrics like pr count and commits have always been terrible gauges for success compared to business performance.
But they're easy to measure, and even easier to game now with AI.
So we're seeing an outrageous gain on these metrics, and they've become almost completely divorced from business results.
No one cares how fast you ship prs. They care that you offer a compelling product, that works when they need it work, for a price they're able and willing to pay.
It's like we've decided to measure how far we've traveled in gallons of gas burned, but completely forgotten about measuring miles per gallon.
Or forgotten to look at the map to see if we're getting closer to our destination.
I've never seen a consumer bugs that complains about how small our codebase is or how little PRs we have produced this month. It's always about some features not working properly.
Previously the core metrics were reducing consumer complaints and implementing features for the sales team to attract new clients. Then they suddenly got replaced by amount of PRs and token usages.
Notice how difficult it is to turn off photo bursts in iPhone? Because that free cloud space needs to be filled fast. So ask your question again and you will find the answer very rapidly. They even gave it a cool name, "tokenmaxxing" what even the fuck.
1. Dependency on some outsourced LLM vendors (no Internet? No API response? Welp, you do you.);
2. Undefined amount of payments/paid subscriptions at vendors;
3. Undefined amount of tokens burnt on each prompt/iteration within undisclosed algorithms;
4. Absolutely no responsibility/copyright for the LLM output;
5. Privacy concerns on inside/company project source code uploaded;
6. Incremental eventual atrophy of developer's own skills;
7. Inhuman attitude for art, development, effort, purpose in general, since the models are built on stolen effort of other, now unknown, people...I agree that these companies' products were fully mature prior to usable coding agents in late 2025, so I don't understand why they would require a large volume of code changes beyond minor promotions and localization enhancements. I would expect their challenges to be in the ML, data, storage, capacity, and compute infrastructure areas.
Some people operate like little boys. They want the BIG RED TRUCK. They haven't considered that's it's really hard to park and gets 5MPG, or that their use cases don't involve fighting fires (for which they are not trained), but they want the big red truck so they can drive the big red truck.
Anyway, if you go the 5000 microservices route, you move all your problems from the application layer into networking and orchestration problems. Best of luck with that.
Humans are way more creative at social cohesion when you remove oligarchs and authoritarians.
software used outside of nerd niches? photoshop, canva, clickup, after effects and unreal engine over feh, imagemagick, impressive, emacs org mode, ffmpeg CLI and pico-8?
It’s going to be very successful, because I used all sorts of LLM assistance (and because it’s adding onto a successful app that’s been shipping for two years).
There’s absolutely no way that I could have managed this scale, on my own.
There will be examples of both success and failure, with LLMs.
What approach are you taking? I'm about to start a mithril.js project, was always under the impression it was the most efficient approach. Are you doing something similar or different or are you referring to WASM?
Here is an example of a template used to render a list of events.
const EventItem = () => {
EventItem.eventTime = (eventData) =>{
if(eventData.isRecurring){
return `${eventData.dayOfWeek}s at ${eventData.nextEventTime}`;
}
return `${eventData.nextEventDate} at ${eventData.nextEventTime}`
}
EventItem.url = (eventData) => {
return `/html/groups/event.html?id=${eventData.eventId}&groupId=${eventData.groupId}`
}
EventItem.location = (eventData)=>{
return `${convertLocationDataForDisplay(eventData.eventLocation)}`
}
return `
<li>
<a
class="btn secondary"
{{href=url}}
{{eventName}}
>
</a>
<div
class="event-time"
{{eventTime}}
>
</div>
<div
class="event-location"
{{location}}
>
</div>
</li>
`;
}
BaseDynamicComponent.defineTemplate(EventItem,"EventItem");
<ul
data-array=data
data-template-name=EventItem
></ul> export default function component(render) {
const $dom = xxxx
render($dom);
}
It’s not hard to be faster than React while exposing broadly similar functionality. If you’re making something for your own usage only, it’s even easier to beat it.
I think what you describe is a lack of harness/infra/process around working with agents on a project. No effort to document ADRs. No effort to document invariants. No effort to design processes that ensure maintainable software even if it were five years ago and only humans were writing the code.
Just because you delegate important decisions to AI doesn't obsolete practices as trivial as maintaining a log of potential issues in your codebase that you'd want to work through, keep track of, and verify.
This is a bad idea - you’re actively contributing to the problem by hiding the negative effects.
Don’t even think about starting that work until you’ve created bug tickets for as much of it as you can, and bright then to management’s attention. Management then needs to figure out priorities for doing that work and whether a change in approach is needed.
There was enough there; I missed it.
Also, I'm planning to release my changes as a framework that can be used for a variety of interactive websites.
I plan to publish an updated version soon.
With a lot of discipline and process control, one could make such a system work, but it's most definitely not a free lunch. The complexity has to go somewhere.
The bigger problem now is handling the AI mistakes and failures, not slogging through all the steps of a refactor. So having a full and complete ready to go fallback version with like Blue / Green deploys might be really helpful. But to do that you need discrete versions, not digging through diffs to find the problem and redeploy.
But this is all just a theory I haven't tested right now.
Someone has to deal with them, but if you are dealing with all of them then you don't really have microservices, just a multi-process monolith.
At the end of the day, it comes down to:
- how far does the data have to travel, and at what cost?
- how much latency can your process tolerate?
- how much unreliability can your process tolerate?
- where and how do you isolate resources that are concurrency sensitive?
- what's the infrastructure going to cost?
I recommend putting time into figuring out the "soft infrastructure" of your projects, usually things you've never been arsed to do in your life (like me until this year).
Start with a docs/*.md folder that you link to from AGENTS.md where you can document things that would be important for you, any human, and especially AI to know. Start with a super basic ADR system where you document invariants over time, maybe a single DESIGN.md file that just lists them. Have a references/ directory that shallow clone all of the important deps you use for local agent reference (and tell the agents about them in AGENTS.md). Keep your plan files to higher level things like invariants, decisions, accepted risks, rejected ideas, that way you review the hard stuff, and sota models these days write crazy-good code.
Look at using AI as a skill that you have to learn and develop, not like how we see CSS where it's the technology's fault if we suck at it for life while putting zero effort into developing the skillset.
Or maybe there's some load bearing "make impossible states unrepresentable" platitude in my AGENTS.md I'm overlooking that's responsible for why I have such a great experience with AI and nobody else on HN apparently is.
I do the same as you. I actively want to succeed with it, and therefore put time into making it work, and I have a good experience. As do the other 80+ developers at my company (it is a fintech). Pretty much every commit is written by claude currently, but I have to steer it constantly, and keep tweaking my setup.
I think the difference is probably that some people just don't really like the idea, therefore put in the minimum of effort, see that results are sub-optimal (which they definitely can be), and declare it useless.
See https://designmd.ai/ for examples.
The point, of course, is that you need some way to document decisions and pivots and eurekas (including rejected ones) over the lifetime of the project. It's a key part of invariant discovery and then committing to them.
We can notice that you're describing the work, but not any result that have derived it from it. I can explain to someone how to learn vim and tmux, but the best argument is to explain the benefits of doing so. I can't just say, take two weeks of your time and wait for the results.
I've been on HN seeing all kinds of comments like yours that promote spending more for tools (time and money) but never expand on WHY I should even do that or what's the proven benefits of doing so.
It applies the same idea specifically to visual design, making things like typography, spacing, colors, layouts, and component patterns explicit and reusable. You can use the existing examples as a starting point or contribute your own.
They are contemplating a lifetime of devalued skills, because they can see that prompting a model is an unskilled task.
Yes skills are going to be devalued, but that isn't happening yet for the vast majority. So its not really apt for them to think this way.
I'd suggest you need better education.
> Prompting isn't unskilled.
That's not what the AI firms are selling.
I've been prompting a bit on a hobby project that sort of boils down to MechE. It's far from my domain of expertise but I've recognized enough BS and been sent down some rabbit holes all too frequently to discover the BS at the end.
I get that SWE get far higher benefit than maybe everyone else, but who is it actively reducing QoL for?
The difficulty in adopting this belief lies in the fact we have multiple points of reference in the past, of visionaries claiming that "this time is different" and we reached the end of history... and well, the rest is history.
It is in fact normal for new technologies to be adopted, and for there to be no cycle where the technology just disappears. There was no Internet winter or railroad winter, not in the same way there was an AI winter where AI just went away.
Those technologies had valuation bubbles but the technologies themselves stuck around and changed the world beyond recognition. If someone sees the rate of change and thinks it'll stop for...some reason, then they're the ones who believe things are different this time.
I 100% agree that "AI" is not going anywhere as long as humans are here (I wouldn't be building a company in the space otherwise).
I'm challenging this specific absolute certainty that "a swarm of agents building code like ants" will be living in eternal summer. This paradigm might be completely different just 6 months from now, from all we know!
In fact there's almost nothing similar between my day to day life and the day to day life even of my grandfather, to say nothing of the Irish peasantry I came from 500 years ago, say. The number of correct everything-is-differences per year seems to be going up, not down.
Smartphones, internet, PCs, computers, semiconductors, relativity, antibiotics, telegraph, printing, electricity, steam power, …
It has stayed comms and compute summer since the end of the twentieth century. It has stayed infection summer since the beginning of the twentieth century. You get the idea.
Let's wait for Anthropic's S-1 to see if this is actually true.
Fundamentally, if Anthropic ain't profitable with all the investment and usage they get, then it's possible that it may not be economical to train new models in the future (I agree that inference for already trained models makes money, but the real question is if this money will pay for the cost of training & employees).
I don't have any clever argument to justify this, you just have to look at the ways the world is changing today and decide for yourself whether there is a clean historical analog.
Are you telling it's shit now? I'm just curious.
Programming will never go back to what it was before 2026.
Of course programming never stands still. I don’t think anyone thinks it will rewind. But your second sentence is very odd.
Your extraordinary claim may reflect life in certain companies in SV in the grip of AI Psychosis, but most companies are evaluating these tools objectively - they are certainly not ready to perform as agents or replace humans, and it is debateable whether they are providing much efficiency boost in the case where you try to replace humans writing code entirely - there are definitely significant downsides - loc inflation, lack of context, incorrect code which appears correct, wasted time, burnout of supervising humans having to read the output etc etc.
All the thought leaders like this article jumping to the shining future of independent agents cooperating under light human supervision are vastly premature - LLMs are nowhere near intelligent or independent enough for that.
My experience with LLM assisted coding is that I need a technical hand on the steering wheel to get something workable out it. Otherwise, what comes out is a brittle, non-functional mess that only in the most tenuous way resembles what I had in mind.
The job was never to type the code out. The job was always to take a problem in the real world, and shape it into a model which can be implemented in software. What LLMs do not do is to architect a system of suitable complexity to the scope of the problem. If you give a low skill worker the job of writing the prompts you will first get a prototype. Then a prototype with more features tacked on. Then a prototype with so many features tacked on that it breaks under its own weight.
Software engineers know system design, and can adapt the system design to the scope of the problem. Are we creating a single piece which will eventually expand into a big system, we need to design completely differently from if we are creating a robust stand-alone thing, which just needs to do one thing and do that one thing really well.
If anything, we will need stricter skill requirements for software engineers. Just because anyone can produce code which runs now, does not mean we should let anyone loose on creating the critical software infrastructure of our society.
And the models won't ever learn distributed systems?
You're basing your assumptions on the current status quo. The models only started getting useful in December, and so we just assume that's where progress ends?
The models are coming for all aspects of software. Schema design, distributed systems, SRE, ... They're not going to stop getting better. Especially when so much value creation and cost cutting is possible.
You assume the contraction of software engineering has peaked. I'm saying it's only getting started.
The skills we have aren't special or particularly hard. They're just boring and mundane enough that they're only attractive to a certain subset of the population. Most people would die if they sat in front of a computer for as long as we do. The demand for our skills has outstripped the labor pool. That's why we've been highly compensated, not because what we do is difficult.
The march of progress will continue, and it's a good thing. It might hurt us to no longer have in demand skills, but the world will be better off as a whole.
The important thing will be knowing what to build and how to market it. That's a totally different skill.
"Typing" the code was never the whole job, and it can be the easiest part. But "the code" is very much the artifact that is used to generate values. It being correct and easy to maintain lower the associated costs and MAY raise its value. It being brittle and hard to maintain raise the associated costs and WILL lower its value.
So being good at system design is how you target the first case.
On the other hand, "you're a prompt engineer or you're fired" just reeks of psychosis. Things will change, they will never be the same, perhaps the profession will contract. But there sure as hell will still be people thinking deeply about their code and crafting it.
Your hypothesis that your job is secure because the models hit a ceiling is based on seven months of observational history.
We've been watching the models get progressively better for years now. It's not going to stop in place.
In some amount of time from now, these models will absolutely require less hand holding.
It's as though everyone with your perspective isn't looking at the overall trend line. You're laser focused on just these last few months.
In just these seven months since Claude got good, I'm at $5M annualized at 65% MoM growth with 30% margins and plenty of opportunity to take that to 70%+. As a dev team of essentially one.
You're in a new game. Stop thinking with preconceived notions and take full advantage of it.
There are going to be a lot of winners and losers with this disruption. Don't lock yourself into the old regime because you grew up on newspaper.
When's the last time you worked as an IC? Is there any reason to take your opinions on "my job" seriously when downward pressure on salaries is only beneficial to you and whatever AI companies you're attempting to start?
"The world will be better off as a whole". Why do you think this? How are you contributing to making the world better with AI? Is there any reason that's not related to making money?
What you did a few years ago will likely dry up as a source of supporting you and your family. There is all kinds of new value to create in the world. Find the calling that is meaningful to you. Go cure cancer instead of plumbing widgets and wizbobs at 100k QPS active-active five nines SLA.
Just don't stay as a gas station pump attendant, butter churner, or elevator button presser.
And it's also wild that you assume what I'm doing doesn't bring value to the world. There's a film being released theatrically in a few months that directly incorporates what I've worked on. I've been a filmmaker for decades outside of tech and that is deeply meaningful to me.
“Directly incorporates” is pretty vague and still seems like it’s financial, but good for you. I hope it’s something that assists artists and doesn’t replace them. Personally it’s hard for me to find meaning in something like that, given the thread’s context of “I don’t even look at the code”. What craft was done? In what way is the movie better now? It’s cheaper?
I won’t endorse glee about anyone losing their job, even if it means people with a lot of freedom can throw things at the wall and see what sticks. Same story as always, it’s just faster now.
You don't look at the bytecode you produce. You don't know 99.99% of your stack. You are a master of abstraction and you always have been. This is just a different flavor of the same recipe.
You've got a tool that will let you execute at greater breadth than ever before. Like what it must've been like for the very first engineers who had access to the internet or the first libraries or package managers.
Job flux is demand finding new salients. Employment hasn't dipped as far as I can tell. There are more exciting opportunities now than ever before, you just have to step into it.
I apologize for misreading and pettily being condescending "in return".
I agree with the way you phrased it here.