
AI coding is blurring the lines between engineers, PMs, and designers. In the short-term, it's going to cause havoc. What happens long-term?
The first time I sat down and used Claude Code's Opus 4.5 to build software, I couldn't believe how good it was.
My next thought was: this is going to change the dynamics inside software teams.
Marc Andreessen recently described the moment as a “Mexican standoff:”
Every engineer now thinks they can be a PM and a designer.
Every PM thinks they can code and design.
Every designer thinks they can do the other two.
The risk is that many individual contributors believe they no longer need the others.
In the short term, this is going to be incredibly disruptive for team culture.
When rare skills become more attainable, people feel pressure to move "up the stack" to prove their value.
Kent Beck expressed this sentiment on X:
"The value of 90% of my skills just dropped to $0. The leverage of my remaining 10% went up a thousand."
My worry is that everyone is recalibrating toward the same 10%. Individual contributors are all racing toward the same layer of leverage.
In Ben Werdmuller's piece, "AI coding works now," he gives advice specifically to engineers. He comments, "AI coding shifts the center of gravity from implementation to judgment," and recommends that engineers focus on these four skills:
Crafting goals for the product
Understanding what users actually want
Being crystal clear about the experience and value you're creating
Designing, building, and maintaining robust software architecture
The challenge to Ben's advice is that lots of people believe they own these skills.
Company Leadership wants to own goals and strategy.
Product Managers see themselves as uniquely qualified to understand what users want.
Designers want control over crafting the user experience.
And Marketing and Sales want to define how value is expressed to the customer.
Engineers own planning and implementing architecture. Performance, scalability, security; it all requires real expertise.
With AI, all of these roles become more fluid. As more people build software and cycle time compresses, they'll start to absorb lessons that it took their colleagues decades to learn.
And ultimately, more individuals will want to own the highest-leverage identity: “In my role, I solve problems and provide value to users.”
Left unchecked, there will be jockeying for position. There might be more animosity (and jealousy) between team members.
I started asking my friends who run software teams what they're seeing.
One founder told me:
I think you're correct here. We're already seeing it — mainly around PMs wanting to write code.
Another said:
We are feeling it on our team for sure. Everyone kinda feels like they can do everyone else's job.
The President of an established software company described a similar shift:
“Our team is a Head of Product and 15 engineers. On smaller projects he's shipping a lot of PRs himself with no developer in the loop.”
But the biggest change wasn't just in who is doing the work. It was in who they’re hiring:
“Where you really see the impact on jobs with us is in the people we're no longer hiring: specialists. In this new era, generalists win.”
John O'Nolan, founder of Ghost, commented:
It’s a turbulent time, for sure — but overall I’m pretty optimistic.
The thing that hasn’t happened yet that I expect will happen in future is that, in addition to old roles being compressed, new roles emerge.
My hope (once the dust settles) is that we come out the other side with more collaboration. Instead of competing for leverage, I'm hoping individual contributors find new ways to work together.
For example, what if Product Managers and Engineers did more AI-driven pair programming? The PM could focus on customer behavior and product goals. The engineer could evaluate architecture, security, and maintainability. They would iterate together in real time, using LLMs.
My friend Matt Stauffer, CEO of Tighten, commented that they're doing this right now:
I demo work to my Biz Dev Manager (the product owner for this internal project), she asks for changes, and then we prompt the LLM live, together. I'm better at prompting and reviewing, she knows the domain better than me. This kind of pair programming is great, because I'm moving quickly and then she can jump off the call later when I'm reviewing, iterating, etc.
Ben Werdmuller's prescription would still be relevant: "All code must have a human owner who will take responsibility for it." In my scenario, the PM and the engineer would co-own the pull request.
37signals is famous for having two-person teams (one designer, one engineer). In an AI world, maybe a paradigm like that becomes the norm?
Once the turbulence has died down, folks will need a new vision for how to work together. How can we use AI and collaborate in ways that help us build better software?
Cheers,
Justin Jackson
Discuss this on Hacker NewsConnect with me on:
🦋 Bluesky
Published on March 4th, 2026
I don't know why people are talking so theoretically. This was months ago.
My friends have startups, I know a lot of engineers. The startups have been laying off people for months, and many of my engineer friends don't have jobs anymore.
Teams are already ruined. I just don't think the companies are. In many cases this seems like rational reallocation of capital to AI, and in a VC funded ecosystem you're failing at your job if you're not following the math.
I think you must have a very cushy job if you're still armchair speculating about this.
If a startup is laying off engineers then it’s dead in the water. That means it’s not growing and focused on cost cutting at the expense of velocity. Thats what a large company does. The issue isn’t AI but the startup fundamentally being broken and this being a last gasp for air before it dies.
Yeah what a lot of people are missing here is tons of small startups are laying people off, but it's not because they don't need engineers, it's because they are out of runway because their entire vertical (usually some sort of SaaS, often b2b SaaS) is basically now nonexistent. Traditionally businesses favored buying software over building it for cost reasons. Now they can cheaply build exactly what they want instead of paying through the teeth for something that is only slightly like what they want. This doesn't mean the work is gone, but it does largely mean large swathes of the SaaS vertical will be gone. The work itself is shifting to the individual businesses that were once the customers of the SaaS.
SWEs will be fine, all these small VC-funded startups building another CRUD app will not.
I work for a startup that makes a b2b SaaS that is _way_ too complex for anyone to spec out in a markdown file, especially when taking things like ITAR compliance into consideration.
We have seen steady growth and there’s been no signs of slowing down.
Our software facilitates order/quote/factory floor workflow automation with auditable trails in the manufacturing space, with cad file analysis and complex procedural pricing equations for quote generation, alongside a Shopify style storefront and many more goodies. We interface with things like shipping, taxes, erp integrations, and so much more.
I don’t see anyone vibe coding an alternative to our software even if they could. Manufacturers have enough on their plate managing their factory floors.
That said, we facilitate $millions in manufacturing orders per week and our engineering team is 3 people. We couldn’t do what we do without AI, and we would have needed to hire more engineers to handle the scale of our business if it weren’t for the power of Claude Code and Cursor.
Or there's just not enough parallelizable work for the business model...
Which again means lack of growth.
A poster-child startup is one that has a long waitlist of willing future customers, and whose engineering team is scaling the tech up, up, up to keep up with the demand.
HN is an interesting place.
6 years ago it was “you need that many engineers, lol, I can build a clone this weekend.”
Now it’s “you need many engineers, trust me bro.”
No, it's "if you already have engineers that know your stack and customers and business then getting rid of them to save a bit of short term cash is stupid unless you're out of runway because of bad business decisions." That is a tangential point to hiring more engineers. You may slow down the rate or hiring however the ROI for getting rid of them in a growing startup is silly imho. A collapsing startup is a different beast.
> HN is an interesting place.
How is it interesting that in a forum with thousands of active users, someone posted a comment that disagreed with other comments from 6 years ago?
Even in this thread, there's many different opinions being expressed.
It's not a single user, rather the majority prevailing opinion/most upvoted comments.
Based on what? Your personal observation and memory bias?
Oh I'm happy this has a name now! Even if it's quite silly.
We have yet to hit this phase in the cycle: "Hey we laid off all our engineers 6 months ago and vibe-coded this thing and now it's super buggy and AI can't fix it. Can you (senior engineer consultant) look under the hood and fix it?"
Senior engineer looks under the hood, sees 500k lines of incomprehensible spaghetti mess with emoji comments everywhere, runs out the door and never looks back.
> Senior engineer looks under the hood, sees 500k lines of incomprehensible spaghetti mess with emoji comments everywhere, runs out the door and never looks back.
Senior engineering _consultant_ looks at those 500k lines of incomprehensible spaghetti mess and sees $$$: months or years of contracts and likely very dysfunctional management that is willing to pay multiple times the cost of full time employees to keep the burn on a non-payroll line and/or keep the “AI first” story rolling on.
> Senior engineering _consultant_ looks at those 500k lines of incomprehensible spaghetti mess and sees $$$: months or years of contracts and likely very dysfunctional management that is willing to pay multiple times the cost of full time employees to keep the burn on a non-payroll line and/or keep the “AI first” story rolling on.
That's not been my experience. Even pre-AI, when I was asked to find a bug in some hacked-together codebase, sticker shock was often the result.
"What do you mean, billing for a week? The guy who created this is an actual software engineer and you're billing just as much as he did!"
I've got a list of small ex-clients who won't get work from me anymore, unless they are happy with "Here's my weekly rate, 1 week minimum".
Hourly rates don't work on a client who considers $200/m to be overpaying for s/ware development services.
If that’s how this works out then perhaps Accenture will be okay after all.
I clean up vibe code as a senior engineer consultant, it's quite lucrative actually. I specifically offer this service because I know how to do it.
This could be a superinteresting field in the future, I guess?
But how do you land contracts? Nobody will post on LinkedIn like "Hiring consultant to cleanup or AI-mess-codebase"? :-D So, nobody will admit that they are in trouble already,so how do you find out?
I've been thinking of jumping into this sooner rather than later because I see this becoming a Thing eventually. Are you enjoying it?
It's fine, I suppose. It's like a puzzle, and you really need to be comfortable with banging your head against a wall trying to make work what is essentially immediately created legacy code by the LLM.
Works it (edit sp: Would it) help if the coders' prompts were available (checked in)?
If code is your documentation I assume it is hard to divine intent?
Prompts wouldn't really help, no. You'll have a high level description based on what you're being hired for then the code tells the story.
No, they're going to stop now, yeah that makes a lot more sense.
I think it's less armchair speculating about the observable outcome, that people are losing their jobs, but the why. AI coding tools aren't making 10x developers, they aren't even making 1.5x developers. They also aren't making "PMs who code" or "designers who code."
It would be really cool if this was the case, I would be singing the praises of these tools finally realizing Stallman's dream of end users who can take control of all the software in their lives for their own benefit. And the huge gains we would see in open source where "man I wish there was a tool that could…" becomes "I'm gonna make a tool that…"
So personally I think it's just a continuation of the belt tightening that was and still is occurring across the economy. I don't think our industry is particularly special on this, everyone is trying to cut headcount right now.
> they aren't even making 1.5x developers
I won't try to speak for anyone other than myself, but my multiplier is definitely over 1.5x, probably higher than 5x.
I choose to sit on my hands in my freed up time so upper management does not catch on to and exploit this fact. Eventually they will though via overzealous coworkers.
> I won't try to speak for anyone other than myself, but my multiplier is definitely over 1.5x, probably higher than 5x.
So you now complete in a single Monday what used to take you Monday-Friday?
Can you even review that fast? How many LoC per day are you generating?
More like a day's worth of coding condensed into half an hour. Time to review/test is mostly unchanged.
Day to day is mainly minor feature additions into a stable product so not a huge amount of code churn.
Rather "do in 1 week what was 1 month before"
It’s easy to produce a high volume of code, sure, but it is not equally easy to test, verify, and integrate it. And with a high volume of code, there is a high volume of shit to review & test & integrate. For companies that give a shit about not vibe coding their way into a disaster (because they have lucrative enterprise contracts that depend on reliability & security), that’s the real blocker. (Plus, these types of projects are big, not trivial, and things are harder to integrate & properly test because of that.)
Not to mention, if a team wants to keep a semblance of understanding of what they own & ship… it can be exhausting to have a huge volume of new code coming into the system.
It’s definitely a productivity unlock. For sure. But there are a lot of knock-on effects we’re still figuring out that counteract how much extra “value” we’re shipping
In my case, the volume of code is roughly the same. I'm not using the efficiency towards pumping out more code, just using it to be AFK more.
I spend enough time iterating and refining to the point I'm comfortable taking ownership of the outputted code. Perhaps hypocritically, I do mald when people upload code for review that they clearly haven't taken the effort to read through critically.
Well, but AI also helps by writing good comments & docs :-) (one thing Im usually very brief)
It’s not hard to 5x your productivity when you were close to zero to start with.
Is that you, boss?
People with a lower multiplier are either in the minority of developers solving genuinely hard/novel problems or, more likely, they've just not figured out how to tap into AI's potential.
Granted, to your point, a decent chunk of the HN crowd belongs to the former and can't relate to us paycheck stealers.
I always hear people say this, but it’s not clear to me what exactly is so difficult about using AI that otherwise-competent developers “can’t figure it out”
My hunch is it's a combination of
* coming in with a bias of not wanting it to work
* having too high of an expectation
* giving up too early
* not trying SOTA models
* not taking the effort to communicate intuitive or painfully obvious things
But perhaps it is too dumb to solve the type of problems you guys are working on and no amount of cajoling will help. All I know is "it works for me."
Agreed, the tech job market was bad before AI was useful.
The "I'm gonna make a tool" thing is slowly happening and will probably help Linux, knocking on wood... https://x.com/xpasky/status/2030016470730658181
Aaaannnnd they're out of business and it was because of slowing demand and tightening credit the whole time.
Here in Europe this is not a thing, I've been hearing about such cases mostly from the US where it's clear that there is a recession going - I don't know why this is not blatantly obvious to everyone who does not view reality as whatever is said by the talking heads on TV.
As an engineer and a daily if not hourly user of Claude Code, I would never dream I could do the jobs of my product / designer teammates. Not because I don’t have opinions on product or design, but simply because they do me the huge service of attending meetings so I don’t have to.
I recognize the necessary evil that is Zoom calls and face-to-face time in the larger context of running a business, but I also know what I’m good at and what I’m not. And long, drawn-out “alignment sessions” are not in my wheelhouse. If my PM and design friends are happy to take that bullet for me, I’m happy to let them do so.
When the product marketer, product manager, and designer are the same person there is no alignment meeting.
In my experience at BigCorp, Inc., "alignment meetings" are for meeting with other teams, not for meeting with your own team. You'd just call that a "team meeting", "feature crew meeting", "leads meeting" (if it's just leads), or something to that effect. In BigCorp, Inc. you traditionally need to have both kinds of meetings somewhat regularly. Not sure how the advent of AI will change that structure.
They meet with customers as often as they meet with each other. Another one of those necessary evils IMO- it's not fun but it needs to get done.
The final frontier: a warm body.
I think the reality is that these tools are good enough that, to some degree, all three of the roles are correct, everyone is now definitely more able to do others' roles, leadership knows this, and even if there's a period of inefficiency or overwork or lower quality output, there's going to be a drive toward collapsing responsibilities. OpenAI saw this early: Member of Technical Staff. The degree to which this negatively impacts the team or company's output is really a function of (1) how drastically leadership does layoffs, (2) how quickly models and agents continue to improve, and (3) how earnestly leadership can admit mistakes and backfill humans when they realize they've over-fired.
In other words: Yes it will ruin our team.