If thats true, I am sure some C-suite manager knows this already. Assuming management knows what they do, after all, they're getting payed for this. The time where engineer are trying to educate people above them should be over. Management gets payed for the big decisions. If they tank the company, so be it. I no longer care.
I think the argument here misses critical nuance; there is a difference between code used to implement a product and when code _is_ the product.
It goes without saying that agents have little to no product sense in any discipline. If you're building a game or an app or a business, your creative input still matters heavily! And the same is true for code; if the software is your product, then absolutely the context missed by skipping the writing process will degrade your output.
That doesn't mean that writing code wasn't a bottleneck even for creating well structured software projects. Being able to try multiple approaches (which would have previously been prohibitively expensive) can in many instances provide something a room of bickering humans never would have reached.
> Agents that consume context need agents that produce it. Once that loop is running, the organization has a written substrate it would never have produced on its own.
I'm not sure a business is helped by documentation that distilled from (hopefully present) PR descriptions and comments in JIRA, by agents. Or wherever this context is supposed to be reverse-engineered from.
It's hilarious to me to see the same kind of engineer, who throughout my career have constantly bitched and moaned about team meetings, agile ceremonies, issue trackers, backlogs, slack, emails, design reviews, and anything else that disrupted the hours of coding "flow state" they claimed as their most essential and sacred activity to be protected at all costs, suddenly, and with no hint of shame, start preaching about about the vital importance of collaborative activities and the apparent inconsequence of code and coding, the moment a machine was able to do the latter faster than them. I mean, they're not even wrong, but the nakedly hypocritical attitude of people who, until a year ago, were the most antisocial and least collaborative members of any team they were on is still extraordinary.
I don’t think that’s the issue. The problem is that with software you don’t know what a user might like until something is in production.
This is probably true of other fields too. But rolling back changes there is expensive (example construction).
But with software you can get to put things out and iterate. This is not to say identifying what’s needed isn’t important but you had roles where the product owner is getting feedback for the previous iteration while the devs are working on the current one.
With code assistants this loop collapses a LOT. Suddenly it can be a lot easier to define better what you need and in near real time also gauge how it would operate.
Both are true “leave me alone” and “you don’t know what to build”. Because the people identifying what to build aren’t the people doing the building.
Then there's the other kind of engineer, who would rather see the world burn and their friends destitute than spend another second in an agile meeting.
Nah they're reaching for something they're good at. Same with you bro.
The stark reality is this. Both coding and project management can be done with AI. I think coding is more important than all the fluff surrounding project management but with AI both are now ready to become obsolete.
The thing with project management is that it's a bit harder for AI to tackle because it's not just pure tokens it needs to deal with. We need to give the agent more tools to interact with real time and real world events for AI to fully take over this aspect of the job, but make no mistake... project management is easier in terms of skill (not in terms of effort).
An important thing can (and one may argue will) be overdone AND hvlfvssed stealing oxygen from another important thing.
While I'm glad you posted this point of view/framing which honestly needs highlighting in the name of a better discussion, I must remind that the moaning back then was for the ceremony stealing time from building.
That was me. I complained a lot about meetings, design docs, etc. I did not understand that the process of discovery is messy and what looks inefficient is not really. I expected sharper meetings, shorter docs etc. In retrospect I see my naivety but it took me too long to change my attitude.
No Thats not the same persons.Thats as simple as that. Those who used to be hyperfocused in the zone/flow so to get integrated designed consistent opiniated KISS Small-Is-Beautifull antipattern-free reusable code featuring the best abstraction layering with just the right amount of external dependencies and cognitive load ... these people are suffering a lot seeing the skills they cherished their whole life being devalued in less than a year. This opinion is a project manager's one. He's probably right. Both sides are right.
If coding by hand took 10x longer, why would it have bee unreasonable for people to demand more time to code? Seems like floored logic and you're just exciting to dunk on people?
I think veteran engineers have always known that the real problems with velocity have always been more organizational than technical. The inability for the business to define a focused, productive roadmap has always been the problem in software engineering. Constantly jumping to the next shiny thing that yields almost no ROI but never allowing systemic tech debt to be addressed has crippled many company's I have worked at in the long-term.
For veterans engineers that might be true. But for a junior engineer pre-AI, velocity has always been technical. I know junior engineers who after a whole year of writing C++ still does not grok std::unique_ptr; and this person consistently has the least velocity on their whole team. When I used to write performance reviews for junior engineers, their performance really was dominated by their velocity, which was roughly measured in lines of bug-free code written within a time period. A good junior engineer would be given a clearly defined feature and write good code quickly, whereas a worse junior engineer would be given the same thing and write code slowly or write buggy code quickly that required so much work debugging and rewriting.
“the programmer himself had a very modest view of his own work: his work derived all its significance from the existence of that wonderful machine. Because that was a unique machine, he knew only too well that his programs had only local significance and also, because it was patently obvious that this machine would have a limited lifetime, he knew that very little of his work would have a lasting value”
I think technical debt started to be somewhat of an issue somewhere in the early 1970s, maybe a few years earlier.
The paper hits the nail right on the head, but it misses the mark on the next constraint: how to decide what to build.
In the old days when writing code took up a lot of resources, the constraint was self-correcting since being off in your implementation was obvious enough that the error could be easily seen after three months of work on the wrong feature. Today, you could spend five wrong efforts in the same amount of time that it used to take you to implement one wrong effort.
The company website linked in the article is broken https://www.dottxt.ai/ on (mobile and desktop) Safari. Looks like your cert doesn’t cover the www subdomain.
What kind of projects are people working on, where understanding what features the management wants is the only difficult part and the rest can just be "typed out" (or, today, offloaded to an LLM)? If that's what you do, then I'm not surprised so many people on HN think LLMs can replace them.
I can see the division here already, and the cogs are afraid. As a dev of 25+ years, currently working for a small company who came from a global company, I see both sides. I'm very excited about AI and love to see my projects come to life so much faster. I still love the craft of code, but its always been about the product for me.
Probably true, but I, for one, have always liked documenting how the code I've written should be used, whether programmers calling APIs I've created, or end-users actually making use of a program's executable. I find writing the docs just as interesting and creative as writing code.
One of the bottlenecks has always been the code. That code has been stolen and is being laundered while companies rely on mediocre engineers who have never written anything of value to promote the burglary tools and call the process "writing software".
It is the same as putting an Einstein paper on a photocopier and call the process "writing a paper".
I agree with the point of the article though: code generation does not really work, the results are bloated and often wrong and people already had more features that they could absorb in 2020.
The solution to this mess is to have 18 year olds boycott studying computer science altogether, since the industry (and mediocre fellow "engineers") will treat them like human garbage.
Doesn't add up. I used to spend more than half my time coding, as did others. Besides the obvious cost, that coding took wall-time which meant talks had to wait. Sure a poor collaborator will jam things up a ton, but a team of at least ok collaborators used to be bottlenecked on code.
It seems like so many developers know this, yet here we are. SV pushing this AI slop economy. More code! Faster! Less testing! Less understanding! It's what we NEED!
The bottleneck has always been the human element. I too used to be one of those up-my-own-ass engineers who thought the most important part of my work was the machine, and it wasn’t until I began actually listening to others and their problems that I realized my function was far more than mere technology scaffolding.
That said, I’m also increasingly aware that puts me in a minority group. I got to see this first hand in a recent org where their codebase and product design hadn’t meaningfully evolved in nearly thirty years. NAT was a “game changer” to them - and one they refused to implement without tons of extraneous testing they would deliberately undermine, stall, and sabotage so they didn’t have to modernize their code accordingly. It was easier for the developers and stakeholders to preserve their own status quo rather than entertain alternatives, to the point of open hostility (name calling, insults, screaming, and a few threats) to anyone suggesting otherwise.
The human element has always been, and always will be the bottleneck. Stakeholders who don’t contribute updated or accurate datasets to automation systems, or who hold back development to preserve personal status and power, or who otherwise gum up the works on purpose to game their own careers.
That’s not to make the argument of “replace all humans with machines”, mind you. Just stating that an organization that incentivizes bad behavior will be slowed down versus ones that incentivize collaborative outcomes, and AI is just going to turbocharge that by removing the friction associated with code creation and shifting that elsewhere.
Absolutely matching the gut feel I've had lately. We've always been pretty good at producing bad code very fast. All of the other stuff - dependency management, learning what's valuable, ownership & boundaries, context switching costs, etc... have always been the bottlenecks and it's just more obvious now.
the bottleneck was never the software, that is the ship we ride,
people, are part of a team focused on a goal, they work together because they believe in that the ship is worth riding on and will reach its destination,
the ship should carry food people want,
team decides what food will be consumed,
captain tries first the food,
if food is good and people want it, people buy more
> Jevons Paradox: when something gets cheaper, you tend to use more of it, not less.
That's a butchering of Jevons paradox. What's stated is not a paradox, but a very natural effect. Obviously usage of something goes up when it gets cheaper.
What Jevons paradox actually describes is the situation where usage of a resource becomes more efficient (which means less of it is needed for a given task), but still the total usage of that resource increases.
94 comments
[ 4.0 ms ] story [ 90.1 ms ] threadThe flashing red dot on the web page is very annoying. Is there some design reason for that?
edit: I meant the <svg> inside `trail-map-container`
It goes without saying that agents have little to no product sense in any discipline. If you're building a game or an app or a business, your creative input still matters heavily! And the same is true for code; if the software is your product, then absolutely the context missed by skipping the writing process will degrade your output.
That doesn't mean that writing code wasn't a bottleneck even for creating well structured software projects. Being able to try multiple approaches (which would have previously been prohibitively expensive) can in many instances provide something a room of bickering humans never would have reached.
I don't think amount of software is what determines whether a company does well.
I don't think capturing quantity of context is that important either.
Now, quality of context. How well do the humans reason?
Then, attitude. How well do the humans respond to bad situations?
Then, resource management. How well does the company treat people and money?
Finally, luck. How much of the uncontrollables are in our favor?
Those are pretty good bottlenecks for a company. I doubt an agent is fixing any of those. At least any time soon.
I'm not sure a business is helped by documentation that distilled from (hopefully present) PR descriptions and comments in JIRA, by agents. Or wherever this context is supposed to be reverse-engineered from.
What even is your point? Are you... mad because the truthiness of a statement can change over time?
This is probably true of other fields too. But rolling back changes there is expensive (example construction).
But with software you can get to put things out and iterate. This is not to say identifying what’s needed isn’t important but you had roles where the product owner is getting feedback for the previous iteration while the devs are working on the current one.
With code assistants this loop collapses a LOT. Suddenly it can be a lot easier to define better what you need and in near real time also gauge how it would operate.
Both are true “leave me alone” and “you don’t know what to build”. Because the people identifying what to build aren’t the people doing the building.
The stark reality is this. Both coding and project management can be done with AI. I think coding is more important than all the fluff surrounding project management but with AI both are now ready to become obsolete.
The thing with project management is that it's a bit harder for AI to tackle because it's not just pure tokens it needs to deal with. We need to give the agent more tools to interact with real time and real world events for AI to fully take over this aspect of the job, but make no mistake... project management is easier in terms of skill (not in terms of effort).
While I'm glad you posted this point of view/framing which honestly needs highlighting in the name of a better discussion, I must remind that the moaning back then was for the ceremony stealing time from building.
1-There is significant collaboration and action required beyond just coding to successfully create+implement software systems
2-When performing the coding step, minimal interruptions are vastly more efficient than working in little chunks of time
If you go back far enough to the time when and one-offs and all programs were written from scratch, I doubt that. https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340...:
“the programmer himself had a very modest view of his own work: his work derived all its significance from the existence of that wonderful machine. Because that was a unique machine, he knew only too well that his programs had only local significance and also, because it was patently obvious that this machine would have a limited lifetime, he knew that very little of his work would have a lasting value”
I think technical debt started to be somewhat of an issue somewhere in the early 1970s, maybe a few years earlier.
In the old days when writing code took up a lot of resources, the constraint was self-correcting since being off in your implementation was obvious enough that the error could be easily seen after three months of work on the wrong feature. Today, you could spend five wrong efforts in the same amount of time that it used to take you to implement one wrong effort.
I don't think this sentence speaks for me. This is the sort of thing I love to do.
Probably true, but I, for one, have always liked documenting how the code I've written should be used, whether programmers calling APIs I've created, or end-users actually making use of a program's executable. I find writing the docs just as interesting and creative as writing code.
It is the same as putting an Einstein paper on a photocopier and call the process "writing a paper".
I agree with the point of the article though: code generation does not really work, the results are bloated and often wrong and people already had more features that they could absorb in 2020.
The solution to this mess is to have 18 year olds boycott studying computer science altogether, since the industry (and mediocre fellow "engineers") will treat them like human garbage.
That said, I’m also increasingly aware that puts me in a minority group. I got to see this first hand in a recent org where their codebase and product design hadn’t meaningfully evolved in nearly thirty years. NAT was a “game changer” to them - and one they refused to implement without tons of extraneous testing they would deliberately undermine, stall, and sabotage so they didn’t have to modernize their code accordingly. It was easier for the developers and stakeholders to preserve their own status quo rather than entertain alternatives, to the point of open hostility (name calling, insults, screaming, and a few threats) to anyone suggesting otherwise.
The human element has always been, and always will be the bottleneck. Stakeholders who don’t contribute updated or accurate datasets to automation systems, or who hold back development to preserve personal status and power, or who otherwise gum up the works on purpose to game their own careers.
That’s not to make the argument of “replace all humans with machines”, mind you. Just stating that an organization that incentivizes bad behavior will be slowed down versus ones that incentivize collaborative outcomes, and AI is just going to turbocharge that by removing the friction associated with code creation and shifting that elsewhere.
people, are part of a team focused on a goal, they work together because they believe in that the ship is worth riding on and will reach its destination,
the ship should carry food people want,
team decides what food will be consumed,
captain tries first the food,
if food is good and people want it, people buy more
> Jevons Paradox: when something gets cheaper, you tend to use more of it, not less.
That's a butchering of Jevons paradox. What's stated is not a paradox, but a very natural effect. Obviously usage of something goes up when it gets cheaper.
What Jevons paradox actually describes is the situation where usage of a resource becomes more efficient (which means less of it is needed for a given task), but still the total usage of that resource increases.