If you can't code by hand professionally anymore, what are you being paid to do? Bring the specs to the LLMs? Deal with the customers so the LLMs don't have to?
Yet, there is no way a product manager without any coding experience could have done it. First, the API needed to communicate to the main app correctly such as formatting, correcting data. This required human engineer guidance and experience working with expected data. AI was lost. Second, the API was designed extremely poorly. You first had to make a request, then retry a second endpoint over and over again while the Chinese API did its thing in the background. Yes, I had to poll it. I then had to do load testing to make sure it was reliable (it wasn't). In the end, I gave a recommendation that we shouldn't rely on this Chinese company and back out of the deal before we send them a huge deposit.
A non-technical PM couldn't have done what I did... for at least a few more years. You need a background and experience in software development to even know what to prompt the AI. Not only that, in the last 3 years, I developed an intuition on where LLMs fail and succeed when writing code.
I still have a job. My role has changed. I haven't written more than 10 lines of code in a day for months now. Yes, it's kind of scary for software devs right now but I'm honestly loving this as I was never the kind of dev who loved the code, just someone who needed to code to get what I wanted.
Everything just changed. Fundamentally.
If you don't adapt to these tools, you will be slower than your peers. Few businesses will tolerate that.
This is competitive cycling. Claude is a modern bike with steroids. You can stay on a penny farthing, but that's not advised.
You can write 10x the code - good code. You can review and edit it before committing it. Nothing changes from a code quality perspective. Only speed.
What remains to be seen is how many of us the market needs and how much the market will pay us.
I'm hoping demand and comp remain constant, but we'll see.
The one thing I will say is that we need ownership in these systems ASAP, or we'll become serfs to computing.
The management has decided that the latter is preferable for short term gains.
That's what so many of you are not getting.
Look at the pretty pictures AI generates. That's where we are with code now. Except you have ComfyUI instead of ChatGPT. You can work with precision.
I'm a 500k TC senior SWE. I write six nines, active-active, billion dollar a day systems. I'm no stranger to writing thirty page design documents. These systems can work in my domain just fine.
> Look at the pretty pictures AI generates. That's where we are with code now.
Yep, that's where we are with code now. Pretty - until you look close. Dogshit - if you care to notice details.
When I notice a genAI image, I force myself to stop and inspect it closely to find what nonsensical thing it did.
I've found something every time I looked, since starting this routine.
"Glossy" might be a good word (no i don't mean literally shiny, even if they are sometimes that).
Can they produce working code? Of course. Will you need to review it with much more scrutiny to catch errors? Also yes, which makes me question the supposed productivity boost.
There are multiple people on each team, you can not know how closely each teammate monitored their AI.
Somebody who does not car will vastly outperform your output. By orders of magnitude. With the current unicorn chasing trends, that approach tends to be more rewarded.
This produces an incentive to not actually care about the quality. Which will cause issues down the road.
I quite like using AI. I do monitor what it’s doing when I’m building something that should work for a long time. I also do total blind vibe coded scripts when they will never see production.
But for large programs that will require maintenance for years, these things can be dangerous.
It's actually worse than that, because really the first case is "produce 1x good code". The hard part was never typing the code, it was understanding and making sure the code works. And with LLMs as unreliable as they are, you have to carefully review every line they produce - at which point you didn't save any time over doing it yourself.
I agree, but this is an oversimplification - we don't always get the speed boosts, specifically when we don't stay pragmatic about the process.
I have a small set of steps that I follow to really boost my productivity and get the speed advantage.
(Note: I am talking about AI-coding and not Vibe-coding) - You give all the specs, and there are "some" chances that LLM will generate code exactly required. - In most cases, you will need to do >2 design iterations and many small iterations, like instructing LLMs to properly handle error gracefully recover from errors. - This will definitely increase speed 2x-3x, but we still need to review everything. - Also, this doesn't take into account the edge cases our design missed. I don't know about big tech, but when I have to do the following to solve a problem
1. Figure out a potential solution
2. Make a hacky POC script to verify the proposed solution actually solves the problem
3. Design a decently robust system as a first iteration (that can have bugs)
4. Implement using AI
5. Verify each generated line
6. Find out edge cases and failure modes missed during design and repeat from step3 to tweak the design, or repeat from step4 to fix bug.
WHENEVER I jump directly from 1 -> 3 (vague design) -> 5, Speed advantages become obsolete.
This is just blatantly false.
But yeah, if anybody can do it, the salaries are going to plummet. You don't need a CS degree to tell the AI to try again.
(Color me skeptical.)
I’ve spent enough time working with cross-functional stakeholders to know that the vast majority of PM (whether of the product, program, or project variety), will not be capable of running AI towards any meaningful software development goal. At best they can build impressive prototypes and demos, at worst they will corrupt data in a company-destroying level of failure.
Right now millions of developers are providing tons of architecture questions and answers. That's all going to be used as training data for the next model coming out in 6 months time.
This is a moat on our jobs as deep as a puddle.
If you believe LLMs will be able to do complex coding tasks, you must also concede they will be able to make the relatively simpler architecture choices easily simply by asking the right questions. Something they're already starting to be able to do.
Now you've put your finger on something. Who is capable of asking the right questions?
It's not a massive jump to go from, 'add a button above the table to the right that when clicked downloads and excel file', to 'The client's asking to dowbload an excel file".
If you believe the LLMs will graduate from junior level coding to senior in the next year, which they're clearly not capable of doing yet despite all the hype, there is no moat of going from coder to BA to PM.
And then you don't need middle management either.
No one but seniors with years and years of experience is producing like that. As evidenced how much the juniors i work with struggle to do the same
How do you tell a computer exactly what you want it to do, without using code?
If AI was following my instructions instead of ignoring them, and after complaining telling me it is sorry, and returns some other implementation which also fails to follow my instructions ... :-(
I’ve been working for cloud consulting companies/departments for six years.
Customers were willing to pay mid level (L5) consultants with @amazon.com by their names (AWS ProServe) $x to do one “workstream”/epic worth of work. I got paid $x - Amazon’s cut in cash and RSUs.
Once I got Amazon’ed, I had to get a staff level position (senior equivalent at BigTech) at a third party company where now I am responsible for larger projects. Before I would have needed people - now I need code gen tools and my quarter century of development experience and my decade of experience leading implementations + coding.
> Bob Slydell: What you do at Initech is you take the specifications from the customer and bring them down to the software engineers?
> Tom Smykowski: Yes, yes that's right.
> Bob Porter: Well then I just have to ask why can't the customers take them directly to the software people?
> Tom Smykowski: Well, I'll tell you why, because, engineers are not good at dealing with customers.
> Bob Slydell: So you physically take the specs from the customer?
> Tom Smykowski: Well... No. My secretary does that, or they're faxed.
> Bob Porter: So then you must physically bring them to the software people?
> Tom Smykowski: Well. No. Ah sometimes.
> Bob Slydell: What would you say you do here?
The agents are the engineers now.
It's a bit like eating junk food everyday and ah sometimes I go see the doctor he keep saying I should eat more healthy and lose some weight.
Then you are simply fucked. The code you deliver will contain bugs which LLM sometimes will be able to fix and sometimes will be not. And as a person who has no clue you will have no idea how to fix it when LLM can not. Also even when LLM code is correct it can and sometimes does introduce gross performance fuckups, like using patterns that employ N-square complexity instead of N for example. Again as a clueless person you are fucked. And if one goes to areas like concurrency, multithreading optimizations one gets fucked even more. I can go on and on on way more particular reasons to get screwed.
For a person who can hand code AI becomes amazing tool. For me - it helps immensely.
Your code in $INSERT_LANGUAGE is no less of a spec to machine code than english is to $INSERT_LANGUAGE.
Spec is still needed, spec is the core problem of engineering. Too much specialization have made job titles like $INSERT_LANGUAGE engineer, which deviated too far from the core problem, and it is being rectified now.