Maybe I'm wrong. Maybe AI Natives will be faster in the end and can build / do more, or building software really is a dead field - but I noticed that I was losing my brain and had to get back into the seat.

There are definitely great use cases for agents - but I think a lot of us aren't flexing our brains anymore and, even worse, some devs believe they are. I urge every developer to put Claude down for a day/week... see how well you can do in the "old" ways. It'll still be here when you get back, but my guess is it'll be a rude awakening.

Understanding the problem and the existing system well enough to design the right solution, even with AI assistance, is a higher cognitive load. I’m doing a lot more of that lately.

I’m more productive, but also more tired. This may be due in part to the breadth of what my team owns, which makes my day a bit more context-switchy than other teams.

As others in this thread have noted, the situation is still evolving. However, I worry less each day about being replaced by AI. There has always been more work than available bandwidth in my experience.

What seems clear to me is that expectations around velocity and throughput will increase (are increasing). AI use will be required to meet those expectations. Learning to use this new tool effectively will be essential for career progression (and preservation).

Before LLMs came, there used to be the technical debt to deal with in a project, now there is also the added cognitive debt which is way more subtle and impactful long-term. If your source of truth isn't source code but a prompt (or even a series of prompts with branches) and the executor of prompts is a non-deterministic agent, I think you've already lost the battle there.

I don't like, I prefer to use Claude/Codex as an aide, not to let it take the wheel entirely but I don't really feel like I have much choice in the matter.

Especially with prototyping-style work, LLMs are clearly good enough for a ton of business-oriented proof-of-concepts, and that line of work is essentially dead. Unfortunately a lot of mid-tier art falls into this category as well, particularly because execs very clearly can't tell good art from bad (on a "customers like this" scale, with functionality being the judge, which is fairly objective. not a subjective "this is good art").

High-skill work is still necessary, but it's hard to tell if it's actually going to be more important (because skill is obviously still needed for actually-good results, and I honestly see no evidence that this will change with current tech) or less (primarily due to less demand, and it being significantly harder for non-skilled to judge skill when everyone can prototype something seemingly-impressive in a weekend). Some will very obviously continue to exist though.

Whether this means "high-skill people are going to be fine, stay the course" or "<10% of high-skill people will be fine, you had better be scrambling right now or looking for a new line of work" is... much less clear.

One possibility is that software starts to look more like traditional manufacturing.

The machine is the company’s core asset. The engineer only needs to know how to operate the machine well. Once that happens, the barrier gets much lower, need much less people, and the job naturally become much less valuable. Some parts will still need to be done by hand, of course. But only a very small part. It is like old factories. They used to need lots of fitters, at all levels of skill. Now you only need a few of the elite ones.

AI is the CNC machine of the software industry.

The more pessimistic future is that, maybe five years from now, the best programmers will look at AI the same way the best Go or chess players look at AI today: Like KeJie said, "I don't even know what I am trying so hard against." We now have a new SOTA every two months. It just took 18 months for LLMs from reasoning models to disproving the unit distance conjecture. ChatGPT itself has not even existed for as long as a college student spends in university.

In any case, we have already passed the point where this can be rolled back.

Maybe ten years from now I will be leaving a comment saying that "programmer" used to be a job too :-/

Programming is the low-hanging fruit for AI. Open source and knowledge sharing have given it huge amount of public, high-quality training data at a level other industries can hardly imagine. And almost everything in programming can be tested and verified inside the computer quickly in a closed loop. No robot arm is needed.

The main weakness of current LLMs is still that they are static: They do not really change themselves through use. Harness tools are just elaborate ornamentation on top of prompts. LLMs are frozen at the moment training stops. Once we get models that can change their own weights through self-feedback, then maybe AGI really is on the horizon.

Thinking optimistically: I may be lucky enough to see it in my lifetime. Maybe by then, people will be able to live more like human beings, instead of organizing their whole lives around work :-)

Even contracts are being drafted by AI, and managers are signing them. I've seen contracts signed using emojis, and the project has already begun.

We live in an interesting era...

We're seeing lots of code being ~written~ generated, deployed, checked (tested manually), then shipping it as done. Fine for the simplist of things, but in a complex system unintended side effects are far more common.

I feel like the system analyst role is going to make a resurgence in the coming years. Once the domain knowledge is lost, there's going to be a need to re-discover it and understand what should be happening and what is happening.

Going against the grain - i don't think all but the most expensive (and non critical) SaaS products are going to be replaced by an in-house system. If you're company of 100 people is spending $12k a year on HR software. Building and running it yourself isn't going to save you 12k and in reality it's going to cost you headcount for someone to manage and maintain it. Mattermost exists and people still pay Slack $200 per year per user when they could just roll out Mattermost "for free".

Basically, in a decade or so, we'll be completely out of the loop in software development; even this title won't exist anymore (like the 2000's webmaster). We'll still be around, but with different roles.

It may seem hopeless as a programmer, but imo you'd be much better off reframing your situation re: the above sentence.

At the high end, there will always (or at least for a fairly long time) be a subset of work where AI can't do everything itself. Perhaps the framework or language is too new, or its built for hardware that's only just become possible. Perhaps the company is worried about security issues resulting from letting LLMs access its systems, or needs a human in the loop to take any liability. Perhaps the tech needs a level of performance that an AI might struggle with, and which a longtime engineer with a computer science background may be better at dealing with (like stock trading systems or something).

This will pay very well, but probably only provide enough jobs for 5-10% of the current software engineering workforce.

Then there will probably be a large number of companies where AI does most of the work, but where one or two people will probably be kept on board to guide it in the right direction/take care of issues. I suspect a lot of less technical/cutting edge companies in more 'traditional' industries will be in this camp.

Finally, a lot of work will just be outright replaced by having an LLM take care of everything. This isn't viable for FAANG companies or fortune 500 level ones, but the average mum and pop business could probably just replace its entire development team with a Claude subscription. I suspect a lot of web development agencies and lower level jobs are just going to vanish.

So, yeah. High level bespoke work where every microsecond is king? Stays mostly the same, albeit with some AI usage to handle the boring stuff.

Basic brochure/shop/CMS site development? Claude and co take over almost entirely.

I'm in a slow-moving, much bigger company. Lot's of talk about "AI" here and we can use copilot if we want to, but there is 0 pressure. I'm in a small team and one colleague uses copilot often. In the beginning there was a minor conflict between him and me, because I found the quality of the LLM code unacceptable and had to ask him to review it more carefully. I think that's settled now, but it makes me sad how a once motivated colleague now seems to try to cheat his way out of work.

I personally find it incredibly boring to write copilot prompts or read its answers full of boiler plate and sycophancy. I don't understand how anyone would want to replace the cognitive work of programming, that I find enjoyable for the most part, with the cognitive work of "talking" to an LLM.

Anyway, I think it will be like this at least for a little while longer: only vibe coding allowed in small companies and less vibe coding the bigger the company is.

But before vibe coding can take over the slow-moving big companies, all the accumulated technical debt will come back to haunt us and vibe-free software will be the new fad. That's what I hope at least.

   151 "profession" wn "WordNet (r) 3.0 (2006)"
   profession
   n 1: the body of people in a learned occupation; "the news spread rapidly through the medical profession"; "they formed a community of scientists"
   2: an occupation requiring special education (especially in the liberal arts or sciences)
   3: an open avowal (true or false) of some belief or opinion; "a profession of disagreement" [syn: {profession}, {professing}]
   4: affirmation of acceptance of some religion or faith; "a profession of Christianity"
   

I think if you’re used to traditional green field development, and have never owned legacy code AI software engineering can be bewildering. If, however, you’ve been stuck maintaining legacy code, the skills serve you well In AI development.

You’re constantly looking how to tame this ball of mud. Test it end to end. Break apart bits to test. You’re chasing where the brittleness in the system exists, and you try to create a testing and feedback strategy to gain leverage on that class of problem. That in turn turns to modularization and gradually more careful organization.

I find starting out you may look at code less. As time goes on, you descend deeper and use AI to do targeted refactors to account for more constraints. You leave alone what's OK to be slop, and hone in on what needs deep care. All along adding guardrails to constrain the big ugly beast and help LLMs stay on track with their work.

The classic Michael Feathers book might be sneakily relevant: https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe...

Yes, may be a skill issue[tm], may be an inherent one or it may not even be relevant anymore, we will see.

For me it currently still works well because I am working on legacy systems I more or less have a good understanding about - so I can judge the agent code. Not sure how this will be with new, green field code.

Not even starting with the discussion how it should be possible to review the sheer amounts of generated code.

Materializing and scoping down broad idea ( or just abstract vision ) into what needs to be built, it’s not the same to say.

“Hey Claude build me a fitness app”

Thank actually understanding your customer behind it, the behaviour and psychology, the journey and what is the actual problem you’re solving.

Tech in general and programming emerged as a need to create new things in a digital world to solve our problems, building them just got easier but understanding the problems and the people behind them, that’s gonna be an increasingly necessary task

However many people have rightfully been saying it for years before LLMs that many so-called software engineers had no business in this field because for a lot of them it was just a way to earn more money than peers. It's not an issue by itself, just a rational human choice but the fact that it was possible was just because of unhealthy economic conditions.

- Humans still own the code

- All code reviewed by humans

- LLM adoption varies across the org. Some are heavy users and some less. Some suspicious some less.

Where are we heading? Depends on model/harness capabilities. Likely some sort of mix where some projects will still require expert humans and others will just be vibe coded. How much we lean in that direction - we'll see.

This was the expectation because hiring was the primary goal, not product delivery. The industry could have fixed this by upgrading itself from an occupation to a profession built upon standards and credentials. That never happened because the 80% would become unemployable, which adds friction to hiring (the real business goal before COVID).

Now, that ship has sailed and there is no going back. The Pareto Principle is now a 5%/95% funnel because there is less incentive to learn to do the work. Good luck!

The responsible and professional way to actually make AI work at scale is to build a dark factory. (You can search HN for a lot of good resources, start with Simon Willison and StrongDM)

This works, until it doesn’t. I’m continuously shocked by these stories, where so many people put the future of their job/company in the hands of these agents after only a few months of existing.

I still constantly run into bad output from LLMs, from code to basic questions. I don’t understand how anyone can hand things over to something that is laughably wrong on a pretty regular basis, often in subtle ways that won’t be noticed by someone who isn’t reading closely and thinking critically.

They’ve gotten better, but I still regularly give them the old Nick Burns treatment, push it out of the way, and do it myself.

Now we have machines that, when asked to produce a paperclip, may instead produce a butter knife, or a banana, or maybe just a "try again later".

These modern "tools" are quite a different animal. They're more akin to roulette wheels that generate massive amounts of heat and CO2.

But it sounds like you're really asking about the state of the world today. If so, I don't think that ideal state is like your friend's company (or at least, as it appeared to be to you). It might be possible that you can make that "dark factory" pattern work (StrongDM seems to be doing it), but it would require infrastructure and discipline that I doubt they're mustering. Think about how CD didn't involve taking a sloppy build process with no testing or observability and just going straight to prod -- it required building up a lot of infra and discipline first.

But on the other hand, I don't think the ideal present involves artisan hand-crafting code either. I haven't written a line of code by hand in enough months that it would genuinely feel weird if I were to try to program that way despite decades of having done just that. That era's done with, and moderate normie practices right now today are more about supervising and guiding agents than about chiseling code into clay tablets.

in the olden days (pre-LLMs) we would write high-level code.

the entire layer was high-level code and rarely would we ever need to peak into the assembly:

writing, debugging, architecting, reviewing, testing - all were done in the high-level language layer.

---

welcome to present day:

since we don't write code - we write intents, we also shouldn't review code either - we should review intents.

I don't review my code anymore. I ask the agent to generate markdown docs, graphviz diagrams, changelogs, audit reports, etc. I only review that.

I also ask it to write test and evaluate by whether the tests passed or not. I don't need to peak into the tests code - I can also ask plain english, pseudocode, control flow graph, whatever it is I want.

I can ask it to find errors or missing tests and improve that too!

code is like assembly now.

rare are the cases you would need to peak into that level.

The industry is going to shift from hiring as many programmers as you can afford to hiring a small number of the best engineers you can find. AI can't replace an engineer's skill and insight, and I have yet to see signs that LLMs are fundamentally capable of such a thing. What is screamingly obvious however is that when a highly skilled engineer learns how to drive AI agents, that's when you get true effort multiplication. A real engineer can leverage AI in ways that an unskilled vibe coder simply cannot, because it turns out that building a house still requires engineering even when you have a nail gun. LLMs can write code all day but if you don't understand programming and engineering on your own, you lack fundamental tools to build software.

Sorry kids, buffet is closed. No more FAANG salaries for anyone with a pulse and a copy of VSCode. The future of the industry looks to lie with a vastly smaller number of much more highly skilled engineers.

What happens when those engineers age out and we realize we stopped training new ones? I genuinely fear for the coming generations of engineers. It's not going to be good.

I recommend you learn to weld instead.

LLM capabilities are mind-blowing.

I’m not a super experienced engineer career-wise ~5 years, so take my view with a grain of salt - but I’ve done work in full-stack, systems, gaming, extensions (web and ide), low level languages including assembly, and a small amount of embedded.

I spend almost all my spare time coding. And have done so for the last 5 years. So I consider myself capable of bringing most projects to fruition.

I roll my eyes when people say “AI sucks” “AI isn’t better than me” “AI doesn’t speed me up” - it’s either a load of shit, delusion, cope, high-horsing, or they are a Luddite.

I’m sorry but the rate at which I can work pre-AI and post-AI is insane (when not limited by bureaucracy). Yes the outputs and code can be terrible, but I can prototype 10 ideas in the time it would take me in the past to prototype 1.

However most of the LLMs approaches are fucking terrible, it gets it working but it’s pure spaghetti and I do all the architecture and usually most of the code. But I prototype ideas with AI. Like if you actually use performance monitoring and memory monitoring tools, LLMs have no fucking clue what they are doing and make slow bloated buggy shit.

But it’s great for blueprinting.

Who’s to say it won’t also be great at implementing too? I think it will be.

But for now it requires guidance and orchestration and I mostly use it to test concepts.

I did my first purely vibe coded completely hands off project the other week and loved the results! It was just for fun.

- spending exorbitant amounts of time up front planning, surfacing every milestone, subtask, and individual change, burning tons of tokens in addition to man hours fixing minute but important mistakes or derivations despite explicit instructions, CLAUDE.md, memory subsystems, agent and skill instructions, etc.

- executing and reviewing results compared to the plan and finding even more mistakes and derivations from the plan often takes a lot of time - the relative rapidity produces a lot of output for the team which stresses our lifecycle and introduces feelings the whole process is on the verge of flying off the rails

- individual developers have different expectations, definitions of acceptable, skills/experience to detect and deal with problems, and patience. I might spend hours to days meticulously planning and executing a ticket and another guy might yolo it in 30 minutes. Other than bug escape rate and tracking review failures I’m struggling with how to track people who are “doing it wrong” let alone telling them the “right” way to do it.

- growing exhaustion, lack of ownership and confidence, frustration, and a generalized feeling of endlessly fighting your tools but in a weird way they never seem to really improve despite all your efforts to do so

- taking humans out of the loop and letting the agents be more autonomous in hopes that we’ll reduce the bottleneck and produce better results has not helped.

- I find even myself fighting (and sometimes failing) the urge to give in even though the proposed or implemented solution doesn’t feel right. Scale that across your team

- experience has not really changed despite changes in models and harnesses

- there’s a deep feeling that I’m doing something wrong and fomo since so many people in the industry boast of incredible results. I probably am, but everything I’ve read about and tried has not really moved the needle much and it’s introducing another dimension of exhaustion and frustration

overall, I don’t feel like we’re being much more productive when you factor in quality and accountability (which should be a given, but this industry increasingly overtaken by a reckless philosophy of speed over everything else). I do think it has helped parallelize tasks, produce higher quality PoCs to explore more options and do it faster, offload joyless but necessary tasks that are narrow in scope and measurable, do exploratory work and act as a generalized interactive knowledge base, and make shallow techniques, technologies, etc. that you don’t yet have experience with. Maybe I’m just missing a critical component or two in the process (formal specification, etc). Maybe it’s growing pains, or maybe there’s a looming rot. Either way job satisfaction and confidence in my work is much lower than I would have expected.

Claude always likes to "go big," for example, by choosing tools that can support millions of concurrent users or by adding unnecessary layers of abstraction that create more maintenance pain. I guess that's good for LLM companies, since more tokens are spent fixing the mess it caused.

Every time I enter plan mode for a huge feature, I end up cutting about 30-60% of the task scope before the LLM can actually start the work. I review the final code, and I still find things to cut. As said before "The best code is no code, or code you don’t have to maintain" [0]

0: https://www.simplethread.com/20-things-ive-learned-in-my-20-...

Writing code versus shipping code: Productivity effects across generations of AI coding tools - https://cepr.org/voxeu/columns/writing-code-versus-shipping-...

To me it felt like there were always engineers and vibers.

Vibers don't work systematically, never test, accept unknown regression, don't use git, and if they do, treat it like Dropbox, use terrible languages, have terrible habits. Vibers got a new tool, too, and it vastly increases the amount of slop. But the slop was always there.

The slop actually got better after vibers stopped writing their own slop, I have to say.

And vibers are less defensive about the particular slop they didn't write themselves.

https://www.reddit.com/r/technology/comments/1ueidyv/softwar...

> I had an interview where I was asked the obligatory “what’s your Al workflow” and I said I use it for searching documentation and writing small functions or boilerplate that are tedious. Then I was asked whether I use Cursor. I said no, and immediately was told that “I’d be a better programmer if I used Cursor”. I have 13 years of software engineering experience, and was talked down by an Al startup with no minimal viable prototype. Then I was told I did not have the experience for the role. I love this timeline so much

I don't think the future is massive data centers running at a staggering loss to generate questionable code.

The future is rethinking IDEs to have local models work in partnership with the developer to ease tedium and catch mistakes.

A model that maintains a visual, zoomable mind-map of the entire project, with two way binding. Code can be created visually or textually, same with data flows.

Project structure and architecture are presented in high-level ways, that can be easily altered and refactored with almost zero tedium.

I think we start using AI for what it's good for: pattern matching and transformation, and stop trying to make it reason and pretend like it's a human.

Once we, as an industry, figure this out we'll unlock a massive boost in quality and productivity, but it looks like there will be some painful times ahead before everyone realizes that the token extrusion machines are only increasing the total cost of ownership, and they are being used incorrectly when we try to outsource our thinking to them.

I think there's an enormous opportunity to build these tools right now, and that whoever nails it will win.

i think that is a more important question that you shouldn't ignore.

do they have growing revenue?

I haven't worked at a startup in over a decade, but the stories I hear now sound the same as back then. There's lots of wasted effort for mediocre to poor code destined to be rewritten or thrown away until there's enough investment to justify more work. At which point, "more work" just means more sprawling slop instead of fixing the technical debt rotting at the foundation.

AI just put a spotlight on the futility of trying to run before you can walk. Whether so many founders are going to stay in denial about it is yet to be seen. Statistics about any line of business says yes. This is how most businesses fail and most of them have to fail.