Hacker News Reader

Comment by tomjen3 | Hacker News Reader

As someone else who is an IT consultant.

You need to run away from any client who thinks your primary purpose is to write code. You must run away from the business if YOU think your primary purpose is to write code.

You should be able to write code and do it well, But the AIs, and I'm not even talking about the ones on the frontier, have been able to write code faster than I have for quite some time.

What you need to explain to your customers is all the things around writing code: software architecture, performance, and so on. Also make sure you have some understanding of the customers business, so you can suggest additional ways to make their lives better/make more money.

Software developers have a chance. Code monkeys? None.

View on HN

The problem is Claude Fable is now better than most programmers I know at software architecture and performance optimization as well.

That's a popular type of AI cope.

First, I am aware they have been able to write code for some time. I made my first LLM coding agent experiment the day after ChatGPT first blew up in November 2022.

I haven't been a "code monkey" in the last say 15 or 20 years of my programming. I would argue also that code money was never really a thing, it was just an excuse that pretentious overpaid developers used for the existence of underpaid exploited programmers. 95% of programmers have to do requirements analysis and design regardless of their pay grade. I learned a long time ago how important requirements analysis and good design is. And the jobs I am applying to largely specify architecture and requirements analysis in the description. Employers are aware of code generation tools.

But also, the premise that writing the code is not the hard part is just nonsense. Sure requirements analysis is harder than people realize, good design is hard and so is understanding things about proper and closed iteration. But that stuff is not, in the aggregate, harder than the code.

And also, frontier models can absolutely do requirements analysis and architecture. And the sheer speed of implementation means that there is a huge built-in advantage for iterating more effectively.

Two points of disagreement:

"Code monkey" absolutely was and still is a thing. I was hired by Big Name Co originally to be staff but a reorg had me do typical senior position duties for around a year, and it was hell. Every decision was made over our heads, feedback was unwelcome because the feature had already gone through design and gotten layers of sign-offs from different areas of the org, etc. My sole purpose was to write code and review peer code. Staying there a full year was way too much.

Second point, requirements analysis is hard because:

* Different stakeholders have conflicting goals, sometimes mutually exclusive * Some stakeholders have ideas that are actively harmful to users, and you must flex political capital to nip it in the bud * Some stakeholders think they know what they want with a far greater degree of clarity than they actually do, and lack the time to sit down and suss out the nuances, because you're a side-show in the grander scheme of their own priorities.

Writing code is a heck of a lot easier than dealing with people at the edges.

Those are good points, but that mostly comes down to lack of organizational status or office politics etc. which is independent of capability level and largely orthogonal to whether it's a human programmer or an AI agent. Unless you are redefining "software engineer" to be more like a political operator. But that goes for any human group and any job. And anyway after a certain level, not providing the senior engineers and or project managers with sufficient political sway to realize projects goals is a management failure. Unless again you are defining software engineer as someone who is a master social manipulator in the context of their job.

A big part of an engineering performing requirements analysis is owning the technical understanding of the requirements and identifying areas where the requirements are not technically feasible, can be done with less expense with adjustments, or can be better achieved with a different solution.

AI will help you draft the communication of that knowledge, but it won't help you actually deliver the knowledge or ensure that the knowledge was appropriately received. As you say, it is a fundamentally human problem, which is why I maintain that writing code is easier.

bingo. to give an analogy in terms of law firms - you can either be a partner who brings in new business or the associate who does the grunt work of reviewing/writing contracts.

guess one which is valuable ?

Reply on news.ycombinator.com