Posted by moebrowne 6 hours ago
The code it generated was awful. The kind of garbage that people who don’t know any better would ship: it looked right and it worked. But it was instantly a maintenance dead end. But I had an effortless time converging on a design that I wouldn’t have been able to do on my own (I’m not a designer). And then I had a reference design and I manually implemented it with better code (the part I am good at).
You can talk to a bunch of designers who will say the opposite. Claude Design Studio generated this garbage UI, that I fixed manually, but it created great code j never could have that made it work.
These systems should allow rapid iteration on discovery and thinking. One can now make a prototype a day that would have taken a week. That means that we should be able to converge on a much better design in the same amount of time it would have taken to make a v0 that turns how to have systemic flaws.
AI should scale our understanding of systems, not just shovel out half baked features and apps.
basically the AI-slop version of food, yet still they thrive
You're suggesting that (a) their UI skills are lacking (based on what? isn't UI exactly what they were iterating on and trying to improve?), and (b) that a real UI expert would've somehow felt the UI they were working on was consistently garbage, despite how many times they iterate on it?
Which means you're saying you don't believe anyone can actually produce high quality (to an expert) output with AI on the same target they're working on, and if they think they are, that just means they don't have a good sense of quality?
AI pixel art looks particularly bad because most users don’t even go through the effort of downscaling and then upscaling it using something as simple as nearest-neighbor scaling, which by itself will squash out a lot of high-frequency noise that manifests in the form of terrible looking "fringing". Proper grid alignment also makes a big difference. It’s not perfect by a long shot, but it helps.
https://en.wikipedia.org/wiki/Michael_Crichton#:~:text=%5B14...
People are never perfectly even in intelligence across all possible disciplines.
Gell-Mann's observation was a sincere and thoughtful caution about the way we transmit information about complicated ideas. Crichton's "amnesia effect" is an excuse to ignore media you dislike.
In the Tailwind thread the other day I was explicitly told that the intended experience of many frameworks is "write-only code" so maybe this is just the way of the future that we have to learn to embrace. Don't worry how it's all hooked up, if it works it works and if it stops working tell the AI to fix it.
It's kind of liberating I guess. I'm not sure if I've reached AI nirvana on accepting this yet, but I do think that moment is close.
There is an enormous untapped market for crappy low-effort apps which previously weren't worth the time - but with the effort so low put together a simple dashboard or one-off tool it becomes much more attractive.
Which is probably why so many random buttons in microsoft/apple/spotify just stop working once you get off the beaten path or load the app in some state which is slightly off base
The number of edge cases in a software is not fixed at all. One of the largest markers of competence in software development is being able to keep them at minimum, and LLMs tend to make that number higher than humanely possible.
The people pushing AI _over_ humans never thought they were. They just don't care about 'good' or 'bad', only 'time-to-market'. A bad app making money is better than a good one that isn't deployed yet. And who cares about anything past the end of the quarter? That's the next guy's problem.
In terms of "junior dev following" it would be the model trying to think and write it as a Senior or Staff Level engineer would.
Humorously, this could be the result of LLMs vacuuming up all the sentiment on the web that the code that LLMs produce is trash-tier.
Maybe a more idealized training set could improve things, but at least for today’s SOTA, you have to get the shitty first draft out and then improve it.
Harnessing makes a difference, but it’s only shuffling around when and where the tokens get generated. It can trade being slower by doing a hidden first draft and only showing the output after doing a self review. But the models still need to generate it all explicitly.
It's not the default, because the training data is full of unmaintainable code done wrong with mistakes. People literally complain that LLMs write too many tests or add comments.
If instead of "do it right", you give it specific actionable advice of how to right code, it does surprisingly well. Newer frontier models also do a great job of mimicking the style and rigor of the surrounding codebase without prompting, if you're working in an established codebase, for better or worse.
You never wrote quick exploratory code? One off scripts? How is the Ai suppsed to know unless you tell it.
If you tell another person to write some code, how are they suppsed to know? If you have your boss come to you and ask you to write some code to do some data analysis are you going to spend weeks writing units tests and perfect abstractions? Or do it quick and get the data and result?
For example, I built up a programming language from scratch with Claude, it knows nuances about my languages syntax, and can write code in my language effectively. I did it mostly as a test. It definitely helped that my language is heavily mostly Python based.
I did an experiment on this a few weekends ago and Codex for example was a lot more adversarial and thorough in its review when given Claude-authored code compared to when given the same code with "I wrote this, can you review it?"
Granted, the load bearing thing here is whether we’re actually getting good at rebuilding up to any sort of standard of quality. Or if the tooling is even structurally capable of doing that rather than just introducing new baskets of problems with each build.
Prototypes are practically free now. You can ask the AI try each architectural or stylistic option and just see which code you like better.
To your point, another interesting note is that rewriting and rearchitecting are also very good.
One pattern I like is to vibe code a set of solutions, pick the approach, then backfill tests and do major refactors to make it maintainable.
Here the skill is knowing what good architecture looks like, and knowing how to prompt and validate (eg what level of tests will speed up the feedback cycle or enable me to make the LLM’s changes legible).
To be fair the “ready, fire, aim” approach of rapid prototyping has been known for a long time, but you need to be quite quick at coding in old world for it to work well IMO.
At the moment, we understand the basic tech, could reasonably DIY, but choose not to knowing full well there's a mess of understandable code somewhere we could go clean up but dont want to. We accept fast iterations because we know roughly the shape of how it "should be" and can guide an automated framework towards that. This is especially true on our own projects or something we built originally! Stark/Iron man knew/moved, the suit assisted by adding momentum.
We're riding our "knowledge momentum".
If companies can hold out long enough, that knowledge completely fades, and the tool is all you have. At that point, they are locked in. Then it's not Iron man, it's an Iron lung (couldn't resist!)
I love the Iron lung reference. Perfect.
AI is great at creating slop that almost works.
But, my god, it is terrible at following clear as day instructions on how to cleanup slop.
It wrote 150k lines of code that almost works in 2 months. It's taken 1 month to delete about 2000 lines of broken architecture and fix it, and it still hasn't gotten it done, despite nonstop repeated efforts to do something not that hard.
I definitely could've fixed it less time then I've spent prompting at this point (but no way I'd have gotten the other 150k lines). But doing it myself is not the point. It's to see if it can actually scale.
The answer is yes... But my god is it agonizing.
The creating garbage part that almost works is fun.
The inevitable cleanup is not.
And unfortunately I don't see this aspect materially improving in the short term.
If you want it to code you something about 5-10k lines of code that's already been done 1000 times before or only slightly different, it's great.
Most people want more than that.
- first I've created a skill how the architecture of the system should look like
- I'll tell the LLM to follow the guidelines; it will not do that 100%, but it will be good enough
- I'll go through what it produced, align to the template; if I like something (either I've not thought about the problem in that way, or simply forgot) I add that to the skill template
- rinse and repeat
This is not only for architecture of the system, but also when (and how to) write backend, frontend, e2e tests, docs. I know what I want to achieve = I know how the code should be organized and how it should work, I know how tests should be written. LLMs allow me to eliminate the tediousness of following the same template every time. Without these guardrails it switches patterns so often, creating unmaintainable crap
Bear in mind - the output requires constant supervision = LLM will touch something I told it not to touch, or not follow what I told it to do. The amount of the output can also sometimes be overwhelming (so, peer review is still needed), but at this point I can iterate over what LLM produces with it, with another LLM, then give to a human if it together makes sense
I'm not a designer either, but I've been around designers long enough to recognize when something is bad but just not know what is needed to make it better/good. I've taken time to find sites that are designed well and then recreated them by hand coding the html/css to the point that I consider myself pretty decent at css now. I don't need libraries or frameworks. My css/html is so much lighter than what's found in those frameworks as well. I still would not call myself a designer, but pages look like they were designed by a mediocre designer rather than an engineer :shrug:
I keep asking myself the same questions, and the conclusion I keep coming to is the clean modeled structure we want to see is for humans to maintain and extend, but the AI doesn't need this.
There's definitely an efficiency angle here where it's faster for AI to go from a clean modeled solution to the desired solution because it's likely been trained on cleaner code. Is this really going to matter though?
The best argument I can come up with is the clean modeled solution is better for existing development tools because it's less likely to get confused by the patch work of vibes throughout the code; but this feels like it ultimately becomes an efficiency concern as well.
This just might be the new reality, and we need to stop looking behind the curtain and accept what the wizard presents us.
This does not match my experience. I do a lot of AI-assisted coding at this point, and what I've seen is that when the AI is asked to extend or modify existing code, it does a much better job on clean, well-structured and well-abstracted code.
I think the reason is simple, and tracks for humans as well: well-structured code is simply easier to understand and reason about, and takes a smaller amount of working-set memory. Even as LLMs get better with coding, I expect that they would converge on the same conclusion, namely that good structure + good abstractions make for code that is more efficient to work with.
I think it’s all about the structure you use to work in and how you use the model. We are shipping better, more human friendly code, with less bugs, then we ever did before and doing it at 1/10 the cost before LLMs.
But we are definitely not vibe coding, and the key seems to be devs with years of experience managing teams, managing the LLM instead. Basically you create the same kind of formal specifications, conventions, and documentation that you would develop for a project with two or three teams, then use that to keep the project on the rails recursively looping back through the docs as you go along. I’ve only had to back out of a couple of issues over the last year, and even though that cost a couple of hours, it was still extremely cheap.
Meanwhile we are shipping at 4x speed with 1/4 the labor, and the code is better than it was because the “overhead” of writing maintainable, self documented code has inverted into the secret ingredient to shipping bug free code at unprecedented speed.
If you just explain the standards to which you want the code written, use a strict style guide, have a separate process that ensures test coverage (not in the same context) you can get example quality code all the way through. Turns out that’s also in the training data.
So yeah, it’s imminent. Let’s see how demand shifts in response in the future.
I think we eventually end up at the tool approach via vendors providing the tools to other companies, but it still feels like there's a long road ahead to get there.
That's not true. The LLM performance will degrade as the codebase gets messier as well. You get to a point where every fix breaks something else and you can't really make forward progress.
Yes, you might be able to get a bit further with a messy codebase just because the LLM won't complain and will just grind through fixing things, but eventually it will just start disabling failing tests instead of actually fixing things.
Of course that just leads to: what’s the best way to achieve that goal? Through elegant code or adding lots of tests? Which is a debate from long before LLMs existed.
This is how societies become shittier. People who are ostensibly responsible for doing their jobs not giving a damn about quality.
LLMs have a limit to how deep they can understand and refactor architectural issues.
That limit is far, far lower than a human's.
Which I think is perfectly worthy of exploration. Some people want to check in the prompts. Or even better, check in a plan.md or evenest betterest: some set of very well-defined specifications.
I'm not sure what the answer will be. Probably some mix of things. But today it is absolutely imperative that the code I write for the case I wrote it in is good quality and can be maintained by more than just me.
It's tempting to move out a layer and try making prompts and plan.md the "source code", and then the generated actual-source-code becomes just another ephemeral form of "intermediate representation" in the toolchain while building the final executable product. But then how are you versioning the toolchain and maintaining any reasonable sense of "stability" (in terms of features/bugs/etc) in the final output?
Example: last week, someone ran our "LLM inputs" source code through AgentCo SuperModel-7-39b, and produced a product output that users loved and it seemed to work well. Next week, management asks for a new feature. The "developer" adds the new feature to the prompting with a few trial iterations, but the resulting new product now has 339 new subtle bugs in areas that were working fine in last week's build owing the fact that, in the meantime, AgentCo has tweaked some weights in SuperModel-7-39b under the hood because of some concern about CSAM results or whatever and this had subtle unrelated effects. Or better yet: next month, management has learned that OtherCo MegaModel-42.7c seems to be the new hotness and tells everyone to switch models. Re-building from our "source" with the new model fixes 72 known bugs filed by users, fixes another 337 bugs nobody had even noticed yet, and causes 111 new bugs to be created that are yet-unknown.
If you treat the output source code as a write-only messy artifact, and you don't have stable, repeatable models, and don't treat model updates/changes as carefully as switching compiler vendors and build environments, this kind of methodology can only lead to chaos.
And don't even get me started on the parallel excuses of "Your specifications should be more-perfect" (perfection is impossible), or "An expansive testsuite should catch and correct all new bugs" (also impossible. testing is only as good as the imperfect specification, and then layers in its own finite capabilities to boot).
I never tried spec driven development for myself, but if I review other's MRs I am typically exhausted after the first 10 lines.
And there are hundreds of lines, nearly always with major inaccuracies.
For myself I always found the plan mode to work well. Once the implementation is done, the code is the source of truth. If it works, it works.
When I want to add more functionality or change it, I just tell the agent what I want changed.
I doubt walls of semi-accurate existing specs are going to be beneficial there, but maybe my work differs from yours.
I've been using LLMs daily and I spun up a few spec driven flows once or twice but like the person above I think the code is the source of truth.
Also why wouldn't you use TDD to enforce the 'spec' then?
I mitigate this by few things: 1. Checkpoints every few days to thoroughly review and flag issues. Asking the LLM to impersonate (Linus Torvalds is my favorite) yields different results. 2. Frequent refactors. LLMs don't get discouraged from throwing things out like humans do. So I ask for a refactor when enough stuff accumulates. 3. Use verbose, typed languages. C# on the backend, TypeScript on the frontend.
Does it produce quality code? Locally yes, architecturally I don't know - it works so far, I guess. Anyway, my alternative is not to make this software I'm writing better but not making it at all for the lack of time, so even if it's subpar it still brings business value.
I suppose you could solve that in two ways. Manually rewrite it as you did. Or formalize an architecture and let the AI rewrite it with that in mind. I suspect that either works.
the power comes from creating the machine you can steer. Treat AI like an over eager college intern who you need to hand hold, but do tasks.
I feel what you write, but then again: every now and then i write small greasmonkey scripts to remove annoyances from webpages, and to do so i have to look at the html and the kind of trash you describe is already there.
I gave up on this recently. It achieved the goal now, and in a year or two, when you actually want to add whatever feature, the SOTA AI will probably be able to clean it up as it does so. What does "maintain" even mean anymore?
If you don't agree, how many years into the future do we need until you would agree?
And people have been saying this exact thing for years now. Someone said this very thing two years ago. And we're still at the "maintenance dead end" stage. So let me flip it back on you: how many years are we going to pour an obscene amount of resources into this thing that is always going to be able to clean up its own messes "in a year or two" before we realize its a dead end (at best) and we need to be using those resources elsewhere? And, similarly, what happens to you when the SOTA AI in two years can't clean up the code it wrote for you two years ago, but people are depending on it and your still on the hook for maintaining it?
Respectfully, I asked first. ;)
> before we realize its a dead end (at best)
You've declared the future, which doesn't leave much room for a conversation. So, cheers!
This is talk and talk is cheap. Prove it, otherwise it's still a million dollar question... unanswered.
HN is notoriously mentally deficient when it comes to AI. They were wrong about self driving cars (I sit in AI cars daily), they were wrong about AI getting used for coding (I don't use an IDE or type code anymore as a SWE). So I have to say unless there's something evidence based or substantial here it's likely given HN track record that most people here will end up being another wrong, baseless and over confident answer.
I'm looking for legit answers not confidently biased statements with no evidence.
Iron Man created Jarvis whose capabilities are way beyond any models in the near future. So it wasn’t an Iron Man moment.
> Iron Man created Jarvis whose capabilities are way beyond any models in the near future. So it wasn’t an Iron Man moment.
Like an LLM, you misunderstood the context. The voyeuristic experience doesn't require fiction to be reality.
(And on a personal note, I'm glad we don't have a publicly released Jarvis before we get our act together about the use.)
Sure, Claude Code and Codex can write (most of) the code for me - but the amount of technical knowledge I need to decide what and how to build remains enormous.
As an example: I'm working on a system right now that works like Claude Artifacts, allowing custom HTML+JS apps to safely run in an iframe sandbox inside a larger application.
Just understanding why that's a useful thing that can be built requires deep knowledge of sandboxing, security threats, browser security models, and half a dozen different platform features that have been evolving over a couple of decades.
A vibe coded without that technical understanding would have zero chance of prompting such a thing into existence, no matter how much guidance the LLMs gave them.
It really saddens me to see some developers talk about literally quitting their careers over AI, right when the benefits of existing deep technical experience have never been more valuable.
1. Because the experience of interacting with AI is miserable. I like writing code. I don't like finding the magic incantation that gets the machine to write the correct code. I don't like correcting the machine when it gets things wrong. I don't like any of this, it's awful and I would never have gone into this field if someone had told me that it would be like this one day.
2. I cannot condone the means by which these tools were created, which is, as far as I am concerned, theft. I think it's unethical to use them at all, because they were created unethically. I dislike using stolen work, I think it's wrong, and I think everyone who uses it is making the world worse and normalizing theft. If continuing in my career means that I have to compromise my ethics, I wouldn't do it even if I loved this stuff, and see point (1).
3. Is anyone going to pay me more for my "more valuable" skills? Doesn't seem like it, engineering salaries on the whole are going down right now. You can believe they'll go up eventually if you like, but there's no evidence that will happen, or that it's happening. If my employer captures all the value, why should I care whether I'm creating more of it?
I'm your exact opposite.
I've felt like code is 1960's punch card tech my entire career. I've always wanted to do more.
So much of coding is plumbing. Or paying attention to tiny little details. Or hunting down stupid bugs. Or changing requirements and refactoring. That shit sucks. All of it.
I've never had so much fun with software. It's starting to feel like magic. And because we possess deep understanding, we are uniquely positioned to take advantage of this.
The AST is not the objective. The finished product is. Our DNA is by all accounts filled with garbage. Let your feelings about code purity and sanctity go. It's the job to be done that matters.
Code is not holy. In 100 years people will look at our ephemeral artifacts as silly little things. Treat it that way today. Means to an end.
One, I think the talk about AI replacing developers is tripe. We’re still correcting the post-Covid hiring binge.
Two, even if that level is breached, I’d consider your skillset more broadly than what you can literally do right now. Organizing people and technical systems is hard. And the article highlights how that doesn’t seem to be something AI is focused on improving on right now. (Would take larger context windows. Which would make inference more expensive.)
I don't intend this to read as pure snark, but someone's abstract value isn't much good to them if the job market itself can't / won't recognize it.
There's an interesting repository with 63600 stars on GitHub (1). The developer of the repository is No 1 at the GitHub's trending contributors list (2). However, it seems like the application isn't what it's described to be (3), and the developers, on their end, are unable to clearly answer whether this is real or not, as it's just messy LLM output.
Proof that the suit alone doesn't make anyone Iron Man.
1. https://github.com/ruvnet/RuView
So, a nonfunctional project is created by AI and AI is used to attests its nonfunctionality.
What a brave new world.
AI creates a delusional product, people don't trust their own opinion regarding it and follow it, another AI is needed to prove that the product is unreal.
In the loop.
I do believe that is a running theme in the Iron Man comics and movies.
It's a reducer of time.
For less experienced developers, it's an immediately reduction at the start of a project. But then they will almost certainly have problems later when their initial decisions come back to haunt them.
For senior devs, it's like having a junior or mid-level dev that will instantly do things within their capability, so long as it's explained to them well enough. This junior dev will do things fairly smartly, but any important decisions left to them will be wholly or subtly wrong. And the subtle ones are the worst ones, because they're so hard to detect.
But if that senior dev sets the guidelines well enough, and notices the problems, development is so, so, so much faster. It's wild.
What folks seem to avoid is that a Junior (in ANY subject) has the ability to LEARN so much faster with an AI research assistant, and that becoming an expert has accelerated for those with the personal stamina to dig deep (this as a requirement hasn't changed). I spend just as much time with my AI tooling asking questions as I do asking it to "build" or "fix" things. "How does this work?". "Can you suggest other tools?".
I think some people always think about AI as an input / output relationship, when a lot of the time, the fiddling in between, with or without AI was always the important part. Yes people will suck in the beginning, against they always did. I think the good folks though will suck for a MUCH shorter time than I did getting into things.
A lot of people will drop out and get discouraged. That happened before too. Learning things requires persistence. I think the only real case to be made is that AI's sense of immediate pleasure can neuter people away from running into friction. AI natives likely won't understand friction and question it.
You don't learn by reading, you learn by doing.
In this case, simply reading the output of an LLM isn't going to substantially educate you.
This is key, I think, and gets overshadowed by people being offended by seeing bad vibecode or claims of 10x speeds, etc.
The most important learning that happens is not when we ask and get the answer to our question right away. It's when we stretch ourselves to seek out the answer, fail a few times, think deeply, then perhaps after a nap, solve the problem. That kind of knowledge is priceless because it not only gets you an answer it gets you some errant paths you can use to avoid problems in future problem solving as well as getting you increased trust in your own thinking.
If the next generations skip this step, they'll always think answers are supposed to be easy to find and will find themselves more and more dependent on AI and less and less confident in their own brains.
This seems like a very polite way of saying they will become less intelligent and less capable
I’m not seeing this. And based on what we’re seeing at the university level, I’m not expecting to.
(The preliminary research so far supports this: using AI to do the hard assignments produces poor learning outcomes, but using AI as a tutor, or even just for help with the hard assignments, produces slightly better learning outcomes.)
I think what you're seeing is the effect of the incentives of the system. The system uses simplistic numbers like grades as proxies for actual learning, and these grades heavily influence students' job prospects, and so you're simply seeing Goodhart's Law in action. Given how easy current methods of skill assessment are to game with AI, my guess is the entire system has to be overhauled.
Source? The few people I’ve seen try to do this wind up with a terrible understanding of the material, with large knowledge gaps and one or two fundamental fuckups. In every case, an introductory textbook would have been better. (It would also have been harder.)
The analogy is unlimited typing in Gmail won’t make you a better writer or typesetter on its own.
I've seen this work well at a job when there's a feedback loop for juniors that incentivized them to learn with more scope and compensation
If anything it allows to be as lazy as possible. I have not seen anyone digging deeper with the AI tools.
Companies with AI will move faster than those without.
AI itself could subsume what we collectively consider as Engineering Taste.
AI is faster at what it does. So even if a junior costs less on his own than AI. Paying extra for AI means gaining first mover advantage.
Only if AI feeds on more taste than garbage.
This is a testable hypotheses with severe lack of citations. Intuition would argue the opposite. We learn by using our brains, if we offload the thinking to a machine and copy their output we don‘t learn. A child does not learn multiplication by using a calculator, and a language learner will not learn a new language by machine translating every sentence. In both cases all they’ve learnt is using a tool to do what they skipped learning.
1. AI is for cheating and doing the work for you. Obviously it won't help you learn faster because you won't have to do any thinking at all.
2. AI is an always-available question answering machine. It's like having a teaching assistant who you can ask about anything at any time. This means you can greatly accelerate the process of learning new things.
I'm in team 2, but given how many people are in team 1 (and may not even acknowledge team 2 as even being a possibility) I suspect there may be some core values or different-types-of-people factors at play here.
But even with category 2. I think that still does not absolve AI as a cheating machine. Doing research is a skill and if you ask AI to do the research for you that is a skill a junior developer simply never learns.
"The expertise reversal effect is present when instructional assistance leads to increased learning gains in novices, but decreased learning gains in experts."
There's a whole lot of depth to the question of how AI tools support or atrophy learning for different levels of expertise.
For such a person, I believe AI can be very empowering for learning. Like Google, wikipedia and stack overflow, Arxiv before it - AI tools give access to a lot of information. It allows to quickly dig deep into any topic you can imagine. And yes, the quality is variable - so one needs to find ways to filter and synthesize from imperfect info. But that was also the case before. Furthermore AI tools can be used to find holes in arguments or a paper. And by coding one can use it to test out things in practice. These are also powerful (albeit imperfect) learning tools. But they will not apply themselves.
And as we are talking about junior developers it is safe to assume your conditions (1), (2), and (4) are all true, if any of them are false, then why did that person apply for and get a job as a junior developer? As for condition (3), all workplaces eventually hires a person who does not fulfill this, then they either fire that person, or they give them a talk and the developer grows out of it and changes their behavior to fulfill that condition.
Aside: you listed 4 conditions for learning. I am not sure these are actually conditions recognized as such by behavior science. In fact, I doubt they are and that these conditions are just your opinions (man).
This is a contradictory statement imo.
Digging deep still takes the same amount of time it used to. AI accelerates the surface level (badly, tbh), it doesn't accelerate digging deep. Becoming an expert still takes time and effort, there really aren't shortcuts.
To torture the Iron Man metaphor a bit. If you're not an expert without the AI, then you're not an expert with it.
Better headline: "Why AI Multiplies Developer Skills Rather Than Replacing Them"
Fewer developers required to achieve the same things means a lot of people are going to be unemployed
It also means that the people who remain will likely be paid less. Why would you pay a senior salary when you could pay a junior salary plus AI subscription and get "the same result"?
I think Software Devs are in for a rough time. I've been doing this for 15 years now, and I'm not looking forward to it. I'm honestly thinking about re-skilling to a different industry. Even if it pays less, it's probably worth it to sit out this shitshow.
It's the same thing that happened to every other skilled profession that was automated in the past. That's why unions became a thing and they started busting heads until their employers paid them more.
Edit: the only way I can see software developer salaries staying the same is if the amount of work available for them expands dramatically.
Hypothetically if half of software developers are laid off and replaced by AI, there will need to be twice as many software development jobs in order for salaries to not go down
Also keep in mind that even if salaries remain flat, inflation means you're making less.
What’s not clear to me is: if writing more code per engineer is possible, does that result in fewer engineers or just more software, especially in areas that traditionally got squeezed: UX, testing, DevEx, documentation, etc. Perhaps the bar just gets raised?
And still worth repeating that AI has net negative gain in team settings but is a booster for lone wolves like me.
I work with two pretty green developers. The rate that they can make a mess is now phenomenal. And the sense of confidence the tools give them with early successes, means any experience I might have to offer means less now. Which is ok, I’m not going to be that “my experience has to be useful to you so I still fell relevant” old guy. But I do find myself curious how “lessons are learned” that lead to greater and greater tool exploitation in this brave new world.
(I think I'm reading this the right way but if not feel free to correct).
In a word: pain.
Until there's a legitimate threat to their well-being (emotional, psychological, or financial), the lessons won't be truly "learned." Until you know the true cost of a decision, you're flying high.
Older engineers have dealt with this organically so it's kind of encoded into their DNA. The very reason certain things aren't done (or a certain way) is because that pain has already been felt/encouraged learning a better way.