---- My poem about sacrificing Engineering Best Practices on the Altar of AI Efficiency.
First, they made CI/CD pipelines to automate the builds and deployment - and I said nothing because I didn't want to watch the scripts run. It's only running my code anyway, and more automation is good. Less for me to do!
Then, they integrated AI into our IDE - and I said nothing because the guardrails kept it in check. It's only writing code following my instructions, and more automation is good. Less for me to do!
Then, they requested source control access so the business owners could skip all the feature planning back-and-forth and just chat with an AI agent until the feature looks how they want it - and I said nothing because they're not merging into master. I'm still in charge of reviewing code, and I have an AI agent helping me review code using some rules and invariants I've handed it, and more automation is good. Less for me to do!
Now, they are requesting an always-on AI agent reviews and merges their code into master with 0 human interaction because their PRs which contain 300K lines changed each have started to pile up over the last 3 days. And I have to just do it because boss man pays my bills. But hey, more automation is good. Less for me to do.... until everything breaks and I have 1 hour to find why the million lines of code merged this week don't work anymore.
----
The story makes it sound like I didn't push back. I did. But after being forced to ignore a full career's worth of red flags and best practices I'm now just whoring my skills out to see how deep this AI-fully-replacing-devs rabbit hole goes. Besides, when else am I going to have crazy money to just throw at a new server and set it up to replace the SDLC end-to-end with a rich man's AI? And there's still the fun technical challenge of "can I make this system secure enough that even when I automate myself out of a job I couldn't revenge hack it?"
Shit. Found this at 8:30am, happy to click a few times before starting work... Suddenly its 10am? Huh? Also, minor spoilers, but it looks like making a crazy OP cell form does nothing once you evolve. I had some crazy RNA/DNA numbers, then as soon as I evolved its like haha none of that matters. Reminds me of evolving out of cell form in SPORE
I've said "code was always the easy part" recently so I should probably explain where I'm coming from. I think the practice of software engineering includes that "understanding of the relationship between code, business, people and teams" you mention, which essentially boils down to the ability to skillfully design a system - regardless of whether it's a big cloud-based web application or a tiny cli tool for use within a team.
To me, the difficult parts of software engineering are in the design. That's where you're defining the problem you're trying to solve, picking what technology to build upon, what kind of architecture you're planning on implementing, ruling out what does/doesn't make sense, taking input from stakeholders, and finding the balance between price and performance. Once all that is covered I generally have a good high-level mental map of a system's structure, and actually writing the code to bring those ideas to life truly is the easier part.
That being said, I still believe writing good code is a skill that is only learned through experience/the practice of actually writing code. And that experience is necessary for reviewing code - regardless of whether the code you're reviewing was written by humans or AI.
Kind of like baking. Putting it in the oven was always the easy part. But combining the right ingredients in the right ratios is necessary, and much more difficult than the putting-it-in-the-oven part. And even then, it takes experience to know when something needs to be pulled early or left in longer. Because ovens are non-deterministic.
> To me, the difficult parts of software engineering are in the design. That's where you're defining the problem you're trying to solve, picking what technology to build upon, what kind of architecture you're planning on implementing, ruling out what does/doesn't make sense, taking input from stakeholders, and finding the balance between price and performance.
This is exactly why I became a PM [1]. I wanted to do "harder" things that had bigger scope than I could do as "just an engineer", and the kind of roles that offer that scope within engineering end up being thin on the ground. Unfortunately, what I've generally found is that being a technical PM is a good way to have people try to knife you constantly. Most PMs are technically illiterate MBA types, and carry a deep grudge against anyone who gives the technology any consideration. They're also good at politics, and want you to die. On the other side of the coin, because most PMs are technically illiterate, engineers often instinctively reject you like a tumor. To overcome this, you need to appeal to the technology, which puts more of a target on your back from the other PMs...
Anyway, my point is that this is all very sad, because you're describing is exactly what a PM does -- but with technical competence. And because of the way the industry is structured, the people who can do that either get shuffled into people management, or reach a rapid career ceiling when so-called "architecture" roles aren't available.
There's this pervasive myth that you cannot be good at technology while also prioritizing the business needs, but usually what this really means is that the "business types" bias in one direction exclusively, and treat the technology as the enemy. It's why so many companies are AI-maxxing now -- the promise of replacing the expensive nerds is the eternal flame for the MBA.
[1] well, that, plus after being a founder, people were suddenly willing to hire me to be a PM...
"Product Manager, your job is to find the mix of features which is fast and cheap and good, and then browbeat the Engineers into implementing them. Don't just parrot me their excuses, fix it!"
Sure, I'm not saying design is easy either, but even if you have detailed user requirements, a fully spec'ed out UI, and some general technical requirements, translating that to (working) code is still really, really difficult.
I used to do a lot of interviews in my previous career, and I can't tell you the number of times I'd be interviewing someone who could talk a good game, but the second it got to writing code, if the world depended on them being able to write a simple correct loop, we'd all be dead. I know everyone shits on Lee code, and I agree the "brain teaser-y" nature of it doesn't often match real world development, but often times I'd tell folks almost exactly what the code needed to do, in English, and they still couldn't translate that to sensible code.
Last side note, when this topic comes up I feel some folks are really biking it down to the absurd "typing was never the hard part". Well, yeah, sure. But actually writing correct, maintainable, well-structured code is (was?) very much at least one of the hard parts.
> Last side note, when this topic comes up I feel some folks are really biking it down to the absurd "typing was never the hard part
Compared to the other parts. If you can do the problem solving part and the design part,code is easy. If you can't write code, I strongly doubt your ability to do the first two.
People talking good game always try to keep it high level and full of jargon. Once you ask them to explain part of the design, you'll see the inconsistency and holes of what they are saying very easily.
Your analogy to baking makes no sense. At best, compiling would be like putting a cake in the oven. Making the cake is coding.
> ovens are non-deterministic
Uhhh… no? Modulo calibration drift, they will get to and hold a commanded temperature for as long as you tell them to. The ambient humidity and temperature in your house / bakery may differ - which can absolutely affect some foods - but ovens are pretty binary.
First, they made CI/CD pipelines to automate the builds and deployment - and I said nothing because I didn't want to watch the scripts run. It's only running my code anyway, and more automation is good. Less for me to do!
Then, they integrated AI into our IDE - and I said nothing because the guardrails kept it in check. It's only writing code following my instructions, and more automation is good. Less for me to do!
Then, they requested source control access so the business owners could skip all the feature planning back-and-forth and just chat with an AI agent until the feature looks how they want it - and I said nothing because they're not merging into master. I'm still in charge of reviewing code, and I have an AI agent helping me review code using some rules and invariants I've handed it, and more automation is good. Less for me to do!
Now, they are requesting an always-on AI agent reviews and merges their code into master with 0 human interaction because their PRs which contain 300K lines changed each have started to pile up over the last 3 days. And I have to just do it because boss man pays my bills. But hey, more automation is good. Less for me to do.... until everything breaks and I have 1 hour to find why the million lines of code merged this week don't work anymore.
----
The story makes it sound like I didn't push back. I did. But after being forced to ignore a full career's worth of red flags and best practices I'm now just whoring my skills out to see how deep this AI-fully-replacing-devs rabbit hole goes. Besides, when else am I going to have crazy money to just throw at a new server and set it up to replace the SDLC end-to-end with a rich man's AI? And there's still the fun technical challenge of "can I make this system secure enough that even when I automate myself out of a job I couldn't revenge hack it?"